Allowed memory size exhausted: jak zwiększyć limit pamięci PHP i kiedy to może nie pomóc

Otwierasz stronę albo panel i zamiast treści widzisz biały ekran z komunikatem: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes). Czasem strona działa normalnie, a błąd wyskakuje dopiero przy imporcie produktów, generowaniu miniatur albo zapisie strony w page builderze. Wyszukiwarka podpowiada jedną radę: „zwiększ limit pamięci”. I często ta rada działa, ale równie często tylko odsuwa problem o kilka dni.

Piszę ten tekst jako osoba, która takie błędy naprawia na co dzień. Nie jestem agencją, nie mam warstwy opiekunów klienta ani zespołu, który przekazuje sobie Twoje zgłoszenie. Ze mną rozmawiasz bezpośrednio i ta sama osoba zajmuje się sprawą od diagnozy do naprawy. Dlatego opiszę to tak, jak faktycznie to robię: najpierw ustalam, co zjada pamięć, potem dopiero decyduję, czy podnieść limit, czy naprawić przyczynę.

Co dokładnie oznacza ten komunikat

PHP przydziela każdemu żądaniu (jednemu wejściu na stronę, jednemu zapisowi w panelu, jednemu zadaniu w tle) określoną ilość pamięci. Gdy skrypt spróbuje zużyć więcej, PHP przerywa jego działanie i zapisuje właśnie ten błąd. To zabezpieczenie: bez niego jedna źle napisana wtyczka mogłaby zająć całą pamięć serwera.

Liczba w komunikacie jest podana w bajtach. Najczęściej spotkasz te wartości:

Wartość w komunikacie	Limit w MB
33554432	32M
67108864	64M
134217728	128M
268435456	256M
536870912	512M

Druga liczba, czyli tried to allocate, to tylko ostatnia porcja pamięci, o którą skrypt poprosił, gdy limit już się skończył. Nie mówi, kto go zapełnił. Najcenniejsza część komunikatu to ścieżka do pliku i numer linii na jego końcu. Jeśli w ścieżce widzisz /wp-content/plugins/nazwa-wtyczki/, masz pierwszego podejrzanego.

Zanim zaczniesz: dwie rzeczy, które zajmą pięć minut

Po pierwsze, zrób kopię pliku wp-config.php (wystarczy pobrać go przez FTP albo menedżer plików w panelu hostingu). Będziesz go edytować, a literówka w tym pliku wyłącza całą stronę. Jeśli po edycji zobaczysz błąd krytyczny, przywrócenie kopii rozwiąże sprawę w minutę. Gdyby się to stało, sprawdź też mój wpis o tym, jak naprawić błąd krytyczny WordPress.

Po drugie, sprawdź, jaki limit masz teraz. W panelu WordPressa wejdź w Narzędzia → Zdrowie witryny → Informacje i rozwiń sekcje dotyczące serwera oraz stałych WordPressa. Zobaczysz tam limit pamięci PHP oraz wartości WP_MEMORY_LIMIT i WP_MAX_MEMORY_LIMIT. W sklepie to samo znajdziesz w WooCommerce → Status, w pozycji o limicie pamięci WP. Dzięki temu po zmianie będziesz wiedzieć, czy cokolwiek się zmieniło, a nie zgadywać.

Krok 1: ustal, co zjada pamięć

Zwiększanie limitu na ślepo to najczęstszy błąd: oszczędzasz pięć minut na diagnozie, a potem tracisz godziny na powracający problem. Włącz zapis błędów do pliku. W wp-config.php, nad linijką zaczynającą się od „To wszystko, przestań edytować”, dodaj:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Teraz odtwórz błąd (wejdź na stronę, zrób import, zapisz wpis) i otwórz plik /wp-content/debug.log. Szukaj linii z Allowed memory size i patrz na ścieżkę. Możesz też zajrzeć do logu błędów PHP w panelu hostingu, bo część hostingów zapisuje błędy tylko tam.

Ścieżka wskazuje na trzy typowe scenariusze. Wtyczka: zwykle jest to plik w /wp-content/plugins/. Motyw lub page builder: ścieżka prowadzi do /wp-content/themes/ albo do katalogu Elementora, Divi, WPBakery. Rdzeń WordPressa: pliki z /wp-includes/ albo /wp-admin/, najczęściej przy obróbce obrazów lub wielkich zapytaniach. Ta informacja decyduje o dalszych krokach.

Ważne: po zakończeniu diagnozy wyłącz WP_DEBUG i usuń debug.log. Ten plik bywa dostępny z przeglądarki i potrafi ujawnić ścieżki na serwerze oraz szczegóły wtyczek.

Krok 2: zwiększ limit pamięci PHP

Metody poniżej ułożyłem od najbezpieczniejszej do najbardziej ryzykownej. Zmieniaj jedną naraz i po każdej sprawdzaj wynik w Zdrowiu witryny. Jeśli wartość się nie zmieniła, przechodzisz do następnej.

Metoda A: panel hostingu

To najczystsze rozwiązanie, bo zmieniasz limit tam, gdzie PHP go faktycznie czyta. W cPanelu szukaj narzędzia MultiPHP INI Editor albo wyboru wersji PHP z opcjami. W DirectAdminie i panelach polskich hostingów opcja zwykle nazywa się Ustawienia PHP lub Konfiguracja PHP. Pole, którego szukasz, to memory_limit. Ustaw 256M i zapisz.

Metoda B: wp-config.php

Dodaj w wp-config.php, także nad linijką „To wszystko, przestań edytować”:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Pierwsza stała dotyczy zwykłej pracy WordPressa. Druga to wyższy limit, po który WordPress sięga w panelu administracyjnym i przy zadaniach takich jak obróbka obrazów. Warto je rozdzielać, bo odwiedzający Twoją stronę nie potrzebują tyle pamięci, co import produktów.

Ta metoda ma jedno ograniczenie, o którym mało kto pisze. WordPress tylko prosi PHP o więcej pamięci. Jeśli hosting zablokował taką możliwość (na przykład wyłączył funkcję ini_set albo narzucił limit na sztywno), Twoja wartość zostanie zignorowana bez żadnego komunikatu. Wtedy w Zdrowiu witryny nadal zobaczysz stare liczby.

Metoda C: plik .user.ini

Na hostingach z PHP w trybie FPM lub CGI (a to dziś większość) w głównym katalogu strony możesz utworzyć plik .user.ini z jedną linijką:

memory_limit = 256M

Zmiana z tego pliku bywa odczytywana z opóźnieniem, zwykle do kilku minut, więc nie oceniaj wyniku po kilku sekundach.

Metoda D: plik .htaccess

Ta metoda działa tylko wtedy, gdy PHP pracuje jako moduł Apache. Wtedy w .htaccess dodajesz:

php_value memory_limit 256M

Uwaga: na serwerach, gdzie PHP działa w trybie FPM lub CGI, ta linijka nie jest rozpoznawana i cała strona zaczyna zwracać błąd 500. Jeśli tak się stanie, usuń dodaną linię, a strona wróci do życia. Dlatego traktuję tę metodę jako ostatnią z listy.

Metoda E: własny serwer (VPS)

Jeśli masz pełny dostęp, edytujesz php.ini (albo plik konfiguracji puli PHP-FPM), ustawiasz memory_limit = 256M i restartujesz usługę PHP. Tu obowiązuje reguła, której nie widać na hostingach współdzielonych: limit dotyczy jednego procesu. Jeśli masz 20 równoległych procesów PHP, a każdy może zająć 512 MB, w teorii serwer potrzebuje 10 GB pamięci. Zbyt wysoki limit na małym VPS-ie kończy się wyłączeniem procesów przez system, a nie ładnym komunikatem PHP.

Jaki limit ustawić

Typ strony	Rozsądny start
Prosta wizytówka lub blog	128M do 256M
Strona na page builderze (Elementor, Divi)	256M
Sklep WooCommerce	256M to oficjalne minimum, w praktyce przy większym sklepie zaczynam od 512M dla panelu
Wartość powyżej 512M dla frontu strony	Sygnał alarmowy: szukaj przyczyny, nie zwiększaj dalej

WooCommerce w dokumentacji zaleca limit pamięci WordPressa na poziomie 256 MB lub więcej. To wartość minimalna. Sklep z tysiącami produktów, wieloma wtyczkami i integracjami (na przykład z Allegro) w panelu potrzebuje zwykle więcej.

Kiedy zwiększenie limitu nie pomoże

To najważniejsza część tego wpisu. Jeśli po podniesieniu limitu błąd wraca, a Ty podnosisz go jeszcze raz, do 512M, potem do 1G, to nie masz problemu z limitem. Masz problem z tym, co ten limit zużywa. Oto sytuacje, które widzę najczęściej.

1. Nieskończona pętla lub rekurencja w kodzie

Skrypt, który wywołuje sam siebie bez końca, zużyje każdą ilość pamięci, jaką mu dasz. Objaw: błąd pojawia się od razu po aktualizacji wtyczki albo po dodaniu fragmentu kodu do functions.php, wyskakuje zawsze w tym samym miejscu, a większy limit tylko wydłuża czas do awarii. Rozwiązanie: cofnąć zmianę, wrócić do poprzedniej wersji wtyczki, a błąd zgłosić autorowi.

2. Wtyczka, która kumuluje dane w pamięci

Niektóre wtyczki wczytują do pamięci całe listy: wszystkich klientów, wszystkie zamówienia, wszystkie wpisy. Na małej stronie to niezauważalne, na sklepie po dwóch latach działania już nie. Sprawdzam to prosto: przez FTP zmieniam nazwę folderu podejrzanej wtyczki, na przykład z nazwa-wtyczki na nazwa-wtyczki-off. WordPress wyłączy ją automatycznie. Jeśli błąd znika, mamy winowajcę.

3. Zapytania bez ograniczeń

Kod, który pobiera „wszystko naraz” (klasyczny przykład to posts_per_page ustawione na -1), działa dobrze na 200 rekordach i wykłada się na 50 000. To typowe dla raportów sprzedaży, eksportów i własnych funkcji dopisanych do motywu. Rozwiązanie to praca na partiach: po 100 czy 500 rekordów naraz, a nie wszystkich razem. Zwiększenie limitu tylko przesuwa moment awarii.

4. Za duże zdjęcia

Obraz w pamięci zajmuje o wiele więcej niż jego plik na dysku, bo PHP rozpakowuje go do postaci pikseli. Zdjęcie 6000 na 4000 px to 24 milionów pikseli, czyli około 90 MB na jedną kopię, a przy tworzeniu miniatur w kilku rozmiarach potrzeba tego więcej. Jeśli błąd wyskakuje przy wgrywaniu zdjęć albo w bibliotece mediów, tu jest przyczyna. Zmniejszaj zdjęcia przed wgraniem (do 2000 do 2500 px szerokości w zupełności wystarczy dla strony).

5. Rozdęte opcje ładowane przy każdym wejściu

WordPress przy każdym żądaniu wczytuje do pamięci wszystkie opcje oznaczone jako autoload z tabeli wp_options. Po latach instalowania i usuwania wtyczek zostają tam śmieci, czasem kilka megabajtów. Rozmiar sprawdzisz w phpMyAdmin (zamień wp_ na swój prefiks tabel):

SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Jeśli wynik to kilka tysięcy KB, masz prawdziwy kłopot, który zwiększa zużycie pamięci przy każdym pojedynczym wejściu na stronę. Zanim cokolwiek usuniesz, zrób kopię bazy. To zapytanie tylko odczytuje dane, ale sprzątanie już nie.

6. Zadania w tle i backupy

Jeśli błąd pojawia się o stałej porze (na przykład w nocy) albo tylko podczas kopii zapasowej, importu czy synchronizacji ze sklepem zewnętrznym, winne jest zadanie WP-Cron lub wtyczka backupu, która pakuje całą stronę w jednym przebiegu. Rozwiązaniem jest zmiana trybu na przyrostowy, podział na mniejsze partie albo przeniesienie kopii na poziom serwera.

7. Prawdziwy problem to nie limit PHP

Komunikat Allowed memory size ... exhausted to wyłącznie limit samego PHP. Jeśli serwer jako całość zabraknie pamięci, nie zobaczysz tego napisu. Zobaczysz błąd 500, 502 lub 503, a w logach systemu wpis o zabitym procesie. W takiej sytuacji zmiana memory_limit niczego nie da, bo problem leży w zasobach hostingu lub liczbie równoległych procesów.

8. Włamanie

Złośliwy skrypt, który rozsyła spam albo kopie się po plikach, też zużywa pamięć. Jeśli limit „nagle przestał wystarczać”, a nic nie zmieniałeś, a do tego w plikach są dziwne wpisy lub w Google widać obce podstrony, to nie jest kwestia konfiguracji. W takim przypadku przejdź do wpisu, jak odwirusować stronę WordPress.

9. Za dużo wszystkiego naraz

Page builder, WooCommerce, wtyczka wielojęzyczna, kilka wtyczek do SEO i trzy do optymalizacji: każda z nich zajmuje swój kawałek pamięci. Tu zwiększenie limitu jest uczciwym rozwiązaniem, ale tylko razem z uporządkowaniem wtyczek. Jeśli po podniesieniu limitu strona przestaje wybuchać, ale działa wolno, przeczytaj, dlaczego Twój sklep WooCommerce działa wolno.

Szybka tabela: objaw i pierwszy ruch

Objaw	Najbardziej prawdopodobna przyczyna	Pierwszy ruch
Błąd od razu po aktualizacji wtyczki	Błąd w nowej wersji, pętla w kodzie	Przywróć poprzednią wersję, zgłoś błąd autorowi
Błąd przy wgrywaniu zdjęć	Zbyt duże obrazy, za niski WP_MAX_MEMORY_LIMIT	Zmniejsz zdjęcia, podnieś limit dla panelu
Błąd tylko w panelu, front działa	Za niski limit dla administracji	Ustaw WP_MAX_MEMORY_LIMIT na 512M
Błąd przy eksporcie lub raporcie	Zapytanie pobiera wszystko naraz	Eksport w partiach, zmiana narzędzia
Błąd o stałej porze	Backup lub zadanie WP-Cron	Zmień tryb backupu, podziel zadanie
Limit zmieniony, ale bez efektu	Hosting blokuje zmianę	Zmień w panelu hostingu lub napisz do supportu
Błąd 500, 502 lub 503 zamiast komunikatu o pamięci	Brak zasobów serwera, nie limit PHP	Sprawdź logi serwera, plan hostingu
Nagły błąd bez żadnych zmian z Twojej strony	Możliwe włamanie	Skan plików, sprawdzenie użytkowników i wtyczek

Krok 3: znajdź winowajcę bez zgadywania

Jeśli log nie wskazuje jednoznacznie sprawcy, postępuję metodycznie. Najpierw instaluję wtyczkę Query Monitor na środowisku testowym. Pokazuje ona szczytowe zużycie pamięci dla każdej podstrony i to, ile zapytań do bazy generuje każda wtyczka. Następnie wyłączam wtyczki partiami, a nie po jednej: połowa, potem połowa z tej połowy. To skraca poszukiwanie z kilkudziesięciu prób do kilku. Na końcu przełączam się na domyślny motyw WordPressa, żeby wykluczyć albo potwierdzić winę motywu.

Ostrzegam: nie rób tego na działającym sklepie w godzinach ruchu. Wyłączenie wtyczki płatności czy wysyłki na produkcji oznacza utracone zamówienia. Do takich testów służy kopia strony (środowisko testowe).

Co zrobić, gdy nie możesz wejść do panelu

Jeśli błąd blokuje wp-admin, cały proces przeprowadzasz przez FTP lub menedżer plików. Edytujesz wp-config.php, zmieniasz nazwy folderów wtyczek i czytasz debug.log, bez logowania do WordPressa. Jeśli zamiast komunikatu o pamięci widzisz zupełnie pustą stronę, zajrzyj do wpisu o białej stronie śmierci w WordPressie. To ten sam rodzaj awarii, tylko bez czytelnego komunikatu.

Czego nie robić

Nie ustawiaj limitu na nieograniczony (-1). Jedna błędna pętla zajmie całą pamięć serwera, a hosting może zawiesić Twoje konto, zanim zdążysz zareagować.
Nie wklejaj wszystkich metod naraz. Kilka zmian w kilku plikach, po których strona przestaje działać, to najgorszy scenariusz do diagnozy. Jedna zmiana, jedna weryfikacja.
Nie zostawiaj włączonego WP_DEBUG. Na działającej stronie i sklepie generuje logi i może ujawniać szczegóły konfiguracji.
Nie edytuj wp-config.php bez kopii. To plik, którego błąd wyłącza całą witrynę.
Nie traktuj większego limitu jako naprawy. Jeśli błąd wraca, to on jest objawem, a nie chorobą.

Lista kontrolna na koniec

Zrobiłem kopię wp-config.php i bazy danych.
Odczytałem ścieżkę z komunikatu i sprawdziłem, czy wskazuje wtyczkę, motyw czy rdzeń.
Sprawdziłem aktualny limit w Zdrowiu witryny.
Podniosłem limit jedną metodą i zweryfikowałem, czy wartość faktycznie się zmieniła.
Sprawdziłem, czy błąd wrócił przy tej samej czynności.
Jeśli wrócił, zająłem się przyczyną: wtyczką, zdjęciami, zapytaniami, autoloadem albo zadaniem w tle.
Wyłączyłem WP_DEBUG i usunąłem debug.log.

Najczęstsze pytania

Czy wyższy limit pamięci spowolni stronę?

Nie, limit jest sufitem, a nie rezerwacją. PHP nie zajmuje z góry 512 MB dla każdego wejścia na stronę, tylko tyle, ile skrypt faktycznie potrzebuje. Wyższy sufit pozwala jednak źle napisanemu skryptowi zużyć więcej, zanim zostanie zatrzymany, i to może obciążyć serwer.

Zmieniłem wp-config.php i nic się nie zmieniło. Dlaczego?

Najczęściej dlatego, że hosting narzuca limit na poziomie serwera i ignoruje wartość z WordPressa. Sprawdź w Zdrowiu witryny, jaki limit faktycznie obowiązuje. Jeśli jest niższy niż ten z wp-config.php, zmień go w panelu hostingu albo poproś o to support. Bywa też, że limity są przypisane do planu i wymagają zmiany pakietu.

Czy 256 MB wystarczy dla sklepu WooCommerce?

Dla małego sklepu z kilkuset produktami i kilkoma wtyczkami tak. To także oficjalne minimum podawane przez WooCommerce. Przy dużym asortymencie, importach, integracjach i raportach zaczynam od 512 MB dla panelu administracyjnego, ale tylko wtedy, gdy wiem, dlaczego jest to potrzebne.

Kto powinien to zrobić: ja czy hosting?

Zmianę limitu możesz zrobić sam. Diagnoza przyczyny, jeśli błąd wraca, wymaga zwykle kogoś, kto czyta logi i wie, na co patrzeć. Support hostingu zajmie się limitami po swojej stronie, ale nie przeanalizuje Twojej wtyczki ani zapytań w motywie.

Gdy to nie działa

Jeśli po podniesieniu limitu błąd wciąż wraca, a Ty nie wiesz, gdzie szukać przyczyny, nie ma sensu tracić kolejnych wieczorów. Zajmuję się awariami i bezpieczeństwem stron WordPress oraz sklepów WooCommerce. Pracuję sam, jako niezależny ekspert, więc nie odsyłam Cię do zespołu ani do kolejki zgłoszeń. Sprawdzę logi, znajdę faktycznego winowajcę i naprawię go tak, żeby błąd się nie powtórzył. Możesz też zajrzeć do wpisu o tym, jakie są najczęstsze przyczyny awarii strony internetowej.

Nie chcesz robić tego samodzielnie? Zajmę się tym za Ciebie. Napisz krótko, co się dzieje, odpowiem tego samego dnia roboczego. Napisz do mnie