I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X 10937 109m 45m 14m 6.0 63m firefox-bin 3417 63076 7876 6756 1.0 53m evolution-alarm 3363 40332 7284 6228 0.9 32m eggcups 24745 37480 8176 6876 1.1 28m evolution-excha 3736 53272 29m 8660 3.9 22m gnome-terminal 3361 44404 21m 10m 2.9 21m nautilus 3357 39868 21m 10m 2.8 17m gnome-panel 4096 25460 7600 5960 1.0 17m gkrellm 3373 20488 3492 2944 0.5 16m gnome-vfs-daemo 3367 43608 26m 10m 3.4 16m rhn-applet-gui 3359 19904 6128 5316 0.8 13m gnome-volume-ma 3387 20904 8068 6696 1.0 12m clock-applet 3389 19456 6648 5696 0.9 12m notification-ar 3316 19080 7140 5960 0.9 11m gnome-settings- 3385 22304 10m 7576 1.4 11m mixer_applet2 3244 21508 9960 6868 1.3 11m gnome-session 4144 22476 10m 7456 1.4 11m wnck-applet 2587 12412 2364 1940 0.3 9.8m gdm-binary 2846 13220 3340 2728 0.4 9880 gdm-binary 3365 13812 4532 3920 0.6 9280 pam-panel-icon 3355 14768 7524 5984 1.0 7244 metacity 7182 10328 3436 2280 0.4 6892 sendmail 18501 11080 4248 1912 0.5 6832 cupsd
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
If so, I can't reconcile what I'm seeing. Free seems to support the summary lines.
total used free... Mem: 775708 764772 10936... -/+ buffers/cache: 326584 449124 Swap: 1572856 160 1572696
Cat of /proc/meminfo also seems to support the summary lines.
SwapTotal: 1572856 kB SwapFree: 1572696 kB
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Any help?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jun 05, 2006 at 06:45:10PM -0400, William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X 3359 19904 6128 5316 0.8 13m gnome-volume-ma
(...)
3355 14768 7524 5984 1.0 7244 metacity 7182 10328 3436 2280 0.4 6892 sendmail 18501 11080 4248 1912 0.5 6832 cupsd
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
If so, I can't reconcile what I'm seeing. Free seems to support the summary lines.
total used free...Mem: 775708 764772 10936... -/+ buffers/cache: 326584 449124 Swap: 1572856 160 1572696
Cat of /proc/meminfo also seems to support the summary lines.
SwapTotal: 1572856 kB SwapFree: 1572696 kB
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Any help?
I can see two possible explanations for this. Maybe both in conjunction.
One is that you get getting multiple entries for the same processes, but different threads. That used to be the way of it up until .. humm, not sure ... 2.4, I guess. Not sure exactly how it works these days. I would have to check.
The other is the overcommit kernel feature. It is possible the kernel is overcommiting memory, and thus showing more than it really in use.
One last thing possible (just thought about it) is that top is adding more than one namespace to those totals. Maybe shared memory (/dev/shm ?). Or any other possible namespace.
I agree it does seem odd, and I have seen this kind of stuff happening before. Once I started hunting it down, and found the reason for it. It was some time ago (2.2 ? 2.4 ? Not sure), so I'm reasonably sure it is not the same reason these days. But I hope I gave you are least some pointers for where to start looking.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Mon, 2006-06-05 at 20:02 -0300, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jun 05, 2006 at 06:45:10PM -0400, William L. Maltby wrote:
<snip>
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X 3359 19904 6128 5316 0.8 13m gnome-volume-ma
(...)
3355 14768 7524 5984 1.0 7244 metacity 7182 10328 3436 2280 0.4 6892 sendmail 18501 11080 4248 1912 0.5 6832 cupsd
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
<snip>
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Any help?
I can see two possible explanations for this. Maybe both in conjunction.
One is that you get getting multiple entries for the same processes, but different threads. That used to be the way of it up until .. humm, not sure ... 2.4, I guess. Not sure exactly how it works these days. I would have to check.
The other is the overcommit kernel feature. It is possible the kernel is overcommiting memory, and thus showing more than it really in use.
One last thing possible (just thought about it) is that top is adding more than one namespace to those totals. Maybe shared memory (/dev/shm ?). Or any other possible namespace.
I agree it does seem odd, and I have seen this kind of stuff happening before. Once I started hunting it down, and found the reason for it. It was some time ago (2.2 ? 2.4 ? Not sure), so I'm reasonably sure it is not the same reason these days. But I hope I gave you are least some pointers for where to start looking.
Would I be correct if I summarized as "Looks like a bug, and possibly a regression that you had seen before"? I think then I'll first start by seeing if there is an open bug somewhere. I hate having to chase code right now as I'm trying to improve my knowledge and use of sendmail, DNS, ... and a whole host of other things that flew by me over the years. <*sigh*>
Anyhow, thanks for getting back to me. I'm going to try to work investigation of this in with the other things I've got going.
Rodrigo Barbosa rodrigob@suespammers.org
<snip sig stuff>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jun 05, 2006 at 08:50:31PM -0400, William L. Maltby wrote:
I agree it does seem odd, and I have seen this kind of stuff happening before. Once I started hunting it down, and found the reason for it. It was some time ago (2.2 ? 2.4 ? Not sure), so I'm reasonably sure it is not the same reason these days. But I hope I gave you are least some pointers for where to start looking.
Would I be correct if I summarized as "Looks like a bug, and possibly a regression that you had seen before"?
Possible.
I think then I'll first start by seeing if there is an open bug somewhere. I hate having to chase code right now as I'm trying to improve my knowledge and use of sendmail, DNS, ... and a whole host of other things that flew by me over the years. <*sigh*>
Anyhow, thanks for getting back to me. I'm going to try to work investigation of this in with the other things I've got going.
Actually, there are 2 places I always start when searching for information on kernel issues:
1) http://www.kernelnewbies.org/ 2) The Linux Kernel Mailinglist Archives
The name of the first option is a bit misleading. One would expect only to find very basic information there. Actually, it is a training ground for kernel hackers, so there is plenty of juicy info there.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
William L. Maltby wrote on Mon, 05 Jun 2006 18:45:10 -0400:
24729 127m 32m 15m 4.3 94m evolution
It looks to me like top is using a different definition of swap. If you compare you see that SWAP shows the difference between VIRT and RES almost exactly. However, if there is no or almost no swap usage how can there be a difference? Only explanation: it shows what *could* be swapped immediately without affecting current activity. Have you tried making it heavily swap and then checked if you see a difference (whichever)? Theoretically, it shouldn't make a difference as it doesn't seem to differentiate between "swapped" and "really swapped".
Kai
Kai Schaetzl wrote:
William L. Maltby wrote on Mon, 05 Jun 2006 18:45:10 -0400:
24729 127m 32m 15m 4.3 94m evolution
It looks to me like top is using a different definition of swap. If you compare you see that SWAP shows the difference between VIRT and RES almost exactly. However, if there is no or almost no swap usage how can there be a difference? Only explanation: it shows what *could* be swapped immediately without affecting current activity. Have you tried making it heavily swap and then checked if you see a difference (whichever)? Theoretically, it shouldn't make a difference as it doesn't seem to differentiate between "swapped" and "really swapped".
Kai
Kai,
I think you hit the nail on the head. According to man ps, the swap size shown by ps is exactly what you say.. the amount of memory it would take if the process were swapped out.
On Mon, 2006-06-05 at 19:55 -0400, Sam Drinkard wrote:
Kai Schaetzl wrote:
William L. Maltby wrote on Mon, 05 Jun 2006 18:45:10 -0400:
24729 127m 32m 15m 4.3 94m evolution
It looks to me like top is using a different definition of swap. If you compare you see that SWAP shows the difference between VIRT and RES almost exactly. However, if there is no or almost no swap usage how can there be a difference? Only explanation: it shows what *could* be swapped immediately without affecting current activity. Have you tried making it heavily swap and then checked if you see a difference (whichever)? Theoretically, it shouldn't make a difference as it doesn't seem to differentiate between "swapped" and "really swapped".
Kai
Kai,
I think you hit the nail on the head. According to man ps, the swapsize shown by ps is exactly what you say.. the amount of memory it would take if the process were swapped out.
Sam and Kai, it sure sounds plausible. One of the great programming productivity gains made was "re-use of code", and not just by calling a module. It could also include physically copying code. Either way, Kai makes it sound as if top might be using the same code fragment as ps uses to report swap.
If this were a democracy, Kai's theory wins! ;-)
<snip sig stuff>
Sam Drinkard wrote on Mon, 05 Jun 2006 19:55:09 -0400:
According to man ps
Ah, I read man top and was wondering where they got definitions ... :-)
Kai
Kai Schaetzl wrote:
Sam Drinkard wrote on Mon, 05 Jun 2006 19:55:09 -0400:
According to man ps
Ah, I read man top and was wondering where they got definitions ... :-)
Kai
Doing more reading and such, but haven't really gleaned much more info, but I do have another question. According to ps, processes that are swapped out to disk are shown by brackets. That being the case, when I turn swap off and do a ps, I still see a lot of programs (insead of processes, per man ps) that are bracketed. Given there is no swap, I wonder why ps reports them as being swapped out? The behavior with swappiness set to 0 is OK, but this morning when I looked at things, I see where during the night, swap usage went from 2.2 mb to 221 mb., and I assume due to the nightly cron jobs, i.e., slocate, updatedb, etc. The actual processes I'm concerned about run during the time period that the cron jobs run too, so maybe the machine did at some point, hit OOM state, but hard to say without being here to look.
So, back to the question ... is ps man page wrong or have I read something into the text that I am mis interpreting?
Sam
On Tue, 2006-06-06 at 13:20 -0400, Sam Drinkard wrote:
Kai Schaetzl wrote:
Sam Drinkard wrote on Mon, 05 Jun 2006 19:55:09 -0400:
<snip>
... with swappiness set to 0 is OK, but this morning when I looked at things, I see where during the night, swap usage went from 2.2 mb to 221 mb., and I assume due to the nightly cron jobs, i.e., slocate, updatedb, etc. The actual processes I'm concerned about run during the time period that the cron jobs run too, so maybe the machine did at some point, hit OOM state, but hard to say without being here to look.
So, back to the question ... is ps man page wrong or have I read something into the text that I am mis interpreting?
Regardless of that, it sounds like your situation indicates a need to run SAR. Turn on your system accounting collection and the reports will let you see exactly what's happening with memory, swap, HD, ... and when. I presume that these are as good or better than the old UNIX ones I remember.
Once you have the bullets, I'm not sure what you might shoot, but you ought to kill *something* just for the aggravation you've been caused! ;-)
Sam
<snip sig stuff>
William L. Maltby wrote:
Regardless of that, it sounds like your situation indicates a need to run SAR. Turn on your system accounting collection and the reports will let you see exactly what's happening with memory, swap, HD, ... and when. I presume that these are as good or better than the old UNIX ones I remember.
Once you have the bullets, I'm not sure what you might shoot, but you ought to kill *something* just for the aggravation you've been caused! ;-)
Bill,
After running sar, I'm not sure I'm confused as I was. I tend to think sar might be correct in what it records and sees. Looking at memory usage and swap, I find the system *is* using all of the available memory, especially at 0420, most likely when the updatedb and slocate crons run. % memory used is averaging 94.26% and swap peaked at about 21%, which sort of relates to the 221mb shown by free this morning. When the machine is quiescent as it gets, mem usage drops to 72% and swap drops to 0.20 %, again, which corresponds with what is reported by free and the system monitor applet. To make a long story short, the machine apparetly does need the swap at times, and while it's not using much during model run time, the cron jobs do turn it loose!
Sar can report *alot* of things, and I suspect I'll be using it more to see if there is anything I can do to tweak the thing to get a bit more performance out of it. Bad enough that it takes so long for my jobs to run, but the number crunching the model does IS pretty tough on things I suppose. Guess we've beat up the swap thing enough.. I'll try to learn more about how to use the additional info at my disposal now.
Sam
On Tue, 2006-06-06 at 14:46 -0400, Sam Drinkard wrote:
William L. Maltby wrote:
<snip>
After running sar, I'm not sure I'm confused as I was. I tend to think sar might be correct in what it records and sees. Looking at memory usage and swap, I find the system *is* using all of the available memory, especially at 0420, most likely when the updatedb and slocate crons run.<snip>
I'll suggest this as an interim workaround. Separate the times for any updatedb, slocate, makewhatis, ... by 10 or 15 minute intervals. The combination of reduced run time due to reduced contention might have them all done near the same ending time as before and may avoid going into swap (even if it's not a big slow down, why do it if no need?) and may very likely ameliorate any observable adverse effects.
If that works, add "nice" to them, cautiously if there are completion "deadlines", which will reduce the effects even further of the maintenance jobs. If there's no completion deadline of consequence a BIG nice value can be used.
If you haven't tried removing the readahead and readahead_early... I've not investigated, but I'm three days into my machine which had locked in the past and still showing only 160 swap use, via free. My thinking is: 1) Linux offers a way to lock pages in memory or processes (UNIX sticky bit) so they won't swap; 2) Readahead locks them (WARNING! No investigation here, pure conjecture); 3) Squeezes other things out of memory; 4) regardless, I disabled those startups on my *workstation* and see no change in behavior; 5) if that's the same for you, why do useless tasks?
<snip>
To make a long story short, the machine apparetly does need the swap at times, and while it's not using much during model run time, the cron jobs do turn it loose!
That's not surprising, given your references to a "weather model"? It's nice to know that the VM does most of what it's supposed to do *right*.
Sar can report *alot* of things, and I suspect I'll be using it more to see if there is anything I can do to tweak the thing to get a bit more performance out of it. Bad enough that it takes so long for my jobs to run, but the number crunching the model does IS pretty tough on things I suppose. Guess we've beat up the swap thing enough.. I'll try to learn more about how to use the additional info at my disposal now.
Another thing to look at. My last contract at IBM (2.2/2.4 days) I found a lot of kernel params that can be set, along the lines of swappiness, that can be used to help meet special needs. I had to use a few of them. Anyway, there may be some left in this kernel. If you get into the kernel docs, they're probably listed, even if not well publicized.
:-} Then you can publish them on this list and let me be lazy in my
(semi-)retirement!
Sam
<snip sig stuff>
HTH
On Mon, 2006-06-05 at 18:34, Kai Schaetzl wrote:
24729 127m 32m 15m 4.3 94m evolution
It looks to me like top is using a different definition of swap. If you compare you see that SWAP shows the difference between VIRT and RES almost exactly. However, if there is no or almost no swap usage how can there be a difference? Only explanation: it shows what *could* be swapped immediately without affecting current activity.
I think what it means is that the virtual memory page table space has been allocated but the page hasn't been accessed yet.
Have you tried making it heavily swap and then checked if you see a difference (whichever)? Theoretically, it shouldn't make a difference as it doesn't seem to differentiate between "swapped" and "really swapped".
How about 'not paged in yet'?
Les Mikesell wrote on Mon, 05 Jun 2006 21:14:33 -0500:
How about 'not paged in yet'?
Or "never swapped" ;-) At least I never see my machine swapping, unless I'm tarring up big directories or something, although they have only moderate memory. With a swappiness of 100 the SWAP in top should then still show the same figure, but the actual usage of the swap file shown with free should have increased by (largely) that value?
Kai
On Mon, 2006-06-05 at 18:45 -0400, William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X
[...]
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
If so, I can't reconcile what I'm seeing. Free seems to support the summary lines.
total used free...Mem: 775708 764772 10936... -/+ buffers/cache: 326584 449124 Swap: 1572856 160 1572696
Cat of /proc/meminfo also seems to support the summary lines.
SwapTotal: 1572856 kB SwapFree: 1572696 kB
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Executables aren't copied into swap - virtual memory is allocated but they page in on demand directly from the binary file. So there really are megs that could swap in if other portions of those programs are executed even though it isn't in the swap partition you designated.
On Mon, 2006-06-05 at 18:52 -0500, Les Mikesell wrote:
On Mon, 2006-06-05 at 18:45 -0400, William L. Maltby wrote:
<snip>
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Executables aren't copied into swap - virtual memory is allocated but they page in on demand directly from the binary file. So there really are megs that could swap in if other portions of those programs are executed even though it isn't in the swap partition you designated.
Just to make sure I'm following here. There are still 3 types of program segments: text, data and bss. Text (and data) never need to be swapped because they are (theoretically) never modified. Bss may need to be swapped. Are you saying that what it is showing is what is potentially available if all swappable memory is swapped out and the "binary" is also discarded (maintaining only a small stack of program counters and other stack data)?
If so, it sounds in agreement with what Kai has suggested?
If that is the case, maybe there is nothing to track down? Everything is operating as intended and it is only that no one has bothered to make it perfectly clear to the user(s), like me?
On Mon, 2006-06-05 at 20:13, William L. Maltby wrote:
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Executables aren't copied into swap - virtual memory is allocated but they page in on demand directly from the binary file. So there really are megs that could swap in if other portions of those programs are executed even though it isn't in the swap partition you designated.
Just to make sure I'm following here. There are still 3 types of program segments: text, data and bss. Text (and data) never need to be swapped because they are (theoretically) never modified. Bss may need to be swapped. Are you saying that what it is showing is what is potentially available if all swappable memory is swapped out and the "binary" is also discarded (maintaining only a small stack of program counters and other stack data)?
It's paged on demand. Instead of thinking about memory being swapped out, think about it never being read from disk into memory until the memory that is supposed to hold it is accessed.
When you start executing a program you only need to load the first block - the rest is loaded on the memory faults from accessing uninitialized virtual memory. Now, just to make things more fun, remember that every shared library as well as the main executable gets it's own text, data, and bss segments, but every instance loaded from the same inode (so hardlinks count) share the same real memory copy of text and data, and fork()'d processes also start out sharing .bss in copy-on-write mode.
If so, it sounds in agreement with what Kai has suggested?
If that is the case, maybe there is nothing to track down? Everything is operating as intended and it is only that no one has bothered to make it perfectly clear to the user(s), like me?
It's sort of like trying to compute disk usage when you have a lot of sparse and hard-linked files. If you add up the individual items it won't match the total space on the disk. It's all done with smoke and mirrors.
Les Mikesell wrote on Mon, 05 Jun 2006 21:29:52 -0500:
It's paged on demand. Instead of thinking about memory being swapped out, think about it never being read from disk into memory until the memory that is supposed to hold it is accessed.
"never being read from disk" implies that there was something written to the disk first. In that case the swap usage figure from top or free would be wrong, wouldn't it?
Kai
On Tue, 2006-06-06 at 07:31, Kai Schaetzl wrote:
Les Mikesell wrote on Mon, 05 Jun 2006 21:29:52 -0500:
It's paged on demand. Instead of thinking about memory being swapped out, think about it never being read from disk into memory until the memory that is supposed to hold it is accessed.
"never being read from disk" implies that there was something written to the disk first. In that case the swap usage figure from top or free would be wrong, wouldn't it?
The executable and it's libraries were written to disk a long time ago. When you start to execute it, the virtual memory is allocated but the disk contents aren't loaded into memory until there is an access to the virtual page. In very old versions of unix, executables were actually copied into swap but now they just page in directly from their own disk file and never need to be written back out. From the virtual memory perspective it is just a matter of which disk block needs to be loaded to initialize the memory page if something ever accesses it.
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X 10937 109m 45m 14m 6.0 63m firefox-bin 3417 63076 7876 6756 1.0 53m evolution-alarm 3363 40332 7284 6228 0.9 32m eggcups 24745 37480 8176 6876 1.1 28m evolution-excha 3736 53272 29m 8660 3.9 22m gnome-terminal 3361 44404 21m 10m 2.9 21m nautilus 3357 39868 21m 10m 2.8 17m gnome-panel 4096 25460 7600 5960 1.0 17m gkrellm 3373 20488 3492 2944 0.5 16m gnome-vfs-daemo 3367 43608 26m 10m 3.4 16m rhn-applet-gui 3359 19904 6128 5316 0.8 13m gnome-volume-ma 3387 20904 8068 6696 1.0 12m clock-applet 3389 19456 6648 5696 0.9 12m notification-ar 3316 19080 7140 5960 0.9 11m gnome-settings- 3385 22304 10m 7576 1.4 11m mixer_applet2 3244 21508 9960 6868 1.3 11m gnome-session 4144 22476 10m 7456 1.4 11m wnck-applet 2587 12412 2364 1940 0.3 9.8m gdm-binary 2846 13220 3340 2728 0.4 9880 gdm-binary 3365 13812 4532 3920 0.6 9280 pam-panel-icon 3355 14768 7524 5984 1.0 7244 metacity 7182 10328 3436 2280 0.4 6892 sendmail 18501 11080 4248 1912 0.5 6832 cupsd
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
If so, I can't reconcile what I'm seeing. Free seems to support the summary lines.
total used free...Mem: 775708 764772 10936... -/+ buffers/cache: 326584 449124 Swap: 1572856 160 1572696
Cat of /proc/meminfo also seems to support the summary lines.
SwapTotal: 1572856 kB SwapFree: 1572696 kB
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Any help?
Looked at the same top info, and I don't understand what I see either. With processes running, I'm seeing close to 500mb of stuff swapped out, but according to free, only the 2.2 mb is swapped. There's gotta be more to this than meets the eye, or something is lying about the swap. The system monitor also shows only 2.2mb of swap in use, so where is top getting this 500+ mb of swap data from?
On Mon, 2006-06-05 at 19:52 -0400, Sam Drinkard wrote:
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data-
<snip>
Now, if I treat all those numbers ending in "m" as megabytes, it doesn't take long to see that I've been lied to somewhere along the way. Or alternatively, I'm dense and "Just Don't Get It" (TM).
Any help?
Looked at the same top info, and I don't understand what I see either. With processes running, I'm seeing close to 500mb of stuff swapped out, but according to free, only the 2.2 mb is swapped. There's gotta be more to this than meets the eye, or something is lying about the swap. The system monitor also shows only 2.2mb of swap in use, so where is top getting this 500+ mb of swap data from?
I suspect Kai and Les have hit on it. I first thought it sounded like a bug, now it may be only a "bug" in documentation not telling it like it is.
<snip sig stuff>
I'll tell you one theory I had earlier today. What if the summary line was reporting "pages" swapped? At 4K/page time 160,000 it cam awful close to matching the total of all the individual entries under the "SWAP" column. I had though I was onto something. If someone's on an arch with other than 4K page size, ...
It was tempting, yes it was. Fortunately, I decided to *ask* rather than *propose*. So I seem only half as much and idiot as I might have seemed (I hope)!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jun 05, 2006 at 09:20:14PM -0400, William L. Maltby wrote:
Looked at the same top info, and I don't understand what I see either. With processes running, I'm seeing close to 500mb of stuff swapped out, but according to free, only the 2.2 mb is swapped. There's gotta be more to this than meets the eye, or something is lying about the swap. The system monitor also shows only 2.2mb of swap in use, so where is top getting this 500+ mb of swap data from?
I suspect Kai and Les have hit on it. I first thought it sounded like a bug, now it may be only a "bug" in documentation not telling it like it is.
<snip sig stuff>
I'll tell you one theory I had earlier today. What if the summary line was reporting "pages" swapped? At 4K/page time 160,000 it cam awful close to matching the total of all the individual entries under the "SWAP" column. I had though I was onto something. If someone's on an arch with other than 4K page size, ...
It was tempting, yes it was. Fortunately, I decided to *ask* rather than *propose*. So I seem only half as much and idiot as I might have seemed (I hope)!
Both theories sound very plausible to me. But since I never heard of any userspace program using "pages" as a unit, I'm tending more toward the one Kai and Les proposed. Not entirely discarting yours, tho.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Sam Drinkard wrote:
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
As normal, while looking at one thing, something else bites my butt. I tuned on the swap field in top and sort on it. Here's an edited snippet of the results.
Mem: 775708k total, 764752k used, 10956k free, 60780k buffers Swap: 1572856k total, 160k used, 1572696k free, 377324k cached
PID VIRT RES SHR %MEM SWAP COMMAND 24729 127m 32m 15m 4.3 94m evolution 3409 97220 5268 4304 0.7 89m evolution-data- 2851 115m 36m 7120 4.8 79m X 10937 109m 45m 14m 6.0 63m firefox-bin 3417 63076 7876 6756 1.0 53m evolution-alarm 3363 40332 7284 6228 0.9 32m eggcups 24745 37480 8176 6876 1.1 28m evolution-excha 3736 53272 29m 8660 3.9 22m gnome-terminal 3361 44404 21m 10m 2.9 21m nautilus 3357 39868 21m 10m 2.8 17m gnome-panel 4096 25460 7600 5960 1.0 17m gkrellm 3373 20488 3492 2944 0.5 16m gnome-vfs-daemo 3367 43608 26m 10m 3.4 16m rhn-applet-gui 3359 19904 6128 5316 0.8 13m gnome-volume-ma 3387 20904 8068 6696 1.0 12m clock-applet 3389 19456 6648 5696 0.9 12m notification-ar 3316 19080 7140 5960 0.9 11m gnome-settings- 3385 22304 10m 7576 1.4 11m mixer_applet2 3244 21508 9960 6868 1.3 11m gnome-session 4144 22476 10m 7456 1.4 11m wnck-applet 2587 12412 2364 1940 0.3 9.8m gdm-binary 2846 13220 3340 2728 0.4 9880 gdm-binary 3365 13812 4532 3920 0.6 9280 pam-panel-icon 3355 14768 7524 5984 1.0 7244 metacity 7182 10328 3436 2280 0.4 6892 sendmail 18501 11080 4248 1912 0.5 6832 cupsd
Note that the summary line says 160k of swap is used. The man pages say the summary and the details under "SWAP" are both reported in "k". No mention of "m" is made, I presume that it means "megabytes"?
If so, I can't reconcile what I'm seeing. Free seems to support the summary lines.
total used free...Mem: 775708 764772 10936... -/+ buffers/cache: 326584 449124 Swap: 1572856 160 1572696
Cat of /proc/meminfo also seems to support the summary lines.
SwapTotal: 1572856 kB SwapFree: 1572696 kB
Looked at the same top info, and I don't understand what I see either. With processes running, I'm seeing close to 500mb of stuff swapped out, but according to free, only the 2.2 mb is swapped. There's gotta be more to this than meets the eye, or something is lying about the swap. The system monitor also shows only 2.2mb of swap in use, so where is top getting this 500+ mb of swap data from?
most of the 'swapped' data is probably sitting in the cache or buffers?
Here is an example:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=129064
On Tue, 2006-06-06 at 13:45 +0800, Feizhou wrote:
Sam Drinkard wrote:
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
<snip>
most of the 'swapped' data is probably sitting in the cache or buffers?
Here is an example:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=129064
Thanks to the patience and efforts of all, Rodrigo, Les, Sam, Feizhou ... I think I've got a handle on this thing.
The only mistake was turning on "SWAP" in top.
I can see difficulty in programming to get a *meaningful* swap figure: that is, one that represents either real swapped memory, or its current needs or its potential maximum need. That assumes one can make the decision as to which to show.
Others already show (apparently) current swap (free, top's summary lines), so what could one put under the "SWAP" column? I now think that it was the maximum possible swap needed for each process, as you all suggested.
Text shared from program segments and libraries, shared data, buffers, cache, parts already swapped, parts marked for swap but not committed yet,... What would show under the "swap top"? From a programming POV, showing anything but the virtual memory use could be complex and have a tight coupling to the VM implementation details, increasing maintenance for a little used data column too.
I am comfortable that "SWAP" only shows the simplest to obtain value and the only problem is that a better explanation is could be provided in the man pages for top.
<snip sig stuff>
And we do know that a fix for the lock up in Sam's and my machine is apparently in the pipeline for U4.
William L. Maltby wrote:
On Tue, 2006-06-06 at 13:45 +0800, Feizhou wrote:
Sam Drinkard wrote:
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
<snip>
most of the 'swapped' data is probably sitting in the cache or buffers?
Here is an example:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=129064
Thanks to the patience and efforts of all, Rodrigo, Les, Sam, Feizhou ... I think I've got a handle on this thing.
The only mistake was turning on "SWAP" in top.
I can see difficulty in programming to get a *meaningful* swap figure: that is, one that represents either real swapped memory, or its current needs or its potential maximum need. That assumes one can make the decision as to which to show.
Others already show (apparently) current swap (free, top's summary lines), so what could one put under the "SWAP" column? I now think that it was the maximum possible swap needed for each process, as you all suggested.
:)
Text shared from program segments and libraries, shared data, buffers, cache, parts already swapped, parts marked for swap but not committed yet,... What would show under the "swap top"? From a programming POV, showing anything but the virtual memory use could be complex and have a tight coupling to the VM implementation details, increasing maintenance for a little used data column too.
I am comfortable that "SWAP" only shows the simplest to obtain value and the only problem is that a better explanation is could be provided in the man pages for top.
Eh? I thought that problem kind of exists for all man pages!
<snip sig stuff>
And we do know that a fix for the lock up in Sam's and my machine is apparently in the pipeline for U4.
If I was a paying customer....
On Wed, 2006-06-07 at 10:37 +0800, Feizhou wrote:
William L. Maltby wrote:
On Tue, 2006-06-06 at 13:45 +0800, Feizhou wrote:
Sam Drinkard wrote:
William L. Maltby wrote:
<snip>
I am comfortable that "SWAP" only shows the simplest to obtain value and the only problem is that a better explanation is could be provided in the man pages for top.
Eh? I thought that problem kind of exists for all man pages!
LOL! 7:10 A.M. still working my first cup of coffee and you made me laugh already!. Good man, good man! I hope all of your day(s) go as well as this minute did for me. :-))
<snip through sig stuff>
Thanks for starting my day right!
LOL! 7:10 A.M. still working my first cup of coffee and you made me laugh already!. Good man, good man! I hope all of your day(s) go as well as this minute did for me. :-))
glad to be of service ;)
<snip through sig stuff>
Thanks for starting my day right!
and mine :)
Feizhou spake the following on 6/6/2006 7:37 PM:
William L. Maltby wrote:
On Tue, 2006-06-06 at 13:45 +0800, Feizhou wrote:
Sam Drinkard wrote:
William L. Maltby wrote:
I need to look more into it, but before I start the long and arduous "googling my life away" process, I figured someone might know the answer. I've read the man pages several times and they didn't change! :-(
<snip>
most of the 'swapped' data is probably sitting in the cache or buffers?
Here is an example:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=129064
Thanks to the patience and efforts of all, Rodrigo, Les, Sam, Feizhou ... I think I've got a handle on this thing.
The only mistake was turning on "SWAP" in top.
I can see difficulty in programming to get a *meaningful* swap figure: that is, one that represents either real swapped memory, or its current needs or its potential maximum need. That assumes one can make the decision as to which to show.
Others already show (apparently) current swap (free, top's summary lines), so what could one put under the "SWAP" column? I now think that it was the maximum possible swap needed for each process, as you all suggested.
:)
Text shared from program segments and libraries, shared data, buffers, cache, parts already swapped, parts marked for swap but not committed yet,... What would show under the "swap top"? From a programming POV, showing anything but the virtual memory use could be complex and have a tight coupling to the VM implementation details, increasing maintenance for a little used data column too.
I am comfortable that "SWAP" only shows the simplest to obtain value and the only problem is that a better explanation is could be provided in the man pages for top.
Eh? I thought that problem kind of exists for all man pages!
<snip sig stuff>
And we do know that a fix for the lock up in Sam's and my machine is apparently in the pipeline for U4.
If I was a paying customer....
When upstream opens the floodgates of patches, CentOS will have them within a week, usually less, depending on if they break something.
And we do know that a fix for the lock up in Sam's and my machine is apparently in the pipeline for U4.
If I was a paying customer....
When upstream opens the floodgates of patches, CentOS will have them within a week, usually less, depending on if they break something.
Yes but geez...RH making its customers wait for a troublesome performance degradation fix...
-
Feizhou -
Kai Schaetzl -
Les Mikesell -
Rodrigo Barbosa -
Sam Drinkard -
Scott Silva -
William L. Maltby