wa (очікування вводу / виводу) від верхньої команди велике

У мене є форум з великою кількістю відвідувачів, Деякі дні навантаження збільшується до 40 без збільшення кількості вісторів. Як видно з нижченаведеного результату, час очікування високий (57%). як я можу знайти причину для цього?
Серверне програмне забезпечення - Apache, MySQL та PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Ось кілька інструментів для пошуку активності диска:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

Також ps auxfви побачите, які процеси перебувають у режимі сну без інтерпретації ( D), оскільки вони чекають вводу / виводу.

Деякі дні навантаження збільшується до 40 без збільшення кількості вісторів.

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

Вихід зверху говорить про те, що СУБД відчуває більшість очікувань вводу / виводу, тому проблеми налаштування бази даних є очевидним кандидатом для дослідження.

Очікування вводу / виводу на сервері баз даних, особливо на шинах завантаження, - це поняття, що ваша СУБД може бути пов'язана з диском (тобто вам потрібна швидша дискова підсистема) або може виникнути проблема налаштування. Напевно, ви також повинні вивчити профайл вашого сервера баз даних - тобто отримати слід про те, що він робить і які запити потребують часу.

Деякі початкові моменти діагностики проблем з налаштуваннями баз даних: -

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

• Тривалий час очікування ресурсів може означати, що необхідно розширити деякі ключові ресурси.

• Тривалий час очікування вводу / виводу може означати, що вам потрібна швидша дискова підсистема.

• Чи є ваш журнал та обсяги даних на окремих дисках? Журнали бази даних мають багато невеликих послідовних записів (по суті вони ведуть себе як кільцевий буфер). Якщо у вас зайнято робоче навантаження з випадковим доступом, спільне використання тих же дисків, що і ваші журнали, це буде непропорційно впливати на пропускну здатність журналу. Для здійснення транзакції з базою даних для запису журналу записи повинні бути записані на диск, тому це покладе вузьке місце на всю систему.
  
  Зауважте, що деякі двигуни зберігання MySQL не використовують журнали, тому це може бути проблемою у вашому випадку.

Виноска: Системи черги

Системи черги (статистична модель пропускної здатності) стають гіперболічно повільнішими, коли система наближається до насичення. Для наближення високого рівня система, яка насичена 50%, має середню довжину черги 2. Система, яка насичена 90%, має довжину черги 10, система, насичена 99%, має довжину черги 100.

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

Запустіть iotopабо atop -dD, щоб побачити, які процеси роблять io. Використовуйте, straceякщо вам потрібно детальніше придивитися.

На обох екранах впевнений, що схоже на "mysqld".

Вам потрібно побачити, що робить цей демон ... які запити виконуються.

Деякі дні навантаження збільшується до 40 без збільшення кількості вісторів.

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

Також: ти працюєш на виділеному сервері або VPS? Якщо ваша служба не на спеціалізованому сервері, дії додатків, що працюють на тому ж хості, матимуть ефект, оскільки VM, з якими працює VM, з яким хост буде конкурувати за частку ресурсу вводу / виводу.

Як зазначають інші, подібні інструменти iotopдопоможуть вам глибше заглянути в те, які завдання сиділи в очікуванні відповідей на введення-виведення та до яких файлів вони отримують доступ у той час.

Як каже Фліп, схоже, проблема полягає в тому, що робить mysql.

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

Я коли-небудь бачу подібне використання процесора / диска під час виконання запитів, що оновлюють мільйони рядків.

Високе середнє навантаження є прямим наслідком вводу-виводу.

Відкрутіть ваш журнал mysql, щоб побачити, чи там поганий код / ​​допоможуть зміни індексів. Аналіз ваших таблиць може допомогти (але, мабуть, не дуже).

C.