| 1 |
Apparently, though unproven, at 13:34 on Sunday 19 September 2010, Alex |
| 2 |
Schuster did opine thusly: |
| 3 |
|
| 4 |
> Alan McKinnon writes: |
| 5 |
> > Apparently, though unproven, at 16:45 on Saturday 18 September 2010, |
| 6 |
> > |
| 7 |
> > Florian Philipp did opine thusly: |
| 8 |
> > > I have a bit of a problem. I'm on KDE-4.4.5 and it eats memory for |
| 9 |
> > > breakfast. Directly after booting, everything is okay but the usage |
| 10 |
> > > grows significantly. I wonder whether this is expected behavior. |
| 11 |
> > > |
| 12 |
> > > The following statistics have been taken after 8 days of uptime |
| 13 |
> > > during which the system was on standby most of the time during work |
| 14 |
> > > days and at night. |
| 15 |
> > > |
| 16 |
> > > free -m |
| 17 |
> > > |
| 18 |
> > > total used free shared buffers cached |
| 19 |
> > > |
| 20 |
> > > Mem: 3754 3588 165 0 57 258 |
| 21 |
> > > -/+ buffers/cache: 3271 482 |
| 22 |
> > > Swap: 6142 978 5163 |
| 23 |
> > > |
| 24 |
> > > A desktop machine that has 4GB RAM and still needs to swap?! |
| 25 |
> |
| 26 |
> What I forgot to ask: Do you feel the performance becomes bad? Does the |
| 27 |
> system feel more responsive again when you restart KDM and log in again? |
| 28 |
> |
| 29 |
> I don't mind the system growing swap, that's normal, but now, as soon as |
| 30 |
> significant swapping starts, the system becomes slow. I don't know why. |
| 31 |
|
| 32 |
It's swapping. It will become slow. Disks are millions of time slower than |
| 33 |
RAM. |
| 34 |
|
| 35 |
> |
| 36 |
> > > Excerpt from top: |
| 37 |
> > > VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
| 38 |
> > > |
| 39 |
> > > 1094m 484m 10m S 0 12.9 96:43.01 firefox |
| 40 |
> > > |
| 41 |
> > > 932m 471m 15m S 0 12.6 5:10.20 akregator |
| 42 |
> > > 384m 303m 2856 S 0 8.1 59:43.43 virtuoso-t |
| 43 |
> > > 709m 282m 2936 S 0 7.5 0:40.51 nepomukservices |
| 44 |
> > > 839m 146m 15m S 0 3.9 8:37.76 thunderbird-bin |
| 45 |
> > > 191m 131m 532 S 0 3.5 12:30.73 dbus-daemon |
| 46 |
> > > 902m 105m 5288 S 0 2.8 0:30.16 krunner |
| 47 |
> > > 263m 105m 1724 S 0 2.8 2:31.18 squid |
| 48 |
> > > 255m 61m 6672 S 7 1.6 305:04.24 X |
| 49 |
> > > |
| 50 |
> > > 1106m 55m 7756 S 0 1.5 4:22.73 amarok |
| 51 |
> > > |
| 52 |
> > > 534m 54m 10m S 0 1.5 2:33.94 kopete |
| 53 |
> > > 559m 52m 6536 S 0 1.4 56:52.37 nepomukservices |
| 54 |
> > > 718m 38m 12m S 4 1.0 143:36.62 plasma-desktop |
| 55 |
> > > 295m 33m 2048 S 0 0.9 1:59.32 mysqld |
| 56 |
> > > 360m 17m 1856 S 0 0.5 0:07.56 tomboy |
| 57 |
> > > 445m 16m 3392 S 0 0.4 38:54.36 nepomukservices |
| 58 |
> > > 365m 14m 6356 S 1 0.4 27:38.49 konsole |
| 59 |
> > > 438m 11m 4928 S 0 0.3 0:20.12 kded4 |
| 60 |
> > > 508m 11m 6364 S 0 0.3 0:45.79 kwin |
| 61 |
> > |
| 62 |
> > Like I posted in another thread today, the memory columns in top do not |
| 63 |
> > mean what most people think they mean, nor are they simplistic. |
| 64 |
> |
| 65 |
> You gave the example of Thunderbird using 150M and Firefox 180M, but |
| 66 |
> together they would not use 330M because some stuff is shared. Hm, isn't |
| 67 |
> this what the SHR column in top is for? In Florian's case, there is |
| 68 |
> firefox with 484M in the RES column and thunderbird with 146M, but the SHA |
| 69 |
> column gives 10M + 15M, so only 25M of 630M are shared? |
| 70 |
|
| 71 |
Yes that's true. I sucked the 150 && 180 numbers out of my ass. |
| 72 |
|
| 73 |
The post was to highlight common problems with reading top output, not to |
| 74 |
diagnose any problem he might be having. |
| 75 |
|
| 76 |
|
| 77 |
|
| 78 |
-- |
| 79 |
alan dot mckinnon at gmail dot com |
Archives