Błąd Allowed memory size exhausted: jak zwiększyć memory_limit PHP

Błąd Allowed memory size of 134217728 bytes exhausted oznacza, że skrypt PHP próbował użyć więcej pamięci, niż pozwala dyrektywa memory_limit (134217728 bajtów to 128 MB), więc PHP przerwał go błędem Fatal error. Szybkie rozwiązanie to podniesienie limitu do 256M w .user.ini, w php.ini lub stałą WP_MEMORY_LIMIT w wp-config.php. Jeśli skryptowi brakuje pamięci nawet przy 512M, problemem nie jest limit, tylko wtyczka, motyw, import albo pętla, i to właśnie trzeba znaleźć.

Co oznacza błąd i jak go odczytać

Typowy wpis w logu wygląda tak:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/web/example.com/public_html/wp-content/plugins/some-plugin/includes/export.php on line 88

• of 134217728 bytes to aktywny memory_limit w bajtach. Po tej liczbie sprawdzisz, czy zmiana zadziałała: jeśli po edycji nadal widzisz 134217728, nowy limit nie został zastosowany.
• tried to allocate 20480 bytes to rozmiar ostatniej alokacji, a nie całkowite zużycie. Mała liczba (kilobajty) oznacza, że pamięć zapełniała się stopniowo, a ta linia była tylko kroplą, która przelała czarę. Duża (dziesiątki lub setki MB) wskazuje na jedną ciężką operację: odczyt dużego pliku, wczytanie całej tabeli, przetwarzanie ogromnego obrazu.
• in … on line … pokazuje, gdzie skrypt się zatrzymał. Ścieżka w wp-content/plugins/plugin-name wskazuje podejrzanego. Ścieżka w wp-includes oznacza, że rdzeń WordPressa wykonywał pracę zleconą przez wtyczkę lub motyw, więc trzeba szukać dalej.

Odwiedzający stronę na WordPressie zwykle widzą zamiast tego komunikat o błędzie krytycznym na stronie, a administrator dostaje e-mail z linkiem do trybu odzyskiwania (zobacz nasz poradnik o błędzie krytycznym WordPressa). Prawdziwa przyczyna zawsze jest w logu.

Nie myl go z Out of memory (allocated …) (tried to allocate …). Ten komunikat PHP zgłasza, gdy to system operacyjny odmawia przydzielenia pamięci: serwerowi skończył się RAM albo na hostingu współdzielonym osiągnięto limit pamięci całego konta. Zwiększenie memory_limit tu nie pomoże.

Jak sprawdzić aktualny memory_limit

Limit można ustawić w kilku miejscach, a strona i wiersz poleceń często używają różnych wartości, więc sprawdzaj go tam, gdzie występuje błąd.

• WordPress: Narzędzia → Kondycja witryny → Informacje. Sekcja Serwer pokazuje limit pamięci PHP (dla strony i dla kokpitu), a sekcja Stałe WordPressa pokazuje WP_MEMORY_LIMIT i WP_MAX_MEMORY_LIMIT.
• Plik testowy w katalogu głównym strony pokazuje limit dla żądań WWW:

<?php
// mem.php - delete it right after checking
echo 'memory_limit: ', ini_get('memory_limit'), '<br>';
echo 'PHP ', PHP_VERSION, ', SAPI: ', PHP_SAPI;

Każda wersja PHP ma własny php.ini, więc sprawdź ponownie po przełączeniu strony na inną wersję PHP. Przez SSH pamiętaj, że CLI czyta osobny plik (w Debianie i Ubuntu /etc/php/8.3/cli/php.ini), a strona działa na PHP-FPM z /etc/php/8.3/fpm/php.ini:

php -i | grep memory_limit    # CLI limit, not the website's
php --ini                     # which php.ini files the CLI loads
wp eval 'echo ini_get("memory_limit"), " / ", WP_MEMORY_LIMIT, " / ", WP_MAX_MEMORY_LIMIT, PHP_EOL;'

Jak zwiększyć memory_limit: wszystkie sposoby

Właściwy sposób zależy od tego, jak uruchamiany jest PHP. Większość nowoczesnych hostingów korzysta z PHP-FPM: .user.ini, php.ini i ustawienia puli działają, a php_value w .htaccess nie.

.user.ini na hostingu współdzielonym

; .user.ini in public_html
memory_limit = 256M

PHP odczytuje te pliki ponownie co 5 minut (user_ini.cache_ttl = 300), więc odczekaj chwilę i sprawdź wynik plikiem mem.php. Jako jednostek używaj tylko K, M lub G: PHP nie rozumie MB, a 256MB odczyta jako 256 bajtów (od PHP 8.2 w logu pojawia się też ostrzeżenie Invalid quantity). Jeśli nic się nie zmienia, hosting zablokował tę wartość: poproś support o jej podniesienie.

php.ini i pula PHP-FPM na VPS

sudo grep -n '^memory_limit' /etc/php/8.3/fpm/php.ini
sudo sed -i 's/^memory_limit = .*/memory_limit = 256M/' /etc/php/8.3/fpm/php.ini
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Dla jednej strony dodaj linię do jej pliku puli, na przykład /etc/php/8.3/fpm/pool.d/example.com.conf. Wartości ustawionej przez php_admin_value nie zmieni ini_set(), więc WordPress i wtyczki nie mogą jej dalej podnieść; użyj php_value[memory_limit], jeśli aplikacja ma mieć taką możliwość. Jeśli panel generuje pule z szablonów, a domyślny szablon nie ustawia memory_limit, obowiązuje php.ini. Nie edytuj domyślnego szablonu ani wygenerowanych plików puli, bo panel nadpisuje je przy aktualizacjach i przebudowie domeny: skopiuj szablon pod nową nazwą i przypisz go do domeny.

.htaccess: tylko z mod_php

php_value memory_limit 256M w .htaccess działa tylko wtedy, gdy PHP pracuje jako moduł Apache. Przy PHP-FPM Apache nie rozpoznaje tej dyrektywy i zwraca błąd 500 dla całej strony, więc jeśli strona przestała działać po dodaniu tej linii, usuń ją.

wp-config.php: WP_MEMORY_LIMIT i WP_MAX_MEMORY_LIMIT

WP_MEMORY_LIMIT dotyczy części publicznej strony (domyślnie 40M, w Multisite 64M). WP_MAX_MEMORY_LIMIT dotyczy ekranów kokpitu dla administratorów, rozpakowywania aktualizacji, przetwarzania obrazów i WP-Cron (domyślnie 256M). WordPress wywołuje ini_set() tylko wtedy, gdy jego wartość jest wyższa od bieżącego limitu PHP, więc stała nigdy nie obniży limitu 512M i nie pokona limitu zablokowanego przez hosting.

// wp-config.php, above "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

CLI: WP-CLI i Composer

php -d memory_limit=1G $(which wp) import big-export.xml --authors=create
COMPOSER_MEMORY_LIMIT=-1 composer update

Composer sam podnosi swój limit do 1,5 GB. Jeśli mimo to się wysypuje (1610612736 w komunikacie), zdejmij ograniczenie przez COMPOSER_MEMORY_LIMIT=-1, o ile serwer ma wystarczająco RAM. PHP 8.5 dodał dyrektywę max_memory_limit: jeśli administrator serwera ją ustawił, memory_limit nie może jej przekroczyć ani przez .user.ini, ani przez ini_set().

Ile pamięci ustawić

memory_limit to górna granica dla jednego procesu PHP, a nie pamięć, którą strona zajmuje cały czas. Większość żądań zużywa znacznie mniej; limit istnieje po to, by jeden niekontrolowany skrypt nie zajął całego serwera.

Nigdy nie ustawiaj memory_limit = -1 dla strony: błąd w kodzie mógłby wtedy zjeść całą dostępną pamięć i położyć całe konto albo serwer. Na VPS planuj najgorszy scenariusz: limit razy liczba procesów PHP-FPM. Typowy domyślny szablon panelu pozwala na maksymalnie 8 procesów na stronę (pm.max_children = 8), więc przy 256M jedna strona mogłaby teoretycznie zużyć 2 GB.

Jak znaleźć to, co zużywa pamięć

Jeśli zwykła strona potrzebuje więcej niż 256M, podniesienie limitu tylko odsuwa problem w czasie. Te cztery kroki zwykle pozwalają znaleźć winowajcę.

Krok 1. Znajdź wpis w logu

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );       // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // hides errors from visitors

Na serwerze z panelem błędy PHP często trafiają też do /var/log/apache2/domains/example.com.error.log lub /var/log/nginx/domains/example.com.error.log. To polecenie pokazuje, które pliki pojawiają się najczęściej:

grep -h "Allowed memory size" wp-content/debug.log /var/log/apache2/domains/example.com.error.log 2>/dev/null | grep -o "in /[^ ]*" | sort | uniq -c | sort -rn | head

Krok 2. Zmierz szczytowe zużycie pamięci

Query Monitor pokazuje szczytowe zużycie pamięci strony na pasku administracyjnym, a także zapytania SQL i wywołania HTTP w podziale na wtyczki. Na działającej stronie mała wtyczka mu-plugin zapisze w logu ciężkie żądania:

<?php
// wp-content/mu-plugins/memory-peak-log.php
register_shutdown_function( function () {
    $peak = memory_get_peak_usage( true ) / 1048576;
    if ( $peak > 96 ) {
        error_log( sprintf( '[memory] %.1f MB %s', $peak, $_SERVER['REQUEST_URI'] ?? 'cli' ) );
    }
} );

Po dniu lub dwóch log pokaże, które adresy URL zbliżają się do limitu: wyszukiwarka, filtry katalogu, admin-ajax.php albo REST API którejś wtyczki. Gdy skończysz, usuń plik.

Krok 3. Wyłącz wtyczki i zmień motyw

wp plugin list --status=active    # save the list first
wp plugin deactivate --all
wp plugin activate woocommerce    # re-enable one at a time, testing the page
wp theme activate twentytwentyfive  # or another installed default theme

Bez SSH zmień nazwę katalogu wp-content/plugins w menedżerze plików. Wtyczka Health Check & Troubleshooting potrafi też wyłączyć wtyczki tylko dla Twojej sesji, więc odwiedzający niczego nie zauważą.

Krok 4. Sprawdź opcje autoload i ciężkie zapytania

Opcje ładowane automatycznie (autoload) trafiają do pamięci przy każdym żądaniu, a pozostałości po usuniętych wtyczkach potrafią rozdmuchać je do kilku megabajtów. Od WordPressa 6.6 Kondycja witryny ostrzega, gdy przekraczają 800 KB. Ich sprzątanie to część regularnej optymalizacji bazy danych na hostingu:

wp option list --autoload=on --format=total_bytes
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY bytes DESC LIMIT 10;"

Zamień wp_ na prefiks swoich tabel. W kodzie własnego motywu szukaj 'posts_per_page’ => -1, co ładuje do pamięci każdy wpis razem z metadanymi.

Typowe przyczyny w WordPressie

• Kreatory stron i ciężkie motywy. Sam Elementor wymaga co najmniej 256 MB, a każdy pakiet dodatków dokłada swoje.
• WooCommerce z dużym katalogiem: raporty, eksport zamówień, masowa edycja produktów, filtry.
• Importy i eksporty tysięcy wierszy w jednym żądaniu. Podziel plik albo uruchom import przez WP-CLI.
• Wtyczki do kopii zapasowych, które budują archiwa w PHP. Kopie na poziomie serwera lub przez cron są bezpieczniejsze.
• Duże obrazy. GD trzyma w pamięci każdy piksel jako 4 bajty, więc zdjęcie 6000 × 4000 pikseli potrzebuje około 96 MB, zanim powstanie jakakolwiek miniatura. Przed wysłaniem zmniejszaj zdjęcia do 2560 px na dłuższym boku: to big_image_size_threshold, od którego WordPress sam zaczyna pomniejszać obrazy.
• Skanery bezpieczeństwa i wtyczki podobnych wpisów, które w jednym przebiegu przechodzą przez każdy plik albo wpis.
• Błędy w kodzie: nieskończone pętle, rekurencja, tablice rosnące wewnątrz pętli.

Hosting współdzielony czy VPS: gdy limitu nie da się podnieść

Na hostingu współdzielonym memory_limit obowiązuje na proces, ale dostawca zwykle ogranicza też łączną pamięć konta. Gdy kilka procesów jednocześnie używa po 256 MB, trafiasz na ten limit i zamiast tego widzisz błędy 500, 503 lub 508. Zobacz, jak działa hosting współdzielony i jak cache i RAM wpływają na szybkość. Co możesz zrobić: ustawić memory_limit w .user.ini lub w ustawieniach PHP w panelu, włączyć cache stron, ograniczyć liczbę wtyczek, przenieść importy i kopie zapasowe do crona lub WP-CLI oraz przejść na większy plan albo VPS, jeśli pamięci stale brakuje.

Na VPS sam kontrolujesz php.ini, pule i liczbę procesów. Pilnuj, by „memory_limit × pm.max_children” dla wszystkich stron plus MySQL i system operacyjny mieściło się poniżej całkowitej ilości RAM. Rzeczywisty średni rozmiar procesu PHP-FPM:

ps -C php-fpm8.3 -o rss= | awk '{s+=$1; n++} END {print s/n/1024 " MB"}'

Najczęstsze pytania

Czy mogę ustawić memory_limit = -1?

Dla jednorazowego zadania CLI na własnym serwerze tak. Dla strony nie: niekontrolowany skrypt zużyłby całą pamięć i położył całą stronę albo serwer, zamiast zakończyć się błędem sam.

Dlaczego WP_MEMORY_LIMIT w wp-config.php nie działa?

Zwykle z jednego z trzech powodów: stała jest zdefiniowana po załadowaniu wp-settings.php, hosting zablokował limit przez php_admin_value albo Twoja wartość nie jest wyższa od bieżącego limitu PHP. WordPress tylko podnosi limit, nigdy go nie obniża.

Dlaczego błąd pojawia się tylko w kokpicie lub podczas aktualizacji?

Tam odbywa się najcięższa praca: rozpakowywanie aktualizacji, przetwarzanie obrazów, importy, kreatory stron. Jeśli hosting nie pozwala WordPressowi podnieść limitu do WP_MAX_MEMORY_LIMIT, pamięci brakuje właśnie w tych miejscach.

Czy wyższy memory_limit przyspieszy stronę?

Nie. To tylko górna granica dla jednego procesu. Jeśli Twój WordPress działa wolno, pomogą cache stron, OPcache i szybki dysk; na VPS zawyżony limit tylko zwiększa ryzyko, że zabraknie RAM.

Czy OPcache i Redis wliczają się do memory_limit?

Nie. OPcache korzysta z osobnej pamięci współdzielonej (opcache.memory_consumption), a Redis czy Memcached działają jako oddzielne usługi. Liczy się tylko pamięć, którą skrypt PHP przydziela podczas żądania, w tym dane pobrane z cache.

Podsumowanie

Allowed memory size exhausted oznacza, że skrypt dotarł do swojego limitu pamięci. Podnieś memory_limit do 256M w sposób, który obsługuje Twój serwer (.user.ini przy PHP-FPM, php.ini lub pula na VPS, do tego WP_MEMORY_LIMIT), sprawdź, czy nowa wartość jest aktywna, a jeśli pamięci nadal brakuje, znajdź winowajcę za pomocą logu, Query Monitor i wyłączania wtyczek po kolei. Jeśli Twoja strona wyrosła z obecnych zasobów, porównaj plany hostingu współdzielonego RichHost z dyskami NVMe i własnym panelem sterowania z asystentem AI albo sprawdź, na co zwrócić uwagę przy wyborze hostingu dla WordPressa.