Temat: problem z obciażeniem

Posiadamy dwa serwery dedykowane

Opteron 2216 Dual 2.4 GHz 2 GB RAM

dla www z dyskami sata raid-5
dla mysql z dyskami sas raid-10

Transfer miesięczny 380GB

Obecna oglądalność ok 7tys UU/dzień ok 32tys odsłon | ok 120tys UU/miesiąc 9000tys odsłon/ miesiąc -> strony serwisów
do tego udostępniana mapka pogody (kilka swf + xml) 60tys/dzień (600tys requestów na dzień) | ok 2.5mln/miesiąc
serwer reklam OpenX ok 200tys/dzień
różnej maści boty (Googlebot,msn,yahoo) ok 100tys requestów/dzień.

Patrząc na ilość requestów tj ok 1mln dziennie (nie licząc gif,jpg,jpeg,png,js,ico,css)

W szczycie czyli od 12:00 do 21:00 CPU skacze do 80-90%

Obecnie głównie siada www ile na tego typu serwerze można wyciągnąć.
Do końca roku planowane jest 2mln odsłon i ok 200tys użytkowników jeśli chodzi o strony serwisów.
Czy te maszyny są w stanie to udźwignąć.

Temat: problem z obciażeniem

Tadeusz Nowak:
Posiadamy dwa serwery dedykowane

Opteron 2216 Dual 2.4 GHz 2 GB RAM

dla www z dyskami sata raid-5
dla mysql z dyskami sas raid-10

Transfer miesięczny 380GB

Obecna oglądalność ok 7tys UU/dzień ok 32tys odsłon | ok 120tys UU/miesiąc 9000tys odsłon/ miesiąc -> strony serwisów
do tego udostępniana mapka pogody (kilka swf + xml) 60tys/dzień (600tys requestów na dzień) | ok 2.5mln/miesiąc
serwer reklam OpenX ok 200tys/dzień
różnej maści boty (Googlebot,msn,yahoo) ok 100tys requestów/dzień.

Patrząc na ilość requestów tj ok 1mln dziennie (nie licząc gif,jpg,jpeg,png,js,ico,css)

W szczycie czyli od 12:00 do 21:00 CPU skacze do 80-90%

Obecnie głównie siada www ile na tego typu serwerze można wyciągnąć.
Do końca roku planowane jest 2mln odsłon i ok 200tys użytkowników jeśli chodzi o strony serwisów.
Czy te maszyny są w stanie to udźwignąć.

Nie, a dokladniej: To nie jest pytanie, na ktore da sie odpowiedziec konkretenie bez dostepu do tego sprzetu, jego logow, konfiguracji itp.

Temat: problem z obciażeniem

Logi mogę udostępnić konfigurację też tylko musiałbym dostać info co jest potrzebne.

Temat: problem z obciażeniem

W ciemno stawiam, że porzebny Ci jest varnish.

Temat: problem z obciażeniem

Podczas godzin szczytu jakie procesy jadą Ci po maszynie? Co Ci mówi top/mysql? Możliwe, że masz nieoptymalnie skonfigurowanego mysql lub apache. Wklej proszę:

$ ps aux
$ w | head -n 1
$ free
$ mysqladmin -u USERNAME -pPASSWORD status
$ df -h
$ df -i
$ curl http://localhost/server-status (potrzebny jest mod_status do apache)
$ netstat -n

Zainstaluj sobie collectd na maszynie i zbieraj statystyki ruchu oraz obciążenia na maszynie. Wklej to, pomyślimy jak to zoptymalizować ew. cachować.

Temat: problem z obciażeniem

To trochę abstrakcyjne pytanie. Nie wiadomo. Może masz kod nieoptymalny, może baza się sype, może co innego. Nikt Ci nie odpowie czy coś może działać czy nie bez dokładnej analizy.

Jak masz bazy danych to sprawdź jak wygląda zużycie cache'a - może trzeba coś przekonfigurować.
Zprofiluj kod aplikacji - może po da się coś ulepszyć. (z zaznaczeniem na profilowanie, a nie zmianę czegoś na ślepo)
Zainstaluj munin'a albo cacti, żeby wiedzieć co dokładnie nie wyrabia (io / sieć / swap / procesor / etc.)
Sprawdź jak wygląda rozkład obciążenia na wątki - jeśli wcześniej znalazłeś, że wszystko stoi na io, może zwiększenie ilości obsługiwanych requestów pozwoli przebić się tym wymagającym tylko cpu.
Jak serwujesz pliki statyczne - może zaoszczędzisz trochę czasu ładując je do jakiegoś fs'a w pamięci.

itd. itd. - musisz po prostu każdy element systemu sprawdzić sam - my mamy za dużo do zgadywania tutaj...

Temat: problem z obciażeniem

Kamil Grabowski:
Podczas godzin szczytu jakie procesy jadą Ci po maszynie? Co Ci mówi top/mysql? Możliwe, że masz nieoptymalnie skonfigurowanego mysql lub apache. Wklej proszę:

$ ps aux
$ w | head -n 1
$ free
$ mysqladmin -u USERNAME -pPASSWORD status
$ df -h
$ df -i
$ curl http://localhost/server-status (potrzebny jest mod_status do apache)
$ netstat -n

Zainstaluj sobie collectd na maszynie i zbieraj statystyki ruchu oraz obciążenia na maszynie. Wklej to, pomyślimy jak to zoptymalizować ew. cachować.

$ ps -aux
----------------------------------------------------------
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 12 74.2 0.0 0 16 ?? RL 12Feb10 69371:58.39 [idle: cpu0]
root 11 49.6 0.0 0 16 ?? RL 12Feb10 51132:39.71 [idle: cpu1]
root 48169 0.0 0.1 9056 1124 ?? S 1:07PM 1:18.59 /usr/bin/vmstat 5 17280
root 0 0.0 0.0 0 0 ?? WLs 12Feb10 0:00.32 [swapper]
root 1 0.0 0.0 2180 180 ?? ILs 12Feb10 0:01.88 /sbin/init --
root 2 0.0 0.0 0 16 ?? DL 12Feb10 2:40.45 [g_event]
root 3 0.0 0.0 0 16 ?? DL 12Feb10 47:50.22 [g_up]
root 4 0.0 0.0 0 16 ?? DL 12Feb10 63:15.95 [g_down]
root 5 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [kqueue taskq]
root 6 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [thread taskq]
root 7 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [xpt_thrd]
root 8 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [acpi_task_0]
root 9 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [acpi_task_1]
root 10 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [audit]
root 13 0.0 0.0 0 16 ?? WL 12Feb10 12:56.38 [swi1: net]
root 14 0.0 0.0 0 16 ?? WL 12Feb10 1221:06.02 [swi4: clock sio]
root 15 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [swi3: vm]
root 16 0.0 0.0 0 16 ?? DL 12Feb10 22:15.24 [yarrow]
root 17 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [swi5: +]
root 18 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [swi6: Giant taskq]
root 19 0.0 0.0 0 16 ?? WL 12Feb10 0:00.01 [swi6: task queue]
root 20 0.0 0.0 0 16 ?? WL 12Feb10 36:25.01 [swi2: cambio]
root 21 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [acpi_task_2]
root 22 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq9: acpi0]
root 23 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq14: ata0]
root 24 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq15: ata1]
root 25 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq10: ohci0 ohci+]
root 26 0.0 0.0 0 16 ?? DL 12Feb10 0:00.39 [usb0]
root 27 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [usbtask-hc]
root 28 0.0 0.0 0 16 ?? DL 12Feb10 0:00.00 [usbtask-dr]
root 29 0.0 0.0 0 16 ?? DL 12Feb10 0:00.26 [usb1]
root 30 0.0 0.0 0 16 ?? DL 12Feb10 0:01.00 [usb2]
root 31 0.0 0.0 0 16 ?? WL 12Feb10 581:16.19 [irq256: bge0]
root 32 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq257: bge1]
root 33 0.0 0.0 0 16 ?? WL 12Feb10 17:16.84 [irq28: twa0]
root 34 0.0 0.0 0 16 ?? WL 12Feb10 0:01.54 [swi0: sio]
root 35 0.0 0.0 0 16 ?? WL 12Feb10 0:00.00 [irq1: atkbd0]
root 36 0.0 0.0 0 24 ?? DL 12Feb10 0:00.00 [sctp_iterator]
root 37 0.0 0.0 0 16 ?? DL 12Feb10 694:12.43 [dummynet]
root 38 0.0 0.0 0 16 ?? DL 12Feb10 3:33.55 [pagedaemon]
root 39 0.0 0.0 0 16 ?? DL 12Feb10 0:11.78 [vmdaemon]
root 40 0.0 0.0 0 16 ?? DL 12Feb10 0:00.06 [pagezero]
root 41 0.0 0.0 0 16 ?? DL 12Feb10 0:05.24 [idlepoll]
root 42 0.0 0.0 0 16 ?? DL 12Feb10 0:23.07 [bufdaemon]
root 43 0.0 0.0 0 16 ?? DL 12Feb10 121:39.03 [syncer]
root 44 0.0 0.0 0 16 ?? DL 12Feb10 3:50.77 [vnlru]
root 45 0.0 0.0 0 16 ?? DL 12Feb10 8:17.91 [softdepflush]
root 46 0.0 0.0 0 16 ?? DL 12Feb10 8:07.69 [schedcpu]
root 463 0.0 0.0 2176 16 ?? Is 12Feb10 0:00.00 /sbin/devd
root 518 0.0 0.0 5908 564 ?? Is 12Feb10 0:10.28 /usr/sbin/syslogd -ss
root 629 0.0 0.0 22292 464 ?? Is 12Feb10 0:00.91 /usr/sbin/sshd -o ListenAddress=XXXXX
root 1083 0.0 0.1 11096 1156 ?? Ss 12Feb10 1:32.34 sendmail: accepting connections (sendmail)
smmsp 1087 0.0 0.0 11096 816 ?? Is 12Feb10 0:01.24 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
root 1093 0.0 0.0 6972 772 ?? Is 12Feb10 0:12.36 /usr/sbin/cron -s
root 1117 0.0 0.0 8024 272 ?? Is 12Feb10 0:00.02 /usr/sbin/inetd -wWa XXXXXXX
root 1147 0.0 0.0 5912 180 ?? S 12Feb10 0:03.94 /usr/libexec/getty std.115200 ttyd1
root 5783 0.0 0.0 5908 608 ?? SsJ 12Feb10 2:38.29 /usr/sbin/syslogd -ss
root 5850 0.0 0.0 22292 448 ?? IsJ 12Feb10 0:01.18 /usr/sbin/sshd -o ListenAddress=XXXXX
root 5857 0.0 0.0 6972 404 ?? IsJ 12Feb10 0:16.41 /usr/sbin/cron -J 15 -s
root 5967 0.0 0.0 5908 604 ?? SsJ 12Feb10 0:06.94 /usr/sbin/syslogd -ss
root 6038 0.0 0.0 6972 404 ?? IsJ 12Feb10 0:10.60 /usr/sbin/cron -J 15 -s
root 15501 0.0 0.0 2788 604 ?? S 8:07PM 0:00.00 sleep 5
1019 15520 0.0 0.0 0 0 ?? ZJ 8:07PM 0:00.08 <defunct>
serwisy 15521 0.0 0.6 69852 11808 ?? SJ 8:07PM 0:00.06 /usr/local/bin/php-cgi -c php.ini
serwisy 15528 0.0 0.6 69852 11796 ?? SJ 8:07PM 0:00.06 /usr/local/bin/php-cgi -c php.ini
serwisy 15529 0.0 0.6 69852 11792 ?? SJ 8:07PM 0:00.06 /usr/local/bin/php-cgi -c php.ini
1037 15531 0.0 0.0 560 372 ?? RJ 8:07PM 0:00.00 /bin/sh php5-wrapper.fcgi
1019 15533 0.0 0.3 42772 6248 ?? RJ 8:07PM 0:00.02 /usr/local/bin/php-cgi -c php.ini
1012 15534 0.0 0.6 69852 11892 ?? SJ 8:07PM 0:00.06 /usr/local/bin/php-cgi -c php.ini
root 48164 0.0 0.1 6972 1164 ?? I 1:07PM 0:00.00 cron: running job (cron)
root 48165 0.0 0.1 7364 1444 ?? Is 1:07PM 0:00.00 /bin/sh -c /root/skrypty/rap/raport.sh
root 48166 0.0 0.1 9288 1892 ?? I 1:07PM 0:00.00 /usr/local/bin/bash raport.sh
root 48168 0.0 0.1 9288 2020 ?? S 1:07PM 0:04.85 /usr/local/bin/bash raport_netstat2.sh 5 17280
root 78954 0.0 0.0 5908 812 ?? SsJ 2Apr10 0:01.70 /usr/sbin/syslogd -ss
root 79026 0.0 0.0 6972 408 ?? IsJ 2Apr10 0:01.92 /usr/sbin/cron -J 15 -s
root 79040 0.0 0.0 8024 628 ?? IsJ 2Apr10 0:00.18 /usr/sbin/inetd -wW -C 60
root 13179 0.0 0.2 10312 3216 d0 I+ 8:04PM 0:00.06 -bash (bash)
root 63832 0.0 0.1 20704 1700 d0 Is Sat12PM 0:00.01 login [pam] (login)
root 1138 0.0 0.0 5912 16 v0 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv0
root 1139 0.0 0.0 5912 16 v1 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv1
root 1140 0.0 0.0 5912 16 v2 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv2
root 1141 0.0 0.0 5912 16 v3 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv3
root 1142 0.0 0.0 5912 16 v4 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv4
root 1143 0.0 0.0 5912 16 v5 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv5
root 1144 0.0 0.0 5912 16 v6 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv6
root 1145 0.0 0.0 5912 16 v7 Is+ 12Feb10 0:00.00 /usr/libexec/getty Pc ttyv7
serwisy 14816 0.0 0.1 9288 2228 p0 Is 8:06PM 0:00.01 -bash (bash)
root 15269 0.0 0.1 20696 1700 p0 I 8:07PM 0:00.01 su -
root 15316 0.0 0.2 10312 3220 p0 S 8:07PM 0:00.05 -su (bash)
root 15535 0.0 0.1 7020 1188 p0 R+ 8:07PM 0:00.00 ps -aux

x 47
www 98681 0.0 0.2 74512 5200 ?? IJ Tue11AM 0:00.10 /usr/local/sbin/httpd -DNOHTTPACCEPT

$ w | head -n 1
----------------------------------------------------------
8:08PM up 61 days, 19:05, 2 users, load averages: 3.22, 3.89, 3.27

$ sysctl -a | grep -i memory
----------------------------------------------------------
Virtual Memory: (Total: 4676584K, Active 330564K)
Real Memory: (Total: 130164K Active 60852K)
Shared Virtual Memory: (Total: 85096K Active: 32968K)
Shared Real Memory: (Total: 20604K Active: 16412K)
Free Memory Pages: 418520K
hw.cbb.start_memory: 2281701376
p1003_1b.memory_protection: 0
p1003_1b.shared_memory_objects: 1

>netstat -n
pogrupowane wszystich 1064

4 SYN_RCVD
7 CLOSING
17 FIN_WAIT_1
117 FIN_WAIT_2
156 ESTABLISHED
445 TIME_WAIT

Active UNIX domain sockets
Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr
ffffff0065b264d8 stream 0 0 0 ffffff004636e4d8 0 0
ffffff004636e4d8 stream 0 0 0 ffffff0065b264d8 0 0
ffffff004636e8b8 stream 0 0 ffffff0016cfd3e0 0 0 0 /var/run/cgisock.94201
ffffff0021aa9d90 stream 0 0 ffffff000dcbb9b0 0 0 0 /var/run/cgisock.31011
ffffff002647c000 stream 0 0 ffffff000de797c0 0 0 0 /var/run/cgisock.79014
ffffff00046fb000 stream 0 0 ffffff00046aeba0 0 0 0 /var/run/devd.pipe
ffffff004301d8b8 dgram 0 0 0 ffffff00046f8aa8 0 ffffff001c93e7c0
ffffff003c2c6ba0 dgram 0 0 ffffff000d4fcba0 0 0 0 /var/run/logpriv
ffffff003c2c62e8 dgram 0 0 ffffff000d5535d0 0 0 0 /var/run/log
ffffff001c93e7c0 dgram 0 0 0 ffffff00046f8aa8 0 ffffff00048931f0
ffffff0004893ba0 dgram 0 0 0 ffffff00048938b8 0 0
ffffff00048933e0 dgram 0 0 ffffff00128a4d90 0 0 0 /var/run/logpriv
ffffff00048937c0 dgram 0 0 ffffff0016f91ba0 0 0 0 /var/run/log
ffffff00048938b8 dgram 0 0 ffffff00166d33e0 0 ffffff0004893ba0 0 /var/run/logpriv
ffffff00048936c8 dgram 0 0 ffffff000d2129b0 0 0 0 /var/run/log
ffffff00048931f0 dgram 0 0 0 ffffff00046f8aa8 0 ffffff00046f8000
ffffff0004893000 dgram 0 0 0 ffffff00046f8ba0 0 0
ffffff00046f8000 dgram 0 0 0 ffffff00046f8aa8 0 0
ffffff00046f8aa8 dgram 0 0 ffffff000486f5d0 0 ffffff004301d8b8 0 /var/run/logpriv
ffffff00046f8ba0 dgram 0 0 ffffff00048637c0 0 ffffff0004893000 0 /var/run/log

$ df -h
----------------------------------------------------------
Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 570G 147G 377G 28% /
devfs 1.0K 1.0K 0B 100% /dev
/matrix/basejail 570G 147G 377G 28% /matrix/www/basejail
devfs 1.0K 1.0K 0B 100% /matrix/www/dev
fdescfs 1.0K 1.0K 0B 100% /matrix/www/dev/fd
procfs 4.0K 4.0K 0B 100% /matrix/www/proc
/matrix/basejail 570G 147G 377G 28% /matrix/phpmyadmin/basejail
devfs 1.0K 1.0K 0B 100% /matrix/phpmyadmin/dev
fdescfs 1.0K 1.0K 0B 100% /matrix/phpmyadmin/dev/fd
procfs 4.0K 4.0K 0B 100% /matrix/phpmyadmin/proc
/matrix/basejail 570G 147G 377G 28% /matrix/ftp/basejail
devfs 1.0K 1.0K 0B 100% /matrix/ftp/dev
fdescfs 1.0K 1.0K 0B 100% /matrix/ftp/dev/fd
procfs 4.0K 4.0K 0B 100% /matrix/ftp/proc

$ df -i
----------------------------------------------------------
Filesystem 1024-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/da0s1a 597188074 154444512 394968518 28% 1121167 76058735 1% /
devfs 1 1 0 100% 0 0 100% /dev
/matrix/basejail 597188074 154444512 394968518 28% 1121167 76058735 1% /matrix/www/basejail
devfs 1 1 0 100% 0 0 100% /matrix/www/dev
fdescfs 1 1 0 100% 4 11092 0% /matrix/www/dev/fd
procfs 4 4 0 100% 1 0 100% /matrix/www/proc
/matrix/basejail 597188074 154444512 394968518 28% 1121167 76058735 1% /matrix/phpmyadmin/basejail
devfs 1 1 0 100% 0 0 100% /matrix/phpmyadmin/dev
fdescfs 1 1 0 100% 4 11092 0% /matrix/phpmyadmin/dev/fd
procfs 4 4 0 100% 1 0 100% /matrix/phpmyadmin/proc
/matrix/basejail 597188074 154444512 394968518 28% 1121167 76058735 1% /matrix/ftp/basejail
devfs 1 1 0 100% 0 0 100% /matrix/ftp/dev
fdescfs 1 1 0 100% 4 11092 0% /matrix/ftp/dev/fd
procfs 4 4 0 100% 1 0 100% /matrix/ftp/proc
a

$ mysqladmin -u USERNAME -pPASSWORD status
----------------------------------------------------------
Uptime: 10217766 Threads: 2 Questions: 914831922 Slow queries: 79189742 Opens: 37153633 Flush tables: 2 Open tables: 1200 Queries per second avg: 89.533

Temat: problem z obciażeniem

wykresy od 12:30 do 12:30 następnego dnia
obciążenie CPU na www




obciążenie CPU na sql




wykresy gnuplot z vmstat co 5secTadeusz Nowak edytował(a) ten post dnia 14.04.10 o godzinie 21:36

Temat: problem z obciażeniem

Rzuć okiem, czy te powtarzające się szpilki w wykresie z SQL nie są powodowane przez coś, co jest odpalane cyklicznie, bo wyglądają na powtarzalne.

Dołączam do tego, co mówili inni, ciężko diagnozować nie dotykając systemu i nie oglądając konfiguracji.

Temat: problem z obciażeniem

Przez jakiś czas śledziłem 'top' ponieważ nie działa żaden program który stale by obciążał. Wnioski moje są takie że to php. Często wskakiwały procesy php które skakały w WCPU do 70% a normalnie ok 20-30%. Na maszynie z apachem jest 20 serwisów ,5 forum ipb 1 socialengine,OpenX,reszta to cms-y (zmodyfikowana Joomla).
Serwisy optymalizuje pod względem zapytań i profiluje kod.

Jedna rzecz mnie bardzo zastanawia zrobiłem test ab i co do strony frontowej wykonał 3,2 req/sec sądzę że to bardzo mało zrobiłem pusty skrypt php i wykonał 20 req/sec i mam obawy że to też mało.

Wnioskuję że zbyt dużo w kodzie nie uda mi się uzyskać skoro pusty skrypt wykonuje się 20 to jak polepszę dwukrotnie to chyba będzie spory sukces. Czy przy takich maszynach powinno to tak wyglądać?

Temat: problem z obciażeniem

Widzę u Ciebie cgisock, upewnij się, że masz PHP jako fcgi, anie cgi.

Temat: problem z obciażeniem

Tadeusz Nowak:
Czy przy takich maszynach powinno to tak wyglądać?

Nie.

1) Użyj jakiegoś acceleratora php - apc/eaccelerator/xcache
2) Jeśli korzystasz z (f)cgi, to zastanów się nad serwerem lighttpd
3) Używaj memcache w miarę możliwości.
4) Kontent statyczny serwuj czymś lżejszym - lighttpd/nginx.

Niestety php jest upośledzonym językiem i jeśli aplikacja jest napisana bardzo modułowo, w wielu plikach (tak jak np. w Zend Framework), to potrzebny jest maksymalnie szybki w odczycie dysk (php dla każdego includowanego pliku wykonuje masę poleceń systemowych).

5) Ktoś sugerował varnish - też go mogę polecić.

Temat: problem z obciażeniem

Php jest uruchomiony jako cgi próbuje zmienić na fastcgi
ale w testach 'ab' nie widać żadnej różnicy.
Apache jest zainstalowany z mod_prefork z suexec wszystko stoi w jailu system freebsd do fastcgi uzyłwm modułu mod_fcgid w jailu security.jail.sysvipc_allowed jest włączone.

Czy powinno na coś zwrócić się szczególną uwagę.
Wrapper php jest w procesach na stałe a więc domniemam że działa fastcgi.Tadeusz Nowak edytował(a) ten post dnia 15.04.10 o godzinie 12:09

Temat: problem z obciażeniem

Zmień na mod_fcgid (tylko uważaj, w portach FreeBSD jest zepsuta wersja, trzeba nowszą zainstalować) i pobaw się parametrami PHP_FCGI_CHILDREN i PHP_FCGI_MAX_REQUESTS. Ponadto zainwestuj w workera zamiast prefork.

Temat: problem z obciażeniem

Ok to jedziemy dalej.

1. Dziennik wolnych zapytań mysql.

Sprawdź, czy masz włączony dziennik wolnych zapytań w mysql. Z tego co widzę to około 8% zapytań w mysql się wolno wykonuje. W my.cnf (plik konfiguracyjny mysql) masz opcje:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2

Jeśli będą często pojawiające się zapytania w dzienniku wolnych zapytań to:
- spróbuj ręcznie wykonać takie zapytanie i porównaj czasy.
- EXPLAIN zapytanie sql, żeby zobaczyć jak jest wykonywane
- sprawdź, czy nie ma uszkodzonych tabel (mysqlcheck)
- sprawdź, czy istnieją indeksy w tabelach. Przy tabelach z powiedzmy ledwo milionem rekordów brak indeksu boli.

Kolejna rzecz, że nie widzę w liście procesów mysql. Czy mysql działa na innej maszynie? Możliwe, też, że użytkownicy robią zapytania typu: SELECT * FROM tabela, a tabela ma 2 mln rekordów. Później w php coś tam się obrabia z tym.

2. Sprawdź, które zapytania HTTP jadą CI po apache. W apache możesz zmodyfikować format logów (LogFormat) i dodać %T - jest to czas jaki był potrzebny na obsłużenie zapytania. Dzięki temu możesz sprawdzić, które zapytania są długo wykonywane. Dla przykładu mój format wygląda następująco:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" served in %T sec" combined

Warto się przyjrzeć wszystkiemu co wykonuje się długo. Dowiesz się wtedy, czy można to w jakiś sposób cachować itp.

3. Lista zadań crona. Z tego co widzę to z crona odpalany jest jakiś skrypt:

root 48165 0.0 0.1 7364 1444 ?? Is 1:07PM 0:00.00 /bin/sh -c /root/skrypty/rap/raport.sh
root 48166 0.0 0.1 9288 1892 ?? I 1:07PM 0:00.00 /usr/local/bin/bash raport.sh
root 48168 0.0 0.1 9288 2020 ?? S 1:07PM 0:04.85 /usr/local/bin/bash raport_netstat2.sh 5 17280

Domyślam się, że to skrypty potrzebne do zbierania statystyk (netstat), które nam umieściłeś.

4. Sprawdź czy nie osiągasz MaxClient i zapytania nie czekają w kolejce (to do tego mierzenia za pomocą "ab" ilości req/sec).

Temat: problem z obciażeniem

FastCGI diametralnie zmieniło obciążenie (ok 50 - 60% podczas szczytu) aż ciekaw jestem jak będzie wyglądać spadek obciążenia jak będzie już uruchomiony eAccelerator.

Kilka razy czytałem o Nginx i Apache razem, czy warto na jednym serwerze zainstalować Nginx dla statycznych obiektów a dynamiczne nadal przepychać przez Apache?

Temat: problem z obciażeniem

Tadeusz Nowak:
FastCGI diametralnie zmieniło obciążenie (ok 50 - 60% podczas szczytu) aż ciekaw jestem jak będzie wyglądać spadek obciążenia jak będzie już uruchomiony eAccelerator.

Jezeli problemem jest I/O to mozesz jeszcze troszke zyskac "bezkosztowo" (tzn. bez duzej ingerencji w aplikacje) rekonfigurujac OpenX, aby jako cache dla banerow uzywal memcached zamiast plikow. Ta opcje znajdzie w jego konfiguracji via admin panel.

Sporo zalezy od aplikacji, ale mysle, ze taki ruch po optymalizacji moglbys zmiescic na jednej maszynie.

Zrob porzadne statystyki na poczatek, bo inaczej to gdybanie, a nie szukanie
trafnych rozwiazan.Piotr B. edytował(a) ten post dnia 19.04.10 o godzinie 21:52

Temat: problem z obciażeniem

Tadeusz Nowak:
FastCGI diametralnie zmieniło obciążenie (ok 50 - 60% podczas szczytu) aż ciekaw jestem jak będzie wyglądać spadek obciążenia jak będzie już uruchomiony eAccelerator.

Kilka razy czytałem o Nginx i Apache razem, czy warto na jednym serwerze zainstalować Nginx dla statycznych obiektów a dynamiczne nadal przepychać przez Apache?

Jeśli masz dużo plików statycznych, a optymalizacje są dalej potrzebne to warto.

Temat: problem z obciażeniem

kolejna z zalet to jak juz oddzielisz app od statica (czasami trzeba porobić trochę cyrków z rewritami jak programista pisał aplikacje w mod_rewrite zamiast w PHP) to to że można w miarę łątwi "wydzielić" część statyczną na inny serwer

Temat: problem z obciażeniem

Tadeusz Nowak:
FastCGI diametralnie zmieniło obciążenie (ok 50 - 60% podczas szczytu) aż ciekaw jestem jak będzie wyglądać spadek obciążenia jak będzie już uruchomiony eAccelerator.

Może być, że o kolejne 50-60% :) Zależy od budowy aplikacji.

Kilka razy czytałem o Nginx i Apache razem, czy warto na jednym serwerze zainstalować Nginx dla statycznych obiektów a dynamiczne nadal przepychać przez Apache?

Nie wiem jak jest najlepiej, ale ja bym zrzucił całość na nginx'a, chyba, że coś by stało na przeszkodzie nieopłacalnej do maczania w niej palców, to wtedy użyłbym dwóch serwerów obok siebie.Peter K. edytował(a) ten post dnia 30.04.10 o godzinie 09:28