LINUX.ORG.RU
ФорумAdmin

Ubuntu: куда уходит память??

 ,


2

2

Много месяцев уже (точный срок не помню, может и с конца прошлого года) наблюдаю такую картину. При активном использовании системы начинает «в никуда» уходить память. Вот свежий пример «промежуточного» состояния. Всего часов через десять после последней перезагрузки, при чём 2/3 времени машина бездействовала.

http://img823.imageshack.us/img823/5890/2256.png

Как видно, суммарная занятость RSS очень невысока. Но показано, что задействовано аж 4Гб оперативки. И это реальная задействованность, не ошибка в подсчётах. Если дело запустить и не перезагружаться несколько суток, то машина начинает заполнять своп, под буфера и кеши выделяется совсем мало, всё начинает притормаживать.

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

http://img546.imageshack.us/img546/6610/5w47.png

Есть мысли, куда копать? «На Gentoo такого не было» ©. Как, впрочем, и на Ubuntu раньше. Вот появилось это в 13.04 или уже в 12.10 — не помню.

Спасает пока только полная перезагрузка. Вырубание иксов и убийство всех юзеровских процессов с последующим рестартом иксов — не помогает.

В данный момент так:

$ free
             total       used       free     shared    buffers     cached
Память:    8120656    6124732    1995924          0     200736    1152256
-/+ буферы/кэш:    4771740    3348916
Swap:      2104508     203544    1900964

★★★★★

Может там много мелких процессов?

( ps -eo rss --no-headers | while read rss; do echo -ne "${rss}+"; done ;echo 0 ) | bc -l

- да, я знаю что библиотеки посчитаются для всех процессов сразу, но пока ведь у нас недочёт.

ps -eo rss,cmd | less | sort -nr  | less
router ★★★★★
()
Ответ на: комментарий от router

Первый код выдаёт 4584776 и это похоже на истину. Top же и free говорят, что занято 6231508. Надо подождать, пока заполнится под 100%, будет точнее видно.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от router
$ grep -i huge /proc/meminfo 
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от val-amart

Да, по симптомам похоже, что это именно что-то утекает. И раз в процессах нет, то в ядре. slabtop показывает такое, но х.з. как это интерпретировать :)

 Active / Total Objects (% used)    : 3022664 / 3431703 (88,1%)
 Active / Total Slabs (% used)      : 106952 / 106952 (100,0%)
 Active / Total Caches (% used)     : 80 / 121 (66,1%)
 Active / Total Size (% used)       : 1705546,91K / 1976296,49K (86,3%)
 Minimum / Average / Maximum Object : 0,01K / 0,58K / 15,53K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
1198752 1081365  90%    0,89K  35165       35   1125280K ext4_inode_cache
717392 547126  76%    0,88K  19948       36    638336K xfs_inode
604737 603610  99%    0,19K  28797       21    115188K dentry
197691 115603  58%    0,10K   5069       39     20276K buffer_head
174144 171601  98%    0,06K   2721       64     10884K kmalloc-64
 61182  59809  97%    0,18K   2781       22     11124K vm_area_struct
 56994  44665  78%    0,09K   1357       42      5428K kmalloc-96
 53228  52372  98%    0,55K   1901       28     30416K radix_tree_node
 39081  34749  88%    0,38K   1861       21     14888K bip-16
 35072  35072 100%    0,02K    137      256       548K ext4_io_page
 28080  27379  97%    0,11K    780       36      3120K sysfs_dir_cache
 27776  26902  96%    0,06K    434       64      1736K anon_vma
 26400  25739  97%    0,12K    825       32      3300K kmalloc-128
 26112  26112 100%    0,01K     51      512       204K kmalloc-8
 17920  14195  79%    0,25K    560       32      4480K kmalloc-256
 17790  17128  96%    0,61K    685       26     10960K proc_inode_cache
 17283  15110  87%    0,19K    823       21      3292K kmalloc-192
 17280  12668  73%    0,03K    135      128       540K kmalloc-32
 13312  13312 100%    0,02K     52      256       208K kmalloc-16
 12928  12928 100%    0,03K    101      128       404K extent_status
 12615  11685  92%    0,55K    435       29      6960K inode_cache
 12580  12253  97%    0,05K    148       85       592K shared_policy_node
  9214   9214 100%    0,12K    271       34      1084K fsnotify_event
  5508   5508 100%    0,04K     54      102       216K Acpi-Namespace
  4536   4536 100%    0,07K     81       56       324K Acpi-ParseExt
  4096   4096 100%    1,00K    128       32      4096K nfs_inode_cache
  3315   2657  80%    0,81K     85       39      2720K task_xstate

В данный момент:

$ free
             total       used       free     shared    buffers     cached
Память:    8120656    7038068    1082588          0     231936    1449276
-/+ буферы/кэш:    5356856    2763800
Swap:      2104508     202628    1901880

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

нет не течет. во-первых, именно inode_cache и dentry учитываются как буфферы в выводе free, во-вторых полтора гига ­— это нормально на десктопе.

val-amart ★★★★★
()

файловый кэш же
освобождается по первому требованию любого приложения
проблема с памятью это когда своп активно использоваться начинает, это в atop наглядно видно
идея в том, что неиспользованная память - потеряная память

af5 ★★★★★
()
Ответ на: комментарий от snoopcat
$ grep -i srec /proc/meminfo
SReclaimable:    1884944 kB

Опять же, что это всё значит? :)

Сейчас уже так:

$ free
             total       used       free     shared    buffers     cached
Память:    8120656    7193748     926908          0     171700    1317084
-/+ буферы/кэш:    5704964    2415692
Swap:      2104508     202612    1901896

Это всё ещё не перезагружаясь. Хром запущен, он тонной процессов известен, так что оценить по top затраты не получится, но atop с группировкой по юзеру выдаёт такое: http://img593.imageshack.us/img593/2/0dur.png

Т.е. без малого три гига уже куда-то ушло.

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

файловый кэш же
освобождается по первому требованию любого приложения

Не похоже, учитывая, что при заполнении начинает тормозить. При плотном заполнении — тормозить ОЧЕНЬ сильно. Очень характерен индикатор-апплет в Gnome: http://img208.imageshack.us/img208/7565/03o2.png

Жёлтый — это пользовательская память, салатовый — разделяемая, светло-синий — буфера, голубой — кеши. Сразу после рестарта жёлтая полоска едва заметна, в считанные пиксели. Сейчас — уже почти заполнено. Ещё через несколько часов будет почти до верха и начнутся тормоза. Полное убиение юзеровских процессов не поможет.

KRoN73 ★★★★★
() автор топика

Попробовал

sync ; echo 2 > /proc/sys/vm/drop_caches

Часть памяти сразу вернулась. Заметная, при чём. Но не в такое состояние, как сразу после рестарта. При чём по данным atop пользовательская память выросла(!) до 5Гб, free показывает, что занято 4.5Гб o_O

И непонятно, что за slab-кеш такой, при заполнении которого начинаются тормоза. Не в cron же ставить их сброс? :)

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

это плохая идея =) хотя, на десктопе может и хрен с ним. slab — это не только кеш. но drop_caches чистит только кеши. s_reclaim показывает сколько можно освободить из slab'a. только вот он вроде не считается в used, т.е. дело не в кешах. уидивительно встати что у тебя там было почти 2Гб, у меня сейчас например ~300Мб при >6Гб буферов и кешей

val-amart ★★★★★
()
Ответ на: комментарий от KRoN73

Видимо это тот случай, когда надо крутить дефолтные swappiness=60 vfs_cache_pressure=100 на что-то более подходящее

af5 ★★★★★
()
Ответ на: комментарий от val-amart

уидивительно встати что у тебя там было почти 2Гб

Дык, вся тема, по сути, этому удивительному поведению ядра Ubuntu и посвящена :) Хорошо, хоть в таком виде удалось причину раскопать. А то раз в пару-тройку дней перезагружаться приходилось.

Что интересно, на ноутбуке с 4Гб оперативки тоже 13.04 стоит — но там такого поведения нет. Разница только в том, что там Unity, а тут Gnome Fallback. Но не думаю, что дело в этом. Ноут раз в несколько недель, наверное, перезагружаю. Правда, он и валяется в основном в спящем режиме.

Вот на работе на днях обновил 12.10 до 13.04 — посмотрю, как там будет (до этого машина месяцами без рестарта стояла, тоже 4Гб, правда, уже не 64 бит, а 32 бит PAE).

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

Видимо это тот случай, когда надо крутить дефолтные swappiness=60 vfs_cache_pressure=100 на что-то более подходящее

swappiness сейчас = 10, vfs_cache_pressure = 100.

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

Жесть... он всегда красный?

Наверное :)

d пожалуйста

http://img266.imageshack.us/img266/8803/r58y.png

В браузере:

http://img593.imageshack.us/img593/5316/cl3k.png

Блин, я почему-то в памяти держал, что «a» переключает аккумуляцию результата за всю сессию, а оказалось — только активные/все процессы переключает. А аккумуляции вообще не вижу в хелпе. Но, ведь, была же вроде?

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

шапку зачем отрезали на второй картинке
вроде бы не видать чтоб кто-то диск юзал сильно, чем тогда память забивается непонятно, наверно гном кривой, вот открыть атоп после перезагрузки и поглядывать почаще, может кто спалится

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

вроде бы не видать чтоб кто-то диск юзал сильно

Да никто диск не юзает. Потому и отрезал, что по нижней части видно, что диск простаивает.

наверно гном кривой

Память не освобождается после остановки иксов, убиения всех юзер-процессов и повторного старта иксов. Так что гном тут не при чём. Зато освобождается после сброса slab-кеша. Так что дело именно в ядре.

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

если дело в ядре, то проблему можно будет повторить и без иксов, попробуйте не запуская их что-нибудь нагрузить

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

если дело в ядре, то проблему можно будет повторить и без иксов, попробуйте не запуская их что-нибудь нагрузить

Как мне имитировать ту же браузерную деятельность в течении нескольких суток? :)

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

еще есть команда для копирования файлов, не будем называть её чтоб случайно сайт не закрыли

af5 ★★★★★
()

Не хочу разбираться в ваших цифрах :D , но по опыту держания годами гном2 десктопа без перезагрузок могу сказать что
а) атски текут некоторые демоны гнома - у меня это gnome-session & gnome-volume-control-applet
б) пулсаудио

В обоих случая помогает убийство соответствующих демонов - они рестартуют, сессия сохраняется, перелогиниватся не надо.

Да, у вас буферы 4.771.740 а занято 6.124.732. То есть именно на данные программ уходит всего ~ 1.3 гига, все остальное разные кеши.

То есть отчего паника - навскидку непонятно.

kernel ★★☆
()
24 октября 2013 г.
Ответ на: комментарий от kernel

атски текут некоторые демоны гнома - у меня это gnome-session & gnome-volume-control-applet

В обоих случая помогает убийство соответствующих демонов - они рестартуют, сессия сохраняется, перелогиниватся не надо.

Убийство gnome-session приводит к завершению сессии.

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

Убийство gnome-session приводит к завершению сессии.

да, прогнал. gnome-settings

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