As by the time, I've learned that Linux works by caching apps by using a lot of RAM and then it reallocates the new stuff by cleaning the old cached pages from memory as compared to other OSs. With 2 gigs of RAM often I see the free memory only as 100-400MB. Using TOP or PS, it doesn't look like any program or process is using excessive memory (the highest process is seen with 1-2% total memory). *So, my questions are:*
what programs are using that much of memory? (or cached memory) Is that really due to a lot of cache in the memory *if yes, then, is there a way to parse the cache to findout what applications are eating up the cache?* *how to free the cached memory?*
*Currently, here are the details:*
Top two high mem processes only using 2.6% of RAM.
[root@Ether ~]# ps aux | sort -nrk4 | head -2 abbask 5922 0.0 1.4 364300 28312 ? S Aug19 0:00 /usr/bin/python -E /usr/bin/sealert -s ntop 4914 0.0 1.2 332752 24760 ? Ssl Aug19 0:00 ntop -d -L @/etc/ntop.conf
[root@Ether ~]# head -5 /proc/meminfo MemTotal: 1913856 kB MemFree: 500612 kB Buffers: 169720 kB Cached: 751000 kB SwapCached: 0 kB
[root@Ether ~]# free -m total used free shared buffers cached Mem: 1869 1380 488 0 165 733 -/+ buffers/cache: 480 1388 Swap: 1983 0 1983
*Total percentage memory for all the processes, being used is 15.5% only.
*[root@Ether ~]# ps aux | awk '{print $4}' | grep [0-9] | tr -s "\n" "+" | awk '{print $1 0 }' | bc 15.5*
*
On Tue, August 19, 2008 11:31, ABBAS KHAN wrote:
As by the time, I've learned that Linux works by caching apps by using a lot of RAM and then it reallocates the new stuff by cleaning the old cached pages from memory as compared to other OSs. With 2 gigs of RAM often I see the free memory only as 100-400MB. Using TOP or PS, it doesn't look like any program or process is using excessive memory (the highest process is seen with 1-2% total memory). *So, my questions are:*
what programs are using that much of memory? (or cached memory)
It's very likely being used as disk cache. You can get some more numbers by running top, and looking at the last two lines of the headers. I routinely see over 1GB of cache on a not very active 4GB system. Your meminfo output is the same numbers, and looks completely normal to me.
Free memory is *bad*; it means it's being wasted completely. Memory used for disk caching is instantly available if it's suddenly needed for a program.
Is that really due to a lot of cache in the memory *if yes, then, is there a way to parse the cache to findout what applications are eating up the cache?*
It's only indirectly tied to an application; it's cached disk blocks. You could say the process that read that file last is responsible, but the *next* process to read those blocks is the one that would benefit.
*how to free the cached memory?*
Why do you want to? As I said, "free" memory is memory that's going to waste. Unless you have severe real-time issues with a process becoming runnable where the difference between discarding a clean cached page, and just allocating a free page, will make a difference, there's no point. If you DO have that level really extreme real-time performance issues, you need to understand the whole virtual memory system an order of magnitude better than you seem to. That's off in a far corner of the Linux application space -- Linux can do some real-time stuff, but it's not the first choice for hard real-time environments last time I talked to any of those people.
An awesome reply. Makes sense!
Thanks.
On Tue, Aug 19, 2008 at 9:42 AM, David Dyer-Bennet dd-b@dd-b.net wrote:
On Tue, August 19, 2008 11:31, ABBAS KHAN wrote:
As by the time, I've learned that Linux works by caching apps by using a lot of RAM and then it reallocates the new stuff by cleaning the old cached pages from memory as compared to other OSs. With 2 gigs of RAM often I
see
the free memory only as 100-400MB. Using TOP or PS, it doesn't look like any program or process is using excessive memory (the highest process is seen with 1-2% total memory). *So, my questions are:*
what programs are using that much of memory? (or cached memory)
It's very likely being used as disk cache. You can get some more numbers by running top, and looking at the last two lines of the headers. I routinely see over 1GB of cache on a not very active 4GB system. Your meminfo output is the same numbers, and looks completely normal to me.
Free memory is *bad*; it means it's being wasted completely. Memory used for disk caching is instantly available if it's suddenly needed for a program.
Is that really due to a lot of cache in the memory *if yes, then, is there a way to parse the cache to findout what applications are eating up the cache?*
It's only indirectly tied to an application; it's cached disk blocks. You could say the process that read that file last is responsible, but the *next* process to read those blocks is the one that would benefit.
*how to free the cached memory?*
Why do you want to? As I said, "free" memory is memory that's going to waste. Unless you have severe real-time issues with a process becoming runnable where the difference between discarding a clean cached page, and just allocating a free page, will make a difference, there's no point. If you DO have that level really extreme real-time performance issues, you need to understand the whole virtual memory system an order of magnitude better than you seem to. That's off in a far corner of the Linux application space -- Linux can do some real-time stuff, but it's not the first choice for hard real-time environments last time I talked to any of those people.
-- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
on 8-19-2008 9:31 AM ABBAS KHAN spake the following:
As by the time, I've learned that Linux works by caching apps by using a lot of RAM and then it reallocates the new stuff by cleaning the old cached pages from memory as compared to other OSs. With 2 gigs of RAM often I see the free memory only as 100-400MB. Using TOP or PS, it doesn't look like any program or process is using excessive memory (the highest process is seen with 1-2% total memory). *So, my questions are:*
what programs are using that much of memory? (or cached memory) Is that really due to a lot of cache in the memory /*if yes, then, is there a way to parse the cache to findout what applications are eating up the cache?*/ /*how to free the cached memory?*/
Why do you need to free the cached memory? That is just how linux works. Having frequently accessed files in the cache more than offsets the time it takes to release the old pages. Trying to have a bunch of free memory will only make your system slower as it has to read all that data from DASD instead of ram. (I just dated myself with the DASD comment)
On Tue, August 19, 2008 11:43, Scott Silva wrote:
(I just dated myself with the DASD comment)
And branded.
I don't recall that anybody referred to "DASD" connected to our IBM 1401; it was just "disk". Were we just a weird corner (I wouldn't swear they didn't use some weird term like DASD in the manuals, just that none of the people I worked with used it)? Or was that a later term, say from the 360 generation?
(When I worked on the 1401, we were in fact well into the 360 generation chronologically, just not at the place I was working; that was in 1969, and we moved from the 1401 to a DEC PDP-11/20 just a couple of years after that.)
On Tue, 2008-08-19 at 11:50 -0500, David Dyer-Bennet wrote:
On Tue, August 19, 2008 11:43, Scott Silva wrote:
(I just dated myself with the DASD comment)
Quit that! Get a girl friend or something! ;-)
And branded.
I don't recall that anybody referred to "DASD" connected to our IBM 1401; it was just "disk". Were we just a weird corner (I wouldn't swear they didn't use some weird term like DASD in the manuals, just that none of the people I worked with used it)? Or was that a later term, say from the 360 generation?
(When I worked on the 1401, we were in fact well into the 360 generation chronologically, just not at the place I was working; that was in 1969, and we moved from the 1401 to a DEC PDP-11/20 just a couple of years after that.)
Ditto here. But our 1401 stuff was being emulated on S360/30. During that time, DASD became the lazy acronym used extensively to cover any of the then-extant direct-access devices (drums, cylinders, "disks" - euphemistically mounted in "pizza ovens (2314/19 IIRC).
On Tue, 2008-08-19 at 13:06 -0400, William L. Maltby wrote:
<snip> that time, DASD became the lazy acronym used extensively to cover any of the then-extant direct-access devices (drums, cylinders, "disks" - euphemistically mounted in "pizza ovens (2314/19 IIRC).
Hmmm... 2311 sticks in my mind too! Oh well, time to
BALR 14
On Tue, Aug 19, 2008 at 10:06 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Tue, 2008-08-19 at 11:50 -0500, David Dyer-Bennet wrote:
On Tue, August 19, 2008 11:43, Scott Silva wrote:
(I just dated myself with the DASD comment)
Quit that! Get a girl friend or something! ;-)
Hey, he should be glad his numbers go that high!
(My office mate just said that.... ;^)
I had to think about what DASD stands for, and I've been around for a while. Besides, nowadays there are DASDs other than disk....
mhr
On Tue, August 19, 2008 12:06, William L. Maltby wrote:
On Tue, 2008-08-19 at 11:50 -0500, David Dyer-Bennet wrote:
I don't recall that anybody referred to "DASD" connected to our IBM 1401; it was just "disk". Were we just a weird corner (I wouldn't swear they didn't use some weird term like DASD in the manuals, just that none of the people I worked with used it)? Or was that a later term, say from the 360 generation?
(When I worked on the 1401, we were in fact well into the 360 generation chronologically, just not at the place I was working; that was in 1969, and we moved from the 1401 to a DEC PDP-11/20 just a couple of years after that.)
Ditto here. But our 1401 stuff was being emulated on S360/30. During that time, DASD became the lazy acronym used extensively to cover any of the then-extant direct-access devices (drums, cylinders, "disks" - euphemistically mounted in "pizza ovens (2314/19 IIRC).
We emulated the 1401 on the DEC 11/20 for a while, first with a standalone emulator, later with a run-time system that integrated into RSTS and let us run the 1401 applications under time-sharing.
I think of drums as being generally *before* then, and what are cylinders that differs from drums? But it *does* actually make sense to have a generic term for that class of storage; we just didn't have enough examples to need it, and "DASD" sounds stupid :-), and as an IBM mainframe term wasn't something we wanted to emulate.
I suppose we're getting a bit far off-topic, but thanks for the stroll down memory lane!
LOL ! I got that fellows :D
But, I guess, computer geeks don't usually have girl friends and the same I do!! Unfortunately :(
LOL
On Wed, Aug 20, 2008 at 1:37 AM, David Dyer-Bennet dd-b@dd-b.net wrote:
On Tue, August 19, 2008 12:06, William L. Maltby wrote:
On Tue, 2008-08-19 at 11:50 -0500, David Dyer-Bennet wrote:
I don't recall that anybody referred to "DASD" connected to our IBM 1401; it was just "disk". Were we just a weird corner (I wouldn't swear they didn't use some weird term like DASD in the manuals, just that none of the people I worked with used it)? Or was that a later term, say from the 360 generation?
(When I worked on the 1401, we were in fact well into the 360 generation chronologically, just not at the place I was working; that was in 1969, and we moved from the 1401 to a DEC PDP-11/20 just a couple of years after that.)
Ditto here. But our 1401 stuff was being emulated on S360/30. During that time, DASD became the lazy acronym used extensively to cover any of the then-extant direct-access devices (drums, cylinders, "disks" - euphemistically mounted in "pizza ovens (2314/19 IIRC).
We emulated the 1401 on the DEC 11/20 for a while, first with a standalone emulator, later with a run-time system that integrated into RSTS and let us run the 1401 applications under time-sharing.
I think of drums as being generally *before* then, and what are cylinders that differs from drums? But it *does* actually make sense to have a generic term for that class of storage; we just didn't have enough examples to need it, and "DASD" sounds stupid :-), and as an IBM mainframe term wasn't something we wanted to emulate.
I suppose we're getting a bit far off-topic, but thanks for the stroll down memory lane! -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
ABBAS KHAN -
David Dyer-Bennet -
MHR -
Scott Silva -
William L. Maltby