Nagły wzrost obciążenia po przeniesieniu na nowy serwer

[leonow32]

Witam

Prowadzę małe forum studenckie dla 120 osób z mojego kierunku. Od paru dni borykam się z takim problemem - po przeniesieniu forum na mech.8p.pl nagle wzrósł transfer do wręcz absurdalnych poziomów - przez trzy dni zjadło mi 600MB, a do bazy danych zostało wysłane 64 miliony zapytań (!!!). Obciążenie serwera przekraczało 7%.

Wyłączyłem shoutbox, wyszukiwarkę, wszystkie boty, zapisywanie przeczytanych tematów dałem na cookies i transfer dzienny spadł do jakich 50-80MB, 5 milionów zapytań do bazy i obciążenie serwera spadło do 0,7%, ale to i tak wiele razy więcej niż było na poprzednim serwerze. Dawniej przez pół roku do bazy trafiło 50 milionów pytań.

Dodam, że raz po raz pojawia się komunikat Internal Server Error. Czasami się pojawia i zaraz od razu znika po odświerzeniu, wydaje się, że jest to niezależne od liczby osób aktualnie siedzących na forum.

Przenoszenie forum wyglądało tak: przerzuciłem wszystkie pliki, zrobiłem kopię bazy danych przy pomocy forum, wgrałem na nowy tę kopię przez phpMyAdmin, ustawiłem plik config.php wraz z kilkoma innymi ustawieniami w panelu. Dla forumowiczów wszystko działa sprawnie i pięknie, ale ten transfer życie mi truje.

Jak mam to naprawić? Co tu może robić takie mega wielkie obciążenie?

Działam na phpBB 3.0.2, PHP: 5.2.8, MySQLi 5.0.67

[daroPL]

Jeżeli nie jest to spowodowane tym, że użytkownicy więcej klikają to stawiam na boty wyszukiwarek. No chyba, że masz na serwerze jeszcze jakąś inną stronę.

[leonow32]

Studenci akurat mają ferie i nie klikają zbyt wiele wszystkie boty wyszukiwarek są wyłączone, a na serwerze nie ma nic innego niż forum.

[jaroslw]

wszystkie boty wyszukiwarek są wyłączone

To, że je wyłączyłeś nie oznacza, że nie odwiedzają Twojego forum. Wyłączyłeś tylko pokazywanie ich na liście użytkowników.

Generowany transfer nie powinien się zwiększyć jeśli nie zwiększyła się liczba odwiedzających. Może ten nowy serwer stoi na słabszej maszynie niż poprzedni? Sprawdź ilość generowanych zapytań SQL.

[leonow32]

Wydaje mi się raczej mało prawdopodobne, żeby płatny serwer był słabszy od darmowego Po wyłączeniu najbardziej obciążających funkcji wychodzi 10 milionów zapytań dziennie.

[jaroslw]

W jaki sposób mierzysz ilość generowanych zapytań? W pliku config.php odkomentuj linię:

Kod: Zaznacz cały

// @define('DEBUG', true);

Podaj wynik ze strony głównej oraz listy i przeglądu tematów.

[leonow32]

Włączyłem od razu debug extra i tak:

na stronie głównej - Time : 0.060s | 8 Queries | GZIP : Off | Memory Usage: 2.87 MiB
przegląd tematów - Time : 0.078s | 11 Queries | GZIP : Off | Memory Usage: 3.14 MiB
temat - Time : 0.071s | 11 Queries | GZIP : Off | Memory Usage: 3.06 MiB

Zaznaczam, że forum ciągle ma wyłączoną wyszukiwarkę i shoutboxa. Te 10 milionów zapytań dziennie jest z phpMyAdmina.

[daroPL]

Wszystko w porządku. Ilość zapytań w normie.

[leonow32]

10 milionów to norma???

[daroPL]

Chodziło mi o ilość zapytań generowanych przez skrypt za jednym odświeżeniem. Po za tym licząc, że forum odwiedza 120 osób to nie są oni wstanie wykonać takiej ilości zapytań.
Sprawdź w logach serwera jakich zapytań SQL jest dużo.

[leonow32]

Najczęściej występują takie:
select (20%) set option (8%) change db (5%) delete (4%) update (4%) show create table (2%) show triggers (2%)insert (1%) - wszystkie inne jakieś małe ułamki procenta. Z bazy zostało ściągnięte 50GB danych, a otrzymane 3GB w ciągu 12 dni (całe szczęście, że na to nie ma limitu transferu )

Na stronie "Informacje o działaniu serwera" są zaznaczone na czerwono takie rzeczy:

Statystyki zapytań: Od rozpoczęcia jego pracy, do serwera zostało wysłanych 97 199 185 zapytań.
Slow_queries 4 603 Liczba zapytań, których wykonanie zajęło więcej niż long_query_time sekund
Innodb_buffer_pool_reads 133 k Liczba logicznych odczytów, których InnoDB nie mógł zaspokoić pulą bufora i musiał wykonać odczyt pojedynczej strony.
Innodb_row_lock_time_avg 832 Średni czas uzyskania blokady rekordu, w milisekundach.
Innodb_row_lock_time_max 3 141 Maksymalny czas uzyskania blokady rekordu, w milisekundach.
Innodb_row_lock_waits 6 Ile razy czekano na blokadę rekordu.
Handler_read_rnd 87 M Liczba żądań odczytu następnego rekordu na podstawie stałego położenia. Wartość jest duża przy wykonywaniu dużej ilości zapytań wymagających sortowania rezultatu. Prawdopodobnie wykonano wiele zapytań wymagających przeszukania całej tabeli lub złączeń, które nie używają poprawnie indeksów.
Handler_read_rnd_next 1 448 M Liczba żądań odczytu następnego rekord w pliku z danymi. Wartość jest duża przy wykonywania wielu przeszukiwań tabeli. Ogólnie sugeruje to, że tabele nie są poprawnie zindeksowane lub że zapytania nie są napisane w sposób pozwalający skorzystać z istniejących indeksów.
Qcache_lowmem_prunes 2 797 k Liczba zapytań, które zostały usunięte z pamięci podręcznej, by zwolnic pamięć do buforowania nowych zapytań. Ta informacje może pomóc dostroić wielkość bufora podręcznego. Do decydowania o tym, które zapytania usunąć z bufora podręcznego używana jest strategia "najpierw najdłużej nieużywany" (least recently used - LRU).
Created_tmp_disk_tables 2 804 k Liczba tabel tymczasowych na dysku utworzonych automatycznie przez serwer podczas wykonywanie instrukcji. Przy dużej wartości Created_tmp_disk_tables, zwiększenie wartości tmp_table_size spowoduje tworzenie tymczasowych tabel w pamięci, a nie na dysku.
Key_reads 13 M Liczba fizycznych odczytów bloków indeksów z dysku. Duża wartość key_reads oznacza, że prawdopodobnie wartość key_buffer_size jest zbyt mała. Współczynnik chybień bufora podręcznego można policzyć ze wzoru Key_reads/Key_read_requests.
Select_full_join 87 k Liczba złączeń nie używających indeksów. Wartość różna od 0 sugeruje staranne przyjrzenie się indeksom tabel.
Select_range_check 357 Liczba złączeń bez użycia indeksów gdy możliwość ich użycia była sprawdzana dla każdego rekordu. (Wartość różna od 0 sugeruje staranne przyjrzenie się indeksom tabel.)
Opened_tables 5 567 k Liczba kiedykolwiek otwartych tabel. Jeśli ta wartość jest duża, prawdopodobnie wielkość pamięci podręcznej tabel jest zbyt mała.
Table_locks_waited 7 958 Ile razy blokada tabeli nie mogła zostać uzyskana natychmiastowo i niezbędne było oczekiwanie. Przy wysoka wartość oraz problemach z wydajnością powinno się najpierw zoptymalizować zapytania, a następnie podzielić tabelę (tabele) lub użyć replikacji.

Co to znaczy, że tabele nie są prawidłowo zindeksowane? Co z tym można zrobić?

[jaroslw]

Spróbuj naprawić i optymalizować wszystkie tabele (opcja dostępna w phpMyAdminie).