Я просто пошел на работу в понедельник утром. Внезапно большое количество пользователей сообщили, что вход на веб-страницу был очень медленным. Когда я вошел на сервер, я увидел, что время вызова Redis сильно превышает время. Таким образом , быстродействующий кеш стал короткой платой.Поскольку данные не были возвращены, ответ на запрос был замедлен.
Веб-мониторинг
Благодаря мониторингу Ali Grafana загрузка процессора, памяти и сетевого ввода и вывода вполне нормальные, поэтому должна быть проблема с Redis.
我们应用使用的是单节点的 32M 16GB 的阿里云 Redis，登录网页监控看性能监控，发现 CPU 使用情况飙升到100%！ ! !
Хотя QPS увеличился с более чем 1000 до 6000, это намного ниже предельного значения, а количество подключений увеличилось с 0 до 3000, что также намного ниже предельного значения (может пользователь просто вышел на работу, там сначала были запросы, а затем ответ задерживался, что приводило к слишком большому количеству очередей команд, открывая много соединений).
Временное решение: сначала арендуйте новый сервер Redis, замените конфигурацию Redis сервера приложений и перезапустите приложение, чтобы не затрагивать других пользователей.
Дальше продолжаем отслеживать особенности Redis.
Мониторинг команд сервера
Войдите в Redis-cli и используйте команду info, чтобы просмотреть состояние сервера и статистику команд.Брат Сян подытожил два исключения:
-
При запросе медленного журнала медленных команд Redis первые десять команд являются «ключами *» и занимают много времени.Выполнение «ключей *» при текущем бизнес-трафике определенно заблокирует бизнес, что приведет к медленным запросам и высокой загрузке ЦП. . Стоит отметить, что интерфейс «ключи *» не открыт на уровне приложения, и нет никакого фонового человека или фоновой программы для запуска этой команды.
-
Просмотрите исполнение инструкций Redis, исключите «EXEC», «PLASHALL» и т. Д. В инструкции по использованию услуг существует 7,5 миллиона вызовов на время потребления, а набор вызовов 8,4 миллиона составляет 3,33. S, DEL имеет 265 миллионов звонков В течение среднего времени 69S и Hmset имеет общее потребление времени 64-м, а Hmget имеет 6,8 миллиона звонков при среднем потреблении 9с, а HGETALL составляет 14 миллиардов вызовов в среднем 205-е годы, клавиши имеют 2 десятки миллионов звонков, потребляют 3740-х. В целом, эти инструкции пропорциональны размеру стоимости, поэтому его можно исследовать недавний рост этих инструкций. Или в последнее время не существует преобразования бизнеса, которое часто использует вышеупомянутые инструкции, которые также приведут к процессору.
(Я забыл сделать скриншот в то время, следующее изображение просто показывает значение команд и параметров)
Статистику команды Redis можно просмотреть через info commandstats, где формат команды
cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX
调用次数、耗费CPU时间、每个命令平均耗费CPU(单位为微秒）
Просмотр медленных команд с помощью команды slowlog (по умолчанию в журнал будет записано более 10 мс, только время выполнения команды, не включая операции ввода-вывода и не записывает медленный ответ, вызванный только сетевой задержкой)
(Я также забыл сделать скриншоты в то время, поэтому я представлю, как выглядит slowlog)
xxxxx> slowlog get 10
3) 1) (integer) 411
2) (integer) 1545386469
3) (integer) 232663
4) 1) "keys"
2) "mecury:*"
Поля на рисунке представляют:
- 1 = Уникальный идентификатор журнала
- 2 = момент времени выполнения команды, выраженный в виде временной метки UNIX.
- 3=Просмотр времени выполнения команды, в микросекундах, 230 мс в 🌰
- 4=Выполненные команды, расположенные в виде массива. Полная команда — это ключи mucury:*
Следовательно, по этим параметрам в основном можно определить, что внезапно возникает большое количествоkeys *Команда вызвала увеличение нагрузки на ЦП, что привело к задержке ответа, проблема не открыта в нашем приложении.keys *Команда Σ(оﾟдﾟоﾉ)
*Наконец, эти статистические результаты и медленные команды были отправлены в группу исследований и разработок, и было обнаружено, что другие конфигурации приложений были настроены с нашим Redis, а затем у них был бизнес-сценарий сканирования данных, и вдруг поступило большое количество вызовов, и ключи продолжали работать., что вызвало перегруженным нашим Redis, поэтому конфигурация была изменена правильно, и наш Redis больше не звонил.
Суммировать
- Для дрожания Redis вы можете сначала посмотреть на мониторинг веб-страниц (Alibaba Cloud отлично справляется!)
- Просмотр статуса команды Redis и медленных команд через команды
- Рассмотрите возможность оптимизации использования Redis в вашем коде.
- Если трафик продолжает расти, вам нужно подумать об обновлении =-=