WordPress Bellek Sınırı Hatası Nasıl Çözülür?

WordPress bellek sınırı hatasını çözmek için önce PHP'nin gerçek memory_limit değerini ve hatayı üreten işlemi belirleyin; ardından wp-config.php, php.ini veya .user.ini üzerinden kontrollü bir artış yapın. Belleği yükseltmek tek başına yeterli değildir: ağır eklenti, PHP-FPM süreç sayısı ve VPS'in toplam RAM kullanımı da ölçülmelidir.

WordPress bellek sınırı hatası ne anlama gelir?

WordPress bellek sınırı hatası, bir PHP isteğinin kendisine ayrılan memory_limit değerini aşmasıyla oluşur. Ekranda genellikle Allowed memory size of ... bytes exhausted mesajı görünür. Düşük PHP belleği, ağır bir eklenti, tema kodu, büyük bir işlem veya aynı anda çalışan PHP-FPM süreçlerinin VPS kaynaklarını tüketmesi bu hatayı tetikleyebilir.

Bu mesaj doğrudan sunucuda RAM kalmadığını söylemez. PHP’nin tek bir istek için izin verilen üst sınırı aşılmış olabilir; işletim sisteminde hâlâ boş RAM bulunabilir. Bu ayrımı yapmadan yalnızca VPS RAM’ini artırmak, asıl nedeni gizler.

Hata mesajındaki iki değer nasıl okunur?

Örnek bir PHP hatası şöyle görünebilir:

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 40960 bytes)

268435456 bayt, 256 MiB değerine karşılık gelir. PHP 256 MiB sınırına ulaşmış ve yalnızca 40 KiB daha ayırmaya çalışırken işlemi durdurmuştur. Buradaki tried to allocate değeri toplam kullanılan belleği değil, son başarısız tahsisin boyutunu gösterir.

WordPress tarafındaki WP_MEMORY_LIMIT ve WP_MAX_MEMORY_LIMIT sabitleri, PHP’nin izin verdiği değerin üzerinde bir sınır oluşturamaz. PHP yapılandırmasındaki memory_limit daha düşükse WordPress’in istediği değer uygulanmayabilir.

Hemen kontrol edin – Hata mesajındaki byte değerini MiB’ye çevirin ve PHP’nin gerçek memory_limit değerini ayrıca doğrulayın.

Önce mevcut PHP bellek sınırını nasıl öğrenirsiniz?

WordPress yönetim panelinde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümüne giderek PHP sürümünü ve bellek sınırını görebilirsiniz. Paneldeki değer, web isteğini karşılayan PHP SAPI’sine aittir; SSH üzerinden çalıştırılan php -i çıktısıyla her zaman aynı olmayabilir.

Komut satırında ilk kontrol için şu komut kullanılabilir:

php -r 'echo "memory_limit=" . ini_get("memory_limit") . PHP_EOL;'

Bu komut CLI yapılandırmasını gösterir. Web sitesi PHP-FPM kullanıyorsa CLI ile FPM farklı php.ini dosyalarından çalışabilir.

Debian ve Ubuntu tabanlı sistemlerde yüklü PHP sürümlerini görmek için:

php -v
php --ini
systemctl list-units --type=service 'php*-fpm.service'

php --ini çıktısı ana yapılandırma dosyasının yolunu verir. FPM servisinin adı sürüme göre php8.2-fpm veya php8.3-fpm olabilir. Servis adını varsaymak yerine systemctl çıktısıyla doğrulamak gerekir.

Web tarafındaki gerçek değeri görmek için geçici bir PHP dosyasında ini_get('memory_limit') kullanılabilir. Dosyayı testten hemen sonra silin; phpinfo() çıktısı sürüm, yol ve ortam bilgilerini gereğinden fazla açığa çıkarabilir.

WordPress’in hangi sınırı kullandığını görmek için WP-CLI yüklüyse:

wp eval 'echo WP_MEMORY_LIMIT . PHP_EOL . WP_MAX_MEMORY_LIMIT . PHP_EOL;'

Komut, WordPress’in tanımladığı değerleri gösterir. PHP’nin gerçek sınırını ayrıca incelemeden bu çıktıyı tek başına yeterli kabul etmeyin.

Değeri karşılaştırın – CLI, PHP-FPM ve WordPress katmanlarının bellek değerlerini ayrı ayrı kaydedin.

wp-config.php ile WordPress bellek sınırı artırılır mı?

WordPress’in wp-config.php dosyasında iki sabit yaygın biçimde kullanılır:

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

WP_MEMORY_LIMIT normal site istekleri için, WP_MAX_MEMORY_LIMIT ise yönetim paneli ve bazı arka plan işlemleri için hedef değeri belirtir. Satırları, dosyadaki That's all, stop editing! yorumundan önce ekleyin. Aynı sabit daha önce tanımlanmışsa ikinci bir define satırı eklemek yerine mevcut satırı düzenleyin.

Bu değerler sihirli bir RAM artışı sağlamaz. PHP’nin memory_limit değeri 128M ise WordPress’in 512M istemesi çoğu kurulumda etkili olmaz. Hosting sağlayıcısı veya PHP yapılandırması ini_set kullanımını da kısıtlayabilir.

Dosyayı değiştirmeden önce yedek alın ve sözdizimini doğrulayın. WP-CLI bulunan ortamlarda:

cp wp-config.php wp-config.php.bak
php -l wp-config.php

php -l yalnızca PHP sözdizimini kontrol eder; WordPress’in doğru dosyadan yüklendiğini garanti etmez. Yanlış bir kopyayı düzenlememek için önce sitenin kök dizinini ve dosyanın sahipliğini kontrol edin.

WordPress’in resmi geliştirici belgelerinde bu sabitler için belirli bir evrensel değer önerilmez. Siteye, eklentilere ve sunucu kapasitesine göre ölçüm yapmak gerekir. 256M bazı içerik sitelerinde yeterli olabilirken, görsel işleme veya büyük içe aktarma işlemleri daha yüksek geçici bellek isteyebilir.

Dosyayı kontrollü değiştirin – Önce yedek alın, tek bir değer değiştirin ve yönetim panelindeki işlemi yeniden deneyin.

PHP memory_limit değeri nasıl artırılır?

WordPress sabitleri etkili olmadığında PHP katmanını inceleyin. Değişiklik yöntemi, sunucunun PHP’yi Apache modülü, PHP-FPM veya farklı bir panel aracılığıyla çalıştırmasına göre değişir.

php.ini üzerinden ayarlama

PHP-FPM için kullanılan php.ini dosyasını php --ini ile bulabilirsiniz; fakat bu komut CLI dosyasını gösterebilir. FPM yapılandırma yolunu servis ve dağıtım belgeleriyle doğrulayın. Satır örneği:

memory_limit = 256M

Değişiklikten sonra ilgili FPM servisini yeniden yükleyin veya yeniden başlatın:

sudo systemctl restart php8.2-fpm
sudo systemctl reload nginx

Buradaki PHP sürümünü sisteminizde kurulu sürümle değiştirin. Sürümü kontrol etmeden php8.2-fpm yazmak, olmayan bir servisi yeniden başlatmaya çalışır.

.user.ini ve kontrol paneli

Paylaşımlı hosting veya sınırlı VPS ortamlarında .user.ini dosyası kullanılabilir:

memory_limit = 256M

PHP-FPM, .user.ini değişikliklerini hemen okumayabilir. user_ini.cache_ttl değerine bağlı olarak birkaç dakika beklemek gerekebilir. cPanel, Plesk veya benzeri bir panel kullanılıyorsa aynı ayarın PHP seçenekleri ekranından yapılması daha güvenlidir.

Apache kullanılan bazı ortamlarda .htaccess içinde php_value memory_limit 256M çalışabilir; PHP-FPM veya CGI kurulumlarında ise 500 hatasına yol açabilir. Web sunucusunun çalışma modelini bilmeden bu satırı eklemeyin.

Hangi eklenti veya tema belleği tüketiyor?

Bellek sınırını artırmak semptomu geçici olarak azaltabilir. Kalıcı çözüm için hatanın hangi istekte oluştuğunu bulmak gerekir. Yedekleme, görsel yeniden boyutlandırma, XML/CSV içe aktarma, sayfa oluşturucu ve e-ticaret eklentileri büyük veri kümeleriyle çalışabilir.

Önce WordPress hata günlüğünü kontrollü biçimde açın:

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

Hatalar genellikle wp-content/debug.log dosyasına yazılır. Üretim sitesinde WP_DEBUG_DISPLAY değerini true yapmak hata ayrıntılarını ziyaretçilere gösterebilir. Test tamamlanınca hata ayıklamayı kapatın veya loglama politikanıza göre yönetin.

Log içinde eklenti veya tema yolunu arayın:

grep -nEi 'Allowed memory size|memory exhausted|wp-content/plugins|wp-content/themes' wp-content/debug.log | tail -n 50

Örneğin /wp-content/plugins/example-plugin/ yolu tekrar tekrar görünüyorsa eklenti güçlü bir adaydır; yine de tek satırın kesin kök neden olduğunu varsaymayın. Aynı işlem bir cron görevi, REST isteği veya yönetim paneli çağrısı tarafından tetikleniyor olabilir.

İzolasyon için staging ortamında eklentileri tek tek devre dışı bırakın. WP-CLI ile:

wp plugin list --status=active
wp plugin deactivate eklenti-klasoru

Üretim ortamında tüm eklentileri bir anda kapatmak ödeme, önbellek veya güvenlik katmanlarını bozabilir. Önce snapshot ya da doğrulanmış yedek alın; ardından kısa bir bakım penceresi planlayın.

WordPress için VPS kurulum adımlarını incelerken PHP sürümü, FPM servisi ve dosya sahipliğini de aynı tabloya ekleyin. Yalnızca uygulama katmanını değiştirip işletim sistemi kaynaklarını izlememek teşhisi eksik bırakır.

İzolasyon testi yapın – Eklenti ve temayı staging ortamında sırayla devre dışı bırakıp her adımda aynı isteği yeniden çalıştırın.

PHP-FPM süreçleri ve sunucu RAM’i nasıl kontrol edilir?

PHP’nin tek istek sınırı ile VPS’in toplam RAM’i farklı konulardır. PHP-FPM’de pm.max_children değeri aynı anda çalışabilecek PHP süreçlerinin sayısını sınırlar. Her sürecin gerçek RSS belleği ölçülmeden yüksek bir değer vermek swap kullanımına ve 502 hatalarına yol açabilir.

free -h
ps -eo pid,ppid,rss,cmd --sort=-rss | head -n 15
systemctl status php8.2-fpm --no-pager

rss değeri KiB cinsindendir. Örneğin en yoğun 10 PHP sürecinin her biri yaklaşık 180 MiB kullanıyorsa pm.max_children = 20 teorik olarak 3,6 GiB civarında bellek isteyebilir; işletim sistemi, veritabanı ve web sunucusu için ayrılacak pay buna dahil değildir.

PHP-FPM havuzu için kaba bir kapasite hesabı yapılabilir:

Güvenli max_children ≈ PHP'ye ayrılabilir RAM / bir PHP sürecinin ortalama RSS değeri

Bu yalnızca başlangıç tahminidir. Yoğun saatlerde ps, FPM durum metrikleri ve monitoring verileriyle doğrulanmalıdır. free -h çıktısında kullanılabilir bellek düşüyor, swap sürekli büyüyor veya kernel loglarında OOM mesajları görülüyorsa yalnızca memory_limit artırmak doğru yaklaşım değildir.

Linux işlem kaynaklarını incelemek için Linux’ta İşlem Yönetimi: ps, top ve kill Kullanımı yazısındaki komutlardan yararlanabilirsiniz. Bellek baskısı sırasında rastgele kill -9 çalıştırmak yerine önce hangi servisin süreç ürettiğini belirleyin.

256M mi, 512M mi? Değer seçimi nasıl yapılır?

Her WordPress kurulumu için geçerli tek bir bellek değeri yoktur. Değer seçerken sitenin normal sayfa isteğiyle ağır yönetim işlemini ayırın.

Tablodaki aralıklar zorunlu gereksinim değil, teşhis için başlangıç noktasıdır. WordPress, PHP veya bir eklenti için 512M her zaman gereklidir şeklinde genel bir kural bulunmaz.

Örneğin yalnızca medya yükleme sırasında hata alınıyorsa görsel boyutları, ImageMagick/GD işlemleri ve PHP çalışma süresi birlikte incelenmelidir. Yönetim panelinde sorun yokken ön yüzde hata varsa tema şablonu, sorgu sayısı veya cache katmanı daha olası adaylardır.

Artışı ölçerek sınırlayın – Belleği bir anda 1G yapmayın; küçük bir artıştan sonra RSS, swap ve hata loglarını yeniden değerlendirin.

WordPress bellek hatası devam ederse ne kontrol edilmeli?

Değer artırıldığı halde hata sürüyorsa aşağıdaki katmanları sırayla inceleyin:

• Yanlış PHP SAPI: CLI’da 512M görünürken PHP-FPM 128M ile çalışıyor olabilir.
• Yanlış dosya: Birden fazla WordPress kurulumu veya staging dizini bulunabilir.
• Yapılandırma kısıtı: Hosting hesabı, PHP direktifini değiştirmeyi engelleyebilir.
• PHP sürümü: Eklenti gereksinimleri ve kullanılan uzantılar sürümle uyumsuz olabilir.
• Gerçek RAM baskısı: FPM, MariaDB ve web sunucusu aynı anda belleği tüketebilir.
• Bozuk kod: Sonsuz döngü veya sınırsız dizi büyümesi bellek limitini hızla doldurabilir.

Nginx logları, PHP-FPM logları ve WordPress logunu aynı zaman aralığında karşılaştırın. HTTP 502 görülüyorsa yalnızca WordPress’e odaklanmayın; upstream PHP-FPM sürecinin öldürülmesi veya zaman aşımı da araştırılmalıdır. Bu ayrımı 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? başlığındaki katman yaklaşımıyla birlikte değerlendirebilirsiniz.

Disk alanı da kontrol edilmelidir. Log yazılamayan, geçici dosya oluşturamayan veya inode’ları tükenen bir sistem farklı belirtiler üretebilir:

df -h
df -i
journalctl -u php8.2-fpm --since "1 hour ago" --no-pager

Disk doluluğu bellek hatasının kendisi değildir; fakat teşhis loglarının kaybolmasına ve PHP süreçlerinin beklenmedik davranmasına neden olabilir.

Katmanları ayırın – WordPress, PHP-FPM, web sunucusu, işletim sistemi ve disk durumunu aynı zaman aralığında karşılaştırın.

Kaynak tüketimini kalıcı olarak nasıl azaltırsınız?

Kalıcı çözüm çoğu zaman daha büyük bir sayı yazmak değil, ağır işlemi küçültmektir. Kullanılmayan eklentileri kaldırın; yalnızca devre dışı bırakmak, dosyaları ve güncelleme yükünü sistemden silmez. Eklentileri güncel tutun, fakat güncellemeyi önce staging ortamında test edin.

Görselleri yüklemeden önce uygun boyuta indirin. Büyük CSV içe aktarmalarını tek bir dev PHP isteği yerine parçalara bölün. WP-Cron yoğun çalışıyorsa gerçek sistem cron’u ile kontrollü bir zamanlama kullanmayı ve aynı görevin paralel çalışmasını engellemeyi değerlendirin.

Sayfa cache’i, PHP OPcache ve veritabanı sorgu analizi de önemlidir. Cache kurmadan TTFB değerini milisaniye hassasiyetinde tartışmak, asıl yükü yanlış yerde aramaktır. Cache kullanımı bellek hatasını her zaman çözmez; tekrarlanan PHP isteklerini azaltarak süreç başına baskıyı düşürebilir.

VPS kaynakları yetersizse CPU, RAM, disk I/O ve swap verilerini birlikte izleyin. Sadece RAM yükseltmek, hatalı bir eklentinin her istekte büyüyen belleğini düzeltmez. Uygulama davranışı düzeltilmeden daha büyük sunucuya taşınan sorun, bir süre sonra daha pahalı biçimde geri döner.

Bir bellek değişikliğinden sonra en azından yoğun saatleri kapsayan monitoring verisini saklayın. Uptime Kuma erişilebilirliği gösterir; PHP-FPM süreç sayısı, RAM ve swap için Prometheus gibi metrik kaynakları gerekir.

Değişiklik Yapmadan Önce Şunları Kontrol Edin

• Hata mesajındaki toplam bellek değerini MiB olarak hesaplayın.
• CLI ile PHP-FPM bellek değerlerinin aynı olup olmadığını doğrulayın.
• wp-config.php dosyasını düzenlemeden önce yedekleyin.
• Hatanın oluştuğu eklenti, tema veya işlemi loglardan belirleyin.
• Değişikliği önce staging ortamında test edin.
• PHP-FPM süreçlerinin RSS, swap ve toplam RAM kullanımını izleyin.
• İşlem tamamlanınca debug loglamasını ve geçici bellek artışını gözden geçirin.

Sık Sorulan Sorular

Kaynaklar

• WordPress Developer Resources – wp-config.php — developer.wordpress.org
• WordPress Developer Resources – Debugging WordPress — developer.wordpress.org
• PHP Manual – Core php.ini Directives — php.net
• PHP Manual – PHP-FPM Configuration — php.net