Linux - реальна настройка апаратного RAID контролера (scsi та cciss)

Більшість систем Linux, якими я керую, мають функціональні апаратні RAID-контролери (в основному HP Smart Array ). Всі вони працюють із RHEL або CentOS.

Я шукаю перекладки в реальному світі, щоб оптимізувати продуктивність для налаштувань, які містять апаратні RAID-контролери з дисками SAS (Smart Array, Perc, LSI тощо) та кешеним керованим або флеш-кешем. Припустимо, RAID 1 + 0 і кілька шпинделів (4+ диска).

Я витрачаю значну кількість часу на налаштування мережевих налаштувань Linux для застосувань із низькою затримкою та фінансовою торгівлею. Але багато з цих варіантів добре задокументовані (зміна буферів для надсилання / отримання, зміна параметрів вікна TCP тощо). Що інженери роблять на сховищі?

Історично склалося так , що я вніс зміни в плануванні ліфта I / O , в останній час вибирають для deadlineі noopпланувальники для підвищення продуктивності в рамках своїх додатків. По мірі прогресування версій RHEL я також помітив, що збірні параметри за замовчуванням для блоків SCSI та CCISS блоків також змінилися. Це впливало на рекомендовані налаштування підсистеми зберігання протягом часу. Однак минуло деякий час, оскільки я не побачив ясних рекомендацій. І я знаю, що налаштування за замовчуванням для ОС не є оптимальними. Наприклад, здається, що буфер заздалегідь зчитування за замовчуванням у 128 кбіт надзвичайно малий для розгортання на апаратному рівні серверного класу.

У наступних статтях досліджується вплив на ефективність зміни кешу наперед читання та nr_requests на чергові блоки.

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-tuning - дійсно має значення
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

Наприклад, це запропоновані зміни для контролера RAID HP Smart Array:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

Що ще можна надійно налаштувати, щоб покращити продуктивність пам’яті?
Я спеціально шукаю варіанти sysctl та sysfs у виробничих сценаріях.

Я виявив, що коли мені довелося налаштувати на нижчу затримку проти пропускної здатності, я налаштував nr_requests вниз від за замовчуванням (до 32). Ідея менших партій дорівнює меншій затримці.

Також для read_ahead_kb я виявив, що для послідовного читання / запису збільшення цього значення пропонує кращу пропускну здатність, але я виявив, що ця опція дійсно залежить від вашої завантаженості та схеми вводу-виводу. Наприклад, у системі баз даних, яку я нещодавно налаштував, я змінив це значення на один розмір сторінки db, що допомогло зменшити затримку читання. Збільшення або зменшення понад цю величину виявилося в моєму випадку.

Що стосується інших параметрів або налаштувань для блокування черг пристроїв:

max_sectors_kb = Я встановив це значення, щоб відповідати тому, що дозволяє обладнання для однієї передачі (перевірте значення файлу max_hw_sectors_kb (RO) у sysfs, щоб побачити, що дозволено)

nomerges = це дозволяє вимкнути або відрегулювати логіку пошуку для об'єднання запитів io. (вимкнення цього сигналу може заощадити деякі цикли процесора, але я не бачив жодної користі при зміні цього для моїх систем, тому я залишив його за замовчуванням)

rq_affinity = Я ще цього не пробував, але ось пояснення за цим документом з ядра ядра

Якщо цей параметр є "1", блок-блок перемістить завершення запиту на процесор "групу", яка спочатку надіслала запит. Для деяких робочих навантажень це забезпечує значне скорочення циклів процесора за рахунок ефектів кешування.
Для конфігурацій пам’яті, яким потрібно максимально розподілити обробку завершення, налаштування цього параметра «2» змушує завершення роботи на запитувальному процесорі (минаючи «групу» логіки агрегації) »

планувальник = ви сказали, що ви спробували термін і noop. Я тестував і noop, і термін, але виявив виграш терміну для тестування, яке я останнім часом робив для сервера баз даних.

NOOP добре працював, але для нашого сервера баз даних я все ж зміг досягти кращої продуктивності, коригуючи планувальник термінів.

Параметри планувальника термінів, розташованих під / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = на зразок nr_requests, але специфічний для планувальника. Правило великого пальця налаштовується для зменшення затримки або вгору для пропускної здатності. Контролює розмір партії запитів для читання та запису.

write_expire = встановлює час закінчення для пакетів запису за замовчуванням 5000ms. Ще раз зменшення цього значення зменшує затримку запису, а збільшення значення збільшує пропускну здатність.

read_expire = встановлює час закінчення для пакетів читання за замовчуванням 500мс. Тут застосовуються ті самі правила.

front_merges = Я прагну вимкнути це, і він увімкнено за замовчуванням. Я не бачу потреби в планувальнику витрачати цикли процесора, намагаючись передати об'єднані запити вводу-виводу.

write_starved = оскільки кінцевий термін орієнтований на зчитування за замовчуванням, це обробити 2 пакети читання до обробки пакета запису. Я вважав, що за замовчуванням 2 є гарним для моєї роботи.

Більше всього, все залежить від вашої завантаженості.

read_ahead_kbможе допомогти вам, якщо дійсно корисно заздалегідь прочитати багато даних із якогось файлу, наприклад, під час трансляції відео. Іноді це може вам сильно нашкодити. Так, за замовчуванням 128 Кб може здатися невеликим, але при достатній сумісності він починає звучати як великий! З іншого боку, з таким сервером, як сервер кодування відео, який лише перетворює відео з формату в інший, це може бути дуже гарною ідеєю.

nr_requests, при перевантаженні може легко залити ваш RAID-контролер, що знову погіршить продуктивність.

У реальному світі потрібно спостерігати затримки . Якщо ви підключені до SAN, погляньте iostat, sarчи ви хочете користуватися, і подивіться, чи проходить дах час обслуговування запиту вводу / виводу. Звичайно, це допомагає і на локальних дисках: якщо затримки дуже великі, подумайте про налаштування налаштувань ліфтів вводу / виводу шляхом зменшення max_requests та інших налаштувань.

FYI read_ahead_kbі blockdev --setraпросто різні способи , щоб встановити однакові налаштування в різних одиницях вимірювання (кБ проти секторів):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

Тож

blockdev --setra 65536 /dev/cciss/c0d0

у вашому прикладі не має ефекту.