Некоторые системы 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, но не это явление.

Вывод '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 Грега . Хотя, если вы поверите слову Грега, это должно происходить только на микроинстанциях.