Автор | Мейсон М.А.

[Официальное сообщество Артаса проводит конкурс сочинений, за участие можно получить призы~Нажмите, чтобы отправить】

Arthas - хороший инструмент, а тут другая волна Amway.Конечно, во всем процессе используются и другие инструменты, такие как MAT, YourKIT (это платно), а при совместном использовании легче находить и решать проблемы . В этот период я ​​также много раз общался с крупными разработчиками и соответственно получал разную информацию.

Установка и запуск Arthas в один клик

• Способ 1. Внедрение удаленной диагностики Arthas одним щелчком мыши с помощью Cloud Toolkit.

Cloud Toolkit 是阿里云发布的免费本地 IDE 插件，帮助开发者更高效地开发、测试、诊断并部署应用。通过插件，可以将本地应用一键部署到任意服务器，甚至云端（ECS、EDAS、ACK、ACR 和 小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算 和 MySQL 执行器等工具。 Не только основная версия IntelliJ IDEA, но и другие версии, такие как Eclipse, Pycharm, Maven и т. д.

Рекомендуется использовать плагин IDEA для загрузки Cloud Toolkit для использования Arthas:He. Special. Talent/2A5CB HW VE ox…

• Способ 2: Прямая загрузка

адрес:GitHub.com/Alibaba/art….

Феномен

• Строительство индекса фоновых приложений, чувствуя себя меньше так много памяти, и теперь использует каждый день или два OOM, нужно перезапустить;
• Существуют полные данные и добавочные данные, OOM в основном происходит на этапе записи полных данных, а OOM в основном происходит, когда обновление полных данных запускается в первый раз ранним утром;
• Бизнес-приложение использует сборщик G1 (Advanced Premium...).

Внутренняя ОС: Упс, что мне делать, если я не знаком с G1, сначала найти способ избавиться от больших парней, а я сам изучу.

У меня есть еще кое-что, я посмотрю позже

Гипотеза Гауда

Судя по имеющейся у вас информации, сделайте смелое предположение, и вы не потеряете деньги, если все равно ошибетесь.

• Это потому, что полный объем записываемых данных превышает пропускную способность кучи, что приводит к OOM?
• Есть ли в бизнесе статический контейнер, который используется не по назначению, не был переработан и в него помещаются элементы, поэтому на OOM уходит два дня?
• Не хватает памяти, какие объекты занимают больше всего, выясните в первую очередь?
• Есть крупные объекты?

дрожу от доказательств

Основная информация

Параметры запуска процесса

-Xms12g 
-Xmx12g
-XX:+UseG1GC 
-XX:InitiatingHeapOccupancyPercent=70 
-XX:MaxGCPauseMillis=200 
-XX:G1HeapWastePercent=20 
-XX:+PrintAdaptiveSizePolicy 
-XX:+UseStringDeduplication 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintGCApplicationStoppedTime 
-XX:+PrintTenuringDistribution 
-Xloggc:/home/search/fse2/gc.log
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=2 
-XX:GCLogFileSize=512M 
-XX:+UnlockDiagnosticVMOptions 
-XX:+PrintNMTStatistics 
-XX:NativeMemoryTracking=summary

Видно, что используется сборщик G1, что раньше не было распространено в бизнес-разработке, ведь это сборщик мусора с низкой задержкой, построенный для большой памяти. Что касается некоторых основных функций коллектора G1, вы можете собрать некоторую информацию. Вероятно, в основном это включает в себя следующее:

• Механизм разделения регионов
• SATB, полное название Snapshot-At-The-Beginning, в буквальном понимании — это снимок объекта, который был жив, когда стартовал сборщик мусора
• Rset, полное название Remembered Set, представляет собой структуру, помогающую процессу GC, идею пространства для времени.
• Pause Prediction Model — это модель прогнозирования пауз.

Судя по этим свойствам G1, он рассчитывает уменьшить ручную настройку операций и реализовать автоматическую настройку (говоря об этом, я чувствую, что появившийся на этот раз OOM, похоже, не связан с самим сборщиком мусора, не из-за объема бизнеса .Большой кучи памяти не хватает, и первопричина может быть на уровне логики кода), и подходит для сценариев, где снижается стоимость железа и постепенно увеличивается большая куча памяти (позже ZGC и Shenandoah , которые также являются волшебными, которые могут управлять большой памятью и имеют очень низкие паузы (сборщик мусора).

Журнал сборщика мусора уже есть, поэтому сначала просмотрите лог и найдите исключение:

#### 这里Heap回收的还只是300多M内存
[Eden: 316.0M(956.0M)->0.0B(1012.0M) Survivors: 48.0M->44.0M Heap: 359.2M(12.0G)->42.0M(12.0G)]
 [Times: user=0.31 sys=0.01, real=0.05 secs]
2020-06-09T02:59:23.489+0800: 2020-06-09T02:59:23.489+0800: 35.922: Total time for which application threads were stopped: 0.0578199 seconds, Stopping threads took: 0.0000940 seconds
35.922: [GC concurrent-root-region-scan-start]
......
......
......
#### 这个点Heap回收的就是11G内存了
[Eden: 724.0M(1012.0M)->0.0B(540.0M) Survivors: 44.0M->72.0M Heap: 11.5G(12.0G)->355.6M(12.0G)] 
 [Times: user=1.51 sys=0.07, real=0.26 secs]
2020-06-09T03:12:36.329+0800: 828.762: Total time for which application threads were stopped: 0.2605902 seconds, Stopping threads took: 0.0000600 seconds

Первоначальный ввод в эксплуатацию

Увеличьте значение параметра -XX:G1ReservePercent, чтобы увеличить объем зарезервированной памяти для «целевого пространства».

уменьшать-XX:InitiatingHeapOccupancyPercentЗаранее начните цикл маркировки

Есть подозрение, что во время GC большое количество данных было записано полностью, а память не высвобождена.Было записано большое количество объектов, что вызывало OOM, поэтому был скорректирован цикл запуска, и доля упала. с 70 до 55. Он срабатывал заранее и резервировал больше места.

GC стал частым, но проблема избыточного использования памяти не была объяснена. А появится ли ООМ снова ранним утром, придется подождать. . . Так что продолжайте смотреть, есть ли какие-либо другие проблемы.

продолжать копать

Если есть сомнения, ответа нет, и надо продолжать копать.Просто бери клавиатуру и делай, а операция лютая как тигр.

Arthas

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

dashboard

Посмотрите на базовую ситуацию, количество потоков, размер кучи, размер старости и коэффициент использования. Когда я впервые увидел это, заполняемость райских и старых областей была довольно высокой, 70~80% (забыл тогда сделать скриншот). Использование памяти относительно велико.

thread

Проверяем, не является ли количество потоков аномальным.Количество потоков в норме, но найдены потоки с высоким потреблением ресурсов.Один из потоков появится позже в другой информационной статистике:

YJPAgent-Telemetry 
ctrl-bidsearch-rank-shard1
YJPAgent-RequestListener
ctrl-bidsearch-rank-shard1

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

profiler

Соберите данные графика пламени памяти и процессора соответственно:

# 内存
profiler start --event alloc
###
profiler stop

# 默认CPU
profiler start
###
profiler stop

• CPU

• ОЗУ

На графике процессорного пламени видно, что поток сборщика G1 фактически занимает половину ресурсов.Возможно, в это время собирался сборщик мусора.Однако в остальном он может в основном располагаться как потокIncrementIndexServiceкласс, который использует больше ресурсов процессора и памяти.

Если бизнес-код действительно ошибочен, он должен быть в этом процессе.После общения выясняется, что главный вход в задачу обработки приложения действительно находится в этом. Сначала бронируйте места.

Поток, видимый потоком, и класс, видимый профилировщиком, в конечном счете находятся в одном и том же бизнес-процессе.

Начинайте проверять гипотезу до того, как:

1. Заполняется ли большое количество объектов памятью при полной записи данных?

После подсчета объема данных, полученных некоторыми бизнес-кодами, метаданные составляют около 1,3 Г. Даже если будет записан полный объем данных, он не должен занимать 12 Г кучи памяти, поэтому предполагается, что при полном объеме данных записывается, могут быть некоторые дефекты в логике кода, в результате чего исходные данные 1,3G инкапсулируются в объекты, намного большие, чем 1,3G.

2. Есть ли статический контейнер?

Да, но после просмотра наблюдения не обнаружено, что контейнер только ставится, но не удаляется.Команда следующая:

watch com.xxx.classname method "{params,target}" -x 3

3. Есть ли крупные объекты?

Для G1 куча по умолчанию разделена на 2048 регионов, куча 12G, регион 6M, а более 3M — большой объект.

jmap histo 30123

По крайней мере, в выходных данных большой объект не является большим объектом, определенным G1.

MAT

Поскольку ничего не найдено, просто сбрасываем кучу. Если вы не хотите или не можете делать дамп, вы также можете использовать jmap histo для просмотра использования памяти. Связь с бизнес-кодом.

Предупреждение: Обязательно отключите трафик перед операцией jmap или Arthas heapdump. К счастью, у нашего сервиса нет онлайн-трафика, а индексация происходит с задержкой, что может временно повлиять на удобство поиска.

После дампа выяснилось, что там 7 Гб, а такой большой файл вообще сложно передать на локалку для анализа.Поэтому используется MAT, чтобы занять 1 Гб памяти сервера для анализа, а результаты анализа скачал на локалку.

Имя потока согласуется с информацией, найденной ранее, и при использовании деталей есть сюрприз.

Строка странных строк, немного похожая на XML, похоже, что-то собирает, поэтому я нашел бизнес-босса, чтобы спросить совета, и обнаружил, что действительно есть логика для сборки solrDocument, и, после того, как YourKit выводит некоторые фрагменты значений объекта , можно обнаружить, что большинство из них находятся в повторной сборке, что примерно означает следующее:

<xml>
...
<country>CA</country>
<country>CA</country>
<country>CA</country>
<country>CA</country>
<country>CA</country>
...n次重复
<country>US</country>
<country>US</country>
<country>US</country>
<country>US</country>
<country>US</country>
<country>US</country>
...n次重复
<country>UK</country>
<country>UK</country>
...
</xml>

Модификация логики кода на самом деле относительно проста, руководители бизнес-развития лучше знакомы с бизнес-процессом и скоро будут иметь план модификации.

После настройки было обнаружено, что использование памяти сильно упало.

Он упал сразу примерно до 4-5G.Если это так, то даже если записывается полный объем данных и выполняется сборка мусора, этого должно быть достаточно. Но я чувствую, что в этой логике кода должно быть место для оптимизации, однако сначала решите проблему, а оптимизация может сделать следующий шаг.

Рассмотрение

Независимо от того, из какого инструмента получены данные, они показываютIncrementIndexServiceМожет быть проблема с логикой этого класса.Корень проблемы, похоже, не имеет ничего общего с настройкой параметра G1.Коренной причиной является дефект логики кода.Расширение памяти или настройка параметров JVM может только облегчить ошибка, но она не может быть решена.

• От процесса к потоку к коду

• Получить базовую информацию о JVM, сборщики, параметры запуска и другую информацию

• Просмотр существующих журналов, журналов GC, бизнес-журналов

• Обсуждать бизнес-сценарии, понимать масштаб входных данных и т. д.

• Угадай возможную причину, сделай смелое предположение

• Используйте инструменты (Arthas, MAT, YourKit, встроенные команды JDK и т. д.) для сбора информации, графиков пламени, энергоемких потоков, дампов стека потоков, анализа пропорций, больших объектов...

• Совмещая реорганизацию данных с поиском корреляции бизнес-кодов и возможных дефектов, можно попытаться скорректировать параметры

• Если в бизнес-коде есть ошибка, исправьте ошибку

Arthas Call for Papers в самом разгаре

Артас держит призыв к бумагам, если у вас есть:

• Устранение неполадок с Артасом
• Интерпретация исходного кода Артаса
• Сделать предложение Артасу
• Не ограничено, другой контент, связанный с Артасом

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

"Облачная нативная платформа AlibabaСосредоточьтесь на микросервисах, бессерверных технологиях, контейнерах, Service Mesh и других технических областях, сосредоточьтесь на популярных тенденциях облачных технологий и практиках крупномасштабного внедрения облачных технологий, а также станьте официальной учетной записью самых облачных разработчиков. "