предисловие

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

В самом деле, еще в прошлом году, я имел дело с подобными проблемами, и записал: «После того , как расследование с целью оптимизации производства 100% практики CPU»

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

анализ

После получения по электронной почте, я сразу зашел на этот сервер, также посмотрел на месте преступления (нагрузка по-прежнему высока).

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

Во - первых, top -cиспользование ресурсов системы отображается в режиме реального времени ( -cпараметры могут отображаться полный команду).

Затем введите 大写 Pзаявку в соответствии с CPUиспользованием сортировки, первый самый высокий коэффициент использования программы.

Конечно , это один из наших Javaприложений.

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

Вторым шагом является естественными рутинными операции должны знать это приложение потребляющего большинство CPUнитей в конце концов делает.

Использование top -Hp pidи ввести Pеще может последовать CPUиспользование потоков сортировки.

На этом этапе нам нужно только помнить идентификатор потока , чтобы преобразовать его в шестнадцатеричный хранится, путем jstack pid >pid.logсоздания файла журнала, используйте шестнадцатеричный только что сохраненный процесс IDдля поиска снимка этого потока , чтобы знать расход CPUнити делает.

Если Вы находите это хлопотно, я настоятельно рекомендую Али с открытым исходным кодом проблема позиционирования артефакт , arthasчтобы локализовать проблему.

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

Подробнее о Артас руководстве , пожалуйста , обратитесь к официальной документации .

Потому что, прежде чем я забываю выстрелы, и здесь я делаю вывод, что это напрямую:

Зеленый загруженная нить это GCнить, которая означает , что он занят сбор мусора.

GC Просмотр

Исследование здесь, опытные пожилые водители будут думать: в основном использование памяти приложение вызывает проблемы.

К тому времени я jstat -gcutil pid 200 50распечатать (каждый 200мс печататься в 50 раз) использование памяти, восстановление дс ситуация.

Информация может быть получена из следующего рисунка:

EdenРайон и oldобласть почти заполнены, видимое восстановление памяти проблематично.
fgcВосстановление высокой частоты, выздоровление наступило в течение 8 времен 10s ( (866493-866485)/ (200 *5)).
Длится дольше, FGC 8W случалось много раз.

Анализ памяти

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

Команда jmap -dump:live,format=b,file=dump.hprof pidможет экспортировать файл снимка.

Тогда мы должны помочь MATтакого рода инструментов анализа для запуска на.

проблема позиционирования

В самом деле, очевидно, что эта картина, есть очень большая строка в памяти, и эта строка просто это временная ссылка на целевой нить.

Возможно забыть об этой строке памяти, занятой около 258 млн, на строку уже очень большие объекты.

Эта строка является громким шумом, который произвел его?

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

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

Окончательный снимок нашел эту тему по конкретной бизнес-код:

Он вызывает метод в записи в базе данных, и этот метод будет сращивать с insertзаявлением, в котором valuesэто сшивание поколение цикла, вероятно , следующим образом :

    <insert id="insert" parameterType="java.util.List">
        insert into xx (files)
        values
        <foreach collection="list" item="item" separator=",">
            xxx
        </foreach>
    </insert>
复制代码

Поэтому, как только этот список очень большой, эта мозаика оператор SQL будет очень долго.

Только с помощью анализа памяти на самом деле можно увидеть , что это Listочень большой, это также привело к окончательному insertбольшое заявление занимаемой памяти.

Стратегия оптимизации

Так как это хорошо, чтобы найти причину этой проблемы будет решена, есть два направления:

Контроль исходного Listразмера, это Listбудет приобретено у таблиц данных, может приобретать подкачки, так что последующие insertзаявления будут уменьшены.
Контроль размер партии данных записи, на самом деле, суть или должны сращивание SQLдлины вниз.
Вся эффективность письма должна быть пересмотрена.

резюме

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

Сначала найдите потребительский CPUпроцесс.
Переориентация потребляет CPUопределенную нить.
Проблемы с памятью dumpанализа снимков.
Заключенный настроить код, результаты тестирования.

Наконец, я хотел бы не получил предупреждение производства.

Поделитесь своими пальцами и самая большая поддержка для меня

Еще раз, производство практики следственной нагрузки высоких CPU