Вопросы Теги

Linux планировщик IO на базах данных с RAID

Удалите любой кэшируемый пароль в своей клиентской машине и попробуйте еще раз или наблюдение за возможными трассировками Conficker :)

3
задан 16 April 2010 в 21:24
2 ответа

Каждая рабочая нагрузка отличается. Таким образом, нет единого ответа на этот вопрос. Для создания вещей более сложными, большинство Планировщиков IO имеет tunables. Таким образом, лучшая вещь, которую можно сделать, протестировать с максимально близко к реальной рабочей нагрузке, сравнивающей. Пока Ваш тест повторяем, он должен работать.

Можно изменить планировщики IO на лету, не перезагружая, который делает экспериментирование с io планировщиками легким сделать. Сделать это использование команда как это echo anticipatory | sudo tee /sys/block/sdb/queue/scheduler замена упреждающего с предпочтительным планировщиком и sdb с корректным блочным устройством. Можно также сделать echo anticipatory > /sys/block/sdb/queue/scheduler если Вы зарегистрированы как корень. Я использую подход мишени так, чтобы я мог просто использовать sudo.

Как minaev у меня была большая удача с Крайним сроком на занятых файловых серверах. У нас не было материала базы данных, поскольку это была главным образом обработка изображений с вычислительным кластером. Но они насыщали бы 2 ссылки GigE и загрузились бы что сервер в течение 48 часов за один раз.

Я также использовал NOOP при контакте с внешними RAID-массивами. То, под чем я подразумеваю внешний, - то, что RAID-контроллер сам содержавшийся во внешнем шасси, и сервер просто рассматривает это как диск SCSI. Если RAID-контроллер находится в сервере затем, я думаю, что Вы все еще хотите избежать NOOP. Но необходимо смочь выяснить что работы лучше всего для Вас с некоторым сравнительным тестированием.

4
ответ дан 3 December 2019 в 05:36
  • 1
    Просто предостережение. Можно изменить планировщик на лету, но у меня было замораживание серверов, когда я изменил его. Они, где довольно занятый, когда я переключил планировщик и это было некоторое время назад, таким образом, это не может быть совершенно релевантно сегодня. –  Dan Andreatta 16 April 2010 в 17:39
  • 2
    @Dan Andreatta Хорошее предостережение. I' ve никогда не сталкиваются с этим самостоятельно даже, в то время как сервер выкладывал пару сотни МБ/с, но ядро всегда изменяется, и каждый дистрибутив имеют их собственные наборы патчей, они относятся к нему. Так it' s довольно возможный, что проблема была ограничена определенной версией ядра или набором патчей дистрибутива. В любом случае, надо надеяться, та проблема была разрешена. –  3dinfluence 16 April 2010 в 17:51
  • 3
    Относительно сравнительного тестирования - я испытал sysbench и bonnie ++. Bonnie ++ оказалась лучше. Есть ли любые лучшие дисковые сравнительные тесты там, которые могут подчеркнуть дисковая пропускная способность и ЦП. –  Raghu 16 April 2010 в 21:22
  • 4
    You' ll, вероятно, хотят выполнить своего рода сравнительный тест MySQL с тех пор that' s Ваша основная цель. Но идеально you' d хотят своего рода генератор нагрузки, который соответствует производственной рабочей нагрузке. –  3dinfluence 16 April 2010 в 21:53
  • 5
    Также обратите внимание, что Упреждающий не в последних ядрах. Вашим выбором в 2.6.33 является CFQ, noop и Крайний срок. –   17 April 2010 в 01:15

Не уверенный, если это помогает, но здесь является интересной статьей из Журнала Red Hat: "При выборе I/O Scheduler for Red Hat® Enterprise Linux® 4 и 2.6 Ядер". Я обычно устанавливал планировщик на крайний срок, и он работает хорошо над моими серверами, но я должен признать, что у меня нет чисел, которые доказали бы, что крайний срок действительно лучше.

2
ответ дан 3 December 2019 в 05:36

Теги

Похожие вопросы