Терміновий ремонт перевантаженого сервера

Зовнішній інструмент моніторингу повідомить вам, що середній час відгуку 5 відстежуваних URL-адрес збільшився вдвічі за останні 30 хвилин. Проект працює на одному фізичному сервері, який не знаходиться під вашим управлінням і працює десь в дата-центрі. Ви підключаєтесь через SSH, запускаєте htop і бачите, що процесор завантажений на 95%, а пам'ять давно переповнена.

По git'у ви знаєте, що близько тижня тому зробили міграцію бази даних на нову структуру таблиць, і колега пише в чаті, що йому довелося запускати міграцію вночі, тому що перерахунок стовпців та індексів зайняв близько 5 годин, під час яких майже вся база даних була заблокована, і не працювали ні INSERT, ні SELECT.

Отже, проблеми з продуктивністю, ймовірно, пов'язані з неправильно спроектованими індексами, погано переробленими SQL-запитами або великим пулом з'єднань. Часу на реверс немає, на сайті 7 тисяч користувачів за даними Google Analytics, і відключення на 5 годин означало б репутаційний ризик для клієнта, а також втрату за цей час від десятків до сотень тисяч крон (важко оцінити, кіношники вигадують достатньо). Ви розумієте, що тестування лише функціональності на тестовому середовищі недостатньо, і вам потрібно також реалізувати навантажувальний тест.

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

Як діяти далі?

1. Ти нічого не робиш. Сайт буде працювати повільніше, але поки сервер може з цим впоратися, думаю, це нормально...
2. Ви спробуєте підготувати план відновлення структури БД і запустити його якнайшвидше.
3. Ви мігруєте сайт на більш потужний сервер (але це означає негайне підвищення ціни для клієнта, а потім очікування, можливо, 6 годин, поки міграція завершиться, адже у вас сотні ГБ таблиць бази даних).
4. Ви дізнаєтеся, які SQL-запити і які сторінки займають найбільше часу, і просто відключите їх.
5. Ви запускаєте Cloudflare і дозволяєте йому статично перевіряти все, що він може.
6. Якась інша магія (не думаю, що тут багато чого можна придумати)...

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt