Назад | Перейти на главную страницу

Некоторые системы Linux становятся очень медленными, когда Redis загружает большой набор данных.

Я получил отчет от пользователя Redis, и я не уверен, что ответить, так как я не эксперт в области Linux и его планировщика, однако нам (как проекту Redis) нужно особенно разбираться в подобных проблемах. в будущем, как и в случае с Redis Cluster, у нас будет несколько экземпляров Redis, работающих одновременно в одном окне. Так что я прошу здесь помощи.

Проблема:

Обычно после перезапуска большого экземпляра Redis система становится настолько медленной, что вы больше не можете вводить текст в оболочке. Когда Redis загружает экземпляр, он использует 100% ЦП (загружает данные как можно быстрее) и последовательно читает файл dump.rdb. Ввод-вывод не особенно высок, поскольку загрузка связана с ЦП, а не с вводом-выводом.

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

У меня сложилось впечатление, что это во многом связано с тем фактом, что это экземпляр EC2, поэтому он связан с используемой технологией виртуализации, поскольку я все время загружаю Redis Наборы данных 24 ГБ в моем ящике без проблем (даже с другими экземплярами Redis, работающими с высокой нагрузкой).

Спасибо за подсказку!

Сальваторе

редактировать: добавление отзывов, полученных от твиттера:

от @ezmobius: @antirez Первое, что нужно сделать, это попробовать его из / mnt или локальных эфемерных дисков, чтобы увидеть, не работает ли его EBS, второе - убедиться, что это не "штраф за первую запись" (погуглите), и если это так, то вам нужно сначала установить dd 0 на диске.

от @dvirsky: @antirez Я запускаю много экземпляров Redis именно на таких узлах ec2. Я заметил некоторое замедление на bgsave, но не это явление.

Вывод "сверху" может дать некоторые подсказки. В левом верхнем углу есть поле с надписью «% украдено», которое отражает количество аппаратных ресурсов ЦП, перенаправленных другим гостям в том же физическом блоке. Я видел такого рода замедления, когда гипервизор решал выделить больше ЦП другому гостю, особенно когда я выполняю какую-то длительную задачу, требующую интенсивного использования ЦП.

Не уверен, ваша проблема в этом или нет, но стоит проверить.

Вы должны проверить кражу процессора (xx.x%st справа от строки процессора), что top отображается при 100% загрузке и замерзшей скорлупе. Steal представляет, сколько из ваших фактических циклов ЦП украдено с вашей машины гипервизором и передано другой машине. Кража ЦП актуальна только в виртуализированных средах. У меня была точно такая же проблема с микро-экземплярами, из-за которой мой экземпляр в основном становился непригодным для использования в течение примерно 1 часа (до тех пор, пока моя задача не завершилась) при выполнении задач с интенсивным использованием ЦП.

Вы можете узнать больше по этой теме, прочитав этот пост на Greg's Ramblings. Хотя, если вы поверите на слово Грегу, это должно происходить только на микро-экземплярах.

У меня была такая же проблема с экземпляром EC2. Вероятно, это не связано с Redis - это происходит, когда происходит большое количество операций ввода-вывода (например, когда redis загружает файл дампа).

Взгляните на эту ветку на форумах Amazon: https://forums.aws.amazon.com/thread.jspa?messageID=215406

Я экспериментировал с разными ядрами / образами, и теперь все работает нормально (на старом ядре 2.6.21).