поиск утечки памяти
Есть встраиваемая система на базе x86 и в ней OpenEmbedded крутится. Со временем, в течение часа, потребление памяти системой возрастает на 10 Мб, и так всё время, видимо до исчерпания.
Есть ли какой-то способ выявить процессы в системе, потребление памяти которыми (не обращая внимания на периодические колебания) имеет тенденцию к увеличению?
Кто как решает эту проблему?
Всякими профилировщиками для поиска утечек памяти относительно единичной программы своей разработки пользоваться умею, а вот как с системой поступить?
Первое, что приходит в голову — собирать скриптом выхлоп
и потом распарсить.
Что такое вообще «потребление памяти системой»?
Объем занятой памяти. Он растет, потом ее не хватит. Свопа в системе нет, да и он не безграничен.
Занятой кем или чем? Как ты увидел, что «память занята системой»?
Я _не_знаю_ что заняло память. Просто свободной памяти становится меньше и это не дисковое кэширование. Просто что-то течет.
Спасибо, интересный метод, надо попробовать.
atop еще умеет статистику собирать.
1. Растут ли процессы? От этого зависит, в ядре искать или в юзерспейсе.
2. Фейлят ли попытки выделить память? Если нет, то память занимается под кэш и в этом ничего страшного нет.
3. Есть ли в ядре самописаные драйверы? Если есть, можно посмотреть /proc/slabinfo — в зависимости от тактики выделения памяти в драйвере, утечка может быть заметна там.
1. это еще надо выяснить — растет общий объем используемой памяти 2. про кэш в курсе, он тут ни при чем 3. нет
Спасибо, попробую atop, не слышал про эту штуку ранее.
1. это еще надо выяснить — растет общий объем используемой памяти
Чудес не бывает — память либо в процессах, либо в кэше, либо в слабах.
2. про кэш в курсе, он тут ни при чем
Отказы в выделении памяти есть или нет?
- Кэш ядра имеет тенденцию съедать всю доступную память
- Проверить не возвращается ли память после вызова
Вангую зелененький блоб втихую жрет.
Вангую зелененький блоб втихую жрет
Пока не занимался этой задачей. Короче, я использую утилиту htop, она показывает что кэш (дисковый в том числе), а что просто занятая память. И я вижу что в течение часа память кушается всё больше и больше. Попробую покилять свои программы, drop_caches тоже попробую.
Гдето на просторах интернетов есть перловый скрипт который это делает для приложений путем периодического парсинга /proc. Кажется он один такой.
Спасибо за наводку, попробую его поискать.
Как ты узнаешь, что потребление памяти растёт?
Оставлю на сутки и посмотрю сколько сожрало. Это когда всё доделаю.
Понял. htop Mem: used: — это used растет, медленно растет, что-то течет.
Какой-то процесс в htop становится безусловным лидером по потреблению памяти? Плодятся ли новые процессы? Если да, то какие?
Ты перепутал с амд.
На рабочем компьютере я вижу что память очень прыгает, но если ничего не делать и смотреть htop то видно что нет тенденции к росту, утечек нет. На целевой же системе ПО, написанное коллегами, видимо что-то не чистит за собой, но! Их ПО это не просто софт на Qt но еще и набор скриптов, может стороннее ПО дает эффект.
Чисто визуально процент потребленной памяти процессами не растет. Лидеры по потреблению тоже не увеличивают процент. Новые процессы не плодятся — есть общий счетчик процессов и он не растет (была ошибка что плодились процессы и я ее пофиксил).
В общем, буду пробовать этот совет выше:
Гдето на просторах интернетов есть перловый скрипт который это делает для приложений путем периодического парсинга /proc. Кажется он один такой.
Источник
Невидимая утечка памяти на Linux — сервер Ubuntu (не кеш-диск /буферы)!
Обратите внимание, что это все еще происходит. Это не , связанное с linuxatemyram.com — память не используется для дискового кэша /буферов. Это выглядит так, как в NewRelic — система течет вся память, использует все пространство подкачки, а затем падает. На этом снимке экрана я перезагрузил сервер, прежде чем он разбился:
Невозможно определить источник утечки, используя общие средства пользовательского пространства. Теперь есть чат, чтобы обсудить эту проблему: http://chat.stackexchange.com /комнаты /27309 /невидимы-памяти утечки-на-Linux
Единственный способ восстановить «недостающую» память — это перезагрузка сервера. Это была давняя проблема, воспроизведенная на серверах Ubuntu 14.04, 14.10 и 15.04.
Использование памяти не отображается сверху и не может быть восстановлено даже после убийства практически каждого процесса (исключая такие вещи, как процессы ядра и ssh). Посмотрите на «кеш-память», «буферы» и «свободные» поля сверху, они не используют память, используемая память «отсутствует» и не восстанавливается без перезагрузки.
Попытка использовать эту «отсутствующую» память заставляет сервер обмениваться, замедлять сканирование и в конечном итоге замораживать.
Оборудование
Я наблюдал это на 3 серверах из примерно 100 до сих пор (хотя другие могут быть затронуты). Один из них — Intel Atom D525 @ 1.8ghz, а второй — Core2Duo E4600 и Q6600. Один использует JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller, остальные используют Qualcomm Atheros Attansic L1 Gigabit Ethernet (rev b0).
Я запускал lshw на серверах проблем, а также на примере сервера OK. Серверы проблем: http://pastie.org/10370534 http://pastie.org/10370537 и http://pastie.org /10370541 — OK Сервер: http://pastie.org/10370544
Применение
Это совершенно безгласное приложение. Монитор не подключен, и фактически XServer не установлен. Это должно исключать графические драйверы /проблемы.
Сервер используется для прокси-сервера и анализа RTSP-видео с использованием live555ProxyServer, ffmpeg и openCV. Эти серверы проходят через большой трафик, потому что это приложение для видеонаблюдения: http://pastie.org/9558324
Я пробовал как очень старые, так и последние версии транков live555, ffmpeg и openCV без изменений. Я также пытался использовать opencv через модули python2 и python3, без изменений.
Точное программное обеспечение /конфигурация загружена на 100 серверов, до сих пор 3 подтвердили утечку памяти. Серверы медленно и незаметно протекают вокруг xMB (один протекал 8 Мбайт, один медленнее, один быстрее) в час, пока все порты не исчезли, серверы начинают сильно меняться, замедляются до обхода и требуют перезагрузки.
MemInfo
Опять же, вы можете видеть, что Cached и Buffers не используют много памяти. HugePages также отключены, поэтому это не преступник.
Свободный выход
Free показывает следующее (примечание кэшировано, а буферы оба низки, поэтому это не кеш диска или буферы!) — память не восстанавливается без перезагрузки:
Если мы вычитаем /добавляем буферы /кеш к используемым и свободным, мы видим:
- 1,772MB действительно используется (- Буферы /Кэш) = 1,838MB используется — 1MB буферы — 66 МБ кэша
- 220 МБ действительно бесплатно (+ буфер /кеш) = 154 МБ свободных + 1 МБ буферов + 66 МБ кэша
Точно так же, как мы ожидаем:
Таким образом, около 1,7 ГБ не используется в пользовательском пространстве и фактически используется ядром, так как система фактически использует 53,7 МБ (см. вывод PS Mem ниже).
Я удивлен количеством комментариев, которые считают, что 1,7 Гбайт используется для кеширования /буферов — это принципиально неверное истолкование вывода! — эта строка означает используемую память , исключая буферы /кеш , подробнее см. в файле linuxatemyram.com.
Выход PS
Ниже приведен полный список запущенных процессов, отсортированных по памяти:
Вот полный список всех запущенных процессов:
Выходной сигнал PS
Выход Slabtop
Ятакже попробовал slabtop:
Другие
Я также пробовал сканировать руткит с rkhunter — ничего не нашел. И я попытался синхронизировать и сбрасывать кеш с помощью:
Это тоже не имело значения.
Я также попытался принудительно отключить или отключить swap с помощью
Я также пытался использовать htop и сортировать по памяти, и он не показывает, куда идет память. Версия ядра — это Linux 3.13.0-40-общий # 69-Ubuntu SMP.
Заключение
Что происходит? — Где все память идет? — Как узнать?
4 ответа
Мое заключение — это утечка памяти ядра где-то в ядре Linux, поэтому ни один из инструментов пользовательского пространства не может показать, где происходит утечка памяти. Возможно, это связано с этим вопросом: https://serverfault.com/вопросы /670423 /Linux-памяти-использование-выше, чем сумма-из-процессов
Я обновил версию ядра с 3.13 до 3.19, и кажется, что утечка памяти прекратилась! — Я верну отчет, если снова увижу утечку.
Было бы полезно иметь простой /простой способ узнать, сколько памяти используется для разных частей ядра Linux. По-прежнему остается загадкой, что вызывало утечку в 3.13.
Вы меняете Swapiness своего ядра или отключите его?
вы можете узнать текущий уровень подкачки с помощью
Вы можете попытаться заставить ваше ядро агрессивно меняться с помощью
, если это уменьшит ваши проблемы, найдите хорошее значение между 1 и 100, подходящее для вашего требования.
История
Я могу воспроизвести вашу проблему, используя ZFS в Linux .
Вот сервер с именем node51 с помощью 20GB ОЗУ. Я обозначил 16GiB ОЗУ для размещения в Кэш адаптивной замены ZFS (ARC) :
Затем я прочитал файл 45GiB , используя Pipe Viewer в моем пуле ZFS zeltik , чтобы заполнить ARC:
Теперь посмотрите на свободную память:
51MiB в буферах
69MiB в кеше
120MiB в обоих
19688MiB используемой ОЗУ, включая буферы и кеш
19568MiB используемой ОЗУ, исключая буферы и кеш
Сценарий Python, на который вы ссылаетесь, сообщает, что приложения используют только небольшой объем оперативной памяти:
19568MiB — 137.4MiB ≈ 19431MiB неучтенной ОЗУ
Объяснение
120MiB используемых буферов и кешей, которые вы видели в приведенной выше истории, для эффективного управления кэшированием данных ядра, отправленных или полученных с внешнего устройства.
Первая строка, помеченная Mem , отображает использование физической памяти, включая объем памяти, выделяемый для буферов и кешей. буфер, также называемый буферной памятью , обычно определяется как часть память, которая откладывается как временное место для хранения данных, которые отправляется или принимается с внешнего устройства, такого как жесткий диск, клавиатуры, принтера или сети.
Вторая строка данных, которая начинается с — /+ buffers /cache , показывает объем физической памяти, которая в настоящее время предназначена для системного буфера Кэш . Это особенно важно в отношении применения программ, поскольку все данные, поступающие из файлов в системе, которые выполняются с помощью read () и write () системных вызовов pass через этот кеш. Этот кеш может значительно ускорить доступ к данным посредством уменьшая или устраняя необходимость чтения или записи на жесткий диск или другой диск.
Теперь, как мы учитываем недостающие 19431MiB ?
В выводе free -m , 19688MiB « used » в « — /+ buffers /cache » происходит из этой формулы:
(Если вы делаете цифры на основе моего вывода free -m , вы заметите, что 2MiB не учитываются, но это из-за ошибок округления, введенных этим кодом: #define S(X) ( ((unsigned long long)(X) > shift) )
Цифры не складываются в /proc/meminfo , либо (я не записывал /proc/meminfo , когда я запускал free -m , но из вашего вопроса можно видеть, что /proc/meminfo не показывает, где отсутствует ОЗУ), поэтому из вышесказанного можно сделать вывод, что /proc/meminfo не рассказывает всю историю.
В моих условиях тестирования язнают как контроль, что ZFS на Linux отвечает за использование высокой ОЗУ. Я сказал ARC, что он может использовать до 16GiB ОЗУ сервера.
ZFS в Linux не является процессом. Это модуль ядра.
Из того, что я нашел до сих пор, использование ОЗУ модуля ядра не отображалось с помощью инструментов информации о процессе, потому что модуль не является процессом.
Устранение неполадок
К сожалению, я не знаю достаточно о том, что Linux предлагает вам способ создания списка того, сколько ресурсов не обрабатываются операционными компонентами (например, ядром и его модулями).
В этот момент мы можем спекулировать, догадываться и проверять.
Вы предоставили вывод dmesg . Хорошо разработанные модули ядра будут записывать некоторые из своих данных в dmesg .
Просматривая dmesg , мне выделился один элемент: FS-Cache
FS-Cache является частью cachefiles и относится к пакету cachefilesd в Debian и Red Hat Enterprise Linux.
Возможно, некоторое время назад вы сконфигурировали FS-Cache на диске RAM, чтобы уменьшить влияние сетевых операций ввода-вывода, поскольку ваш сервер анализирует видео данных.
Попробуйте отключить любые подозрительные модули ядра, которые могли бы сесть в ОЗУ. Вероятно, они могут быть отключены с помощью blacklist в /etc/modprobe.d/ , а затем sudo update-initramfs -u (команды и местоположения могут различаться в зависимости от дистрибутива Linux).
Заключение
Утечка памяти теряет 8MB/hr вашей ОЗУ и не освобождает ОЗУ, похоже, что бы вы ни делали. Я не смог определить источник утечки памяти на основе предоставленной вами информации и не смог найти способ найти утечку памяти.
Тот, кто более опытен с Linux, чем мне нужно будет предоставить информацию о том, как мы можем определить, куда идет «другое» использование ОЗУ.
Я начал щедрость по этому вопросу, чтобы узнать, можем ли мы получить лучший ответ, чем «спекулировать, догадываться и проверять».
Вы не совсем правы — да, ваша бесплатная команда -m показывает бесплатную 220MB, но она также показывает, что 1771MB используется в качестве буферов. Буферы и кэширование — это память, используемая ядром для оптимизации доступа к данным медленного доступа, обычно к дискам. Поэтому вы должны учитывать всю память, помеченную как буферы, как свободную память, потому что ядро может вернуть ее, когда это требуется.
Источник
