Apache i bardzo wysoki load

[jasny 21]

Z powyższego raportu mk-query-digest wynika, że masz:

 

1. bardzo duże tabele, albo

2. niepoindeksowane JOINy

 

przy czym, opcja druga jest znacznie bardziej prawdopodobna.

 

SELECT m.member_id FROM mpc_members m LEFT JOIN mpc_pfields_content p ON ( p.member_id=m.member_id )

LEFT JOIN mpc_profile_portal pp ON ( pp.pp_member_id=m.member_id ) WHERE m.member_group_id NOT IN(5) ORDER BY m.members_l_display_name asc LIMIT 20,20\G

 

Podstawowa sprawa w przypadku czegoś takiego, to nałożenie indeksów na kolumny łączące tabele:

 

ALTER TABLE mpc_members ADD INDEX idx_member_id (member_id);

ALTER TABLE mpc_pfields_content ADD INDEX idx_member_id (member_id);

ALTER TABLE mpc_profile_portal ADD INDEX idx_pp_member_id (pp_member_id);

 

a także nałożenie indeksu na kolumnę w warunku WHERE:

 

ALTER TABLE mpc_members ADD INDEX idx_member_group_id (member_group_id);

 

Oczywiście, wcześniej przy pomocy SHOW INDEXES FROM tabela; upewnij się, czy taki indeks już nie istnieje np. w postaci klucza głównego - nie ma sensu dublować, trzeba się wtedy zastanowić, dlaczego nie jest wykorzystywany.

 

 

W przypadku tego zapytania:

 

SELECT m.*,p.* FROM mpc_members m LEFT JOIN mpc_profile_portal p ON ( p.pp_member_id=m.member_id ) WHERE m.members_l_display_name LIKE '%dewo%' OR p.pp_bio_content LIKE '%dewo%' OR p.signature LIKE '%dewo%' OR p.pp_about_me LIKE '%dewo%' ORDER BY member_id desc LIMIT 0,25\G

 

indeks na kolumny łączące być może trochę pomoże, ale jeśli tabela mpc_members jest spora, to to zapytanie nie ma prawa działać wydajnie. Obustronne wildcardy w WHERE potrafią zabić każdą bazę.

 

Zainteresuj się czymś takim, jak wyszukiwanie pełnotekstowe w MySQL (http://dev.mysql.com...ext-search.html), ewentualnie od razu (szczególnie jeśli planujesz, że ilość danych w tej tabeli będzie rosła), Sphinxem. Tyle że takie zmiany to już kwestia modyfikacji zapytań, czyli grzebania w kodzie serwisu.

 

Dzieki za wyczerpujaca odpowiedź, odrabiam zadanie domowe ;]

[Gość squeezer]

Dzieki za wyczerpujaca odpowiedź, odrabiam zadanie domowe ;]

 

Daj znać z jakim skutkiem. Wprowadź poprawki, zobacz co się po nich w slowlogu łapie. Podrzuć wyniki EXPLAIN tych zapytań.

[jasny 21]

Generalnie zastosowałem się do poprzednich zaleceń i wygląda na to, że jest lepiej. Wczoraj miałem tylko jeden "pik" na loadzie co widać na poniższym obazku. Wczoraj też forum przekroczyło barierę rekordu ( po prostu było w stanie wpuścić większą ilość osób ).

Wczoraj

 

 

Dzisiaj było już bez postojów.

 

Dzisiaj

 

 

Forum mam ustawione tak, że w momencie osiągnięcia load 30 wyświetla komunikat o przeciążeniu.

 

 

Dorzucam jeszcze loga z /var/log/messages z 24.08 ... nie potrafie zinterpretować tych komunikatów, które są w logach w okolicy 13 (w momencie piku ).

log.txt

[Gość N3T5kY]

a co ma w tym konkretnym przypadku kernel z tym wspolnego?

jesli jest cos co powinno byc przekompilowane w kernelu ovh to warto sie tym podzielic zamiast wypisywac ogolniki

 

np. w niektórych przypadkach łatka grsecurity może przeszkadzać

 

Wobraź sobie, że kernel ma dużo wspólnego z każdym przypadkiem! Fajny bajer co?

Edytowano Sierpień 25, 2010 przez N3T5kY (zobacz historię edycji)

[Gość squeezer]

Z tego logu wynika tyle, że podczas piku obciążenia kończy Ci się pamięć. Trzeba by organoleptycznie sprawdzić co jest tego przyczyną. Czy ilość procesów Apache leci w kosmos, bo MySQL nie wyrabia z wykonywaniem zapytań, czy po prostu tak jest, bo jest wzrost ruchu. Sprawdź w logach Apache czy około tej 13 wzrosła liczba połączeń w jednostce czasu? Ile jednoczesnych połączeń wtedy miałeś? Podczas kolejnego takiego wzrostu obciążenia spróbuj zaobserwować co się dzieje w bazie - czy zapytania wiszą zbyt długo? Jakie zapytania?

 

Jeśli jeszcze tego nie zrobiłeś, to może pora zainstalować oprócz Apache coś lekkiego - tak aby Apache zajmował się tylko php, a nginx czy inne takie wystawiało pliki statyczne? Ograniczysz w ten sposób liczbę procesów Apache konieczną do działania.

[jasny 21]

leży i kwiczy. Ciekawe jest to, że serwer padł rano... i leżał do wieczora. Czy to normalne zachowalnie linuksów, że kładą się po maxymalnym obciążeniu ?

[kafi 2425]

Jeśli jest to OpenVZ'owy VPS, to jak najbardziej, jeśli skończy mu się dostępna pamięć, to się wykłada.

[jasny 21]

To nie jest VPS, czytaj topik

[kafi 2425]

A jak wygląda ilość swapu?

[jasny 21]

Od kiedy na serwerach używamy swapu ;]

[kafi 2425]

A czemu niby posiadanie partycji swap na serwerze to zbrodnia?

 

No jeśli nie masz partycji SWAP, to w sumie nic dziwnego, że w peakach ci się system wysypuje.

Bo sytuacja jest taka sama jak i z OpenVZ'owym vpsem - kończy się pamięć, mallocki zwracają błędy, do tego działa OOM Killer, no i ogólnie działa to nieprzewidywalnie.

Nie jesteś nawet w stanie dobić się do owego serwera, bo próba startu powłoki również wywala ci błąd OOM.

[Gość squeezer]

leży i kwiczy. Ciekawe jest to, że serwer padł rano... i leżał do wieczora. Czy to normalne zachowalnie linuksów, że kładą się po maxymalnym obciążeniu ?

 

Normalne to to nie jest, aczkolwiek sporo zależy od tego co rozumiesz pod pojęciem 'pad'. Wyłączyć się nie powinien, ale mógł być tak zajęty sobą, że na jakąkolwiek reakcję na bodźce zewnętrzne nie miał czasu Tak z ciekawości, jeśli maszyna fizycznie działała, to czy udało mu się cokolwiek w logach nabazgrać przez czas 'padu'? Jeśli oomkiller pojechał, to powinieneś mieć w nich cokolwiek - z grubsza takie coś jak w poście z 25 August 2010 - 22:54

[jasny 21]

I znowu klops. Ciekawe jest to, że nagle wykorzystanie ramu skacze na 100%

 

Sep  4 06:25:01 mpcforum kernel: imklog 3.18.6, log source = /proc/kmsg started.
Sep  4 06:25:01 mpcforum rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="3737" x-info="http://www.rsyslog.com"] restart
Sep  4 16:56:38 mpcforum kernel: apache2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep  4 16:56:38 mpcforum kernel: apache2 cpuset=/ mems_allowed=0
Sep  4 16:56:38 mpcforum kernel: Pid: 14983, comm: apache2 Not tainted 2.6.34-xxxx-std-ipv4-64-hz1000 #2
Sep  4 16:56:38 mpcforum kernel: Call Trace:
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810b04fd>] ? cpuset_print_task_mems_allowed+0x8d/0xa0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c2dd6>] dump_header+0x76/0x1d0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810934f3>] ? ktime_get_ts+0xb3/0xe0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff814e9635>] ? ___ratelimit+0xa5/0x120
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c2fb1>] oom_kill_process+0x81/0x190
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c3510>] __out_of_memory+0x50/0xc0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c3606>] out_of_memory+0x86/0x1e0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c8152>] __alloc_pages_nodemask+0x722/0x750
Sep  4 16:56:38 mpcforum kernel: [<ffffffff81068488>] ? enqueue_task_fair+0x1b8/0x210
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810f0267>] alloc_pages_current+0x87/0xd0
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c09b7>] __page_cache_alloc+0x67/0x70
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c9b4b>] __do_page_cache_readahead+0xcb/0x210
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c9cac>] ra_submit+0x1c/0x20
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c9ec5>] ondemand_readahead+0x115/0x240
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810ca101>] page_cache_sync_readahead+0x31/0x50
Sep  4 16:56:38 mpcforum kernel: [<ffffffff810c2174>] generic_file_aio_read+0x4d4/0x680
Sep  4 16:56:38 mpcforum kernel: [<ffffffff81102341>] do_sync_read+0xd1/0x120
Sep  4 16:56:38 mpcforum kernel: [<ffffffff81102f78>] vfs_read+0xc8/0x180
Sep  4 16:56:38 mpcforum kernel: [<ffffffff81103120>] sys_read+0x50/0x90
Sep  4 16:56:38 mpcforum kernel: [<ffffffff81030d2b>] system_call_fastpath+0x16/0x1b
Sep  4 16:56:38 mpcforum kernel: Mem-Info:
Sep  4 16:56:38 mpcforum kernel: Node 0 DMA per-cpu:
Sep  4 16:56:38 mpcforum kernel: CPU	0: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	1: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	2: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	3: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	4: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	5: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	6: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	7: hi:	0, btch:   1 usd:   0
Sep  4 16:56:38 mpcforum kernel: Node 0 DMA32 per-cpu:
Sep  4 16:56:38 mpcforum kernel: CPU	0: hi:  186, btch:  31 usd: 105
Sep  4 16:56:38 mpcforum kernel: CPU	1: hi:  186, btch:  31 usd:   0
Sep  4 16:56:38 mpcforum kernel: CPU	2: hi:  186, btch:  31 usd: 185
Sep  4 16:56:38 mpcforum kernel: CPU	3: hi:  186, btch:  31 usd: 155
Sep  4 16:56:38 mpcforum kernel: CPU	4: hi:  186, btch:  31 usd:  29
Sep  4 16:56:40 mpcforum kernel: CPU	5: hi:  186, btch:  31 usd:  51
Sep  4 16:56:45 mpcforum kernel: CPU	6: hi:  186, btch:  31 usd: 100
Sep  4 16:56:49 mpcforum kernel: CPU	7: hi:  186, btch:  31 usd:   1
Sep  4 16:56:49 mpcforum kernel: Node 0 Normal per-cpu:
Sep  4 16:56:49 mpcforum kernel: CPU	0: hi:  186, btch:  31 usd: 183
Sep  4 16:56:49 mpcforum kernel: CPU	1: hi:  186, btch:  31 usd: 102
Sep  4 16:56:49 mpcforum kernel: CPU	2: hi:  186, btch:  31 usd: 143
Sep  4 16:56:50 mpcforum kernel: CPU	3: hi:  186, btch:  31 usd: 182
Sep  4 16:56:50 mpcforum kernel: CPU	4: hi:  186, btch:  31 usd:  56
Sep  4 16:56:50 mpcforum kernel: CPU	5: hi:  186, btch:  31 usd:  16
Sep  4 16:56:50 mpcforum kernel: CPU	6: hi:  186, btch:  31 usd: 124
Sep  4 16:56:50 mpcforum kernel: CPU	7: hi:  186, btch:  31 usd:  60
Sep  4 16:56:50 mpcforum kernel: active_anon:1602055 inactive_anon:315606 isolated_anon:225
Sep  4 16:56:50 mpcforum kernel: active_file:429 inactive_file:362 isolated_file:31
Sep  4 16:56:50 mpcforum kernel: unevictable:0 dirty:0 writeback:352 unstable:0
Sep  4 16:56:50 mpcforum kernel: free:11775 slab_reclaimable:4353 slab_unreclaimable:49788
Sep  4 16:56:50 mpcforum kernel: mapped:494 shmem:32 pagetables:47940 bounce:0
Sep  4 16:56:52 mpcforum kernel: Node 0 DMA free:15876kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolat$
Sep  4 16:56:52 mpcforum kernel: lowmem_reserve[]: 0 2991 8041 8041
Sep  4 16:56:52 mpcforum kernel: Node 0 DMA32 free:24224kB min:4264kB low:5328kB high:6396kB active_anon:2327468kB inactive_anon:582040kB active_file:412kB inactive_file:56kB unevictable:0kB iso$
Sep  4 16:56:52 mpcforum kernel: lowmem_reserve[]: 0 0 5050 5050
Sep  4 16:56:52 mpcforum kernel: Node 0 Normal free:7000kB min:7200kB low:9000kB high:10800kB active_anon:4080752kB inactive_anon:680384kB active_file:1304kB inactive_file:1392kB unevictable:0kB$
Sep  4 16:56:52 mpcforum kernel: lowmem_reserve[]: 0 0 0 0
Sep  4 16:56:52 mpcforum kernel: Node 0 DMA: 1*4kB 2*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15876kB
Sep  4 16:56:52 mpcforum kernel: Node 0 DMA32: 4379*4kB 43*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 1*4096kB = 24100kB
Sep  4 16:56:52 mpcforum kernel: Node 0 Normal: 779*4kB 40*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 6876kB

 

[Gość squeezer]

To niekoniecznie jest ciekawe, raczej normalne. Jakiś skok obciążenia - większa ilość jednoczesnych użytkowników na stronie, jakieś zapytanie do bazy, które się przycięło, ktoś na ftp zaczął coś wgrywać. W efekcie jeden element układanki zaczyna zdychać, drugi na niego czeka i rośnie w liczbę procesów czy też wątków. Procesy tak już mają, że chcą pamięci i pamięć się kończy. Taki problem może spowodować w zasadzie cokolwiek. Zorganizuj sobie jakiś dodatkowy monitoring - np. w cronie co pięć minut zrzucaj sobie gdzieś do logu wynik:

mysql -e 'SHOW FULL PROCESSLIST;'

wynik:

ps -T aux 

z konsoli. Ważne żeby była flaga T, która wyświetla ilość wątków - będzie można porównać ilość procesów Apache z ilością wątków MySQL. Przy okazji będzie się dało sprawdzić czy jakieś inne procesy w tle nie działają. Zrzucaj także wynik

vmstat 1 1

żeby można było zorientować się jaki jest ruch na dysku i obciążenie procesora.

 

Dzięki takiemu logowi będziesz miał przynajmniej jaki taki przegląd tego, jak rozwijała się sytuacja wraz ze wzrostem obciążenia.Jak już to zorganizujesz, to sprawdź logi Apache z czasu wzrostu obciążenia czy nie ma tam nic podejrzanego - większa ilość wywołań, szalejący googlebot i tak dalej.

[jasny 21]

Nie mogę sobie pozwolić na dalsze postoje... niestety Bardzo dziękuję za pomoc. Wygląda na to, że bariery sprzętowej niestety nie da się przeskoczyć , bez wielkich ingerencji w sam skrypt forum, w związku z tym kupuję mocniejszy serwer z 24gb ramu, mam nadzieję że to na jakiś czas wystarczy. Chciałem serdecznie podziękować wszystkim angażującym się w temacie, na pewno porady zawarte na tym forum posłużą mi w dalszej optymalizacji serwera.

 

Pozdrawiam!