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

Понимание рекомендованных настроенных профилей RedHat

Мы собираемся развернуть настроенные (и их количество) на ~ 1000 серверах, большинство из которых являются серверами VMware либо на NetApp, либо на хранилище 3Par.

Согласно документации RedHats, мы должны выбрать virtual-guestпрофиль. Что он делает, можно увидеть здесь: tuned.conf

Мы меняем планировщик ввода-вывода на NOOP, поскольку и VMware, и NetApp / 3Par должны выполнять за нас достаточное планирование.

Однако после небольшого исследования я не уверен, почему они увеличиваются. vm.dirty_ratio и kernel.sched_min_granularity_ns.

Насколько я понял, увеличивается увеличение vm.dirty_ratio до 40% будет означать, что для сервера с оперативной памятью 20 ГБ 8 ГБ могут быть грязными в любой момент, если только vm.dirty_writeback_centisecsпопадает первым. И при сбросе этих 8 ГБ все операции ввода-вывода для приложения будут заблокированы до тех пор, пока не будут освобождены грязные страницы.

Увеличение dirty_ratio, вероятно, будет означать более высокую производительность записи на пиках, поскольку теперь у нас есть больший кеш, но опять же, когда кеш заполняется, ввод-вывод будет заблокирован на значительно более длительное время (несколько секунд).

Во-вторых, почему они увеличивают sched_min_granularity_ns. Если я правильно понимаю, увеличение этого значения уменьшит количество временных интервалов на эпоху (sched_latency_ns) означает, что у запущенных задач будет больше времени, чтобы завершить свою работу. Я понимаю, что это очень хорошо для приложений с очень небольшим количеством потоков, но, например, для. apache или другие процессы с большим количеством потоков, не приведет ли это к обратным результатам?

Вот график конфигураций настроенных-ADM ...

Думаю, полезно видеть их в табличной форме. Главное отметить, что настройки RHEL6 по умолчанию - отстой !! Другое дело, что профили корпоративного хранилища и виртуального гостя идентичны, за исключением уменьшенного обмен на стороне виртуального гостя (имеет смысл, правда?).

Что касается рекомендаций по лифту ввода-вывода хранилища, у вас есть несколько уровней абстракции на уровне хранилища. Используя планировщик noop имело бы смысл, если бы вы использовали RDM или предоставляли хранилище непосредственно своим виртуальным машинам. Но поскольку они собираются жить на NFS или VMFS, мне все еще нравятся дополнительные параметры настройки предоставленный планировщиком крайнего срока.

Настроенные профили можно изменять на лету в работающих системах, поэтому, если у вас есть какие-либо проблемы, протестируйте свое приложение и определенную среду и тесты.

Посмотрите видео Шака и Ларри о настройке производительности с Summit, они подробно рассказывают о настроенных профилях.

Один из самых важных выводов заключается в том, что профили - это только рекомендуемая отправная точка, а не неизменные числа, которые волшебным образом идеально подходят для любой среды.

Начните с одного профиля и поэкспериментируйте с настройками. Создайте хорошую рабочую нагрузку для тестирования и измеряйте показатели, важные для вашего бизнеса.

Меняйте по одному и записывайте каждый результат на каждой итерации. Когда вы закончите, просмотрите результаты и выберите настройки, которые дали наилучшие результаты. Это ваш идеальный настроенный профиль.

Короткий ответ заключается в том, что любая настройка - это догадки и имеет ценность только в том случае, если она подкреплена эмпирическими данными: попробуйте. Измерьте это. Если вам это не нравится, подправьте его.

Более длинный ответ:

Увеличение dirty_ratio, вероятно, будет означать более высокую производительность записи ... IO будет заблокирован на значительно более длительное время

Нет. Увеличение коэффициента грязных данных означает, что ваша система с меньшей вероятностью попадет в состояние, при котором ей необходимо начать блокировку записи. Обратной стороной является то, что используется больше памяти и повышается риск потери данных в случае сбоя.

это означает, что у запущенных задач будет больше времени, чтобы закончить свою работу

Процессы обычно сдаются до истечения их временного отрезка. Проблема с виртуальной машиной заключается в том, что ваша машина может конкурировать за ЦП и кэш L1 / L2 с другими виртуальными машинами - высокий уровень переключения задач (из-за упреждающего освобождения) оказывает большое влияние на пропускную способность. Типы приложений, которые обычно развертываются на виртуальных машинах, связаны с процессором (веб-серверы, серверы приложений).

Да, увеличение пропускной способности (которое относится ко всем типам приложений) будет происходить за счет увеличения задержки - но последняя составляет порядка микросекунд, когда большинство транзакций занимают миллисекунды. Если вам нужна возможность реального времени / очень низкая задержка, вам не следует использовать виртуальную машину.