Temat: problem z wydajnością

Na początku od razu się przyznam, że administruje serwerami linux od kilku lat ale nigdy nie miałem serwera o znacznym obciążeniu i nie mam z tym żadnych doświadczeń.
Maszyna stara ale porządna 8GB RAMu, 4 dwurdzeniowe Xeony 2GHz, macierz dyskowa HP MSA 1000 więc powinna na wiele pozwolić.
Software w miarę standardowy Apache+PHP+postgres, w tle gdzieś tam chodzi poczta ale nie generuje dużego ruchu.
Pod tym PHPem siedzą fora phpBB3, odsłon relatywnie mało bo ok 10-15 tyś. dziennie i na tym koniec obciążenia.
top pokazuje:

 22:24:35  up 21 min,  1 user,  load average: 4.59, 6.02, 4.98

177 processes: 175 sleeping, 2 running, 0 zombie, 0 stopped

CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle

           total    3.3%    0.0%    6.6%   0.0%     0.4%   36.3%   53.2%

           cpu00    2.7%    0.0%    7.7%   0.0%     3.7%   84.0%    1.5%

           cpu01    4.5%    0.0%    7.5%   0.0%     0.0%   87.6%    0.1%

           cpu02    5.9%    0.0%   23.8%   0.0%     0.0%   19.4%   50.6%

           cpu03    6.5%    0.0%    9.5%   0.0%     0.0%   21.0%   62.8%

           cpu04    0.3%    0.0%    1.1%   0.0%     0.0%   33.7%   64.6%

           cpu05    2.5%    0.0%    1.7%   0.0%     0.0%   31.6%   64.0%

           cpu06    1.1%    0.0%    0.3%   0.0%     0.0%    6.7%   91.6%

           cpu07    2.5%    0.0%    1.1%   0.0%     0.0%    5.9%   90.2%

Mem:  7973764k av, 7954644k used,   19120k free,       0k shrd,   55820k buff

                    974280k actv, 6456488k in_d,  128596k in_c

Swap: 8388472k av,       0k used, 8388472k free                 1016872k cached



  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND

 1358 ________  16   0 42632 begin_of_the_skype_highlighting              16 0 42632      end_of_the_skype_highlighting begin_of_the_skype_highlighting              16 0 42632      end_of_the_skype_highlighting begin_of_the_skype_highlighting              16 0 42632      end_of_the_skype_highlighting  41M  1680 R     4.7  0.5   8:03   2 postmaster

  376 ________  16   0     0    0     0 DW    0.9  0.0   2:00   1 kjournald

 3898 ________  19   0 18128  17M 16676 D     0.8  0.2   0:00   0 postmaster

 2906 ________  16   0  9472 9472  4528 S     0.5  0.1   0:01   0 httpd

 3872 ________  15   0  9360 9360  4444 S     0.4  0.1   0:00   1 httpd

 1356 ________  16   0 33928  33M 33328 D     0.2  0.4   0:18   3 postmaster

 2942 ________  15   0  9432 9432  4528 S     0.2  0.1   0:02   5 httpd

 3277 ________  15   0  1100 1100   840 S     0.2  0.0   0:00   5 sftp-server

 3549 ________  16   0  9444 9444  4528 S     0.2  0.1   0:03   1 httpd

 3706 ________  15   0 12656  12M  4548 S     0.2  0.1   0:02   7 httpd

 1357 ________  15   0 14100  13M 13688 S     0.1  0.1   0:03   2 postmaster

Reszta prodesow nie istotna. To co się rzuca w oczy to masa % iowait i czasem pojawia się dużo % system, user jest zawsze najmniej.

iostat pokazuje:

avg-cpu:  %user   %nice    %sys %iowait   %idle

           4.72    0.00   20.01   32.18   43.08



Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn

cciss/c0d0       28.28       478.23       240.84     567894     285998

cciss/c0d0p1      0.03         0.16         0.02        188         22

cciss/c0d0p2      0.02         0.22         0.00        256          0

cciss/c0d0p3     28.21       477.48       240.83     566994     285976

sda               0.03         0.22         0.00        256          0

sda1              0.01         0.11         0.00        136          0

sdb             996.94      1316.48     38651.36    1563290   45897720

sdb1            996.92      1316.38     38651.36    1563170   45897720

Tu zresztą to dobrze widać. Masa operacji dyskowych ale macierz powinna podołać.
ps pokazuje największe zużycie procka dla:

root       376  9.5  0.0     0    0 ?        DW   22:03   2:30 [kjournald]

_______   1358 40.1  0.5 49912 42628 ?       S    22:04  10:07 postgres:

stats collector process

reszta jest na normalnym poziomie.
Powiedzcie mi co można stuningować w postgresie i apaczu żeby zwiększyć wydajność? Na co jeszcze powinienem popatrzeć żeby zwalczyć obciążenia? Wiem, że na pewno to postgres tak jeździ po maciorze a nie robi więcej jak kilkadziesiąt kwerend na raz bo śledziłem go przez jakiś czas i nic mnie nie powaliło.
Strony nie ładują się jak do niedawna w ciągu 1-2 sekund a ok, 30-60 sekund więc strasznie się wszystko spowolniło przy stosunkowo nieznacznym wzroście obciążenia.Wojciech Nabiałek edytował(a) ten post dnia 05.10.10 o godzinie 23:01

Temat: problem z wydajnością

Obciążenie CPU nie jest wysokie, możliwe że wąskim gardłem są dyski. Proponuję sprawdzić jakie procesy najwięcej je obciążają, można do tego użyć narzędzia iotop (chyba kernel >= 2.6.20, musi istnieć plik /proc/self/io), które pokazuje te dane w czasie rzeczywistym.

Pozdrawiam

Temat: problem z wydajnością

PostgreSQL'a łatwo obadać czy to on generuje obciążenie. 1. Zależnie od wersji log_min_duration_statement aby sprawdzić czy są długie lub masa krótkich zapytań. 2. Sprawdź logi pod kątem zbyt częstych checkpointów - mogą powodować piki w zapisie na dyski. 3. Czy vacuumy są robione.Łukasz Filut edytował(a) ten post dnia 06.10.10 o godzinie 00:08

Temat: problem z wydajnością

Grzegorz Szymański:
Obciążenie CPU nie jest wysokie, możliwe że wąskim gardłem są dyski. Proponuję sprawdzić jakie procesy najwięcej je obciążają, można do tego użyć narzędzia iotop (chyba kernel >= 2.6.20, musi istnieć plik /proc/self/io), które pokazuje te dane w czasie rzeczywistym.

Pozdrawiam

Najbardziej obciążają procesy postgresa i apacza

Łukasz Filut:
PostgreSQL'a łatwo obadać czy to on generuje obciążenie. 1. Zależnie od wersji log_min_duration_statement aby sprawdzić czy są długie lub masa krótkich zapytań. 2. Sprawdź logi pod kątem zbyt częstych checkpointów - mogą powodować piki w zapisie na dyski. 3. Czy vacuumy są robione.

jest autovacuum włączone i widzę, że je robi więc tu powinno być spoko.
Nie wiem jak użyć tego log_min_duration_statement i jak sprawdzić te checkpointy :(

Druga w nocy, ruchu na stronie nie ma a obciążenie jest:

 02:17:27  up  4:14,  1 user,  load average: 12.62, 11.57, 10.93

198 processes: 193 sleeping, 5 running, 0 zombie, 0 stopped

CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle

           total    2.4%    0.0%   95.1%   0.0%     0.0%    0.5%    1.7%

           cpu00    2.3%    0.0%   94.0%   0.0%     0.2%    0.2%    3.0%

           cpu01    4.5%    0.0%   92.6%   0.0%     0.1%    0.0%    2.6%

           cpu02    2.2%    0.0%   95.5%   0.0%     0.0%    0.8%    1.3%

           cpu03    2.2%    0.0%   96.8%   0.0%     0.1%    0.4%    0.4%

           cpu04    2.2%    0.0%   95.0%   0.0%     0.0%    0.4%    2.3%

           cpu05    1.9%    0.0%   96.1%   0.0%     0.0%    0.5%    1.3%

           cpu06    1.9%    0.0%   94.7%   0.0%     0.0%    0.8%    2.4%

           cpu07    2.2%    0.0%   96.5%   0.0%     0.0%    0.9%    0.2%

Mem:  7973764k av, 7858028k used,  115736k free,       0k shrd,  132644k buff

                   4055256k actv, 3371480k in_d,   84352k in_c

Swap: 8388472k av,   12488k used, 8375984k free                 2758120k cached



  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND

 1358 ________  25   0 42640  41M  1680 R    10.2  0.5 135:55   3 postmaster

21288 ________  23   0 19004  18M 17284 D     6.9  0.2   0:08   3 postmaster

21292 ________  22   0 19580  19M 17976 D     6.9  0.2   0:04   2 postmaster

21182 ________  25   0 52936  51M 47272 D     6.3  0.6   0:48   3 postmaster

20724 ________  25   0  249M 249M  188M D     6.0  3.2  10:46   4 postmaster

17675 ________  16   0  454M 454M  211M S     4.8  5.8  30:32   6 postmaster

20235 ________  25   0  414M 414M  212M R     4.8  5.3  20:55   4 postmaster

20626 ________  16   0 13212  12M  4480 S     4.4  0.1   1:48   1 httpd

16693 ________  18   0  454M 454M  211M S     4.2  5.8  31:04   1 postmaster

19196 ________  25   0  413M 413M  211M S     4.2  5.3  30:37   5 postmaster

15868 ________  18   0  454M 454M  211M S     4.1  5.8  34:06   7 postmaster

19626 ________  25   0  413M 413M  211M R     3.9  5.3  24:42   7 postmaster

21285 ________  21   0 20536  20M 18924 S     3.9  0.2   0:06   5 postmaster

18627 ________  17   0  455M 455M  211M D     3.7  5.8  26:34   1 postmaster

21293 ________  20   0 18988  18M 17572 R     3.5  0.2   0:02   1 postmaster

21262 ________  16   0 12664  12M  4368 S     3.4  0.1   0:02   0 httpd

21283 ________  19   0  1216 1216   880 R     3.2  0.0   0:08   4 top

21294 ________  20   0 16996  16M 15780 D     3.2  0.2   0:01   7 postmaster

21143 ________  16   0 12928  12M  4460 D     2.1  0.1   0:06   5 httpd

21137 ________  16   0 12804  12M  4460 S     1.6  0.1   0:05   6 httpd

  376 ________  15   0     0    0     0 SW    1.1  0.0  30:43   7 kjournald

Zapytań jest mniej ale są teraz w śród nich takie:

580      15868 28.2  6.2 522352 500696 ?     D    00:15  38:01 postgres: forum forum 127.0.0.1(48323) SELECT

580      16693 29.2  6.2 522388 500736 ?     S    00:30  35:00 postgres: forum forum 127.0.0.1(49327) SELECT

580      17675 33.1  6.2 522388 500996 ?     S    00:45  34:29 postgres: forum forum 127.0.0.1(50640) SELECT

580      18627 34.2  6.2 522416 501068 ?     S    01:00  30:32 postgres: forum forum 127.0.0.1(51991) SELECT

580      19196 47.2  6.2 522348 501024 ?     S    01:15  34:59 postgres: forum forum 127.0.0.1(52640) SELECT

580      19626 49.7  6.2 522416 500972 ?     S    01:30  29:16 postgres: forum forum 127.0.0.1(53134) SELECT

580      20235 58.0  6.2 522356 501260 ?     S    01:45  25:22 postgres: forum forum 127.0.0.1(53845) SELECT

580      20724 62.8  3.9 352628 318620 ?     R    02:01  17:56 postgres: forum forum 127.0.0.1(54532) idle

580      21182 60.7  2.9 290496 234120 ?     D    02:16   8:05 postgres: forum forum 127.0.0.1(55059) SELECT

580      21827 20.0  0.2 237880 18460 ?      S    02:29   0:00 postgres: forum fora 127.0.0.1(55662) idle

580      21828  114  0.2 238516 19656 ?      D    02:29   0:01 postgres: forum 

Może jakieś robale mi łażą po serwie? Apacz w logach nic nie pokazuje nadzwyczajnego ale ...

Temat: problem z wydajnością

Jaki masz raid na macierzy i jaki FS? Macierz pewnie ma jakies GUI a tam na pewno jest zakladka obciazenia LUNow zobacz co tam ciekawego widac.
Moze jakis job na bazie jest uruchomiony i "zamula" system?
Co do tuningu Apacha luknij tutaj:
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
Przydalo by sie jeszcze zobaczyc co tam vmstat pokazuje.

Temat: problem z wydajnością

Apache goły czy opakowany w dodatki? Mod_rewrite mod_security?
Reguł dla mod_security ile masz do mielenia?

Postgresa możesz trochę odchudzić przez Query Planning: http://www.postgresql.org/docs/8.3/static/runtime-conf...

Optymalizacja cache dla Postgresa też się przyda. Google wiedzą wiele na ten temat.

Temat: problem z wydajnością

Panowie, imho problem nie jest w braku zasobów, a w konfiguracji... ta maszyna przy takim przeznaczeniu powinna się nudzić przez 99% czasu.
15000 odsłon dziennie, nawet przy założeniu, że dzieje się to tylko w przeciągu 8 godzin to jest 30 na minutę. Wiem, że phpbb3 nie jest demonem optymalizacji, ale bez przesady.
naprawdę potrzebujesz: stats_start_collector ? moze spróbuj wyłączyć i zobaczyć czy to z tego powodu?

Temat: problem z wydajnością

Pan Marcin ma oczywiście rację, jeżeli zidentyfikowane zostało już co rzeczywiście obciąża procesor i dyski, a wynika że jest to Postgres to czas na zabawę z jego konfiguracją. Ja niestety nie mam z nim większego doświadczenie, więc nie pomogę. Mogę tylko poradzić, żeby nie zmieniać więcej niż jednaj zmiennej, parametru na raz :) Polecam też monitorowanie systemu (mrtg i podobne narzędzia) żeby mieć obraz obciążenia w dłuższej perspektywie czasu, jest to pomocne w problemach wydajnościowych.

Pozdrawiam

Temat: problem z wydajnością

Macierz na ext3 RAID5 soft właśnie ściągnąłem i popatrzę co on mi powie.
vmstat

procs                      memory      swap          io     system         cpu

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa

14  1   7116  27928  66296 1538428    0    0    61   726  112    79  4 17 48 31

Patrząc z brzega dokumentu, apacz jest optymalny ale nie wnikałem jeszcze w szczegóły ale zrobię to zaraz.

Do apacza podpięte jest php5, mod_rewrite, mod_ssl, mod_secure i jakieś śmieci ale dla rewrita i secura to jest tylko kilka regułek.
Optymalizacji kwerend nie zakładam bo nie będę przecież zmieniał istniejącego produktu. Myślę, że lepiej lub gorzej ale oni o to zadbali.

Co do tej optymalizacji cache to się zgadzam ale myślę, że nie tylko cache ale całość ustawień dotyczących pamięci trzeba przerobić.

Marcinie, masz 100% racji i powiem, że do niedawna tak było, raptem wszystko siadło a ja nie znam przyczyny. Domniemam, że jest to kwestia zwiększenia ruchu i wyskoczenia poza jakiś parametr optymalizujący zasoby.

stats_start_collector jako taki w 8.3 nie daje się wyłączyć (nie ma takiej opcji w konfigu a wpisana z palca wywala błąd), można wyłączyć składowe. U mnie jest tak:

# - Query/Index Statistics Collector -

track_activities = off

track_counts = off

update_process_title = off



# - Statistics Monitoring -

log_parser_stats = off

log_planner_stats = off

log_executor_stats = off

log_statement_stats = off

a mimo to proces kolektora chodzi i widać było ile zjada zasobów. Nie wiem jak go całkiem wywalić ale może to by pomogło.

Co do zmieniania parametrów pojedynczo i testowania to się zgadzam i tak robiłem ale bez skutku. Najważniejszym parametrem jest dla niego shared_buffers, u mnie ustawione na 800MB (wcześniej miałem ponad 300MB) ale nie zauważyłem zmiany w wydajności.

Wiem, że google wie wszystko ale może znajdzie się ktoś z doświadczeniami w tuningowaniu postgresa i apacza i podzieli się informacją na co kłaść największy nacisk albo nawet poda procentowe wartości dla ważniejszych zmiennych.

Temat: problem z wydajnością

Zrób zrzut z sar`a z opcją -A
LC_ALL=C /usr/bin/sar -A -f > <nazwapliku>

Do podglądania wyników używam kSara.
W dokumentacji jest napisane, że poza linuxem działa także pod solarisem.
http://sourceforge.net/projects/ksar/

Program napisany w javie także ściągnij najnowszą wersję.

Temat: problem z wydajnością

Bartosz Zieliński:
Zrób zrzut z sar`a z opcją -A
LC_ALL=C /usr/bin/sar -A -f > <nazwapliku>

Do podglądania wyników używam kSara.
W dokumentacji jest napisane, że poza linuxem działa także pod solarisem.
http://sourceforge.net/projects/ksar/

Program napisany w javie także ściągnij najnowszą wersję.

Super sprawa, sara zawsze patrzyłem ręcznie ale z tym softem to zupełnie inny wymiar informacji :)
Potwierdza tylko, że jest coś nie tak ale dalej nie wiem co dokładnie i jak to zwalczyć. Pozwoliłem sobie wysłać Tobie na priv zrzut z sara to sam zobaczysz jakie to jest brzydkie ...

Temat: problem z wydajnością

Z wyników iostat'a wynika, że masz sporo zapisów na sdb1.
Nie wiem ile masz dysków w MSA ale 1000 iops może być dla niej za dużo.
Oczekiwanie na podsystem io powoduje wysokie kolejkowanie i słabą wydajność.

Kwestią osobną jest namierzenie procesu/ów który za to odpowiada.

Temat: problem z wydajnością

RAID5 i baza danych to zły pomysł, zwłaszcza przy dużej ilości zapisów ;]
załóżmy 4 dyski
zapis każdego bloku wymaga:
1) odczytania 2 sektorów, po 1 na dysk
2) policzenie sumy kontrolnej
3) zapis sumy kontrolnej oraz bloku na dysk

dla porównania RAID10 wymaga tylko 2 zapisów, żadnych odczytów
oczywiście, hardwarowy kontroler RAID zcachuje sobie cześć tego więc nie bedzie aż tak źle, ale dalej nie rewelacyjnie.

Ideał byłby oddzielny serwer z dyskami SSD ale przy takim ruchu nie powinien się dusić
Postgres (większość już koledzy powiedzieli):

commit_delay = 100000                   # range 0-100000, in microseconds                                      

commit_siblings = 20                    # range 1-1000             

spowoduje commitowanie "w grupach" przy dużej ilości requestów czasami pomaga (zależy od "inteligentności" RAIDu)
[/code]

PHP - rozumiem że używasz mod_php ? apache + FastCGI w 99% przypadkach jest lepszym rozwiązaniem:
* nie każdy proces apacha ma załadowany PHP = więcej ramu dla DB
* przy dużej liczbie procesów pracuje tylko x PHPów a nie tylkoe ile procesów apacha
* można używać mpm_worker ;]

ale jak widzę problem nie leży w apachu, patrzyłeś w slow query log ? Można też na "żywo" patrzeć co zalega, ale nie pamiętam atm co trzeba było włączyć w statach, postgresa przez jakiś czas już nie debugowałem.

Temat: problem z wydajnością

@Krzysztof
sdb1 i sda1 to maciorka, dysków ma na full, wiem że przez iowaity wszystko wisi i wiem, że jest za to odpowiedzialny postgres.

@Marcin
Ta maciorka była kupiona zanim zacząłem pracować na AP i już na niej stał ten RAID i dane więc nie miałem na to wpływu a teraz za bardzo nie mam gdzie zabrać tych danych żeby ją przerobić. A zakup czegokolwiek nowego w tym momencie nie wchodzi w grę.

Wprowadziłem zmiany w tych opóźnieniach zapisu ale dalej nie widzę wzrostu wydajności i dalej mam 35-40 tysięcy operacji zapisu na sekundę!

Co do php, 100% stron jest w php więc nie bawiłem się w fastCGI co nie znaczy, że po walce z postgresem nie pokombinuje z apaczem.

Puki co postgres wygrywa i co nie wygrzebie w necie to nie przynosi rezultatu :(

Temat: problem z wydajnością

Jak to się mówi, nic nie dzieje się bez przyczyny a przyczyną mojego spowolnienia nie było to, że raptem konfiguracja przerastała odpowiadać obciążeniu tylko ... po kilku latach działania postgres natworzył w jednym katalogu $PG_PATH/data/base/(jakiś_numerek)/ tyle obiektów, że system plików nie wyrabia i nawet nie da się ich wylistować bo ... obciążenie sys i iow rośnie w kosmos.
Tak to teraz niechcący zobaczyłem i jeszcze nie szukałem rozwiązania ale może ktoś na szybko podpowie jak w postgresie popartycjonować istniejące dane bez zatrzymywania bazy?

Edit.
Widzę, że to nie będzie chodziło o partycjonowanie tylko o tablespace bo nie chcę rozbijać wielkich plików na mniejsze tylko wielki folder na mniejsze. Na razie się przenoszą dane, zobaczymy czy uda się osiągnąć zaplanowany efektWojciech Nabiałek edytował(a) ten post dnia 07.10.10 o godzinie 23:49