У мене є екземпляр MySQL на двох виділених серверах. Один для виробництва, інший для тестової платформи.

Два сервери майже однакові, різниця лише в тому, що RAID-контролер і віртуальна гучність (HD однакові). На виробництві є виділений HW RAID-контролер та об'єм RAID 10. З іншого боку, контролер RAID, здається, є програмним забезпеченням (Lenovo ThinkServer RAID 110i), а гучність - RAID 5.

Ми помітили, що під час зобов’язань MySQL ми спостерігаємо високий вміст:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 & dm-14-8 пов'язані з розділами бази даних.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Я підозрюю рейдерського контролера, як я можу бути впевненим?

Моя відповідь мала 2 частини: дослідження драйвера блокового пристрою; та оптимізацію, на яку варто звернути увагу у випадку використання. Але я видалив останню частину, оскільки повідомлялося, що це може призвести до втрати даних. Дивіться коментарі.

Дослідження обладнання

Я зрозумів, що для одного і того ж додатка, але на двох різних наборах апаратних засобів продуктивність дуже відрізняється, і ви хочете зрозуміти, чому. Тому я пропоную спочатку засіб, який допоможе вам знайти відповідь на "чому".

Для продуктивності я часто посилаюся на карту продуктивності Linux, надану Бренданом Греггом у своєму блозі. Можна побачити, що для низького рівня (найближчого до апаратного) такий інструмент, як blktraceби, був ідеальним.

Не дуже знаючи цей інструмент, я роздивився і знайшов цю цікаву статтю про blktrace від Марка Брукера. В основному він пропонує наступне: виконання тракту вводу / виводу за допомогою blktrace; використовуючи інструмент btt для отримання інформації з цього сліду. Це було б щось подібне (для сліду 30 с):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

Вихід може бути досить довгим, але шукайте записи D2C. Це дасть вам уявлення про час, необхідний для повідомлення про введення / виведення, доставлене драйверу пристрою, про завершення цього драйвера.

Приклад виводу ( dnf upgradeпрацює на VM VirtualBox на моєму зайнятому ноутбуці):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Він показує невтішну середню 45 мс на введення / вивід, до 3,94 с у гіршому випадку !!

Щоб дізнатися більше про способи використання blktrace для проведення цього дослідження, прочитайте статтю Marc Brooker, дуже повчальну.

Процес jbd2 призначений для документування ext4. Логічно, що файловій системі потрібно писати в журнал під час виконання mysql, це не повинно бути приводом для будь-яких турбот. На величину навантаження, спричиненої jbd, впливають ваші параметри кріплення для розділів dm-10-8 та dm-14-8. Напевно, бажано провести дуже консервативне переміщення в розділі бази даних, щоб уникнути пошкодження вашої бази даних, якщо щось трапиться, а ваш сервер випадково перезавантажиться. Ви можете вибрати інші параметри кріплення в тестовому середовищі лише для порівняння.