Как определить утечку памяти linux

Невидимая утечка памяти на 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 используется в качестве буферов. Буферы и кэширование — это память, используемая ядром для оптимизации доступа к данным медленного доступа, обычно к дискам. Поэтому вы должны учитывать всю память, помеченную как буферы, как свободную память, потому что ядро ​​может вернуть ее, когда это требуется.

Источник

Русские Блоги

Как определить, есть ли утечка памяти в программе под Linux?

Язык C — это язык, которого никогда нельзя избежать при разработке встраиваемых систем. Будь то операционная система или разработка с нуля, эффективность языка C проявляется повсюду.Язык C может напрямую управлять памятью и имеет идеальный механизм управления памятью. Если вы используете его хорошо, вы можете резать железо, как грязь, а если вы не используете его хорошо, вы можете порезать себе руки!

Будь то C или C ++, многие студенты неизбежно совершают ошибку утечки памяти. Поскольку мы обычно пишем небольшие программы, даже если запрошенная память не высвобождается, это не повлияет на результаты программы, поэтому мы редко обращаем внимание на утечки памяти. Но если поставить эту проблему в коммерческий проект, это будет большой скрытой опасностью.

Как определить, есть ли в программе утечка памяти, сегодня я поделюсь с вами общим инструментом —valgrind。

valgrind Его можно назвать артефактом отладки памяти Linux, вы можете использовать его для обнаружения утечек памяти, диких указателей или проверки вызовов функций, кешей и проблем использования стека. Первый взглядvalgrind Руководство для мужчин:

Его основные функции помещены в параметр [–tool =].

memcheck: это наиболее широко используемый инструмент valgrind. Это тяжелая программа проверки памяти, которая может найти большинство ошибок памяти при разработке, таких как: использование неинициализированной памяти, использование памяти, которая была освобождена, доступ к памяти за пределами границ и т. д. .

callgrind: в основном используется для проверки проблем в процессе вызова функции в программе.

cachegrind: в основном используется для проверки проблем с использованием кеша в программе.

helgrind: в основном используется для проверки проблем конкуренции в многопоточных программах.

massif: в основном используется для проверки проблем с использованием стека в программе.

extension: вы можете использовать функции, предоставляемые ядром, для написания ваших собственных специальных инструментов отладки памяти.

Неинициализированный указатель

test1.c

Лучше всего добавить параметр [-g] при компиляции. Параметр [-g] может видеть номер строки при отладке.

Проходитьvalgrind Отладчик.

Отладочная информация ясно говорит нам, что существует проблема с 7-й строкой программы: 1. Используется неинициализированный указатель; 2. Незаконный доступ к указателю. Вызвать segfault в конце программы.

Утечка памяти

test2.c

Добавьте [–leak-check = full] для повторного запуска:

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

Использовать дикий указатель

test3.c

результат операции:

Хотя в программе используются «дикие» указатели, во время работы не возникает ошибок сегментации. Здесь управление памятью языка C не является строгим.Ошибка сегментации возникает только при доступе к памяти, защищенной системой.Хотя память освобождена, она не защищена, поэтому даже при обращении к ней проблем не возникнет. Однако valgrind все еще может обнаружить это незаконное использование.

Стек за пределами доступа

test4.c

результат операции:

Освободите память несколько раз

test5.c

новый и удалить

valgrind То же самое относится к программам на C ++. Например, команды new и delete не совпадают, и доступ к стековой памяти осуществляется вне пределов. Использование такое же, как и выше, поэтому здесь код не пишется.

подводить итоги

При обнаружении проблемы трудно обнаружить проблему утечки памяти, поэтому в настоящее время valgrind может проявить большую мощность.В то же время я также хочу напомнить всем, что вам также следует уделять внимание при написании кодов. После того, как вы подадите заявку на память, вы должны освободить ее. Так же, как пойти в библиотеку, чтобы взять книгу, библиотека рано или поздно закроется. Развивайте хорошие навыки программирования, ведь отладка программ — пустая трата времени.

Больше статей, видео, встроенных обучающих ресурсов, подпишитесь на WeChat【Интеллектуальное оборудование Xueyide】

Интеллектуальная рекомендация

Используйте Maven для создания собственного архетипа скелета проекта (4)

Один, базовое введение в Maven Во-вторых, скачайте и настройте Maven Три, настроить домашнее зеркало на Али В-четвертых, создайте содержимое скелета архетипа В-пятых, создайте проект через архетип 6. .

Станция интерпретации больших данных B пользуется популярностью среди гигантов района «призрачные животные» Цай Сюкуня.

Автор | Сюй Линь Ответственный редактор | Ху Вэйвэй Предисловие Недавно Цай Сюкунь отправил письмо юриста на станцию ​​B. Содержание письма юриста показало, что «на станции B имеется большое кол.

Вопрос A: Алгоритм 7-15: алгоритм кратчайшего пути Дейкстры

Название Описание Во взвешенном ориентированном графе G для исходной точки v задача о кратчайшем пути от v до оставшихся вершин в G называется задачей кратчайшего пути с одной исходной точкой. Среди ш.

Учебный дневник — перелистывание страниц

Используйте плагин Layui.

Нулевое основание для отдыха-клиента

Предисловие: статья, обобщенная, когда я только что связался с тестом API, в дополнение к остальному клиенту этот инструмент сам, некоторые из мелких пониманий API, я надеюсь помочь тому же белую белу.

Вам также может понравиться

Подробно объясните, как новички используют sqlmap для выполнения инъекционных атак на базы данных mysql.

Шаг 1. Откройте для себя инъекцию Со мной все было нормально, когда я был свободен, я случайно нажал на чужой блог и обнаружил, что ссылка заканчивается на id, поэтому я проверил его вручную. Результа.

Vue заметки сортируют, пусть вам начать с Vue.js:. 04_3 Сетевое приложение: AXIOS плюс Вью

В предыдущем разделе мы ввели основное использование AXIOS, по сравнению с нативным Ajax, который при условии, что способ является более простым и, а сетевые данные теперь в состоянии получить его ров.

Шаблон алгоритма конной повозки

Блог гангстеров Тележки, запряженные лошадьми, используются для решения проблемы самой длинной подстроки палиндрома. Основное внимание уделяется подстрокам, а не подпоследовательностям. Если вы хотите.

35 Line Code, чтобы получить метод исследования событий (ON)

Об авторе: Чжу Сяою，Личный публичный номер: языковой класс большой кошки Эта проблема научит вас этой большой классе Cat.Как написать наиболее эффективное метод исследования событий с 35 Line R Code C.

Образ докера: gitlab

GitLab Docker images Both GitLab CE and EE are in Docker Hub: GitLab CE Docker image GitLab EE Docker image The GitLab Docker images are monolithic images of GitLab running all the necessary services .

Источник