Введение
"Привет всем, я восторженные массы Чаоян."
Недавно в некоторых группах open source сообщества я увидел, что у некоторых студентов был ООМ в онлайн-среде, и они срочно обратились за помощью в группу. Для справки, одноклассники сначала перехватили вывод в лог-системе, информацию об исключении OOM в верхнем регистре стека исключений. Одноклассник сказал: «Сегодня я несколько раз перезапускал службу. Возможно, это утечка памяти, но я не могу найти, где утечка. С чего мне начать это исследовать?». Возможно, вы сталкивались с плохо написанным кодом в процессе разработки, что приводило к утечкам памяти и, наконец, к OOM всего сервиса.Конечно, это OOM является общим термином, и OOM будет происходить в 4 блоках JVM.Это то, что я писал в предыдущей статье:«[Внутреннее развитие силы, серия 2] Дайте импульс JVM»Как уже упоминалось, незнакомые студенты могут прочитать его внимательно.
То, что мы называем OOM, является относительно распространенной проблемой для разработчиков JAVA, и это также обязательный пункт проверки в процессе собеседования. Лично я боролся с этим много лет назад, и я также сталкивался с такими сценариями, как многопоточность, неправильная ссылка на объекты в классах коллекций, рекурсивные циклы и т. д., из-за которых онлайн-сервис OOM зависал и злился. . Я помню, что когда это было еще одно приложение, коллега добавил логику бизнес-обработки при записи логов через log4j, но она не обрабатывалась должным образом в ссылке appender, что приводило к утечкам памяти из-за того, что объекты не перерабатывались в потоке, когда число пользователей увеличилось. В начале я постоянно подгонял параметры для Tomcat и увеличивал стартовую память JVM. Так что какое-то время при обнаружении OOM необходимо перезапускать и добавлять память, но это всегда бесполезно.В конце концов, необходимо внести изменения на уровне кода, чтобы найти основную причину утечки памяти. и полностью вылечить.
Сегодня давайте рассмотрим причины OOM и некоторые методы устранения неполадок, которые помогут вам решить проблемы типа "O".
Понятия, связанные с OOM
"Давайте сначала рассмотрим с вами связанные концепции OOM:"
OOM
❝Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
❞
Полное название OOM — OutOfMemory, на официальном сайте оно переводится так: JVM выдает эту ошибку, когда не хватает памяти для выделения места под объекты, а сборщику мусора негде освободить место.
утечка памяти
Память, используемая приложением, не была освобождена и не может быть восстановлена, поэтому JVM не может снова использовать память.В настоящее время происходит утечка памяти. Это "вам не надо, не используйте для других!".
переполнение памяти
Объем памяти, запрошенный программой, превышает объем памяти, который может предоставить JVM, что приведет к переполнению памяти. В большинстве случаев переполнение памяти вызвано утечками памяти, а трафик действительно велик, а служба не была эластично расширена или ток службы ограничен, что приводит к переполнению памяти. Я не могу этого вынести!
Повседневная жизнь ООМ
Из-за медицинского бизнеса пиковый период бизнеса наступит в понедельник утром, уже в период единого приложения до обновления архитектуры службы, потому что уровень разработчиков неравномерен, и все предприятия связаны друг с другом. Особенно в период роста бизнеса время от времени будут возникать такие сбои, как OOM и высокая загрузка ЦП сервера. Эксплуатационный и обслуживающий персонал или персонал по исследованиям и разработкам смотрят на мониторинг сервера.Во многих случаях память увеличивается, и она вот-вот перестанет поддерживаться, поэтому они перезапускают службу. Это действительно «эксплуатация и обслуживание искусственного интеллекта»! В то время коллега, перезапустивший службу, сделал дамп моментального снимка памяти и моментального снимка потока и отправил его персоналу отдела исследований и разработок для анализа. За это время эксплуатационный и обслуживающий персонал тоже был жалким!
Позже, с развитием бизнеса и ростом персонала, он постепенно перешел на микросервисную архитектуру. До реализации автоматического масштабирования служб в отдельных службах время от времени возникает OOM. Конечно, наша система мониторинга также устанавливает пороговые значения.Например, всякий раз, когда сервис превышает 80% памяти, коллеги, отвечающие за эксплуатацию и техническое обслуживание, а также коллеги по исследованиям и разработкам будут получать набор предупреждений по SMS, электронной почте и мгновенным сообщениям. Или услуга слишком поздняя для обработки, это уже OOM, процесс обслуживания зависает там, и моментальный снимок автоматически экспортируется.Коллеги по эксплуатации и обслуживанию отправляют снимок соответствующим коллегам по исследованиям и разработкам для анализа, и обнаруживается, что все равно будет утечка памяти, которая приведет к OOM.
Устранение неполадок OOM
Далее, в сочетании с нашей текущей ситуацией, мы представим метод борьбы с OOM.
1. Запуск службы плюс параметры
Вот что у нас есть на git.Добавлен индексный файл Deployment.yml каждого сервиса.При появлении OOM файл моментального снимка будет экспортирован по пути DUMP_PATH. Затем выполните jenkinsfile через jenkins, выполните сценарий sh под образом докера и запустите службу. Конечно, это можно настроить и через скрипты и т.д. Я считаю, что каждая компания индивидуальна, но важно добавить-XX:+HeapDumpOnOutOfMemoryErrorа также-XX:HeapDumpPathЭти два параметра запуска, так что в случае OOM моментальный снимок в это время также может быть сохранен, чтобы помочь персоналу отдела исследований и разработок в анализе.
2. Проверьте журнал
При возникновении OOM система мониторинга выдаст предупреждение, а мы получим кучу коротких сообщений, IM-сообщений и т.д., поэтому скриншоты здесь делать не буду. В любом случае, это определенная вами информация о тревоге. Позже при эксплуатации и ремонте службы мы перейдем к Kibana, чтобы запросить соответствующие журналы в соответствии с сообщением.
Здесь мы переключимся на фильтр связанной службы, чтобы запросить журнал службы.Конечно, диаграмма здесь просто для имитации, и данных для запроса OOM нет. При фактическом запросе журнала, если у службы есть OOM, будет соответствующая информация о стеке.
3. Эксплуатация и техническое обслуживание
Когда служба эксплуатации и обслуживания получает предупреждающую информацию, она отправляется на сервер для расследования. В первую очередь локализуем проблему обслуживания, то есть обычно проверяем некоторые команды сервера, такие как: top, jps, jinfo и эти основные операции. После обнаружения соответствующих служб, если требуется онлайн-анализ, в основном будут проверены соответствующие разработчики, включая стек, сборщик мусора, статус потока и другую связанную информацию. Разработчики будут использовать jmap, jstat и jstack для проверки по одному. Если OOM появится, то служба эксплуатации и обслуживания сделает снимок и отправит его разработчику для анализа.
4. Анализ ООМ
Симуляция ООМ
Это связано с тем, что в последнее время в системе не было OOM, и под рукой нет актуального содержимого обращения (потому что OOM произошло давно). Итак, я собираюсь написать демонстрацию и посмотреть на шаги и методы устранения неполадок. Как я уже говорил, причиной OOM иногда может быть не код, а неправильная настройка параметров и высокий трафик. Однако сегодня в основном речь идет о проблеме утечки памяти кода, которая приводит к переполнению памяти. Более того, помимо счетчика программ, у JVM появится OOM в куче, стеке виртуальной машины, области методов и локальном стеке методов. Так как наш ежедневный анализ памяти использует MAT (Eclipse Memory Analyzer, здесь нет необходимости устанавливать eclipse, его можно установить самостоятельно), поэтому я буду использовать этот инструмент для демонстрации сегодня.
"Вот пример переполнения динамической памяти непосредственно в коде:"
Здесь напрямую используется метод больших объектов, а грубый бесконечный цикл напрямую втыкает 10M объектов в память кучи. Параметры загрузочной памяти:-Xms10M -Xmx50M, и создайте снимок, когда установлен OOM, и сохраните его по указанному пути:-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=具体路径
"Конкретные настройки следующие:"
Конечно, если это локальная отладка, вы также можете использовать JProfile для мониторинга, и вы можете получить поток, память и т. д. службы в режиме реального времени Однако, если вам нужно открыть порт службы и получить его в реальном времени время, это принесет некоторое давление на службу. Я помню, что когда я использовал одно приложение, я также использовал jprofile для прямого подключения к службе для устранения неполадок.
Результат выполнения: программа запускается 8 раз, и пространство кучи сразу переполняется. Поскольку соответствующие параметры установлены, вывод:java_pid53518.hprofдокумент.
Устранение неполадок идей
"Вот конкретная идея использования MAT для проверки:"
- Просмотрите типы, потребляющие больше всего памяти, в представлении MAT и грубо проанализируйте причину утечек памяти;
- Просмотрите подробный список и цепочку ссылок на объекты большого типа, чтобы найти конкретную точку утечки памяти;
- просматривать значения и зависимости атрибутов объекта, а также разбираться в логике и параметрах программы;
- Проверьте поток, чтобы определить, связана ли проблема OOM со слишком большим количеством потоков;
- Найдите соответствующий код и измените его. Конечно, это может быть трагично, вы не проверили. . . .
расследование МАТ
- Старт МАТ:
Система Mac сообщит об ошибке при нажатии кнопки «Установить и запустить», поэтому запустите ее напрямую с помощью команды:/你的路径/MemoryAnalyzer -data ./dump
- загрузить файл hprof
Откройте основной интерфейс MAT, который является обзорным интерфейсом.Видно, что при использовании OOM размер всей кучи составляет 32,6 МБ, а некоторые объекты занимают 32 МБ. Теперь давайте посмотрим на объект.
- Посмотреть список объектов
Только что мы увидели, что результат запуска программы 8 раз. Здесь ровно 8 объектов, занимающих 32M, что и является ожидаемым результатом нашей программы. Далее, что это за объекты? Сколько экземпляров? В каком потоке работают объекты?
Щелкните большой объект, щелкните правой кнопкой мыши и введите входящие ссылки.
- Просмотр графика результатов объекта
В это время видно, что большой объект — это объект в ArrayList, Retained Heap (глубокая куча) представляет собой память, занимаемую самим объектом и объектом, связанным с объектом, а Shallow Heap (мелкая куча) представляет собой память, занятая самим объектом. Сам объект ArrayList занимает всего 24 байта, но все связанные с ним объекты занимают 33 МБ памяти. Это показывает, что должно быть что-то постоянно добавляющее объекты в этот ArrayList, вызывающее OOM. И он показывает код в основном потоке main программы. Это также ожидаемо от самого нашего кода.
- Проверьте ситуацию с потоком
Из ситуации с потоком видно, что ArrayList в основном потоке был связан с большим объектом, что привело к генерации OOM. В других потоках нет исключений, что действительно соответствует логике нашего кода.
- Последний шаг — избавиться от больших объектов, забитых в код, не зацикливаться бесконечно. . . . . задача решена.
Суммировать
Это лишь краткое введение в процесс расследования OOM.Конечно, в некоторых случаях это не так просто, онлайн-мониторинг - более сложная и хлопотная вещь. Лично я считаю, что самое главное — хорошо проделать проверку кода, системный мониторинг и журнал ключевых шагов. Мониторинг сервисов и управление ими — важная возможность для микросервисов и облачных систем, а также отражение технической мощи команды. Мы также постоянно совершенствуем наши возможности по отслеживанию и быстрому устранению неполадок. Мы надеемся, что эта простая идея поможет каждому что-то получить. Я буду продолжать поддерживать отношение обмена и добиваться прогресса со всеми.
"«Предыдущие статьи:»"
«[Развитие внутренней силы, серия 1] Линейная структура данных (Часть 1)»
«[Развитие внутренней силы, серия 1] Линейная структура данных (Часть II 1)»
«[Внутреннее совершенствование, серия 1] Линейная структура данных (Часть 2)»
«[Внутреннее развитие силы, серия 2] Дайте импульс JVM»
«[Развитие внутренней силы, серия 2] Трудная JIT»
специальное заявление
Данная статья является оригинальной статьей, если вам необходимо перепечатать, пожалуйста, свяжитесь со мной и укажите источник. Спасибо!