Allowed Memory Size Exhausted Hatası Nedir, Nasıl Çözülür?

Bir ürün içe aktarma işlemi başlatıyorsunuz, sayfa yarıda kalıyor ve ekranda tek satırlık bir cümle beliriyor: Fatal error: Allowed memory size of 134217728 bytes exhausted. PHP bellek limiti hatası tam olarak bunu söyler — çalışan betik, kendisine ayrılmış bellek tavanına dayanmış ve PHP onu öldürmüştür. Site komple çökmez, sadece o istek ölür; bu yüzden ana sayfa gayet iyi açılırken yalnızca eklenti güncellemesi, WooCommerce ürün senkronizasyonu ya da yedek alma işlemi patlar. Hatanın en can sıkıcı tarafı da budur: sorun aralıklı göründüğü için insanlar günlerce yanlış yerde arar.

Bu yazıda iki şeyi ayrı ayrı ele alacağız. Birincisi, memory_limit değerinin bu sunucuda tam olarak nerede tanımlı olduğu ve hangi katmanın hangisini ezdiği — çünkü Türkçe kaynakların büyük kısmı "php.ini'yi düzenleyin" deyip bırakıyor ve paylaşımlı hostingte bu dosyayı düzenleyen kullanıcı hiçbir değişiklik göremiyor. İkincisi, limiti 256M'ye çıkardığınız hâlde aynı hatanın devam etmesinin ne anlama geldiği: o noktadan sonra elinizde bir limit sorunu değil, büyük ihtimalle sonsuz döngü ya da kontrolsüz büyüyen bir dizi vardır ve limiti artırmaya devam etmek sunucuyu daha da kötü duruma sokar.

Allowed Memory Size Exhausted Hatası Tam Olarak Ne Anlama Geliyor#

Hata, tek bir PHP isteğinin ayırabileceği azami RAM miktarının aşıldığını bildirir. Bu limit sunucunun toplam RAM'i değildir; istek başına bir tavandır. 8 GB RAM'li bir sunucuda memory_limit = 128M ise, sunucuda 7 GB boş RAM dururken bile 129 MB isteyen betik öldürülür. Amaç kasıtlıdır: kaçak bir betiğin tüm makineyi yutup diğer siteleri de düşürmesini engeller.

Hata mesajı üç bilgi taşır ve üçü de işinize yarar:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /home/kullanici/public_html/wp-includes/wp-db.php on line 2056

• 134217728 bytes → aktif limit. 1048576'ya bölün: 128 MB. Ayarladığınızı sandığınız değer bu değilse, düzenlediğiniz dosya okunmuyor demektir.
• tried to allocate 20480 bytes → son damla. 20 KB'lık küçük bir ayırma isteğinde patlıyorsa bellek zaten doluydu; tek seferde 100 MB istendiği bir satırda patlıyorsa (tried to allocate 104857600 bytes) suçlu doğrudan o satırdır.
• Dosya yolu ve satır numarası → suçlu değil, kurban. wp-db.php bellek sızdırmaz; oraya kadar birikmiş yükün son adımını orada yapmıştır. Bu ayrımı yapmamak, insanların WordPress çekirdek dosyalarını değiştirmeye kalkmasının başlıca sebebidir.

Hata Nerede Görünür: Ekranda Yoksa Log'a Bakın#

Hata çoğu zaman ekranda görünmez. display_errors kapalıysa ziyaretçi bomboş beyaz sayfa ya da 500 hatası görür. Bu durumda hatayı log dosyasından okumanız gerekir:

# cPanel hesabında en yaygın konumlar
tail -n 50 ~/public_html/error_log
tail -n 50 ~/logs/error_log

# Kendi sunucunuzda PHP-FPM kullanıyorsanız
tail -n 100 /var/log/php-fpm/www-error.log
journalctl -u php8.2-fpm --since "10 minutes ago"

# Nginx erişim/hata günlüğü
tail -n 100 /var/log/nginx/error.log

Beyaz ekranla karşılaşıyorsanız hatayı geçici olarak görünür kılmak için php hata raporlama ayarlarını gözden geçirin; canlıda display_errors açık bırakmayın, log'a yazdırıp okuyun. WordPress'te wp-config.php içine geçici olarak şunu ekleyebilirsiniz:

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

Bu ayar hatayı wp-content/debug.log dosyasına yazar ve ziyaretçiye hiçbir şey göstermez. İş bittiğinde üçünü de kaldırın.

memory_limit Nerede Tanımlı: Katmanlar ve Ezme Sırası#

Yıllardır gördüğüm en yaygın zaman kaybı burada yaşanıyor: kullanıcı bir dosyayı düzenliyor, değeri kaydediyor, hiçbir şey değişmiyor ve "hosting izin vermiyor" sonucuna varıyor. Gerçekte değişiklik yapılmıştır ama daha üstteki bir katman onu eziyordur. Sıralama şudur — aşağıdaki tablo yukarıdan aşağıya doğru güçlenir, yani en alttaki satır diğerlerini geçersiz kılar:

Kritik ayrım şudur: FPM havuzunda php_admin_value[memory_limit] = 128M yazıyorsa, .user.ini, .htaccess ve ini_set() tamamen etkisiz kalır. Buna karşılık php_value[memory_limit] yazıyorsa uygulama katmanı onu yükseltebilir. Paylaşımlı hostingte sağlayıcı genelde php_admin_value kullanır; bu yüzden pakette tanımlı tavanın üstüne çıkamazsınız ve çıkamamanız normaldir.

İkinci kritik ayrım da PHP'nin çalışma modudur. .htaccess içindeki php_value satırı yalnızca Apache mod_php ile çalışır. Sunucu PHP-FPM ya da LiteSpeed ile çalışıyorsa aynı satır ya hiçbir şey yapmaz ya da doğrudan 500 Internal Server Error üretir. .htaccess'e php_value yazınca site tamamen çöküyorsa teşhis budur — 500 internal server error çözümü yazısında bu senaryoyu ayrıca ele alıyoruz.

Aktif Değeri Ölçün, Tahmin Etmeyin#

Herhangi bir düzenleme yapmadan önce şu anda geçerli olan değeri okuyun. Bunun tek doğru yolu, sitenin çalıştığı ortamdan sormaktır. Web kökünde geçici bir dosya oluşturun:

<?php
// bellek-testi.php — işi bitince SİLİN
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;
echo 'Yuklenen ini: ' . php_ini_loaded_file() . PHP_EOL;
echo 'Ek ini dosyalari: ' . php_ini_scanned_files() . PHP_EOL;
echo 'SAPI: ' . php_sapi_name() . PHP_EOL;

Bu dört satır, kırk dakikalık tahmin turunu bitirir. SAPI çıktısı fpm-fcgi ise .htaccess yolunu unutun, .user.ini kullanın. apache2handler ise .htaccess çalışır. php_ini_loaded_file() size gerçekten okunan php.ini'nin tam yolunu verir — düzenlediğiniz dosya bu değilse, boşuna uğraşmışsınız demektir.

Komut satırına erişiminiz varsa dikkat: php -i | grep memory_limit çıktısı CLI ortamının değeridir ve web ortamından farklı olabilir. CLI genelde memory_limit = -1 (sınırsız) ile gelir; bu yüzden WP-CLI ile çalışan bir komut sorunsuz biterken aynı iş tarayıcıdan yapılınca patlar. Doğru karşılaştırma için FPM havuzunu sorun:

php-fpm8.2 -tt 2>&1 | grep -i memory
grep -R "memory_limit" /etc/php/8.2/fpm/

Limiti Katman Katman Nasıl Artırılır#

Aşağıdaki yolları yukarıdan aşağıya deneyin; ilki işe yarıyorsa diğerlerine dokunmayın.

1. cPanel / MultiPHP INI Editor. Paylaşımlı hostingteyseniz doğru yol budur. cPanel → Software → MultiPHP INI Editor → Basic Mode → alan adını seçin → memory_limit alanına 256M yazıp kaydedin. Bu ekran arka planda hesabınızın .user.ini dosyasını yazar, dolayısıyla FPM ile uyumludur. CloudLinux kurulu bir sunucudaysanız Select PHP Version → Options sekmesinde aynı değeri bulursunuz; oradaki tavan paket sınırınızdır ve listede daha yüksek bir değer yoksa artıramazsınız.

2. .user.ini (FPM/CGI). Panel yoksa web kökünde dosyayı elle oluşturun:

memory_limit = 256M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

⚠️ .user.ini anında etkili olmaz. PHP bu dosyayı user_ini.cache_ttl süresi kadar (varsayılan 300 saniye) önbellekte tutar. Değişiklik görünmüyorsa beş dakika bekleyin ya da FPM'i yeniden başlatın.

3. .htaccess (yalnızca mod_php). SAPI çıktınız apache2handler ise:

php_value memory_limit 256M

4. WordPress'e özel sabitler. wp-config.php içinde, /* That's all, stop editing! */ satırının üstüne:

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

Burada sık yapılan bir hata var: WP_MEMORY_LIMIT ön yüz için geçerlidir, WP_MAX_MEMORY_LIMIT ise yönetim paneli ve cron işleri içindir. Sadece ilkini artırıp panelde hâlâ hata alan çok kişi görüyorum. Ayrıca bu sabitler ini_set() çağırır; sunucu php_admin_value ile kilitlemişse hiçbir etkisi olmaz, sessizce yok sayılır.

5. Kendi sunucunuzda FPM havuzu. Root erişiminiz varsa doğru yer havuz dosyasıdır:

; /etc/php/8.2/fpm/pool.d/site.conf
php_admin_value[memory_limit] = 256M

sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

Kendi VDS'inizi yönetiyorsanız php memory limit yazısındaki havuz ayarları bölümü, hangi değerin kaç eşzamanlı isteğe karşılık geldiğini hesaplamanıza yardımcı olur.

256M'ye Çıkardım, Hata Devam Ediyor: Artık Limit Sorunu Yok#

Burası yazının asıl sebebi. Limiti iki katına çıkardığınızda hata kaybolmalıdır. Kaybolmuyorsa, ihtimallerin sıralaması şudur:

a) Değişiklik gerçekten uygulanmadı. Önce bunu eleyin: hata mesajındaki bayt sayısı hâlâ eski değeri mi gösteriyor? Allowed memory size of 134217728 yazıyorsa limit hâlâ 128M'dir, ayarınız okunmamıştır. Yukarıdaki bellek-testi.php ile doğrulayın.

b) Bayt sayısı arttı ama hata sürüyor. 268435456 bytes exhausted görüyorsanız ayar uygulanmış, betik 256 MB'ı da yemiştir. Normal bir web isteği 256 MB kullanmaz. Bu noktada elinizde büyük ihtimalle şunlardan biri vardır:

• Sonsuz ya da çok derin döngü. Bir while koşulu asla yanlışlanmıyordur, ya da iki fonksiyon birbirini çağırıyordur (özyineleme). Her tur bellekte yeni bir kare bırakır, limit ne olursa olsun dolar.
• Filtre/hook zinciri kendini tetikliyor. WordPress'te klasik senaryo: save_post içinde wp_update_post() çağırmak. Fonksiyon kendi kancasını yeniden tetikler ve döngü kapanmaz.
• Sorgu sonucu tamamen belleğe alınıyor. SELECT * FROM siparisler ile 400 bin satır çekip foreach ile dönmek. Satır sayısı arttıkça limit ne olursa olsun bir gün dolar.
• Görsel işleme. GD ile 6000×4000 piksel bir JPEG açmak, dosya 3 MB olsa bile bellekte piksel başına 4 bayt ile ~96 MB yer kaplar. Aynı anda birkaç boyut üretmek bunu katlar.

Ayrımı yapmanın pratik yolu: limiti artırdıktan sonra hatanın ne kadar sürede geldiğine bakın. Gerçek bir limit darlığında betik daha uzun süre çalışır ve genelde tamamlanır. Döngüde ise hata her seferinde neredeyse aynı sürede gelir; süre limitle orantılı artmaz. Aynı tabloyu süre tarafında da görürsünüz — maximum execution time exceeded hatası ile bellek hatası çoğu zaman aynı kaçak kodun iki farklı yüzüdür ve hangisinin önce dolduğu tamamen tesadüftür.

Bellek Tüketen Kodu Bulmak#

Şüpheyi kanıta çevirmenin birkaç ucuz yolu var.

Eklentileri sırayla devre dışı bırakın. Panele giremiyorsanız FTP ya da dosya yöneticisinden wp-content/plugins klasörünü plugins-kapali yapın; site açılırsa suçlu eklentilerdedir. Sonra klasörü geri adlandırıp eklentileri tek tek geri açın. Bu kaba yöntem, wordpress eklenti çakışması senaryolarının çoğunu on beş dakikada çözer.

Kod içinde ölçün. Şüphelendiğiniz döngünün içine geçici olarak koyun:

foreach ( $satirlar as $i => $satir ) {
    if ( $i % 500 === 0 ) {
        error_log( sprintf(
            'Satir %d — bellek: %.1f MB, zirve: %.1f MB',
            $i,
            memory_get_usage( true ) / 1048576,
            memory_get_peak_usage( true ) / 1048576
        ) );
    }
    // ... asıl iş
}

Log'da bellek her 500 satırda düzenli olarak artıyorsa veri birikiyordur; sabit kalıyorsa döngü zaten sorun değildir.

Veriyi parça parça işleyin. Kalıcı çözüm limiti artırmak değil, tek seferde belleğe alınan veriyi küçültmektir:

$sayfa = 0;
do {
    $satirlar = $wpdb->get_results( $wpdb->prepare(
        "SELECT id, baslik FROM {$wpdb->prefix}urunler ORDER BY id LIMIT %d OFFSET %d",
        500, $sayfa * 500
    ) );

    foreach ( $satirlar as $satir ) {
        islem_yap( $satir );
    }

    unset( $satirlar );
    $sayfa++;
} while ( ! empty( $satirlar ) );

Büyük dosyalar için de aynı mantık: file_get_contents() dosyanın tamamını belleğe alır, fgets() satır satır okur. 700 MB'lık bir CSV'yi ilkiyle açmaya çalışmak hiçbir limitle mümkün değildir.

Ne Zaman Limit Artırılmalı, Ne Zaman Kaynak Yükseltilmeli#

Karar için basit bir çerçeve:

Son satır önemli: memory_limit yüksekse ama sunucunun fiziksel RAM'i yetmiyorsa, aynı anda gelen 20 isteğin her biri 256 MB isteyince sunucu takas alanına düşer, sonra OOM killer devreye girer ve PHP-FPM süreçleri öldürülür. Bu tabloda tek bir istek değil, tüm site tekleyerek çalışır. Paylaşımlı pakette bu sınırı zaten sağlayıcı yönetir; kendi sunucunuzdaysanız free -h çıktısı ile pm.max_children değerini birlikte değerlendirmeniz gerekir. Toplam RAM'i sürekli sınırda gezen bir site için doğru çözüm limit oynatmak değil, paylaşımlı hosting kaynak limitleri yazısında anlattığımız üzere kaynak tarafını büyütmektir.

Sıkça Sorulan Sorular#

Allowed memory size exhausted hatası siteyi tamamen kapatır mı#

Hayır, yalnızca o isteği öldürür. Diğer sayfalar normal açılmaya devam eder çünkü limit istek başına uygulanır. Ancak hata ana sayfayı üreten kodda oluşuyorsa ziyaretçi beyaz ekran ya da 500 hatası görür ve pratikte site kapanmış gibi davranır. Hangi isteklerin etkilendiğini anlamak için sunucu hata günlüğüne bakıp hatanın hangi dosya yolunda tekrarladığını izleyin.

memory_limit değerini kaç yapmalıyım#

Modern bir WordPress kurulumu için 256M makul bir başlangıçtır, WooCommerce çalıştıran siteler için 384M da yaygındır. 128M bugün için düşüktür ve orta ölçekli bir eklenti setinde sınırda kalır. 512M'nin üzerine çıkmak neredeyse hiçbir zaman doğru cevap değildir; o noktada sorun limitte değil kodda olur ve artırmaya devam etmek yalnızca sunucunun toplam RAM'ini riske atar.

wp-config.php içine WP_MEMORY_LIMIT yazdım ama değişmedi#

Bu sabit ini_set() çağrısıyla çalışır ve sunucu limiti php_admin_value ile kilitlemişse sessizce yok sayılır. Ayrıca sabiti dosyanın en altına, "stop editing" yorumunun altına yazdıysanız WordPress o noktada değeri zaten okumuş olur ve yazdığınız satır geç kalır. Önce ini_get('memory_limit') çıktısıyla gerçek değeri ölçün; değişmiyorsa hosting panelinden veya FPM havuzundan artırmanız gerekir.

.htaccess dosyasına php_value yazınca site 500 hatası veriyor#

Sunucunuz PHP'yi mod_php ile değil, PHP-FPM veya LiteSpeed ile çalıştırıyor demektir. Bu modlarda Apache php_value direktifini tanımaz ve yapılandırmayı geçersiz sayıp 500 döner. Satırı .htaccess dosyasından silin, aynı ayarı .user.ini dosyasına memory_limit = 256M biçiminde yazın. Hangi modda olduğunuzu php_sapi_name() çıktısıyla kesin olarak öğrenebilirsiniz.

Hata mesajındaki dosya adını değiştirmem gerekir mi#

Hayır, o dosya neredeyse her zaman kurbandır, suçlu değil. PHP hatayı belleğin dolduğu anda hangi satır çalışıyorsa orada bildirir; bu genellikle veritabanı katmanı ya da bir çekirdek dosyadır. Çekirdek dosyaları düzenlemek sorunu çözmediği gibi ilk güncellemede kaybolur ve siteyi kırılgan hâle getirir. Bunun yerine yığını geriye doğru izleyin: hangi işlem sırasında oluştuğunu, hangi eklenti devre dışıyken kaybolduğunu bulun.

Limiti artırmak sunucunun genel performansını düşürür mü#

Tek başına ayarı yükseltmek bellek harcamaz, yalnızca tavanı yükseltir. Risk, aynı anda çalışan çok sayıda isteğin bu tavana yaklaşmasıyla ortaya çıkar: eşzamanlı 20 istek 256 MB'ı da kullanırsa sunucu takas alanına düşer ve tüm site yavaşlar. Bu yüzden limiti artırırken PHP-FPM havuzundaki eşzamanlı süreç sayısını da gözden geçirmek gerekir; ikisi birlikte hesaplanmadığında sonuç, tek isteğin ölmesi yerine tüm sunucunun tekleşmesi olur.

Bellek hatası ile süre aşımı hatası aynı anda çıkabilir mi#

Evet ve bu ikisi genellikle aynı kök nedenin farklı yüzleridir. Kontrolsüz büyüyen bir döngü hem belleği doldurur hem süreyi tüketir; hangisinin önce dolduğu betiğin veri yoğunluğuna bağlıdır. Bir işlemde bazen bellek, bazen süre hatası alıyorsanız iki limiti de artırmak yerine işlemi parçalara bölmeniz gerekir. Toplu işleri 500'lük gruplar hâlinde çalıştırmak her iki hatayı birden kalıcı olarak ortadan kaldırır.

Toplu içe aktarma sırasında limiti geçici artırmanın güvenli yolu var mı#

Evet, ayarı yalnızca o betiğin başında ini_set('memory_limit', '512M'); ile yükseltip işlem bitince dokunmamak en temiz yoldur; sonraki istekler yine düşük limitle çalışır. Bu yöntem yalnızca sunucu değeri kilitlememişse işe yarar. Daha güvenli alternatif, içe aktarmayı tarayıcı yerine WP-CLI ile komut satırından çalıştırmaktır; CLI ortamının limiti çoğu sunucuda zaten ayrıdır ve web isteklerini etkilemez.

Kapanış#

Allowed memory size exhausted hatasının çözümü iki soruyu doğru sırayla sormaktan geçer. Önce "limit gerçekten ne ve nerede tanımlı?" — bunu ini_get('memory_limit') ve php_ini_loaded_file() çıktısıyla ölçün, tahmin etmeyin; düzenlediğiniz dosya okunmuyorsa yaptığınız her değişiklik boşadır. Sonra "limit yeterli hâle geldi mi?" — 256M'de biten iş normaldir, 512M'de bile bitmeyen iş bir kod sorunudur ve orada artırmayı bırakıp döngüyü, sorguyu ya da görsel işlemeyi parçalara bölmek gerekir. Hata mesajındaki dosya adının kurban olduğunu hatırlamak da tek başına birçok saati kurtarır.

Bu ayarları paylaşımlı pakette değiştirmek her zaman mümkün olmuyor; PHP sürümünü ve bellek limitini kendiniz seçebildiğiniz bir zemin istiyorsanız web hosting paketlerinin PHP seçici ekranı ya da yoğun WooCommerce kurulumları için e-ticaret hosting tarafı doğru başlangıç olur. Toplu içe aktarma ve raporlama gibi işlerin sürekli sınırı zorladığı sitelerde asıl çözüm kendi kaynaklarınızı yönetmektir; VDS sunucu paketlerinde FPM havuzunu ve limitleri doğrudan siz yapılandırırsınız. Sunucuyu kendiniz yönetmek istemiyorsanız sunucu yönetimi hizmeti bu ayarların ve izlemenin sorumluluğunu üstlenir.