Skocz do zawartości
neomusic

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

Polecane posty

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 ?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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:

 

28070587_10214505263172579_7545926657984

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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".

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Strace to raczej za grube narzędzie dla Ciebie ;)

 

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 przez hakeryk2 (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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 przez Rafiki (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

 

post-49436-0-20253200-1520434048_thumb.png

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 przez hakeryk2 (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×