Исчезает свободная память - утечка памяти


11

На недавно запущенной системе freeотчеты об использовании 1,5 ГБ ОЗУ (всего 8 ГБ ОЗУ, Ubuntu 12.04 с lightdm и плазменным рабочим столом, запущено одно окно консоли). При работающих приложениях, которые я использую, он по-прежнему потребляет не более 2G. Однако, если система работает в течение нескольких дней, все больше и больше моей свободной оперативной памяти исчезает - не отображается в списке используемых приложений: в то время как smem --pie=nameотчеты используют менее 20% (и 80% доступны), все остальное говорит иначе. free -mнапример отчеты о 7-м дне:

             total       used       free     shared    buffers     cached
Mem:          7459       7013        446          0        178        997
-/+ buffers/cache:       5836       1623
Swap:         9536        296       9240

(так что вы можете видеть, это не буферы или кеш). Сегодня это закончилось полным сбоем системы: отсутствовал менеджер окон, «зависшие в воздухе» приложения (без рамки) и всплывающее окно, уведомляющее меня о «слишком большом количестве открытых файлов». Отчеты системного журнала:

kernel: [856738.020829] VFS: file-max limit 752838 reached

Поэтому я закрыл те приложения, которые смог закрыть, и убил X, используя Ctrl-Alt-backspace. После этого X попытался снова подойти с failsafeX, но не смог этого сделать, так как больше не мог определить свою конфигурацию. Поэтому я переключился на консоль с помощью Ctrl-Alt-F2, собрал всю информацию, которую мог придумать (vmstat, free, smem proc/meminfo,, lsof, ps aux) и, наконец, перезагрузил компьютер. X снова придумал failsafeX; на этот раз я сказал ему «восстановиться из резервной копии конфигурации», затем переключился на консоль и успешно использовал ее startxдля отображения графической среды.

Я не имею ни малейшего понятия о том, что вызывает эту проблему - хотя это должно быть связано либо с самим X, либо с некоторыми пользовательскими процессами, работающими на X - как после убийства X, free -mвывод выглядел следующим образом:

             total       used       free     shared    buffers     cached
Mem:          7459       2677       4781          0         62        419
-/+ buffers/cache:       2195       5263
Swap:         9536         59       9477

(Освобождается ~ 3,5 ГБ) - для сравнения с выводом после нового запуска:

             total       used       free     shared    buffers     cached
Mem:          7459       1483       5975          0         63        730
-/+ buffers/cache:        689       6769
Swap:         9536          0       9536

Еще два полезных вывода предоставлены memstat -u. Незадолго до крушения:

User     Count     Swap      USS      PSS      RSS
mail         1        0      200      207      616
whoopsie     1      764      740      817     2300
colord       1     3200      836      894     2156
root        62    70404   352996   382260   569920
izzy        80   177508  1465416  1519266  1851840

После убийства Х:

User     Count     Swap      USS      PSS      RSS
mail         1        0      184      188      356
izzy         1     1400      708      739     1080
whoopsie     1      848      668      826     1772
colord       1     3204      804      888     1728
root        62    54876   131708   149950   267860

И после перезагрузки снова в X:

User     Count     Swap      USS      PSS      RSS
mail         1        0      212      217      628
whoopsie     1        0     1536     1880     5096
colord       1        0     3740     4217     7936
root        54        0   148668   180911   345132
izzy        47        0   370928   437562   915056

Использование файловой системы за одну неделю Использование ядра / процессора в течение одной недели

Изменить: только что добавил две графики из моей системы мониторинга. Интересно видеть: каждый раз, когда происходит «скачок» в потреблении памяти, пики процессора тоже. Просто нашел это прямо сейчас - и это напоминает мне еще один индикатор, указывающий на сам X: часто, возвращаясь к моей машине и разблокируя экран, я обнаруживал, что что-то делает тяжелую работу на моем процессоре. Сверяясь с top, всегда получалось /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none.

Итак, после этого длинного объяснения, наконец, мои вопросы:

  1. Какие могут быть возможные причины?
  2. Как я могу лучше определить вовлеченные процессы / приложения?
  3. Какие шаги можно предпринять, чтобы избежать такого поведения - если не считать перезагрузки машины все X дней?

Я работал 8.04 (Hardy) около 5 лет на моей старой машине, никогда не испытывая подобного (всегда более 100 дней безотказной работы, до перезагрузки, например, для обновления ядра). Теперь это совершенно новая машина со свежей установкой 12.04 . В случае, если это имеет значение, некоторые характеристики:

APU AMD A4-3400 с HD-графикой Radeon (tm), использующий драйвер ATI / Radeon с открытым исходным кодом (поэтому fglrx не установлен), 8 ГБ ОЗУ, WDC WD1002FAEX-0 hdd (1 ТБ), материнская плата Asus F1A75-V Evo. Ubuntu 12.04 64-bit с KDE4 / Plasma. Приложения, которые обычно открываются более или менее постоянно, включают в себя Evolution, Firefox, konsole (с запущенным Midnight Commander, около 4 вкладок) и LibreOffice - плюс иногда Calibre, Gimp и Moneyplex (банковское программное обеспечение, которое я использую уже почти 20 лет, в версии, которая хорошо на Харди).

Изменить: сегодня я нашел одного из "злых парней": плазменный рабочий стол KDE4s. Использованная память была снова до 5 Гб, когда я сделал killall plasma-desktop && plasma-desktop. Это освободило 1,3 ГБ ОЗУ! psговорит:

                             RSS    SIZE   VSZ
plasma usage before restart  120988 526472 1300816
plasma usage after restart   92352  495972 1263632

Так где же эти 1,3 ГБ были? Разница между этими значениями, если сложить, составляет 96 МБ, а не 1,3 ГБ.

И это может быть только одна часть, так как все еще используются 3,7 ГБ (должно быть менее 2 ГБ). Я отслеживал это в течение последних 6 дней, используя несколько инструментов: используемая память (не говоря о кеше и буферах) медленно, но неуклонно увеличивается. Даже если я не за своим столом, чтобы запустить что-нибудь ...

Что касается мониторинга процессов с открытыми файлами, в настоящее время я использую следующую 1-строчку (я люблю shell и особенно bash), чтобы получить топ-5:

echo "$(for pid in $(ls -a /proc|egrep '^([0-9])*$'|sort -n 2>/dev/null); do \
if [ -e /proc/$pid/fd ]; then FHC=$(ls -l /proc/$pid/fd|wc -l); \
if [ $FHC -gt 0 ]; then PNAME="$(cat /proc/$pid/comm)"; \
echo "$FHC files opened by $pid ($PNAME)"; fi; fi; done)"|sort -r -n|head -n5

Команда здесь в 4 строки для лучшей читаемости. Ничего особенного, кроме того, что Skype не любит разорвать интернет-соединение. Каждое отключение вызывает небольшое увеличение его открытых файлов, но ничего драматического. С другой стороны, похоже, что плазма также ответственна за это:

Использование VFS (2 дня)

Видите падение файловых дескрипторов в конце? Это был перезапуск плазмы.


Очищает ли sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'дополнительный баран? Вы можете просматривать открытые файлы программ, используяlsof
Savvas Radevic

Кроме того, вы пробовали переключать менеджеры рабочего стола? например lxde (или lubuntu-desktop)? Наконец, вы уверены, что вывод на диск в порядке? Вы проверили SMART-данные диска и скорость копирования файлов с / на диск с помощью live cd?
Саввас Радевич

Отметьте это, чтобы проверить, есть ли у вас утечка. Как обнаружить утечку памяти
Митч

@medigeek: Как я уже говорил, кеш и буферы не являются проблемой. Смотрите вывод free. Переключение на другой DE я на самом деле рассмотрел; если бы был доступен KDE3.5, у меня не было плазмы. Это может быть только временно, чтобы увидеть, если Плазма участвует.
Иззи

@Mitch: я понял, что memprof должен был использоваться против известного процесса (который я еще не изолировал). Уверен, что его можно использовать для всей системы? Более того, как подсказывает ошибка «слишком много открытых файлов», мне кажется, что какой-то процесс открывает много файловых дескрипторов, а не освобождает их. Не уверен, что это будет пойман Memprof. Сейчас я настроил скрипт для захвата топ-5 процессов открытыми файлами - надеюсь, это окажется злым.
Иззи

Ответы:


6
  1. Огромное количество открытых файлов - хороший признак того, что что-то идет не так. Я думаю, что это будет какой-то системный демон KDE.

  2. Откройте консоль и запустите «top». Затем используйте <и>, чтобы изменить столбец сортировки на VIRT или RES и посмотреть, какие программы используют больше всего памяти. Утечка памяти будет отображаться как сильно завышенное использование виртуальной памяти, так как после потери указателя на утечку памяти она не будет использоваться и будет заменена. Также запустите «lsof» и найдите процесс с большим количеством открытых файлов, так как это действительно утечка дескриптора файла.

  3. Отследить программу и сообщить об ошибке.


Я уже пытался использовать top / htop для этого. Проблема в том, что он не показал никаких результатов в отношении резидентной памяти (как описано выше, только небольшая часть используемой памяти могла быть подключена к работающим приложениям). А что касается памяти VIRTual, ее трудно интерпретировать (даже сразу после запуска виртуальная память использует здесь до 3 ТБ - размер, который даже мой жесткий диск не может обработать). Так, например, в настоящее время, например, Evolution использует 1,9 ГБ VIRT, в зависимости от top, а общая используемая память составляет до 1,2 ГБ (без учета кеша и буферов). И да, мое первое намерение - отследить программу, чтобы я мог сообщить об ошибке ...
Иззи

Только что добавил 2 imgs из моей системы мониторинга. Похоже, «прыжки» всегда происходили в одно и то же время дня (хотя 1 исключение). К сожалению, imgs не дает метки времени для проверки cron. Кстати: есть ли способ контролировать, какой процесс имеет сколько файлов открыто?
Иззи

1
Ваше предположение было хорошим. Хотя это и не демон, в основном это был компонент KDE: plasma-desktop (см. Выше). Забавная вещь об этом: я только разобрался и разместил это здесь - и через 10 минут в моем ежедневном apt-get update && apt-get upgradeвыпуске было обновление для плазменного рабочего стола; эти парни быстрые X) Теперь я просто смотрю это некоторое время, чтобы увидеть, решена ли проблема, прежде чем объявить об этом. До сих пор все выглядит довольно многообещающе.
Иззи

Все еще выглядит стабильно. Хотя ни то, ни другое lsofне topуказывало на «злой процесс», ваше предположение относительно демона KDE указало мне на нарушителя спокойствия. Еще раз спасибо - время безотказной работы моей машины составляет около 14 дней, и все выглядит стабильно, хотя я даже параллельно запускал такие вещи, как VirtualBox, компиляция и т. Д. Поэтому я считаю это решенным и отмечаю ближайший матч :)
Иззи

0

Я думаю, что это нормальное поведение системы. Скорее всего все хорошо.

Вы можете прочитать эту замечательную статью (linux съел моего барана), чтобы понять, как linux управляет вашим бараном и почему не нужно беспокоиться:

http://www.linuxatemyram.com/


4
О - я никогда не слышал, что это «нормальное поведение системы», если система падает через 7 дней с ошибкой «слишком много открытых файлов». Я использую Linux уже около 15 лет, такого никогда не было. И да, я полностью понимаю, как Linux использует «свободную оперативную память» (используя ее для кеширования и т. Д.) Как указывалось выше: кеш и буферы здесь не проблема. Я не говорю о том, что оперативная память используется по уважительным причинам - Linux никогда не будет придерживаться кэшей по цене обмена.
Иззи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.