Некоторые системы Linux становятся очень медленными, когда Redis загружает большой набор данных
Я получил отчет от пользователя Redis, и я не уверен, что ответить, так как я не эксперт в области Linux и его планировщика, однако нам (как проекту Redis) нужно особенно разбираться в подобных проблемах. в будущем, как и в Redis Cluster, у нас будет много экземпляров Redis, запущенных одновременно в одном окне. Поэтому я прошу помощи здесь.
Проблема:
- Ядро: "Linux redis1 2.6.32-305-ec2 #9-Ubuntu SMP четверг 15 апреля 08:05:38 UTC 2010 x86_64 GNU/Linux"
- много свободной оперативной памяти, никакие другие процессы не выполняют значительных операций ввода-вывода.
- Важно, работает на большом экземпляре EC2, а не на реальном сервере. Я никогда не видел ничего подобного в не виртуализированной среде. Экземпляр EC2 представлял собой: "Экстра большого объема 17,1 ГБ, большой объем памяти, 6,5 ЭБУ (2 виртуальных ядра с вычислительными блоками 3, 25 EC2 каждый), 420 ГБ локального хранилища экземпляров, 64-разрядная платформа".
По сути, после перезапуска большого экземпляра Redis система будет работать так медленно, что вы больше не сможете печатать на оболочке. Когда Redis загружает экземпляр, он использует 100% ЦП (загружает данные максимально быстро) и последовательно читает файл dump.rdb. Ввод / вывод не особенно высок, поскольку загрузка связана с процессором, а не с вводом / выводом.
Почему на самом деле коробка с двумя процессорами и большим количеством оперативной памяти, без перестановок на диске, должна в основном перестать работать с этой рабочей нагрузкой?
У меня сложилось впечатление, что это во многом связано с тем фактом, что это экземпляр EC2, что связано с используемой технологией виртуализации, поскольку я постоянно загружаю наборы данных Redis 24 ГБ в свой ящик без каких-либо проблем (даже с другими экземплярами Redis). работает с высокой нагрузкой).
Спасибо за любую подсказку!
Salvatore
Изменить: добавив некоторые отзывы, которые я получил из твиттера:
от @ezmobius: @antirez первым делом, попробуйте его из /mnt или локальных эфемерных дисков, чтобы увидеть, не является ли его EBS ненадежным, 2-й, чтобы убедиться, что это не "штраф за первую запись" (google it), и если это так сначала вы должны dd 0 на диске.
from @dvirsky: @antirez Я запускаю много экземпляров redis именно на таких узлах ec2. Я заметил некоторое замедление на bgsave, но не это явление.
3 ответа
Вывод 'top' может дать некоторые подсказки. В левом верхнем углу есть поле с надписью "% украдено", которое отражает количество аппаратного ЦП, перенаправленного на другие гости в том же физическом блоке. Я видел подобные замедления, когда гипервизор решает выделить больше ЦП другому гостю, особенно когда я выполняю какую-то длительную задачу, интенсивно использующую ЦП.
Не уверен, если это ваша проблема или нет, но стоит проверить.
У меня была такая же проблема на экземпляре EC2. Вероятно, это не связано с Redis - это происходит, когда происходит высокий IO (например, когда redis загружает файл дампа).
Посмотрите эту ветку на форумах Amazon: https://forums.aws.amazon.com/thread.jspa?messageID=215406
Я экспериментировал с разными ядрами / образами, и теперь он работает нормально (на старом ядре 2.6.21).
Вы должны проверить процессор украсть (xx.x%st на правой стороне линии процессора), что top показывает, когда вы испытываете 100% нагрузки и замерзшей оболочки. Steal показывает, сколько ваших фактических циклов ЦП украдено с вашей машины гипервизором и передано другой машине. Кража процессора актуальна только в виртуализированных средах. У меня возникла именно эта проблема с микроэкземплярами, из-за которой мой экземпляр стал непригодным к работе в течение примерно 1 часа (до тех пор, пока моя задача не была завершена) при выполнении задач с интенсивным использованием процессора.
Вы можете найти больше на эту тему, прочитав этот пост на Rreglings Грега. Хотя, если вы поверите слову Грега, это должно происходить только на микроинстанциях.