Змініть одне, виміряйте знову: як знайти справжнє вузьке місце

Коли платформа повільна, найшвидше замовлення є замовленням на більше всього. Воно часто трохи допомагає, дорого коштує і залишає справжню причину на місці, щоб та вкусила знову на наступному піку трафіку. Альтернатива менш захоплива і набагато ефективніша: знайти той один ресурс, на який чекає навантаження, змінити в ньому одне і виміряти знову. Ось метод та інструменти.

Почніть з числа, а не з відчуття

«Сайт повільний» перевірити не можна. «Checkout займає чотири секунди на вечірньому піку і менше однієї вночі» можна. Перш ніж чогось торкатися, прив’яжіть симптом до вимірювання, яке можна повторити: час сторінки ззовні, тривалість запиту, час виконання пакетного завдання, частота запитів, за якої починаються помилки. Це число є тим, за чим ви зрозумієте, чи допомогло хоч щось із того, що ви змінили. Без нього кожна зміна відчувається як прогрес.

Потім запишіть шлях, який проходить повільна операція: клієнт, мережа, балансувальник, web-сервер, застосунок, кеш, база даних, сховище. Вузьке місце десь на цьому шляху, і шлях каже вам, куди дивитися.

Перевіряйте кожен ресурс на використання, насичення й помилки

Проста дисципліна, яку популяризував Brendan Gregg як метод USE, тримає пошук чесним. Для кожного ресурсу на шляху, CPU, пам’ять, мережа, сховище, ставте три питання: наскільки він зайнятий, чи стоїть робота в черзі до нього, і чи повідомляє він про помилки? Ресурс може бути мало завантаженим і все одно бути проблемою, якщо запити стоять у черзі перед ним, тож друге питання важить найбільше.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Дивіться на використання по ядрах, а не лише на середнє. Одне ядро під повним навантаженням, коли решта простоюють, вказує на однопотокове вузьке місце, яке більша кількість ядер не виправить. У vmstat run queue (r), яка стабільно більша за кількість ядер, є насиченням.

Пам’ять.

free -h
vmstat 1
cat /proc/pressure/memory

Тиск на пам’ять проявляється як активність reclaim і час простою у файлі pressure. На правильно побудованій віртуальній машині немає swap, у якому можна сховатися, тож навантаження, якому справді потрібно більше пам’яті, ніж воно має, падає гучно, і це чесний результат: виправлення є або більше пам’яті, або ощадливіший застосунок.

Сховище.

iostat -x 1
pidstat -d 1

Стовпці, які мають значення, це середній час очікування читання і запису та розмір черги. %util вводить в оману на flash і томах SAN, які обслуговують багато запитів паралельно і можуть показувати високе використання, маючи ще багато запасу. Зростання часу очікування разом із зростанням черги є справжнім сигналом.

Мережа.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Порівнюйте трафік по учасниках bond: один учасник зайнятий, поки інший простоює, це проблема hashing, а не пропускної здатності. Втрати й помилки в лічильниках інтерфейсу вказують нижче операційної системи, на кабелі, оптику або комутатор.

База даних. Багато повільних платформ є базою даних, яка читає з диска те, що мала б читати з пам’яті. На MySQL або MariaDB порівняйте логічні читання з читаннями, які мусили піти в сховище:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Якщо Innodb_buffer_pool_reads (читання, що промахнулися повз пам’ять) зростає швидко відносно Innodb_buffer_pool_read_requests, робочий набір не вміщується в buffer pool. Slow query log з розумним порогом каже вам, які запити за це платять.

Змініть одне

Щойно один ресурс виділяється, сформулюйте гіпотезу, яка пояснює початкове число, і зробіть одну зміну, яка її перевіряє: buffer pool, розрахований під робочий набір, політику hash для bond, кеш перед дорогою сторінкою, запит з індексом, якого йому бракує, VM, зменшену так, щоб уміститися в один сокет CPU. По одній зміні за раз, бо якщо ви зміните три речі й число покращиться, ви не знатимете, яка саме допомогла, і, можливо, залишите дві, які все погіршили.

Виміряйте знову, тим самим способом

Повторіть вимірювання з початку, за тих самих умов: та сама пора доби або те саме синтетичне навантаження, той самий тест, ті самі інструменти. Зміна, яка не допомогла, усе одно є результатом, бо вона щось виключає; відкотіть її і поверніться до ресурсів.

Повторюйте, доки початковий симптом не зникне або наступне вузьке місце не стане тим, що справді має вирішувати гроші. Саме тоді купівля обладнання є правильною відповіддю, і ви точно знатимете, який ресурс купувати.

Як це виглядає на практиці

Деякі з найефективніших налаштувань мають довжину в один рядок. Ми розраховуємо буфери пам’яті баз даних так, щоб гарячі дані жили в RAM, а flash обслуговував справжню роботу, і кожен сервер з bond, який ми будуємо, хешує за адресами і портами, щоб обидві лінії несли трафік. Обидва є постійними правилами на кожній платформі, якою ми керуємо.

Як ми це робимо

Робота над продуктивністю є тим, як ми експлуатуємо кожну платформу, якою керуємо, а не окремим продуктом. Ми вимірюємо на кожному рівні, від I/O по томах на масивах і лічильників по портах на bond і комутаторах до slow logs на базах даних і зовнішнього вимірювання часу через CDN, перш ніж назвати причину. Постійні правила, які надійно правильні, такі як bond, що використовує обидві лінії, flash, до якого ставляться як до flash, і VM, що вміщуються в один сокет, застосовуються до кожної збірки. Коли платформі справді потрібно більше ємності, ми кажемо вам, який ресурс, скільки й чому.

Якщо ваша платформа повільна, а єдина пропозиція досі була «більший сервер», дайте нам спершу її виміряти.

Поговоріть з інженером

Related

Пов’язане: Інженерія продуктивності та ємності · Bare metal сервери на HPE і Dell · Enterprise SAN сховище на HPE 3PAR, all-flash