Утечка памяти в Linux?
Такая проблема, на сервере куда-то утекает память.
top — 14:58:30 up 21 days, 16:05, 2 users, load average: 0.66, 0.50, 0.49
Tasks: 145 total, 2 running, 141 sleeping, 2 stopped, 0 zombie
Cpu(s): 15.9%us, 0.0%sy, 0.0%ni, 84.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8194056k total, 8109096k used, 84960k free, 921072k buffers
Swap: 7815580k total, 764k used, 7814816k free, 6353068k cached
На сервере установлены:
— mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (x86_64) using readline 5.2 (дефолтный конфиг)
PHP 5.3.5-0.dotdeb.0 (fpm-fcgi) (built: Jan 7 2011 00:07:27)
Copyright © 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright © 1998-2010 Zend Technologies
with Suhosin v0.9.32.1, Copyright © 2007-2010, by SektionEins GmbH
— Sphinx 0.9.9-release (r2117) (indexer —all запускается раз в 5 минут по крону)
— Сайт на CodeIgniter-e, около 5000 HTTP запросов в минуту
Если сервер перезагрузить — всё хорошо, но примерно за неделю вся память сжирается неизвестно куда. Как посмотреть, куда она делась и как её освободить?
По мойму вы не разобрались в матчасти и начали истерику.
У вас не кушается свап значит системе хватает памяти. Линукс активно использует для кеша память им собственно и зажрана ваща память, если память нужна будет программе то линукс освободит память для программы.
Бояться надо когда растет swap used
Swap: 7815580k total, 764k used, 7814816k free, 6353068k cached
У меня примерно всегда такая ситуация
Mem: 8039080k total, 7962872k used, 76208k free, 3756k buffers
Swap: 10092536k total, 1516k used, 10091020k free, 7122616k cached
И аналогичная на серверах с 24 гигами оперативы.
Ubuntu: куда уходит память??
Много месяцев уже (точный срок не помню, может и с конца прошлого года) наблюдаю такую картину. При активном использовании системы начинает «в никуда» уходить память. Вот свежий пример «промежуточного» состояния. Всего часов через десять после последней перезагрузки, при чём 2/3 времени машина бездействовала.
Как видно, суммарная занятость RSS очень невысока. Но показано, что задействовано аж 4Гб оперативки. И это реальная задействованность, не ошибка в подсчётах. Если дело запустить и не перезагружаться несколько суток, то машина начинает заполнять своп, под буфера и кеши выделяется совсем мало, всё начинает притормаживать.
Вот скриншот постарше и с реальным использованием:
Есть мысли, куда копать? «На Gentoo такого не было» ©. Как, впрочем, и на Ubuntu раньше. Вот появилось это в 13.04 или уже в 12.10 — не помню.
Спасает пока только полная перезагрузка. Вырубание иксов и убийство всех юзеровских процессов с последующим рестартом иксов — не помогает.
Куда может «утекать» свободное место на диске?
Некоторое время назад у меня после старта ОС стало всплывать сообщение о том, что в корневой ФС осталось мало свободного места. Места становилось все меньше и меньше при том, что никаких новых пакетов я не за это время не устанавливал. Удалил кое-какие ненужные пакеты. Но через некоторое время свободное место опять сократилось. Сейчас вообще свободно 100К. И это при том, что в последнее время даже апдейты не ставил. Корень, var и home у меня на разных разделах. Поэтому ничего, кроме того, что я подцепил что-нибудь нехорошее из Инета, в голову не приходит. Но таки может дело не этом? Может это чудеса ext4, к примеру? Может что-то поломалось, и у нее журнал забивается чем-то. Что подскажите коллеги? Где бы что бы покопать?
логи,
кэш пакетной системы(той которая устанавливает программы)
неисправное шифрование или ещё какая школоло поделка от авторов убунты/или какого-то другого дурного дистрибутива eCryptfs съедает место?
О «du» никогда не слышал?
Поэтому ничего, кроме того, что я подцепил что-нибудь нехорошее из Инета, в голову не приходит.
Загрузись с live-cd (live-usb)
кэш пакетной системы(той которая устанавливает программы)
Это все должно быть в /var, т.е. на другом физическом диске. А переполнен раздел на диске, куда смонтировано все остальное за исключением var и home. В /etc конечно может что-то меняться, но не гигабайты же.
Плюсую баобаб, удобнейшая вещь. Если нет иксов, то есть NCurses Disk Usage.
На самом деле, «показания» du бывают не слишком актуальны. Иногда df и du показывают совсем разное. du не считает удалённые файлы, с которыми продолжают работать процессы. Их можно глянуть чем-то типа
А что ты конкретно предлагаешь сделать с помощью du? Узнать размеры 10000 файлов?
Узнать размеры каталогов, например
Я уже понял, что ты ламер. Ничего тебе не предлагаю, тебе помогут близкие тебе по духу.
Покажет тебе все файлы, которые изменились за последние сутки
у меня после старта ОС стало всплывать сообщение
После старта! Что будет с удаленными файлами после рестарта?
Грузился. fsck криминала не показал. Хотя gparted показал несколько гигов свободного места на разделе.
«показания» du бывают не слишком актуальны
du не считает удалённые файлы
Чёт тут нестыковка. Если оно не считает то, чего уже нет — где неактуальность?
du запускай. Смонтируй только / в /mnt, например.
затем
1. cd /mnt
2. du -sm * | sort -n
3. затем cd . в самую большую директорию и снова п2.
Баобаб запускал. Сейчас уже не помню, что он там показал. Но, какой смысл в его показаниях. Ну увижу я, сколько места занимают каталоги на корне. Суммарно все сойдется с показаниями df. Это может означать, что где-то есть файлы, которые не ставились с дистриба, или файлы, у которых непонятно отчего вырос размер. Как их искать. Вроде в rpm есть возможность сравнить хэши для реально установленных файлов с хэшами из пакетов. А если показания Баобаба даже не сойдутся с df. То значит глючит ФС. Так?
После старта! Что будет с удаленными файлами после рестарта?
Скажем так. После того, как я удалил пакеты со старой версией ядра, то как минимум ls показал отсутствие образа этого ядра в /boot и соответствующего версии ядра каталога с модулями. Ну и разумеется df показал, что свободного места стало больше. А вот после нескольких перезагрузок (через день-два) свободное место уменьшилось.
Удалённые файлы != то, чего нет. Удалённый файл продолжает занимать место, пока он открыт хотя бы в одном процессе.
Вот это дельная мысль. надо будет попробовать.
И? Процесс завершится и файл удалится окончательно. А у ТС постоянно что-то пишется на диск и там остаётся.
Корень, var и home у меня на разных разделах
А /tmp где ? И во всякие /opt и /srv ничего не ставилось ?
Удалённые файлы != то, чего нет. Удалённый файл продолжает занимать место, пока он открыт хотя бы в одном процессе.
А какое в данном случае это имеет значение? Ну предположим, что удаленный файл был занят процессом. После завершения процесса по какой-то причине место, занимаемое файлом, не освободилось. Ну я удалял бы файлы, а свободного места оставалось столько же, но оно бы не сокращалось само.
А /tmp где ? И во всякие /opt и /srv ничего не ставилось ?
По /tmp и /srv Баобаб показывал какие-то совсем маленькие цифирьки. /tmp, кстати если мне память не изменяет, в ramfs монтируется. Хотя, пожалуй, на /srv стоит обратить повышенное внимание. В /opt я вообще собственноручно ничего не ставил.
/tmp, кстати если мне память не изменяет, в ramfs монтируется
если это указано в fstab, не?
Но пока процесс не завершится, «показания du будут не слишком актуальные».
Сейчас не помню и этого компа рядом нет. Вечером буду смотреть. Интересно, что будет, когда окажется 0 свободного места?
И даже никто не спросил, а сколько у него вообще места в корне?
И даже никто не спросил, а сколько у него вообще места в корне ?
В общем-то, это не очень важно. Туда никто не должен писать, если с него убраны все каталоги, где таковое возможно. То есть, это
основные:
/tmp
/home
/var
/usr/tmp (хотя туда мало кто пишет, да и чаще это симлинк на /var/tmp)
Вроде ничего не забыл. А, /usr/src ещё может быть, если ядра собирать по старой методике, а не опакечивать, или не ставить готовые.
Интересно, что будет, когда окажется 0 свободного места?
Демоны не запустятся → система загрузится в аварийном режиме (возможно, read-only) и попросит пароль рута.
Фигасебе какая софтина, спасибо.
ищешь самые «крупные» папки, идешь далее du -sh /folder/* и тд.
В любом случае придется работать руками, так как только ты знаешь, что в твой системе необходимо и занимает место » с пользой», а что на самом деле раздулось.
может, у тебя почта рута переполнилась? ну, там, лезет кто-то на сервер, а тебе сообщения сыплются про облом авторизации, например. больше ничего вроде на руте и нет такого переполняемого.
а ещё может у тебя своп в файле сделан
Если оно не считает то, чего уже нет — где неактуальность?
Файловые дескрипторы остаются вроде, так что по факту файл есть.
может, у тебя почта рута переполнилась ?
О, точно. В некоторых дистрибутивах почта рута, по-умолчанию, пишется не в /var/spool/mail/, а в
root/, который, опять же, в зависимости от дистрибутива, может оказаться в /root, а не где-то ещё.
Сейчас уже не помню, что он там показал. Но, какой смысл в его показаниях.
Я не пойму, так вам надо узнать чем занято место, или нет?
Ну в общем всем спасибо. Все-таки, когда советуешься с разными людьми, находится кто-нибудь, кто посоветует то, о чем сам забываешь. Хотя все оказывается очевидно, как дважды два. Короче, совет внимательно осмотреть /srv возымел действие. Оказалось именно там bacula «лепила» периодически бэкапы. На каталоге, где сохранялись бэкапы, стояли права, разрешающие доступ только пользователю/группе bacula. Баобаб, конечно, показывал, что /srv практически пуст. Нахрена он автоматически в Mate запускается из-под user-а, если заранее известно, что покажет цифры с потолка? Могли бы предлагать пройти авторизацию, чтобы стартонуть его с правами root-а. Ну и я, конечно, малость тормознул. Bacula я не настраивал. Просто когда-то поставил пакеты с ней до кучи, а ковыряния с настройкой оставил до лучших времен. А потом вообще про неё забыл. А она, оказывается, тихо делала свое дело. Ну а вообще радует хотя бы то, что это не руткит какой-нибудь.
Пользуюсь постоянно командой:
sudo du -xm —max-depth=1 / | sort -rn
где вместо / последовательно вставляю нужные мне пути.
Для того, что бы узнать куда девается место, большего никогда не требовалось,.