задний план

Здравствуйте, меня зовут Тонг.

Вчера вечером я возвращался домой с работы. В метро вдруг позвонил начальник. Производственная среда системы Б реагировала медленно, что повлияло на использование системы А. Десятки тысяч молодых братьев не могли получать заказы, и около 300 000 заказов застряли. Идите и помогите разместить его.

Я вернулся домой около 8:30 и сразу же присоединился к членству онлайн.

перезагружать

Когда я присоединился к клубу, там уже были коллеги, которые помогали найти. Как говорится, перезагрузка может решить 80% проблем. Если перезагрузка не может решить, это должно быть потому, что количества перезагрузки недостаточно. Ба, нет, перезагрузка не может решить эту проблему.

Факты доказали, что проходить волну стресс-тестов после перезапуска по-прежнему бесполезно.При 1000 одновременных тестов среднее время отклика составляет 3-4 секунды.Это результат нескольких последовательных стресс-тестов.

Обновление конфигурации

Перезапуск кажется недействительным, и мы входим во второй этап - конфигурация обновления.Два экземпляра 4-ядерных 8G обновлены до шести 8-ядерных экземпляров 16G, а также удвоилась конфигурация базы данных.Проблемы, которые можно решить с деньгами мы обычно не будем вкладывать слишком много рабочей силы ^^

Факты доказали, что добавление конфигурации бесполезно, 1000 одновременных, среднее время отклика стресс-теста по-прежнему составляет 3-4 секунды.

Интересный.

В этот момент вмешались брат Тонг и я.

Просмотр мониторинга

После того, как я подключился к Интернету, я проверил мониторинг и обнаружил, что ЦП, память, диск, сетевой ввод-вывод и использование кучи памяти JVM экземпляра, похоже, в порядке.Это действительно головная боль.

Локальный стресс-тест

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

Кажется, что с самим сервисом действительно нет проблем.

прохождение кода

Другого пути действительно нет, вынимайте код, группа больших мужиков вместе смотрит код, а однокурсники из R&D объясняют нам бизнес-логику. сломанного кода он написал, на самом деле вмешался брат Тонг Раньше они изменили волну кода, есть место, чтобы поставить команду redisscanизменился наkeys *, здесь зарыта яма, но это не главная проблема сейчас, о ней мы поговорим позже.

Прочитал весь код и обнаружил, что операций redis много, и есть цикл for, в котором настраивается команда get redis, проблем нет, основная проблема все же может быть сосредоточена в части redis, и звонки слишком частые.

добавить журнал

Проверьте код, за исключением того, чтоscanизменился наkeys *(насчет этого пока не знаю), проблемы в принципе нет, просто добавляйте логи, добавляйте логи небольшими разделами, ОК, перезапускайте сервис, и делайте волну стресс-тестов.

Разумеется, результаты не изменились, анализируем лог.

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

Изменить количество соединений Redis

Проверьте конфигурацию Redis, используйте автономный режим, память 1G, количество подключений по умолчанию равно 8, клиент все еще относительно старый jedis, решительно изменен на салат по умолчанию Springboot, количество подключений сначала было доведено до 50, перезапустите службу и нажмите волну.

Среднее время ответа от 34 секунды до 23 секунды, не очевидно, продолжаем увеличивать количество подключений, потому что у нас 1000 concurrent, в каждом запросе много операций redis, так что ожидание точно будет, в этот раз напрямую сушим количество подключений до 1000, перезапускаем сервис , нажмите волну.

Получается, что существенного улучшения нет.

Проверьте журнал еще раз

На данный момент нет хорошего решения.Мы снова возвращаемся к журналу, проверяем время операций, связанных с redis, и обнаруживаем, что 99% операций get возвращаются быстро, в основном на 05 миллисекунд, однако всегда есть несколько, которые достигают 800900 миллисекунд на возврат.

Мы думали, что с Redis все в порядке.

Однако после нескольких стресс-тестов время так и не было поднято.

Очень беспомощный, в это время было уже за 3 часа ночи, и лидер заговорил, позвав людей из HUAWEI CLOUD.

Устранение неполадок HUAWEI CLOUD

Наконец, мы вызвали сотрудников, связанных с HUAWEI CLOUD, чтобы вместе разобраться в проблеме.Конечно, они были неохотны, но кто просил нас платить ^^

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

Они временно утроили пропускную способность Redis, давайте проведем еще один стресс-тест.

Удерживая кусок травы, среднее время отклика внезапно упало до 200–300 миллисекунд! ! ! !

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

Это настоящая заноза в заднице.

В этот момент мы подумали, что проблема решена так, и лидеры пошли спать~~

на производстве

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

Мы попросили экспертов HUAWEI CLOUD утроить производственную пропускную способность.

Извлеките ветку исправления из рабочей отправки, закройте сигнатуру, перезапустите службу и пройдите волну стресс-тестирования.

Закончилось, продакшн-среда еще хуже, а среднее время отклика 5-6 секунд.

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

Практического эффекта нет, все равно 5-6 секунд.

Какая боль в заднице.

Просмотр мониторинга

Глядя на мониторинг Redis в HUAWEI CLOUD, пропускная способность и управление потоком на этот раз в норме.

На этот раз аномалией стал ЦП, и тест давления ЦП Redis сразу взлетел до 100%, что привело к медленному отклику приложения.

Пробудите экспертов HUAWEI CLOUD redis снова

Уже больше четырех утра, и у всех закончились идеи.Эксперты Redis из HUAWEI CLOUD, пожалуйста, разбудите меня снова!

Разбудите экспертов Redis из HUAWEI CLOUD снова, помогите нам проанализировать предысторию и обнаружили, что 140 000 сканирований были выполнены в течение 10 минут~~

Обратите внимание на Princess Tong, читайте исходный код и смотрите больше хороших статей!

Злой скан

Я спросил сотрудников R&D, где используется сканирование (раньше его меняли, я не знаю), и обнаружил, что каждый запрос будет вызывать сканирование, чтобы получить ключ, начинающийся с определенного префикса, каждый раз сканировать 1000 фрагментов данных, проверять общее количество ключей redis, около 11 Десять тысяч, то есть запрос нужно сканировать 100 раз, 1000 одновременных, около 100 000 сканирований, мы знаем, что в redisscanиkeys *Это для выполнения полного сканирования таблицы, которое потребляет много ресурсов ЦП.140 000 операций сканирования напрямую заставляют ЦП летать на небеса.

Почему CPU в тестовой среде не на высоте?

Для сравнения, общее количество ключей Redis в тестовой среде и производственной среде, в тестовой среде всего 900 ключей, и каждый запрос сканируется один раз илиkeys *Когда-то проблем с пряжей не было.

Почему в производственной среде так много ключей?

Спросите сотрудников отдела исследований и разработок, почему в производственной среде так много ключей, а срок действия не установлен?

Сотрудники НИОКР сказали,что установлен код написанный другим коллегой.При открытии кода это действительно волшебный код.Мне неудобно выкладывать конкретный код.Есть суждение о том,устанавливать ли время истечения срока действия в соответствии с условиями.Во всех случаях время истечения не установлено успешно.

Текущий обходной путь

В это время уже 4:30 утра, хотя все еще очень взволнованы, но после решения руководства она пока не будет двигаться, потому что система А приостановила вызов системы Б, так что в это время время система B может сказать, что трафик почти равен 0, мы будем устранять эту проблему в два этапа в течение дня.

Первый шаг — очистить данные Redis в производственной среде, оставив лишь небольшую часть необходимых данных.

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

Что ж, это конец расследования несчастного случая на производстве. В последующем брат Тонг продолжит расследование.

Суммировать

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

1. В прошлом это были ЦП, память, диск и JVM самой службы приложений.Это был первый раз, когда встретились пропускная способность и текущий предел Redis;
2. После присоединения к HUAWEI CLOUD многие вещи еще не освоены, в том числе индикаторы мониторинга, которые все еще нужно изучать медленно;
3. Redis должен отключить ключи и команды сканирования, а для большинства ключей должен быть установлен срок действия!

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