wa (Oczekiwanie na We / Wy) z górnego polecenia jest duże

Mam forum z dużą liczbą odwiedzających. W niektórych dniach obciążenie wzrasta do 40 bez wzrostu liczby odwiedzających. Jak widać z poniższego wyjścia, czas oczekiwania jest wysoki (57%). jak znaleźć przyczynę tego?
Oprogramowanie serwera to Apache, MySQL i 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

Oto kilka narzędzi do wyszukiwania aktywności na dysku:

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

W ps auxfmożna także sprawdzić, które procesy są w nieinterpretowalną -tę snu dysku ( D), ponieważ czekają na I / O.

W niektóre dni obciążenie wzrasta do 40 bez wzrostu liczby odwiedzin.

Możesz także utworzyć kopię zapasową i sprawdzić, czy dysk twardy powoli przestaje działać. Dysk twardy zwykle zaczyna zwalniać, zanim się zwalnia. To może również wyjaśniać wysokie obciążenie.

Dane wyjściowe z góry sugerują, że DBMS doświadcza większości oczekiwań we / wy, więc problemy ze strojeniem bazy danych są oczywistym kandydatem do zbadania.

Oczekiwanie we / wy na serwerze bazy danych - szczególnie w przypadku skoków obciążenia - jest wskazówką, że DBMS może być albo związany z dyskiem (tzn. Potrzebujesz szybszego podsystemu dyskowego), albo może mieć problem ze strojeniem. Prawdopodobnie powinieneś również przeanalizować profilowanie serwera bazy danych - tzn. Uzyskać informacje o tym, co robi i jakie zapytania zajmują dużo czasu.

Niektóre punkty początkowe do diagnozowania problemów z dostrajaniem bazy danych: -

• Znajdź zapytania, które zajmują najwięcej czasu, i spójrz na plany zapytań. Sprawdź, czy jakieś mają dziwne plany zapytań, takie jak skanowanie tabeli tam, gdzie nie powinno być. Może baza danych wymaga dodania indeksu.

• Długi czas oczekiwania na zasób może oznaczać konieczność rozszerzenia pewnej puli kluczowych zasobów.

• Długie czasy oczekiwania we / wy mogą oznaczać, że potrzebujesz szybszego podsystemu dyskowego.

• Czy woluminy dziennika i danych znajdują się na osobnych dyskach? Dzienniki bazy danych zawierają wiele małych zapisów sekwencyjnych (zasadniczo zachowują się jak bufor pierścieniowy). Jeśli masz zajęte obciążenie losowego dostępu współdzielące te same dyski co dzienniki, będzie to nieproporcjonalnie wpływać na przepustowość rejestrowania. Aby transakcja w bazie danych została zatwierdzona, wpisy dziennika należy zapisać na dysku, co spowoduje wąskie gardło w całym systemie.
  
  Pamiętaj, że niektóre silniki pamięci MySQL nie używają dzienników, więc może to nie być problem w twoim przypadku.

Przypis: Systemy kolejkowania

Systemy kolejkowania (model statystyczny przepustowości) stają się hiperbolicznie wolniejsze, gdy system zbliża się do nasycenia. Dla przybliżenia wysokiego poziomu, system, który jest w 50% nasycony, ma średnią długość kolejki 2. System, który jest w 90% nasycony, ma długość kolejki 10, a system, który jest w 99% nasycony, ma długość kolejki 100.

Zatem w systemie zbliżonym do nasycenia niewielkie zmiany obciążenia mogą powodować duże zmiany czasów oczekiwania, co w tym przypadku przejawia się jako czas oczekiwania na operacje we / wy. Jeśli pojemność I / O podsystemu dyskowego jest prawie nasycona, niewielkie zmiany obciążenia mogą spowodować znaczące zmiany w czasach odpowiedzi.

Uruchom iotoplub atop -dD, aby zobaczyć, jakie procesy wykonują io. Użyj, stracejeśli potrzebujesz dokładniejszego spojrzenia.

Na obu ekranach wygląda na to, że „mysqld” jest odpowiedzialny.

Musisz zobaczyć, co robi ten demon ... jakie zapytania są uruchomione.

W niektóre dni obciążenie wzrasta do 40 bez wzrostu liczby odwiedzin.

To, co robią użytkownicy, może być równie znaczące, jak liczba, która faktycznie tam jest. Operacje takie jak przeszukiwanie forum będą bardziej wymagające niż ładowanie i przeglądanie pojedynczych wątków lub list wątków.

Ponadto: czy korzystasz z dedykowanego serwera lub VPS? Jeśli Twoja usługa nie znajduje się na serwerze dedykowanym, działania aplikacji działających na tym samym hoście będą miały wpływ, ponieważ maszyny wirtualne, z którymi dzieli się maszyna wirtualna, będą rywalizować o udział w zasobach we / wy.

Jak zauważyli inni, narzędzia takie iotoppomogą ci głębiej przyjrzeć się zadaniom, które czekają na odpowiedzi I / O i jakie pliki mają w danym momencie dostęp.

Jak mówi Flip, wygląda na to, że problem dotyczy tego, co robi mysql.

Około połowa twojej fizycznej pamięci jest obecnie używana do buforowania I / O - oprogramowanie forum generuje zwykle wiele szybkich zapytań zwracających małą liczbę wierszy z mocno wypaczonymi gorącymi obszarami dysku - więc coś zdecydowanie dzieje się źle, jeśli system wydaje tyle czasu czekam.

Zawsze widzę takie użycie procesora / dysku podczas uruchamiania zapytań aktualizujących miliony wierszy.

Wysoka średnia obciążenia jest bezpośrednią konsekwencją wejścia / wyjścia.

Podkręć logowanie mysql, aby zobaczyć, czy jest tam zły kod / zmiana indeksów pomogłaby. Analiza twoich tabel może pomóc (ale prawdopodobnie niewiele).

DO.