Przejdź do treści
Konfiguracja

Jak naprawić błąd "Allowed Memory Size Exhausted" w WordPress

Jeśli Twoja witryna wyświetla Fatal error: Allowed memory size of 268435456 bytes exhausted, dodaj tę linię do wp-config.php powyżej komentarza / That's all, stop editing! /

Opublikowano

Jeśli Twoja witryna wyświetla Fatal error: Allowed memory size of 268435456 bytes exhausted, dodaj tę linię do wp-config.php powyżej komentarza /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. To przywraca większość witryn do działania w niecałą minutę. Przeczytaj jednak resztę tej strony, zanim odejdziesz od komputera, ponieważ podniesienie limitu to diagnostyka, a nie leczenie. Jeśli awaria wraca przy wyższej wartości, prawdziwym problemem jest kod, który zużywa pamięć bez ograniczeń, a wyższy pułap tylko daje mu więcej luzu.

Co ten błąd tak naprawdę oznacza

PHP śledzi, ile pamięci przydzieliło każde żądanie. Gdy pojedyncze żądanie próbuje przydzielić więcej niż memory_limit ustawiony w php.ini (lub nadpisany przez WordPress), PHP natychmiast zabija żądanie fatalnym błędem i wypisuje liczbę bajtów, przy której padło. 268435456 bytes to 256M. 134217728 to 128M. 536870912 to 512M. Liczba po “tried to allocate” mówi o rozmiarze ostatniej kropli, a nie o rozmiarze samego problemu.

WordPress nakłada własne limity na te z PHP. WP_MEMORY_LIMIT (domyślnie 40M lub limit PHP, jeśli jest wyższy) zarządza front-endem. WP_MAX_MEMORY_LIMIT (domyślnie 256M) zarządza operacjami po stronie panelu administracyjnego, takimi jak biblioteka mediów czy aktualizacje wtyczek, które faktycznie potrzebują więcej. WordPress wywołuje ini_set('memory_limit', ...) przy ładowaniu na podstawie tych stałych — ale tylko wtedy, gdy hosting zezwala na ini_set, i tylko do twardego limitu ustawionego przez hosting. Ta ostatnia część jest powodem, dla którego edycja wp-config.php czasami zdaje się nic nie dawać.

Napraw to, po kolei

1. Podnieś limit WordPress w wp-config.php. To pierwsza rzecz do wypróbowania, ponieważ jest odwracalna i nie rusza niczego innego.

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

Jeśli nie masz pewności, gdzie umieścić te linie, lub chcesz przy okazji poprawnie ustawić pozostałe popularne stałe, nasz generator wp-config wygeneruje czysty blok, który możesz wkleić. Umiejscowienie ma znaczenie — wszystko poniżej linii “stop editing” jest ignorowane.

2. Jeśli to nic nie daje, to hosting ogranicza PHP. Podnieś memory_limit na poziomie PHP. W php.ini:

memory_limit = 256M

Na wielu hostingach współdzielonych nie możesz bezpośrednio edytować php.ini. Spróbuj zamiast tego pliku .user.ini w katalogu głównym witryny lub ustaw wartość przez .htaccess na konfiguracji Apache/mod_php:

php_value memory_limit 256M

Zwróć uwagę, że php_value w .htaccess wyrzuca błąd 500 na nginx lub na konfiguracjach PHP-FPM, ponieważ jest to dyrektywa Apache/mod_php. Jeśli po jej dodaniu dostajesz błąd 500, to właśnie dlatego — usuń ją i użyj .user.ini.

3. Sprawdź wartość, która faktycznie działa. Nie ufaj temu, co edytowałeś; ufaj temu, co raportuje PHP. Umieść jednolinijkowy plik w katalogu głównym witryny:

<?php echo ini_get('memory_limit');

Wczytaj go w przeglądarce, odczytaj wartość, a następnie usuń plik. Jeśli wciąż pokazuje 128M po tym, jak ustawiłeś 256M, hosting Cię nadpisuje i musisz się z nim skontaktować albo użyć ustawienia w jego panelu.

Część, którą większość poradników pomija

Podnoszenie limitu to diagnostyka. Oto jak odczytać wynik.

Jeśli ustawisz 256M i witryna działa stabilnie przy normalnym ruchu, miałeś uzasadniony pułap, który był zbyt niski — częste na witrynach z dużymi bibliotekami mediów, WooCommerce lub kreatorami stron. Gotowe.

Jeśli ustawisz 256M i znów pada, potem 512M i znów pada, przestań podnosić. Normalne żądanie WordPress nie potrzebuje 512M. Gdy zużycie pamięci rośnie bez pułapu, coś się zapętla lub kumuluje: wtyczka ładująca całą tabelę bazy danych do tablicy, add_action, który rekurencyjnie wyzwala sam siebie, procedura importu trzymająca w pamięci naraz każdy wiersz albo dwie wtyczki walczące ze sobą wewnątrz tego samego haka. Podniesienie limitu nie naprawia niekończącej się pętli — tylko przesuwa awarię o kilka sekund później i utrudnia jej odtworzenie.

Aby znaleźć winowajcę, wyłącz wszystkie wtyczki i przełącz się na domyślny szablon, taki jak Twenty Twenty-Four. Jeśli błąd zniknie, włączaj wtyczki po jednej, aż wróci. Włącz dziennik debugowania, aby wychwycić, gdzie padło:

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

Fatalna linia w wp-content/debug.log wskazuje plik i numer linii, które przydzieliły ostatni fragment pamięci. To zwykle sama pętla lub coś oddalonego od niej o jedno wywołanie funkcji.

Czego nie robić

Nie ustawiaj WP_MEMORY_LIMIT na -1 ani 1024M i nie zapominaj o tym. Nieograniczona pamięć nie naprawia wycieku; pozwala rozbieganemu żądaniu zjeść cały serwer, co może położyć każdą inną witrynę na tej samej maszynie i ściągnąć Ci telefon od hostingu. Pułap to funkcja bezpieczeństwa. Zachowaj go.

Nie wklejaj ini_set('memory_limit', '512M') do functions.php jako głównego rozwiązania. Uruchamia się on zbyt późno przy niektórych awariach — jeśli awaria następuje podczas ładowania rdzenia WordPress, zanim wykona się functions.php Twojego szablonu, ta linia nigdy się nie uruchomi. wp-config.php ładuje się wcześniej i jest właściwym miejscem.

Nie zakładaj, że to problem hostingu, i nie zmieniaj planu na wyższy. Czasami hosting jest naprawdę niewymiarowy. Często jednak dokładnie ta sama awaria podąża za Tobą na większy plan, ponieważ przyczyna przywędrowała razem z Twoimi wtyczkami. Najpierw wyklucz pętlę; to nic nie kosztuje.

Nie podnoś memory_limit, aby naprawić błąd max_execution_time. To różne limity z różnymi komunikatami. Wyczerpanie pamięci mówi “Allowed memory size … exhausted.” Przekroczenie czasu mówi “Maximum execution time … exceeded.” Podniesienie niewłaściwego marnuje całe popołudnie.

Wciąż utknąłeś?

Jeśli potwierdziłeś, że działający limit to faktycznie 256M lub więcej, przetestowałeś z wszystkimi wtyczkami wyłączonymi i domyślnym szablonem, a pamięć nadal się wyczerpuje, masz prawdziwy wyciek wart wytropienia w dzienniku debugowania, a nie pułap wart podnoszenia. Uchwyć fatalną linię, zanotuj, do katalogu której wtyczki wskazuje, i to jest Twoje zgłoszenie błędu. Najpierw ustaw poprawnie bazowe stałe w wp-config.php za pomocą generatora wp-config, abyś wiedział, że limity są ustawione tam, gdzie myślisz — a potem idź czytać dziennik.