Настройка Linux I / O Scheduler для твердотельных накопителей

Привет читатели Techblog!

Я собираюсь поговорить о настройке планировщика ввода-вывода Linux для увеличения пропускной способности и уменьшения задержки на SSD. Я также затрону еще одну интересную тему о настройке производительности NuoDB, указав хранилище для архива и каталогов журналов.

Настройка планировщика ввода-вывода Linux

Linux дает вам возможность выбрать планировщик ввода / вывода. Планировщик также может быть изменен без перезагрузки! В этот момент вы можете спросить: «Зачем мне вообще менять планировщик ввода-вывода?» Изменение планировщика имеет смысл, когда затраты на оптимизацию ввода-вывода (переупорядочение запросов ввода-вывода) не нужны и дороги. Этот параметр должен быть точно настроен для каждого устройства хранения. Лучшая настройка для SSD не будет хорошей настройкой для HDD.

Текущий планировщик ввода / вывода можно просмотреть, введя следующую команду:

mrice@host:~$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

Текущий планировщик ввода / вывода (в скобках) для / dev / sda на этом компьютере — CFQ , полностью честная очередь. Этот параметр стал стандартным в ядре 2.6.18 и хорошо работает для жестких дисков. Однако твердотельные накопители не имеют вращающихся пластин или магнитных головок. Алгоритмы оптимизации ввода / вывода в CFQ не применяются к твердотельным накопителям. Для твердотельных накопителей  планировщик ввода-вывода NOOP может уменьшить задержку ввода-вывода и увеличить пропускную способность, а также исключить время ЦП, затрачиваемое на переупорядочение запросов ввода-вывода. Этот планировщик обычно хорошо работает на SAN, SSD, виртуальных машинах и даже на модных картах ввода-вывода Fusion. В этот момент вы, вероятно, думаете: «Хорошо, я продан! Как мне уже изменить планировщик?» Вы можете использовать команду echo, как показано ниже:

mrice@host:~$ echo noop | sudo tee /sys/block/sda/queue/scheduler

Чтобы увидеть изменения, просто перезапустите планировщик.

mrice@host:~$ cat /sys/block/sda/queue/scheduler
[noop] anticipatory deadline cfq 

Обратите внимание, что noop теперь выбран в скобках. Это изменение носит временный характер и будет сброшено к планировщику по умолчанию, в данном случае CFQ, когда машина перезагрузится. Вам нужно отредактировать конфигурацию Grub, чтобы сохранить настройки навсегда. Однако это изменит планировщик ввода-вывода для всех блочных устройств. Проблема в том, что NOOP не является хорошим выбором для HDD. Я бы только навсегда изменил настройку, если бы на машине были только SSD. 

На Grub 2:

Edit: /etc/default/grub
Add "elevator=noop" to the GRUB_CMDLINE_LINUX_DEFAULT line.
sudo update-grub

На этом этапе вы изменили планировщик ввода-вывода на NOOP. Как вы знаете, если это имеет значение? Вы можете запустить сравнительный тест и сравнить числа (просто не забудьте очистить кэш файловой системы). Другой способ — взглянуть на вывод iostat. Запросы ввода-вывода проводят меньше времени в очереди с планировщиком ввода-вывода NOOP. Это можно увидеть в поле «await» от iostat. Вот пример более крупной операции записи с NOOP.

iostat -x 1 /dev/sda

Настройка производительности NuoDB

Теперь, когда вы узнали о планировщике ввода-вывода NOOP, я расскажу о настройке NuoDB с помощью SSD. Если вы прочли технические блоги, то узнаете, что для базы данных NuoDB есть два строительных блока: механизм транзакций, сокращенно TE, и менеджер хранилища SM. TE — это копия базы данных только в памяти (фактически часть базы данных). В результате SSD не поможет производительности TE, потому что он не сохраняет атомы на диск. SM содержит два модуля для записи на диск: архив и журнал. В архиве атомы хранятся на диске, когда параметр конфигурации архива указывает на файловую систему (по сравнению с HDFS и S3). Журнал, с другой стороны, синхронно записывает сообщения на диск. Если вы читаете пост в блоге о  долговечностиВозможно, вы помните, что параметр «Удаленная фиксация с ведением журнала» обеспечивает наивысший уровень надежности, но за счет более низкой скорости. Использование SSD в этой ситуации может значительно улучшить производительность.

Чтобы настроить этот параметр, нам нужно создать каталог nuodb на SSD:

mkdir -p /ssd/nuodb

SSD в этом примере имеет точку монтирования / ssd на этом компьютере. Легко, правда? Я предполагаю, что вы уже установили планировщик ввода-вывода Linux для SSD на NOOP. Следующим шагом является настройка NuoDB для использования этого пути при создании каталога журнала. Журнал имеет прямую корреляцию с пропускной способностью транзакции, поскольку журнал должен завершить запись на диск, прежде чем SM отправит ACK для подтверждения транзакции в TE. Как насчет архива? Архив отделен от фиксации транзакции, атомы останутся в памяти и постепенно попадут на диск. Это будет очень мало влиять на TPS базы данных. В результате каталог архива можно разместить только на обычном жестком диске. Краткое руководство по настройке производительности — поместить журнал на SSD, а архив можно поместить на жесткий диск.

Вот команды:

nuodbmgr --broker localhost --password bird
nuodb [domain] > start process sm
Database: hockey
Host: s1
Process command-line options: --journal enable --journal-dir /ssd/nuodb/demo-journal
Archive directory: /var/opt/nuodb/demo-archives
Initialize archive: true
Started: [SM] s1/127.0.0.1:37880 [ pid = 25036 ] ACTIVE

nuodb [domain/hockey] > start process te
Host: t1
Process command-line options: --dba-user dba --dba-password goalie
Started: [TE] t1/127.0.0.1:48315 [ pid = 25052 ] ACTIVE

Важным моментом этой настроенной конфигурации является то, что только журнал находится на SSD. В результате твердотельный накопитель не обязательно должен быть одним из этих огромных дисков с ТБ. Стоимость твердотельных накопителей значительно упала в цене, и для данных журнала достаточно одного твердотельного накопителя емкостью 128 или 256 ГБ. Эта конфигурация должна соперничать с локальной эффективностью фиксации, которая является потрясающей, учитывая, что это самый высокий уровень долговечности! Я призываю вас попробовать и задать несколько вопросов.