VPS: 8 GB RAM (po zwiększeniu z 4 GB przed awarią), 2 core, Debian 9, Apache 2.4.25, MariaDB 10.1.48; zarządzanie przez właściciela sklepu za pomocą Webmina

Prestashop po aktualizacji do wersji 1.7.8.7 z 1.6.1.24

—

Klient zgłosił się do mnie z problemami w uruchomieniu silnika bazodanowego MySQL. Po uzyskaniu dostępu do serwera uruchomiłem go z opcją innodb_force_recovery, które rozwiązało problem. Restart serwera bez opcji recovery kończył się w kolejnych próbach sukcesem – bazy danych działały prawidłowo. Logi jasno wskazywały, że doprowadziły do tego problemy z kończącą się pamięcią operacyjną.

W wyniku niedostępności sklepu domena została przepięta na drugi VPS, gdzie z backupu udało się odbudować konfigurację i sklep działał na Prescie 1.6. Po uruchomieniu bazy danych nastąpiło przepięcie z powrotem na stary serwer. Tutaj działała już Presta 1.7. Gdy tylko cache DNS się przeładował i rekord A zaczął wskazywać na ten VPS obciążenie drastycznie skoczyło (tak jak to miało miejsce po aktualizacji, przed przepięciem) – load average był rzędu 80, CPU 100%, RAM 100%.
* Tutaj warto wspomnieć, że po aktualizacji, gdy Presta działała w trybie maintance nie było problemu. Gdy tylko ten tryb był wyłączany i strona była dostępna online obciążenie wariowało.
** Co ciekawe na nowym serwerze, gdy uruchamiano Preste w wersji 1.7 przez pewien czas było ok. Po około godzinie sytuacja zaczęła się powtarzać tak jak na pierwszym VPS – obciążenie wariowało.

Domena wróciła z powrotem na drugi VPS. Aby mieć dostęp do starego serwera po nazwie domenowej dodałem odpowiedni rekord do pliku /etc/hosts na firmowym laptopie (Fedora 39) i przystąpiłem do naprawy.

Na początku zauważyłem, że CPU zżerają procesy php-cgi. Przepiąłem wirtualny host Apache, aby korzystał z php-fpm w wersji 7.1 (która była już na serwerze). Przy okazji zrobiłem tam delikatny porządek po ustawieniach wprowadzonych przez klienta. W międzyczasie kombinowałem z ustawieniami pm. Wszystkie były konfigurowane i testowane – static, ondemand, dynamic. Na tym trzecim finalnie zostało. Dodatkowo wprowadziłem kilka modyfikacji zgodnie z zaleceniami Presty w oficjalnej dokumentacji.
* Chyba zaczynam dojrzewać do decyzji nginx+php-fpm > apache+php

Gdy obciążenie delikatnie spadło zauważyłem, że gdy zatrzymam usługę bazy danych kończy się problem. Wykonałem więc optymalizację w pliku my.conf na bazie powyższej dokumentacji. Kolejny krok, który pomógł, ale nie naprawił ostatecznie problemu.

Nauczony doświadczeniem, że dziwne zachowania aplikacji webowych (WordPress, Presta,…) mogą świadczyć o zainfekowaniu. Na forum znalazłem informację o module ’BLM vulnerability’. Zresetowałem hasło do panelu admina, zainstalowałem i uruchomiłem moduł. Znalazło kilka problemów bezpieczeństwa, które zostały naprawione. Kolejny krok, który delikatnie pomógł.

Podczas prac administracyjnych podstawowym wyznacznikiem są logi. Tutaj było ich kilka (php-fpm, virtualdmin, apache, vhosty). Diagnostyka z wykorzystaniem tail -f pozwoliła ustalić, że strona dość często odpytywana jest przez bot Yandex. Szybki przegląd neta co to jest i decyzja o zablokowaniu z wykorzystaniem pliku robots.txt.

Praca jako informatyk w dużej mierze to rozwiązywanie problemów do czego wbrew pozorom dość często używamy Internetu (dokumentacje, fora, artykuły). W tym przypadku również pomogło forum, na którym użytkownicy wspominali na problemy z cache. Do diagnostyki wykorzystałem strace, które faktycznie wskazało na dość dużo działań w katalogu var/cache. Zmodyfikowałem kilka opcji w ustawianiach wydajności, które znajdują się w panelu Presty. Zlikwidowało to ostatecznie obciążenie serwera.

Podsumowanie:
Ciężko określić jedno konkretne miejsce, które generowało problem. Można wskazać na ostatni krok, czyli cache – ale czy zadziałałoby to bez poprzednich zmian? Nie dam gwarancji.
Po tych wszystkich pracach serwer w spoczynku się nudzi (obciążenie jest znikowe), a podczas testów benchmarkiem ab przy 100 połączeniach load average nie przekroczył 4.

Trochę prywaty:
Z Prestą miałem już kontakt jakieś 10 lat temu. Nie pamiętam dokładnie co wtedy robiłem, ale też odbiło się to i „zostawiło uraz na psychice” 😛 W tej sytuacji tylko utwierdzam się w przekonaniu: WooCommerce > PrestaShop 😉

UPDATE:

Po kilkunastu godzinach problem powrócił. Tym razem pomogło to: