OT - what is top telling me?
Mem: 1036588k total, 1008564k used, 28024k free, 68k buffers Swap: 1000432k total, 40k used, 1000392k free, 704392k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26666 root 17 0 261m 69m 69m R 2.2 6.9 0:00.07 crm114 26662 root 18 0 213m 38m 37m R 1.2 3.8 0:00.04 crm114 25807 bulwark 14 -2 27624 23m 1728 S 44.9 2.3 0:42.08 spamd 26048 bulwark 15 -2 27136 23m 1724 S 21.5 2.3 0:24.76 spamd 26155 bulwark 14 -2 27096 23m 1724 S 0.0 2.3 0:11.69 spamd 26333 bulwark 14 -2 26444 22m 1716 S 0.0 2.2 0:01.34 spamd 14541 root 13 -2 25312 22m 2232 S 0.6 2.2 4:56.24 spamd 31322 per 15 0 34264 21m 15m R 1.2 2.2 19:29.32 konsole 26625 bulwark 15 -2 25312 21m 992 S 0.0 2.1 0:00.00 spamd 10186 root 15 0 56944 12m 1092 S 4.7 1.2 48:13.30 ibwd 31353 per 16 0 27672 10m 8652 S 0.0 1.0 0:04.06 kded 31351 per 15 0 23768 7540 6420 S 0.0 0.7 0:00.03 klauncher 31346 per 16 0 23916 6624 5440 S 0.0 0.6 0:00.03 kdeinit 31349 per 15 0 23264 6204 5112 S 0.0 0.6 0:00.01 dcopserver I understand virtual memory management perfectly well, although possibly not quite so well on Linux. In the above, 40K of swap-space is used, yet it appears that e.g. the two crm114 trasks, the ibwd and kded tasks have large amounts swapped out. I know top isn't exactly optimal for performance monitoring, but this seems completely off the mark. Any explanations? (this is kernel 2.6, SUSE Linux 10.1RC3). /Per Jessen, Zürich
Per Jessen wrote:
I understand virtual memory management perfectly well, although possibly not quite so well on Linux. In the above, 40K of swap-space is used, yet it appears that e.g. the two crm114 trasks, the ibwd and kded tasks have large amounts swapped out. I know top isn't exactly optimal for performance monitoring, but this seems completely off the mark.
No-one's got any suggestions regarding this discrepancy?? Here's another top console-shot: Mem: 646504k total, 456352k used, 190152k free, 400k buffers Swap: 506512k total, 0k used, 506512k free, 273080k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13672 root 25 0 184m 144m 20m R 97.2 22.9 5:04.16 y2base 5428 per 15 0 30644 17m 14m S 1.6 2.8 1:25.30 konsole 13766 per 16 0 2184 996 760 R 0.7 0.2 0:00.22 top 5427 per 15 0 9028 1936 1084 S 0.3 0.3 0:15.31 sshd 1 root 16 0 716 284 248 S 0.0 0.0 0:02.89 init How can y2base use 184M virtual storage of which only 144M is resident - yet no swap-space is in use? /Per Jessen, Zürich
On Thursday 18 May 2006 08:49, Per Jessen wrote:
Per Jessen wrote:
I understand virtual memory management perfectly well, although possibly not quite so well on Linux. In the above, 40K of swap-space is used, yet it appears that e.g. the two crm114 trasks, the ibwd and kded tasks have large amounts swapped out. I know top isn't exactly optimal for performance monitoring, but this seems completely off the mark.
No-one's got any suggestions regarding this discrepancy??
Here's another top console-shot:
Mem: 646504k total, 456352k used, 190152k free, 400k buffers Swap: 506512k total, 0k used, 506512k free, 273080k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13672 root 25 0 184m 144m 20m R 97.2 22.9 5:04.16 y2base 5428 per 15 0 30644 17m 14m S 1.6 2.8 1:25.30 konsole 13766 per 16 0 2184 996 760 R 0.7 0.2 0:00.22 top 5427 per 15 0 9028 1936 1084 S 0.3 0.3 0:15.31 sshd 1 root 16 0 716 284 248 S 0.0 0.0 0:02.89 init
How can y2base use 184M virtual storage of which only 144M is resident - yet no swap-space is in use?
y2base consumes about 97% CPU and 23% MEM and runs about 5 hours? I cannot look upon your monitor, but is (was?) YaST working ok? Cheers, Leen
Leendert Meyer wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13672 root 25 0 184m 144m 20m R 97.2 22.9 5:04.16 y2base 5428 per 15 0 30644 17m 14m S 1.6 2.8 1:25.30 konsole 13766 per 16 0 2184 996 760 R 0.7 0.2 0:00.22 top 5427 per 15 0 9028 1936 1084 S 0.3 0.3 0:15.31 sshd 1 root 16 0 716 284 248 S 0.0 0.0 0:02.89 init
How can y2base use 184M virtual storage of which only 144M is resident - yet no swap-space is in use?
y2base consumes about 97% CPU and 23% MEM and runs about 5 hours?
y2base is always CPU-intensive, increasingly so in the later releases. And yes, it uses quite a bit of memory too. Oh, and it's 5min, 4sec 160millisec ... and it's CPU-time not real time :-) The system it's running is a PII 400MHz, so yast using 5mins of CPU-time is very realistic. /Per Jessen, Zürich
Per Jessen wrote:
Here's another top console-shot:
Mem: 646504k total, 456352k used, 190152k free, 400k buffers Swap: 506512k total, 0k used, 506512k free, 273080k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13672 root 25 0 184m 144m 20m R 97.2 22.9 5:04.16 y2base 5428 per 15 0 30644 17m 14m S 1.6 2.8 1:25.30 konsole 13766 per 16 0 2184 996 760 R 0.7 0.2 0:00.22 top 5427 per 15 0 9028 1936 1084 S 0.3 0.3 0:15.31 sshd 1 root 16 0 716 284 248 S 0.0 0.0 0:02.89 init
How can y2base use 184M virtual storage of which only 144M is resident - yet no swap-space is in use?
Interesting question. Sadly I don't know the answer :( I did find one hint with a bit of googling on this page: http://gentoo-wiki.com/FAQ_Linux_Memory_Management It says that VIRT includes the full size of libraries, but RES includes only the pages that are loaded. But SHR is only 20m so that can't account for everything. Perhaps showing some of the other memory-related columns will help? Cheers, Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-05-18 at 08:49 +0200, Per Jessen wrote:
No-one's got any suggestions regarding this discrepancy??
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEbksbtTMYHG2NR9URAuNcAJ9XYs5Z/LWaax+3cTccJv3pJb38sQCfXz1R NdaMyHGQiHySPoCw7HK2uDE= =k2ej -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-20 at 00:47 +0200, I wrote:
The Thursday 2006-05-18 at 08:49 +0200, Per Jessen wrote:
No-one's got any suggestions regarding this discrepancy??
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight.
I got another idea; I don't know if Linux does this, but I remember Windows did, and perhaps still does. Windows can completely discard unused code sections of programs and libraries; I don't mean swaping memory out, but discard. If that part of the code is needed again, it is reloaded from the original executable file. This way, it needs less swap file space. Can Linux do a similar thing? Using swap space would be faster (when reading back), I think, but if it does it could also help explain the discrepancy you found in top. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEblRTtTMYHG2NR9URAkcLAJ9S1kBvAG9J/sR9tHixRekEWUNBTwCcDDll k3Xk0LfLDiTHZ/ZzGSKPsho= =yqnk -----END PGP SIGNATURE-----
Carlos, On Friday 19 May 2006 16:27, Carlos E. R. wrote:
The Saturday 2006-05-20 at 00:47 +0200, I wrote:
The Thursday 2006-05-18 at 08:49 +0200, Per Jessen wrote:
No-one's got any suggestions regarding this discrepancy??
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight.
I got another idea; I don't know if Linux does this, but I remember Windows did, and perhaps still does. Windows can completely discard unused code sections of programs and libraries; I don't mean swaping memory out, but discard. If that part of the code is needed again, it is reloaded from the original executable file. This way, it needs less swap file space.
Yes. Pure code pages don't get sent to swap, they're read from the original executable file directly and abandoned instead of being swapped out when the RAM page is needed for another purpose.
Can Linux do a similar thing? Using swap space would be faster (when reading back), I think, but if it does it could also help explain the discrepancy you found in top.
Definitely. The linkers play along by aligning code boundaries in .so files on convenient boundaries (512 bytes at the smallest, but probably larger) so data can be sent directly from disk via DMA to the RAM location that is set up in the page tables to be present at the proper place in the application's virtual address space. The only speed advantage for swap (assuming it uses the same disks as the file system(s)) is guaranteed physical contiguity of logically contiguous pages. But that's true in the file system unless (or until) there's fragmentation of the executable or shared object files.
-- Cheers, Carlos Robinson
Randall Schulz
Carlos E. R. wrote:
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight.
I had some suspicions along those lines myself - if a daemon does a malloc(100M), it's VIRT size would presumably shoot up to 100M, but until all of that 100M has been initialised, none of it will be resident, nor will it be swapped out.
I got another idea; I don't know if Linux does this, but I remember Windows did, and perhaps still does. Windows can completely discard unused code sections of programs and libraries; I don't mean swaping memory out, but discard. If that part of the code is needed again, it is reloaded from the original executable file. This way, it needs less swap file space.
Read-only pages - I'm sure Linux can do this too.
Can Linux do a similar thing? Using swap space would be faster (when reading back), I think, but if it does it could also help explain the discrepancy you found in top.
Well, that's a lot of code - 20M or so. I suppose with libraries it's possible. /Per Jessen, Zürich
On Saturday 20 May 2006 00:47, Carlos E. R. wrote:
The Thursday 2006-05-18 at 08:49 +0200, Per Jessen wrote:
No-one's got any suggestions regarding this discrepancy??
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight.
I noticed that for y2base, VIRT = RES + 2*SHR. Is this meaningfull or should I
/dev/null?
Cheers, Leen
participants (5)
-
Carlos E. R. -
Dave Howorth -
Leendert Meyer -
Per Jessen -
Randall R Schulz