Prestashop load apache/php-fpm ponad 100% - prośba o pomoc

[neomusic 0]

Witam,

Zmagam się z problemem obciążenia (load cpu) serwera dedykowanego - bardzo mocnego (96GB RAM, Intel 2 x Xeon E5-2640v3, dyski SSD itd.) ze sklepem opartym o prestashop .

 

Cel to nawet ponad 1000 jednoczesnych użytkowników, niestety ap apache od poziomu 100-200 sim. users zaczyna działać nieznośnie wolno. Htop już przy 100 jednoczensych połączeniach na 10tys. req pokazuje obciążenie CPU 100% na wszystkich wątkach (a jest ich aż 24).

 

Dodatkowo SQL wyeksportowałem na osobną maszynę z 64GB RAM , także na SSD, 12 rdzeni...a i tak load jest nie do zniesienia i ze strony praktycznie nie daje się korzystać.

 

Próbowałem przeróznych ustawień apache , php-fpm, nginx, varnish - nieustannie jest masakra.

 

Konfig: apache 2.4, event mpm + nginx proxy, php-fpm , varnish, memcached. Teoretycznie powinno śmigać, ale jest tragedia.

 

Please, pomóżcie. na serwerze działa też netrelic , wg wykresów aplikacja działa dobrze, problemem są ustawienia serwera .

 

Jakiś pomysł na co zwrócić uwagę ?

napisałem w dziale serwery www, tutaj umieszczony omyłkowo, przepraszam . do usunięcia

[lord101 18]

Popatrz w logi jaki to jest ruch. Dodatkowo nie zawsze baza danych na osobnej maszynie to dobry pomysł.

 

Bardzo podejrzany jest load na takiej maszynie dla jednego sklepu. Jakiego raida masz dla serwera HTTP ?

[neomusic 0]

Popatrz w logi jaki to jest ruch. Dodatkowo nie zawsze baza danych na osobnej maszynie to dobry pomysł.

 

Bardzo podejrzany jest load na takiej maszynie dla jednego sklepu. Jakiego raida masz dla serwera HTTP ?

 

raid10 jest na tym serwerze .

 

Tak to wygląda w trakcie testu z ab -n 10000 -c 1000:

 

[lord101 18]

Testy syntetyczne działają trochę inaczej czy naturalny ruch. Natomiast samo uruchomienie takiego testu i popatrzenie w htop'a niestety nic nie da.

[hakeryk2 0]

Mam dokładnie ten sam problem tylko, że na słabszej maszynie.

apache 2.4, event mpm + nginx proxy, php-fpm i opcache

Od czasu do czasu zdarzają się właśnie takie zawiechy że wszystkie rdzenie stoją na 100% i tylko podwójny lub potrójny reboot całego VPS przywraca wszystko do życia. Żadnych błędów w logach aplikacji.

[lord101 18]

Reboot to nie jest żadne rozwiązanie. Logi błędów to nie wszystkie logi jakie są na serwerze. Jest pełno narzędzi do "monitoringu".

[hakeryk2 0]

Reboot to nie jest żadne rozwiązanie. Logi błędów to nie wszystkie logi jakie są na serwerze. Jest pełno narzędzi do "monitoringu".

Dopiero pół roku siedzę w temacie i robiłem coś takiego. Czytałem wszystkie logi każdej aplikacji - nic z nich nie wynikało.

 

Restartowałem najpierw każdą usługę po kolei i sprawdzałem czy może wtedy to wstanie: apache, nginx, php, php-fpm, mysql. Nic się nie działo, serwer dalej 100%. Restart wszystkich naraz poprzez && - serwer wstawał na sekunde i zawieszał się dalej na 100%.

 

Dopiero kompletny reboot pomaga.

 

Próbowałem strace podpiąć pod php, php-fpm i mysql i nic nie wywnioskowałem z nich.

Moje tylko małe spostrzeżenie jest następujące. Kiedyś na tej konfiguracji chciałem mecached zaisntalować, zainstalowałem ale nie dawało to wielkiego kopniaka więc przeszedłem na opcache i jest znacznie lepiej, jednak tak mniej więcej od momentu zainstalowania memcached i wywalenia go po wielu problemach zaczęły się te problemy za zacinaniem się serwera, tak więc nie wiem czy to właśnie memcached nie macza w tym wszystkim paluchów.

[Bartosz Z 236]

Strace to raczej za grube narzędzie dla Ciebie

 

Co zużywało CPU po restarcie usług?

[hakeryk2 0]

wszystkie usługi php-fpm: pool nazwadomeny.pl i każdą grep auxem sprawdzałem po id procesu i podpinałem pod strace ale nic nie wywnioskowałem. Jakieś porady co wtedy robić gdy proces żre 100% i jak sprawdzić co mieli?

Aha i cały czas rosła wartość np standardowo jest:
Tasks: 51, 90 thr, 3 running, a przy zawieszeniu się jest około
Tasks: 52, 150 thr, 3 running i wartość thr rośnie sobie z czasem zawieszenia się.


Włączyłem również logi dla php-fpm ale dalej nic nie logowało.

Jedynie logi np z apache to czasami pojawiające się 503

(104)Connection reset by peer: [client ************** ] AH01075: Error dispatching request to : adres url
oraz
Failed to read FastCGI header którego kompletnie nie ogarniam skoro nie korzystam z fastCgi dla tej domeny.

Edytowano Luty 21, 2018 przez hakeryk2 (zobacz historię edycji)

[Rafiki 2]

do autora tematu - na takim sprzęcie to powinieneś udźwignąć z spokojem 10x większe obciążenie ...i to bez przenoszenia bazy na oddzielną maszynę

Jeśli przeniosłeś bazę na oddzielną maszynę i nadal to samo - to prawdopodobnie z bazą wszystko ok.

Miałem taki sam problem.
Co macie w ustawieniach wydajności w prestashop?
Jeśli "Użyj pamięci podręcznej" jest na tak i ustawiony jakiś memcached czy buforowanie do plików - wyłączacie to zupełnie - i po problemie (można zostawić tylko pamięć podręczną dla smarty ale to na samym początku w sekcji "ustawienia dotyczące smarty" - wszystko to ofc w zakładce wydajność )

Jeśli to nie pomoże, to .... po pierwsze nie wiem po co uruchamiać apache i nginx razem (nginx jako reverse proxy) - to nie ma przełożenia praktycznego ani szybkościowego - zabiera więcej zasobów i jest aktualnie trochę bez sensu... polecam użycie samego nginx'a i php-fpm - wszystkie moduły nawet najbardziej skomplikowane a nawet multistore działa bezproblemowo na czystym nginx i prestashop.

Jeśli znowu server będzie miał overload - to włacz htop albo nawet wpisz: ps xauf
Zobacz jakie procesy zjadają cały CPU lub RAM - i stąd najlepiej po nitce do kłębka.
Jeśli mysql - włacz logowanie długich zapytań, zoptymalizuj mysql'a - tutaj da się na prawde dużo zrobić
Jeśli nginx/php - upatrywałbym błedu w jakimś module / szablonie - bardzo możliwe ,że kod jest gdzieś tak spaprany ,że "pożera" wszystko co jest dostępne - często tak sie zdarza gdy ktoś nieumiejętnie wprowadza jakieś zmiany w kodzie modułów albo w szablonach. Wtedy najlepiej przywrócić domyślny theme, wyłączyć wszystkie nadpisywanie i niestandardowe moduły - jeśli to pomoże to po kolei wszystko włączać z powrotem i badać co tak zamulało

 

Dyskusje polecam przenieść na rootnode - gdzie przenieśli się wszyscy doświadczeni userzy z WHT po przejęciu przez nazwe

Edytowano Luty 21, 2018 przez Rafiki (zobacz historię edycji)

[hakeryk2 0]

Korzystając z strace pobrałem id php-fpm i ustaliłem, że przyczyną był zacięcie się odczytu cache z wtyczki socialsharing. Proces wpadał w pętle przy próbie odczytu.Nie znam jeszcze przyczyny dokładnej.

[hakeryk2 0]

Dlaczego nie mogę edytować swojej wiadomości?Mniejsza z tym. Powód podany powyżej był tylko cząstkowy. Sytuacja stała się ponownie i ten błąd po strace dotyczy ogólnie całego folderu cache niezależnie od wtyczki tak więc pakiet apache + nginx ma problem z kasowaniem plików cache by robić to jakoś ultra szybko i dostaje zwiechę. Nie wiem jak to rozwiązać.

To co na screenie to leci jak szalone

 

Na chwilę obecną pomaga usunięcie folderu z konsoli przez rm -rf sciezka_do_foldery_cache i szybciej sam sie odbudowuje niż zdąży się odpytać czy usunęło.

Edytowano Marzec 7, 2018 przez hakeryk2 (zobacz historię edycji)

[Gość]

Zainstaluj memchaed podepnij pod prestahsopha i powinno coś pomóc jak nie pomoże to zainstaluj openlitespeeda i na pewno pomoże

[hakeryk2 0]

Miałem memcached - nie pomogło. Korzystam z opcache (tak wiem, że to coś innego, ale dla mnie jest wystarczające) i tak jak stwierdziłem wcześniej - problem leży po stronie usuwania plików których jest mnóstwo na kombinacji apache + nginx.

[lord101 18]

To wyłącz w panelu presty opcję: smarty cache do pliku