задний план
Запущен новый проект в маркетинговом центре.После запуска проекта платформа мониторинга показала, что уровень воды в РТ регулярно поднимался и опускался.
Первоначальное расследование
В первый раз, когда я посмотрел на график мониторинга, я подумал, что это вызвано одновременным отказом пакетов ключей redis, потому что интервал между пиками составлял ровно 15 минут, и время отказа ключа redis также было установлено в это время. В то же время, по отзывам компании по эксплуатации и обслуживанию в то время, объем запросов SQL к этой таблице велик, и она вызывается 36530 раз за 15 минут, что составляет 80% производительности библиотеки.
Из мониторинга ссылок выяснилось, что RT некоторых mysql очень высок.
Исходное место проблемы
В сочетании со временем отклика бд проблема начального позиционирования такова: после проникновения кеша большое количество SQL-запросов приводит к увеличению RT.
Но на самом деле это не может объяснить проблему регулярного подъема.
Итак, я добавил защиту от поломки кеша, выложил ее в сеть и обнаружил, что RT действительно вышел из строя! Считай, что проблема решена.
проблема снова появляется
После Фестиваля лодок-драконов я сегодня снова посмотрю на ситуацию RT и восстановлю ситуацию первой картинки.
Устранение неполадок
Такое ощущение, что проблема не в том, что представлялось изначально. Итак, я проверил ситуацию с сервером и обнаружил, что загрузка ЦП сервера также очень странная.
Поэтому я использовал jstack для проверки использования многопоточности в проекте и не нашел никаких исключений.
использовать top -Hp pidПросмотр потоков с наибольшей загрузкой ЦП
printf "%x\n" 19838Получите шестнадцатеричное значение 4d7e
jstack 19832 | grep "4d7e"Проверьте ситуацию с потоком
Было обнаружено, что наиболее потребляющим процессором был поток gc.
jstat -gc 19832 1000Проверьте ситуацию с GC
Нашел большой баг. В старости было настроено только 64M, а онлайн всегда был fullgc.За три дня фестиваля лодок-драконов fullgc был пройден более 190 000 раз. . Ладно, можешь идти к брату по эксплуатации и обслуживанию пить чай.
В заключение
Конфигурация онлайн-старости слишком мала, что приводит к тому, что система все время находится в fullgc и STW, блокируя пользовательский поток.Как правило, время блокировки составляет около 100 мс, что приводит к взлету RT. Вернитесь в нормальное состояние после fullgc, rt возобновится, а затем снова продолжите fullgc.
считать
1. В платформе мониторинга отсутствует мониторинг JVM
2. Для интерфейсов с большим количеством запросов оцените риск поломки кеша
3. При устранении неполадок следует одновременно учитывать несколько аспектов ЦП, памяти, ввода-вывода и JVM.