Komunikat Allowed memory size ... exhausted jest jednym z nielicznych błędów, które dość jasno wskazują kategorię problemu: proces PHP przekroczył dozwolony limit pamięci. Nie mówi jednak, dlaczego. Przyczyną może być import, duży obraz, raport WooCommerce, ciężka wtyczka, rekurencja w kodzie albo zbyt niski limit dla realnego obciążenia strony.
Szybka odpowiedź
Najpierw odczytaj z komunikatu, w którym pliku i przy jakiej operacji zabrakło pamięci. Sprawdź rzeczywisty memory_limit PHP, a nie tylko wartość wpisaną w wp-config.php. WP_MEMORY_LIMIT jest ustawieniem WordPressa, ale nie może magicznie przekroczyć twardego limitu narzuconego przez PHP lub hosting.
WP_MEMORY_LIMIT a memory_limit PHP
WordPress może prosić o określoną ilość pamięci dla aplikacji, ale ostateczny limit ustala środowisko PHP. Na hostingu współdzielonym panel może ignorować część zmian. Na VPS-ie sprawdź konfigurację właściwego SAPI i puli PHP-FPM. Zdarza się, że CLI ma inny limit niż PHP obsługujące stronę, więc wynik polecenia w SSH nie zawsze opisuje żądanie WWW.
Duże obrazy i operacje na mediach
Dekodowanie wielkiego JPEG-a do pamięci może wymagać znacznie więcej RAM-u niż rozmiar pliku na dysku. Generowanie miniaturek, konwersja WebP/AVIF i edycja obrazów potrafią chwilowo zużyć dużo pamięci. Jeśli błąd pojawia się tylko przy uploadzie konkretnego zdjęcia, nie szukaj przyczyny w całej stronie.
Importy, raporty i duże kolekcje danych
Kod, który pobiera dziesiątki tysięcy rekordów do jednej tablicy PHP, może przekroczyć limit nawet na mocnym serwerze. Lepsze rozwiązanie to przetwarzanie porcjami, stronicowanie i praca w tle. Zwiększanie limitu z 256 MB do 2 GB dla wadliwego algorytmu tylko przesuwa moment awarii.
Wyciek lub rekurencja w kodzie
Jeśli pamięć rośnie bardzo szybko przy prostym żądaniu, sprawdź pętlę, rekurencję albo kolekcję, która nigdy nie jest zwalniana. Profilowanie i stack trace są tu ważniejsze niż ustawienia WordPressa. Problem może ujawnić się dopiero po aktualizacji, bo nowa wersja rozszerzenia uruchamia inną ścieżkę kodu.
Kiedy zwiększenie limitu jest uzasadnione
Jeżeli strona wykonuje normalną, świadomie cięższą operację i serwer ma zapas RAM-u, rozsądne zwiększenie limitu może być poprawnym rozwiązaniem. Zawsze sprawdź jednak, ile równoległych procesów PHP może działać. Limit 1 GB przy 20 workerach na serwerze z 8 GB RAM-u jest prostą drogą do OOM.
Jak potwierdzić, że naprawa naprawdę działa?
Po zmianie odtwórz dokładnie operację, która wcześniej kończyła się Allowed memory size exhausted, i obserwuj szczytowe zużycie pamięci procesu. Jeżeli podniosłeś limit, wynik powinien mieć bezpieczny zapas; jeśli poprawiłeś kod, zużycie powinno spaść. Sprawdź również kilka równoległych procesów, bo limit dotyczy pojedynczego procesu, a całkowite zapotrzebowanie serwera rośnie wraz z liczbą workerów.
Co obserwować po zmianie?
W logach szukaj kolejnych komunikatów memory exhausted oraz restartów PHP-FPM lub OOM killer. Jeżeli problem dotyczył obrazu, przetestuj kilka plików o zbliżonych wymiarach. Jeśli importu — kilka paczek danych. Pojedynczy sukces przy mniejszym pliku może dać fałszywe poczucie bezpieczeństwa.
Kiedy przekazać temat dalej?
Eskaluj, gdy proces PHP zużywa setki megabajtów przy prostym żądaniu albo pamięć rośnie wraz z czasem działania zadania. To sygnał potencjalnego błędu algorytmu, wycieku lub niekontrolowanego zbierania danych. Sam wyższy limit może w takim przypadku doprowadzić do OOM całego serwera.
Praktyczny scenariusz diagnostyczny
Przykład: import produktów działa przy 50 rekordach, ale przy 500 kończy się komunikatem o wyczerpaniu pamięci. Zwiększenie limitu z 128 do 512 MB może ukryć problem, jeśli wtyczka ładuje cały plik i wszystkie obrazy do pamięci naraz. Sprawdź dokładny Allowed memory size exhausted w logu oraz miejsce w stack trace. Jeśli problem rośnie liniowo wraz z liczbą rekordów, lepszym rozwiązaniem może być porcjowanie importu. Jeżeli pamięć zużywa konkretna funkcja podczas normalnego requestu, trzeba znaleźć powód. Limit jest bezpiecznikiem, nie optymalizatorem. Po zmianie obserwuj szczytowe użycie pamięci i kilka kolejnych importów, żeby upewnić się, że naprawa nie polega jedynie na przesunięciu momentu awarii.
Bezpieczna kolejność działań
- Zapisz pełny komunikat błędu i operację, przy której występuje.
- Sprawdź rzeczywisty
memory_limitdla PHP-FPM. - Porównaj problem z logami i użyciem pamięci procesu.
- Wyłącz lub popraw komponent, który alokuje nadmierną pamięć.
- Zwiększ limit tylko wtedy, gdy serwer ma zasoby i operacja tego realnie wymaga.
- Po zmianie przetestuj równoległe obciążenie oraz monitoring RAM.
Czego nie robić
Nie ustawiaj ogromnego memory_limit jako uniwersalnej naprawy. Nie kopiuj przypadkowych definicji WP_MEMORY_LIMIT w kilku miejscach konfiguracji. Jedno spójne ustawienie i pomiar są bezpieczniejsze niż seria „magicznych” wartości.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli WordPress regularnie dobija do limitu pamięci, możemy wskazać konkretną operację lub rozszerzenie, sprawdzić PHP-FPM i dobrać limity tak, aby nie zagrozić całemu serwerowi.
Najczęściej zadawane pytania
Czy WP_MEMORY_LIMIT i PHP memory_limit to to samo?
Nie. WordPress może ustawiać własny docelowy limit, ale nie przekroczy ograniczeń narzuconych przez konfigurację PHP lub hosting.
Ile pamięci powinien mieć WordPress?
Nie ma jednej wartości dla wszystkich stron. Prosta witryna i duży sklep mają inne potrzeby. Liczy się pomiar i dostępny RAM serwera.
Dlaczego błąd pojawia się tylko przy wgrywaniu zdjęcia?
Obróbka obrazu może wymagać znacznie więcej pamięci niż sam rozmiar pliku na dysku.
Czy zwiększenie RAM serwera zawsze pomoże?
Nie, jeśli przyczyną jest błąd w kodzie lub nieograniczona alokacja. Najpierw trzeba ustalić, co zużywa pamięć.