Теперь, когда наша внутренняя инфраструктура Puppet перенесена на Puppet 6 и настроена, пришло время переключить на нее вторую инфраструктуру.
Вчера я перенес нашу вторую инфраструктуру и начал видеть больше проблем. Эмпирические правила из прошлого поста были полезны, но мне все еще нужно было обновить доступную память, чтобы компенсировать нехватку вычислительной мощности (вероятно, это связано с базовыми виртуальными процессорами, регулирующими IaaS).
А затем произошел сбой кукольного сервера с превышением предела накладных расходов GC ошибка. Эта ошибка возникает, когда процессор тратит более 98% времени на сборку мусора.
Посмотрев на нашу панель управления Grafana, я понял, что у нас нет показателей по сбору мусора, поэтому я добавил график с двумя показателями:
- среднее время на GC: среднее время, затрачиваемое на выполнение каждого запроса на сборку мусора, рассчитываемое как скорость более 1 минуты (поскольку
jvm_gc_collection_seconds_sumявляется накопительным счетчиком) - Время GC: процент времени, затраченного процессорами на выполнение GC, более 1 минуты (поскольку
jvm_gc_collection_seconds_countтакже является накопительным счетчиком)
Формулы следующие:
время на запрос {{gc}}:rate(jvm_gc_collection_seconds_sum{job="puppetserver"}[1m])/rate(jvm_gc_collection_seconds_count{job="puppetserver"}[1m])оценить {{gc}}:оценить(jvm_gc_collection_seconds_sum{job="puppetserver"}[1m])
Затем я посмотрел на графики примерно в то время, когда превышен предел накладных расходов GC произошла ошибка:
Да, у меня действительно была проблема. Я перезапустил кукольные серверы, и с тех пор этого не происходило. Тем не менее, ставки на PS MarkSweep по-прежнему остаются довольно высокими. Вот последние 15 минут, пока я пишу:
Для сравнения, инфраструктура, которую я обновил на прошлой неделе, работает намного лучше, а показатели GC значительно ниже 10%:
В дополнение к высокой скорости, затрачиваемой на сборку мусора в потоках PS MarkSweep GC, я также заметил, что среднее время GC для PS MarkSweep тоже довольно велико и составляет от 2 до 3 секунд. Значения немного ниже (чуть меньше 2 секунд) в моей первой инфраструктуре.
В общем, похоже, что во всем виновата сборка мусора PS MarkSweep. Это, как правило, требует много ресурсов процессора в течение длительных периодов времени.
Хорошей новостью является то, что PS MarkSweep – это устаревший сборщик мусора , и избавиться от него не так уж сложно, поскольку OpenJDK 11 по умолчанию заменяет его сборщиком мусора молодого поколения G1 .
В официальном образе Docker puppet server устанавливается пакет puppet server , который извлекает openjdk-8-jre-headless в качестве зависимости. OpenJDK 11 также официально поддерживается начиная с Puppet 6.6, но пакет не позволяет устанавливать его вместо OpenJDK 8. Итак, сейчас я просто создам образ и установлю openjdk-11-jre-headless в дополнение к OpenJDK8, и пусть Ubuntu автоматически обновит альтернативу для Java.
На следующем графике показана разница во времени GC между PS MarkSweep и G1 после обновления до OpenJDK 11:
И вот как выглядит GC после хорошей разминки:
От 2 секунд до 80 мс, это большое улучшение, если вы спросите меня!
Оригинал: “https://dev.to/camptocamp-ops/taming-puppetserver-6-pt-ii-garbage-collection-2oh2”