Komunikat o wyczerpaniu pamięci to jeden z najbardziej frustrujących problemów, na jakie można natknąć się podczas zarządzania stroną www. Praca nad nowym wpisem, instalacja wtyczki lub próba aktualizacji nagle zostają przerwane przez surowy komunikat systemowy. Dowiedz się, jak zwiększyć limit pamięci PHP i naprawić błąd „Allowed Memory Size Exhausted” w WordPressie, aby przywrócić pełną sprawność serwisu i zabezpieczyć go przed ponownymi awariami.
Szybka odpowiedź (Quick Fix): Aby natychmiast naprawić błąd wyczerpania pamięci w WordPressie, połącz się ze swoim serwerem przez FTP lub Menedżer Plików, otwórz główny plik wp-config.php i tuż przed linijką /* That's all, stop editing! Happy publishing. */ wklej poniższy kod: > define( 'WP_MEMORY_LIMIT', '256M' ); > Zapisz zmiany w pliku i odśwież stronę w przeglądarce.
—
Czym jest błąd „Allowed memory size exhausted” i dlaczego powstaje?
Każda operacja wykonywana przez WordPress – od generowania pojedynczego wpisu blogowego, przez przetwarzanie koszyka w sklepie, po generowanie podglądu w edytorze wizualnym – to seria instrukcji napisanych w języku PHP. Aby serwer mógł przetworzyć te instrukcje, dynamicznie alokuje określoną przestrzeń w pamięci operacyjnej RAM serwera.
Problem allowed memory size exhausted wordpress pojawia się w momencie, gdy dany proces (np. skrypt generujący miniaturki zdjęć lub synchronizujący stany magazynowe) potrzebuje więcej pamięci RAM, niż wynosi maksymalny pułap przypisany w konfiguracji serwera dla pojedynczego wątku PHP. Gdy skrypt osiągnie ten sufit, silnik PHP ze względów bezpieczeństwa natychmiast przerywa jego działanie, rzucając błąd krytyczny:
text Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097152 bytes) in /home/user/public_html/wp-content/plugins/przyklad/plik.php on line 123
Jeśli na Twoim serwerze w celach bezpieczeństwa wyłączone jest bezpośrednie raportowanie błędów na ekranie (display_errors = Off), zamiast powyższego komunikatu zobaczysz pustą przestrzeń. W takiej sytuacji wyczerpanie pamięci staje się bezpośrednią przyczyną awarii znanej w środowisku webmasterskim jako Jak naprawić „Biały Ekran Śmierci” (White Screen of Death) w WordPressie? – Ragn.
Anatomia błędu: jak przeliczyć bajty na megabajty (MB) w komunikacie błędu?
Gdy na ekranie pojawia się komunikat zawierający frazę fatal error allowed memory size of bytes exhausted, początkujący administratorzy czują się zdezorientowani ciągiem cyfr. PHP domyślnie komunikuje zużycie zasobów w bajtach. Aby dowiedzieć się, jaki limit zatrzymał Twoją stronę, wystarczy podzielić wskazaną wartość dwukrotnie przez 1024 (przeliczając bajty na kilobajty, a następnie na megabajty).
Poniższa matryca ułatwia błyskawiczną identyfikację aktualnie przypisanego limitu:
| Wartość w bajtach (z komunikatu błędu) | Wartość w MB | Kontekst systemowy w środowisku WordPress | | :— | :— | :— | | 41 943 040 bytes | 40 MB | Domyślny, przestarzały limit bazowy pojedynczej instalacji WordPress | | 67 108 864 bytes | 64 MB | Domyślny limit bazowy dla WordPress Multisite / minimum WP Core | | 134 217 728 bytes | 128 MB | Standardowy limit tanich hostingów współdzielonych; minimum dla małego sklepu | | 268 435 456 bytes | 256 MB | Rekomendowany standard dla nowoczesnych stron (Elementor, WooCommerce) | | 536 870 912 bytes | 512 MB | Zaawansowane środowiska z rozbudowanymi procesami w tle (CRON, importy XML/CSV) |
Druga część komunikatu – np. *(tried to allocate 2097152 bytes)* – wskazuje, jakiej porcji pamięci zabrakło skryptowi do pomyślnego zakończenia zadania (w tym wypadku: zaledwie 2 MB).
Główne przyczyny: zasobożerne wtyczki (WooCommerce, Elementor), importy i pętle zapytań
Do najczęstszych powodów zderzenia się z limitem pamięci należą:
- Rozbudowane page buildery: Narzędzia takie jak Elementor, Divi czy WPBakery ładują do pamięci dziesiątki bibliotek i kontrolek jednocześnie podczas edycji strony w czasie rzeczywistym.
- Wtyczki e-commerce (WooCommerce): Rozbudowane tabele bazy danych, dynamiczne obliczanie podatków, obsługa sesji koszyka i integracje bramek płatności drastycznie zwiększają zapotrzebowanie na pamięć operacyjną.
- Masowe importy danych: Wtyczki typu WP All Import czy moduły migracji bazy danych przetwarzające duże pliki XML/CSV wymagają przetwarzania setek rekordów w jednym cyklu roboczym.
- Nieoptymalny kod (błędy wordpress pamięć ram): Źle napisana pętla zapytań SQL (
WP_Query), która próbuje załadować do pamięci podręcznej tysiące wpisów naraz bez stronicowania (paginacji).
—
Jaki powinien być bezpieczny limit pamięci PHP dla nowoczesnego WordPressa?
Zastanawiając się, ile pamięci php dla wordpress jest optymalną wartością, należy rozgraniczyć oficjalne wytyczne twórców oprogramowania od rzeczywistości rynkowej.
Wymagania WordPress Core vs. realne zapotrzebowanie zaawansowanych motywów
Oficjalna dokumentacja projektu WordPress podaje, że minimalny wymóg techniczny to 64 MB. Wartość ta sprawdza się jednak wyłącznie w przypadku czystej instalacji opartej o domyślny motyw (np. Twenty Twenty-Four) z garścią prostych wtyczek blogowych.
W ekosystemie komercyjnym sytuacja wygląda zgoła inaczej:
- Prosta strona firmowa (Gutenberg + lekki motyw): 128 MB
- Strona z page builderem (Elementor / Divi): minimum 256 MB
- Sklep WooCommerce z wieloma integracjami: 256 MB do 512 MB
Architektura WordPressa rozróżnia dwa niezależne parametry alokacji pamięci:
WP_MEMORY_LIMIT– określa limit alokacji dla standardowych operacji generowania front-endu (widoku strony dla czytelników) oraz standardowych procesów w tle.WP_MAX_MEMORY_LIMIT– definiuje limit pamięci przeznaczony wyłącznie na potrzeby panelu administracyjnego (/wp-admin/). Panel zarządzania z reguły wykonuje cięższe operacje (np. czyszczenie baz, parsowanie widgetów, dekompresję zip przy aktualizacjach), dlatego WordPress domyślnie pozwala na ustawienie w tym miejscu wyższej wartości (standardowo 256 MB).
Ekspercki Pro-Tip: Nigdy nie ustawiaj limitu pamięci na -1 (wartość oznaczająca brak limitu) na środowiskach produkcyjnych. Jeśli wtyczka wpadnie w nieskończoną pętlę lub skrypt bazy danych spróbuje zmapować całą zawartość potężnej tabeli do tablicy PHP, proces zmonopolizuje 100% pamięci RAM fizycznego serwera. W takim scenariuszu zadziała mechanizm jądra systemu Linux – OOM Killer (Out Of Memory Killer) – który gwałtownie zabije procesy PHP-FPM lub bazę danych MySQL, doprowadzając do całkowitej niedostępności wszystkich stron na serwerze.
—
Jak krok po kroku zwiększyć limit pamięci PHP w WordPressie? (4 metody)

Przed przystąpieniem do jakichkolwiek modyfikacji plików systemowych zawsze wykonaj kopię zapasową (backup) edytowanego pliku na dysku lokalnym. Nawet drobna literówka w plikach konfiguracyjnych potrafi unieruchomić całą witrynę.
Metoda 1: Edycja pliku wp-config.php (rekomendowana przez WordPress)
To najbardziej bezpośredni sposób zarządzania pamięcią z poziomu aplikacji. Plik wp-config.php znajduje się w głównym katalogu Twojej instalacji WordPressa (zazwyczaj public_html lub www).
- Połącz się z serwerem za pomocą klienta FTP (np. FileZilla) lub otwórz Menedżer Plików w panelu swojego hostingu.
- Odszukaj i edytuj plik
wp-config.php. - Przewiń plik niemal na sam dół, odnajdując linię:
php /* That's all, stop editing! Happy publishing. */ - Bezpośrednio przed tą linijką wklej definicje stałej
wp_memory_limitoraz limitu administracyjnego:php define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' ); - Zapisz plik i prześlij go z powrotem na serwer.
Metoda 2: Modyfikacja dyrektyw w pliku .htaccess
Jeśli korzystasz z serwera Apache lub LiteSpeed, parametry środowiska PHP można często nadpisać za pośrednictwem pliku konfiguracyjnego serwera www.
- W głównym katalogu strony odszukaj ukryty plik
.htaccess(upewnij się, że w programie FTP masz włączone pokazywanie ukrytych plików z kropką na początku). - Otwórz plik do edycji i na samym dole wklej instrukcję odpowiadającą za zwiększenie limitu php htaccess:
apache php_value memory_limit 256M - Zapisz zmiany.
Ważne ostrzeżenie: Jeśli Twój hosting obsługuje PHP w trybie CGI/FastCGI lub PHP-FPM, próba użycia dyrektywy php_value w pliku .htaccess zakończy się błędem składni serwera. Po odświeżeniu strony możesz natychmiast zobaczyć Jak rozwiązać problem „Wewnętrzny Błąd Serwera 500” w WordPressie? – Ragnos Blog. Jeśli tak się stanie, nie panikuj – po prostu usuń dodaną linijkę z pliku .htaccess, zapisz go ponownie i skorzystaj z Metody 3 lub 4.
Metoda 3: Zmiana parametrów w php.ini lub .user.ini
Jeśli posiadasz dostęp do głównego pliku konfiguracyjnego PHP lub Twój hostingodawca pozwala na lokalne nadpisywanie parametrów per-katalog:
- Zlokalizuj w głównym folderze domeny plik
php.inilub.user.ini(jeśli nie istnieją, w wielu środowiskach możesz stworzyć taki plik tekstowy samodzielnie). - Dodaj lub zmodyfikuj istniejącą dyrektywę
memory_limit: ini memory_limit = 256M - W przypadku plików
.user.iniserwer odczytuje zmiany z opóźnieniem (często do 5 minut, zależnie od ustawieniauser_ini.cache_ttl).
Metoda 4: Zmiana limitu w panelu hostingu (cPanel / DirectAdmin / PHP Selector)
Większość nowoczesnych firm hostingowych blokuje manualną edycję plików konfiguracyjnych serwera, oddając do rąk użytkownika interfejs graficzny.
- cPanel:
- Zaloguj się do panelu i przejdź do sekcji Oprogramowanie -> Select PHP Version (lub *MultiPHP INI Editor*).
- Kliknij zakładkę Options (Opcje).
- Odszukaj pole
memory_limit, kliknij na bieżącą wartość i wybierz z rozwijanej listy256Mlub512M. - Zmiany zostaną zapisane automatycznie.
- DirectAdmin:
- Wejdź w Zaawansowane funkcje -> Konfiguracja PHP lub Wybór wersji PHP.
- Odszukaj dyrektywę
memory_limiti zmień jej wartość na wyższą. - Zapisz formularz.
—
Zwiększyłem limit, a błąd nadal występuje? Co poszło nie tak
Zdarzają się sytuacje, w których pomimo dopisania define('WP_MEMORY_LIMIT', '512M'); błąd Fatal error: Allowed memory size exhausted nie ustępuje ani na chwilę. Wynika to zazwyczaj z dwóch zjawisk technicznych.
Twardy limit pamięci (Hard Limit) narzucony przez hostingodawcę

WordPress to tylko oprogramowanie działające wewnątrz środowiska serwerowego. Jeśli Twój tani pakiet współdzielony posiada twardy limit w pliku nadrzędnym php.ini wynoszący 128 MB, żadna instrukcja w wp-config.php ani w .htaccess nie jest w stanie go podnieść. Kod w aplikacji może jedynie obniżyć limit dla konkretnego skryptu, ale nigdy nie przebije globalnego limitu procesu narzuconego przez administratora serwera (tzw. Resource Governance w CloudLinux / LVE Manager). W takiej sytuacji jedynym wyjściem jest przejście na wyższy pakiet hostingowy lub kontakt z supportem usługodawcy.
Wycieki pamięci (Memory Leaks) – dlaczego podnoszenie limitu to czasami tylko pudrowanie problemu?
Jeżeli podnosisz limit z 256 MB na 512 MB, a po tygodniu błąd powraca, sygnalizując zużycie pełnych 512 MB, nie masz do czynienia ze „zwykłym brakiem pamięci”, lecz z wyciekiem pamięci (memory leak).
Powstaje on w wyniku błędów w architekturze wtyczki lub motywu:
- Skrypt alokuje obiekty w nieskończonych tablicach bez ich zwalniania (
unset()). - Wadliwie skonstruowane zapytania cyklicznie przetwarzają całą bazę rekordów.
- Konflikt dwóch niekompatybilnych wtyczek powoduje zapętlenie hooków akcji WordPressa.
W takim przypadku ciągłe windowanie RAM-u nie rozwiązuje źródła awarii – prędzej czy później skrypt skonsumuje każdą przydzieloną pulę.
—
Jak sprawdzić aktualny limit pamięci w panelu WordPress? (Narzędzie Stan witryny)
Nie musisz logować się na FTP ani instalować zewnętrznych skryptów diagnostycznych, aby zweryfikować, czy wprowadzone zmiany przyniosły skutek. WordPress posiada wbudowane narzędzie diagnostyczne.
- Zaloguj się do kokpitu WordPressa jako administrator.
- W menu bocznym wybierz: Narzędzia -> Stan witryny.
- Przejdź do zakładki Informacja (obok zakładki *Status*).
- Rozwiń sekcję Serwer – odszukaj pozycję Limit pamięci PHP (wskazuje globalny limit przydzielony przez serwer).
- Rozwiń sekcję Stałe WordPressa – odszukaj parametry WP_MEMORY_LIMIT oraz WP_MAX_MEMORY_LIMIT (wskazują limity zadeklarowane bezpośrednio w konfiguracji Twojej strony).
Jeśli w sekcji *Stałe WordPressa* widzisz 256M, a w sekcji *Serwer* nadal widnieje np. 128M, oznacza to, że hosting blokuje zmiany aplikacyjne i konieczna jest modyfikacja ustawień po stronie panelu serwera (Metoda 4).
—
Powiązane awarie: kiedy brak pamięci prowadzi do poważniejszych błędów serwera
Wyczerpanie limitów alokacji pamięci rzadko bywa problemem odizolowanym. Ponieważ pamięć RAM jest współdzielona pomiędzy procesami interpretera PHP a transakcjami bazodanowymi, krytyczny deficyt pamięci wywołuje efekt domina.
Gdy proces PHP zostanie przerwany w trakcie wykonywania złożonej transakcji zapisu do bazy danych, może dojść do zablokowania tabel (table lock) lub przeciążenia wątków serwera SQL. W konsekwencji kolejni użytkownicy próbujący połączyć się ze stroną nie ujrzą już błędu o wyczerpaniu bajtów, lecz Jak naprawić „Błąd połączenia z bazą danych” w WordPressie? – Ragnos Blog. Prawidłowa higiena zasobów serwera i eliminacja pamięciożernych wtyczek to fundament stabilnego działania całej infrastruktury webowej.
—
Najczęściej zadawane pytania (FAQ)
Czy mogę samodzielnie ustawić limit 1024M w wp-config.php?
Możesz wpisać taką wartość do pliku, ale zadziała ona tylko wtedy, gdy Twój fizyczny serwer oraz pakiet hostingowy dopuszczają tak wysoką alokację na jeden proces. W przypadku standardowych hostingów współdzielonych wpisanie wartości wyższej niż twardy limit serwera zostanie po prostu zignorowane przez interpreter PHP.
Dlaczego błąd pojawia się tylko podczas edycji w Elementorze lub aktualizacji wtyczek?
Edytory wizualne (page buildery) oraz procesy rozpakowywania archiwów .zip podczas aktualizacji wtyczek generują tzw. skoki zapotrzebowania pamięci (memory spikes). Podczas normalnego wyświetlania podstrony serwis może zużywać zaledwie 45 MB RAM-u, jednak w momencie uruchomienia edytora wizualnego narzut pamięciowy gwałtownie rośnie powyżej 150–200 MB, powodując natychmiastowe załamanie procesu przy zbyt niskim limicie bazowym.
Jak sprawdzić, która wtyczka zużywa najwięcej pamięci?
Najlepszym narzędziem diagnostycznym jest bezpłatna wtyczka Query Monitor. Po jej aktywacji na górnym pasku administracyjnym pojawi się wskaźnik zużycia pamięci dla bieżącego żądania HTTP. W panelu wtyczki można podejrzeć dokładny profil zużycia zasobów RAM z podziałem na poszczególne wtyczki, motyw oraz zapytania SQL do bazy danych, co pozwala bezbłędnie wytypować komponent odpowiedzialny za przeciążenie serwisu.

