Оптимизация Linux для виртуализаци

Linux elevator

теперь про значения для elevator/scheduler:

По-умолчанию оно установлено в значение cfq или deadline:


cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

Рекомендуется устанавливать его в значение noop:


echo noop > /sys/block/sda/queue/scheduler
cd /sys/block/sda/queue
grep .* * 
scheduler:[noop] deadline cfq

Для того, чтобы настройки были постоянными, добавьте “elevator=noop” в параметры загрузки ядра в файле /etc/grub.conf, они будут применены ко всем блочным устройствам. Или добавьте соответствующий скрипт в /etc/rc.local, для того, чтобы гибко устанавливать настрйки для каждого отдельного блочного устройства.

Пример скрипта установки scheduler в noop для sdb

Не забудьте поменять sdb на имя вашего блочного устройства

cat /etc/rc.local | grep -iv "^exit" > /tmp/temp
echo -e "echo noop > /sys/block/sdb/queue/scheduler\nexit 0" >> /tmp/temp
cat /tmp/temp > /etc/rc.local; rm /tmp/temp

Настройки Sysctl с работой Virtual Memory

Стоит опытным путём подобрать наиболее оптимальные значения работы виртуальной памяти ОС — параметры sysctl: vm.dirty_background_ratio, vm.dirty_ratio и vm.swappiness.

Проверяем значения sysctl

sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500

sysctl -a | grep swappiness
vm.swappiness = 60

Так у одного заказчика наиболее оптимальными значениями для RedHat Enterprice Linux 6 с СХД NetApp с SSD кешем и подключением по FC8G были: vm.dirty_ratio = 2 и vm.dirty_background_ratio = 1, которые существенно снизили нагрузку CPU хоста. Для проверки оптимальных настроек Linux хоста воспользуйтесь утилитой Linux Host Validator and Configurator. Во время тестирования утилиты SnapDrive под Linux (или другими Unix-like) ОС воспользуйтесь SnapDrive Configuration Checker for Unix. Подробнее про подбор оптимальных параметров vm.dirty* смотите здесь. В случае использования БД Oracle или виртуализации, внутри такой Linux машины рекомендуется устанавливать значение vm.swappiness=0. Это значение даст использовать swap только когда физическая память действительно закончиться, что является наиболее оптимальным для таких задач.

Устанавливаем значения sysctl

sysctl -w vm.dirty_background_ratio=1
sysctl -w vm.dirty_ratio=2
echo vm.dirty_background_ratio=1 >> /etc/sysctl.conf
echo vm.dirty_ratio=2 >> /etc/sysctl.conf

#for Guest VMs or Oracle DB
sysctl -w vm.swappiness=0
echo vm.swappiness=0 >> /etc/sysctl.conf

#Reload data from /etc/sysctl.conf
sudo sysctl –p I/O queue size или длинна очереди ввода-вывода на HBA Значение по-умолчанию обычно 128, его нужно подбирать вручную. Увеличение длинны очереди имеет смысл при случайных операциях ввода-вывода, генерирующих множество операций disk seek на дисковой подсистеме. Изменяем так:

echo 100000  > /sys/block/[DEVICE]/queue/nr_requests

Иногда изменение этого параметра может не давать результатов, к примеру в случае с InnoDB 
(из-за особенностей работы этого приложения, 
которое само оптимизирует данные перед их записью) или 
в случае увеличения параметра выше дефолтного при работе с SSD дисками (так как в них нет операций disk seek).


Файловая система

ФС может вносить существенные коррективы при тестировании производительности.
Размер блока ФС должен быть кратным 4КБ. К примеру, если мы запускаем синтетическую нагрузку подобную 
генерируемой OLTP, где размер оперируемого блока в среднем равен 8КБ, то ставим 8КБ. 
Хочу также обратить внимание что как сама ФС, 
её реализация для конкретной ОС и версия может очень сильно влиять на общую картину производительности. 
Так для при записи 10 МБ блоками в 100 потоков командой dd файлов от БД на ФС UFS расположенной на LUN 
отданный по FC4G с СХД FAS 2240 и 21+2 дисками SAS 600 10k в одном агрегате показывал скорость 150 МБ/сек, 
тогда как та же конфигурация но с ФС ZFS показывала в два раза больше (приближаясь к теоретическому 
максимуму сетевого канала), а параметр Noatime вообще никак не влиял на ситуацию.

Noatime на Хосте

На уровне файловой системы можно настроить параметр при монтрировании noatime и nodiratime, который 
не даст обновлять время доступа к файлам, что часто очень положительно сказывается на производительности. 
Для таких ФС как UFS, EXT3 и др. У одного из заказчиков установка noatime при монтировании файловой 
системы ext3 на Red Hat Enterprise Linux 6 сильно уменьшило нагрузку на CPUхоста.