LINUX.ORG.RU

Куда уходит память - часть II


0

1

Проблема на Kubuntu 10.10 - у меня есть большое подозрение, что память расходуется совершенно нездоровым образом. Помогите пожалуйста выяснить причины.

После некоторой работы без перезагрузки память «замусоривается». Ниже - показания top. Вот чего я не понимаю: если сложить резидентную память, то вряд ли и один гиг наберется. Если еще и вычесть разделяемую, то будет еще меньше. Так почему же по общим показателям мало того что память заполнена под завязку, так еще и своп заканчивается? И он таки реально закончится скоро. Хотя открытых приложений у меня больше не становится. Как это понимать?

И еще заметил, что на последней версии Kubuntu даже перезапуск иксов не так эффективно высвобождает память, и своп так и остается замусорен метров на 200-300, и предел достигается быстрее, так что нормально помогает только полная перезагрузка.

Mem:   1017228k total,   950280k used,    66948k free,    27312k buffers
Swap:  1048572k total,   709056k used,   339516k free,   236068k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
29362 artem     20   0  415m 140m  50m S    2 14.2  25:53.81 konqueror          
 2025 artem     20   0  608m 115m  31m S    4 11.7  63:11.54 plasma-desktop     
20276 artem     20   0 1099m  94m 8412 S    0  9.5  24:50.84 eclipse            
16831 artem     20   0  265m  68m  20m S    0  6.9  23:22.55 kopete             
10281 artem     20   0  313m  66m  21m S    0  6.7  14:26.42 dolphin            
15459 artem     20   0  295m  53m  23m R   99  5.4  51:10.49 kontact            
 1202 root      20   0  145m  41m  29m S    6  4.1 128:40.07 Xorg               
16836 artem     20   0  120m  31m 9556 S    1  3.2  14:36.58 skype              
 2023 artem     20   0  353m  27m 9060 S    0  2.7   0:41.20 knotify4           
 2141 artem     20   0  299m  25m 9308 S    0  2.6   0:44.64 kmix               
 2024 artem     20   0  286m  23m  17m S    0  2.4   1:57.62 krunner            
 8937 artem     20   0  188m  23m  12m S    0  2.4   1:41.39 choqok             
 9551 artem     20   0  143m  23m  15m S    5  2.3   9:04.44 konsole            
 1944 artem     20   0  174m  17m  11m S    0  1.8  11:55.96 kded4              
 1995 artem     20   0  236m  15m  10m S    0  1.6   7:19.43 kwin               
20978 artem     20   0  108m  14m  11m S    0  1.5   0:05.18 gwenview           
 2150 artem     20   0  117m  13m 8636 S    0  1.4   0:29.85 knotes             
 2226 artem     20   0  115m  11m 9344 S    0  1.1   0:04.23 python             
 1204 clamav    20   0 20084  11m 4444 S    0  1.1   2:25.14 freshclam          
 2236 artem     20   0  116m  10m 9308 S    0  1.1   0:08.46 klipper            
30664 artem     20   0 80572 9568 6488 S    0  0.9   0:00.50 kio_pop3           
 3014 artem     20   0  107m 9484 8540 S    0  0.9   4:17.13 kwalletd           
 2276 artem     20   0 45940 9212 4096 S    0  0.9   0:34.09 kio_http_cache_    
 6032 artem     20   0  106m 8568 7492 S    0  0.8   2:47.66 korgac             
 1993 artem     20   0  117m 7708 7116 S    0  0.8   0:04.17 ksmserver          
 2073 artem     20   0 84084 7556 7032 S    0  0.7   0:02.51 akonadi_ical_re    
 2081 artem     20   0 81848 7540 6980 S    0  0.7   0:02.45 akonadi_vcard_r    
 2074 artem     20   0 83892 7516 6976 S    0  0.7   0:02.32 akonadi_ical_re    
 2079 artem     20   0 82312 7436 6888 S    0  0.7   0:02.66 akonadi_maildis    
 2032 artem     20   0 78708 7348 6476 S    0  0.7   4:36.08 kuiserver          
 2075 artem     20   0 83888 7304 6828 S    0  0.7   0:02.33 akonadi_ical_re    
 2076 artem     20   0 81672 7212 6772 S    0  0.7   0:02.17 akonadi_kabc_re    
 1950 artem     20   0 79592 7108 6452 S    0  0.7   0:07.22 kglobalaccel       
 2071 artem     20   0 83828 7088 6756 S    0  0.7   0:02.17 akonadi_birthda    
 2077 artem     20   0 81588 7016 6696 S    0  0.7   0:02.15 akonadi_maildir    
 2080 artem     20   0 88356 6952 6588 S    0  0.7   0:06.77 akonadi_nepomuk    
 2072 artem     20   0 81672 6936 6676 S    0  0.7   0:02.15 akonadi_contact    
12695 root      20   0 81032 6916 6536 S    0  0.7   0:05.79 kded4              
 2078 artem     20   0 81584 6884 6652 S    0  0.7   0:02.14 akonadi_maildir    
 2139 artem     20   0 80188 6756 6468 S    0  0.7   0:03.75 polkit-kde-auth    
 2117 artem     20   0 81828 6516 6288 S    0  0.6   0:16.30 kaccess            
 1942 artem     20   0 45804 6144 5404 S    0  0.6   0:10.76 klauncher          
 2217 artem     20   0  453m 5768 4312 S    0  0.6   0:28.42 nm-applet          
 2142 artem     20   0  332m 5036 3552 S    0  0.5   1:37.03 nautilus           
12692 root      20   0 43740 4592 4592 S    0  0.5   0:00.15 klauncher          
25070 artem     20   0 37808 4452 1720 S    3  0.4  21:36.68 python             
 2103 artem     20   0 36640 4096 4096 S    0  0.4   0:00.09 nepomukserver      
 1941 artem     20   0 73356 4088 3412 S    0  0.4   0:10.43 kdeinit4           
 2129 artem      9 -11 98080 4064 3228 S    0  0.4   6:32.79 pulseaudio         
 2328 artem     20   0  313m 3808 2928 S    0  0.4   0:07.78 bluetooth-apple    
  942 root      20   0 19712 3220 2348 S    0  0.3   0:28.40 NetworkManager     
 2038 artem     20   0  164m 3152 3152 S    0  0.3   0:28.69 akonadiserver      
 2036 artem     20   0 46072 3028 2692 S    0  0.3   0:09.72 akonadi_control    
26670 root      10 -10  2932 2924 2056 S    0  0.3   0:08.50 atop               
 9553 artem     20   0  8976 2808 1260 S    0  0.3   0:03.10 bash               
 1921 artem     20   0 54528 2760 1820 S    0  0.3   0:04.85 gnome-keyring-d    
26372 artem     20   0  120m 2676 2424 S    0  0.3   0:00.46 googletalk-call   


Последнее исправление: raa (всего исправлений: 1)

клиника...

Led ★★★☆☆
()

$ free -m |egrep -v 'Mem|Swap'


Хотя открытых приложений у меня больше не становится.


И чо, по-твоему уже запущенные программы не могут выделять ram?

anon_666
()
Ответ на: комментарий от anon_666

$ free -m |egrep -v 'Mem|Swap'

Про кеш я в курсе. Ну и чо? Вы на использование свопа посмотрите.

$ free -m
             total       used       free     shared    buffers     cached
Mem:           993        945         48          0         37        332
-/+ buffers/cache:        575        418
Swap:         1023        665        358

И чо, по-твоему уже запущенные программы не могут выделять ram?

Я уже позакрывал все что должно кушать память - эклипсы и контакты мирно спят. Осталось: один браузер с одной вкладкой, две консоли, месседжер и твиттер. А память куда-то уходит. Хочу выяснить КУДА. Резидентной памяти не густо выделено. А виртуальная - она ведь адекватно не скажет о том, сколько физической памяти реально задействовано. Так как понять, кто выделяет ram?

raa
() автор топика
Ответ на: комментарий от raa

>Вы на использование свопа посмотрите.
Почему система не должна использовать своп, если он есть?

позакрывал все что должно кушать память

Осталось: один браузер с одной вкладкой, две консоли, месседжер и твиттер.


С каких пор всё это не жрёт раму?

Так как понять, кто выделяет ram?

Выделение != использование. Выделение памяти отражает VIRT, использование - RES.

Хочу выяснить КУДА.

Смотреть, у какого процесса увеличиваются значения VIRT/RES, не?

anon_666
()
Ответ на: комментарий от anon_666

Вы на использование свопа посмотрите.

Почему система не должна использовать своп, если он есть?

Зачем Вы передергиваете? :) Одно дело, когда система просто использует своп, разумно, скидывая туда «ненужное». Другое дело, когда это делается агрессивно, явно из-за нехватки памяти, потому как наступает момент, когда своп заканчивается, и система начинает жутко тормозить (у меня это происходит примерно когда своп переваливает за 700-800 метров).

позакрывал все что должно кушать память
Осталось: один браузер с одной вкладкой, две консоли, месседжер и твиттер.

С каких пор всё это не жрёт раму?

Жрет конечно. Но логических оснований такому агрессивному пожиранию я сейчас не вижу. Тем более, что до обновления дистрибутива такое и не происходило. При текущей загрузке у меня в свопе было бы меньше 200 метров. А сейчас - 700.

Так как понять, кто выделяет ram?

Выделение != использование. Выделение памяти отражает VIRT, использование - RES.

По вашему мнению, RES включает в себя память, выделенную в «куче»? Тогда чем еще можно объяснить агрессивное использование свопа, тогда как используемый объем легко вмещается в физической памяти?

Хочу выяснить КУДА.

Смотреть, у какого процесса увеличиваются значения VIRT/RES, не?

RES не увеличивается ни у какого процесса на сколь-нибудь серьезные величины. VIRT - там просто заоблачные цифры, что по ним можно понять и как по ним судить?

raa
() автор топика
Ответ на: комментарий от megabaks

Вы на использование свопа посмотрите.

vm.swappiness=60?

Да, но какое это имеет значение в данном случае? Я так понимаю, что это как бы вероятность того, что страница будет отправлена в своп. Но при этом, если что-то где-то берется, то что-то куда-то пропадает, правильно? Т.е. должно освободиться физической памяти, увеличиться кеш... А этого не происходит, кеш прижат к потолку, и вот уже снова тачка начинает тормозить, сейчас придется и мессенджер закрыть, чтобы не зависнуть :)

Не, я таки попробую изменить, но все же интересно обоснование, а не только метод тыка.

raa
() автор топика
Ответ на: комментарий от raa

>По вашему мнению, RES включает в себя память, выделенную в «куче»?

Это не моё мнение, так и есть.

anon_666
()
Ответ на: комментарий от baverman

уменьшь
Или вообще своп отключи

Ок, попробую. Спасибо. Правда вот, я его для того и включаю, чтобы не вешалась тачка )))

А как это отобразится на RES? Это поле показывает только физическую используемую память, и своп сюда не входит?

anon_666

Ну Вы и буквоед :) Даже если Вам кажется, что так оно и есть, это все равно ваше мнение )))

raa
() автор топика
Ответ на: комментарий от raa

Это поле показывает только физическую используемую память, и своп сюда не входит?

Именно.

baverman ★★★
()
Ответ на: комментарий от baverman

Вот он, гад, вылез! :)

plasma-desktop - 259m

Спасибо большое всем. Мое ошибочное представление о том, чем является RES, вводило меня в заблуждение. Теперь буду знать, как обнаружить паразита.

После перезапуска плазма занимает 73 метра. Тоже не мало, но потерпеть можно. А вот в целом остается использовано 560 метров памяти (не считая кеш) при том, что уже не осталось ни одного приложения кроме консоли и твиттера, отъедающих всего полтинник напару.

raa
() автор топика
Ответ на: комментарий от raa

жуть какая )
видимо правда - в кубунте готовить кеды не умеют - не должны они столько жрать

megabaks ★★★★
()
Ответ на: комментарий от Jetty

М-да.... А ведь мне так нравится дебиан/убунта... Совсем не хочется расставаться с ними только из-за того, что в убунте плохо собрана kde.

raa
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.