PHP Limitleri: Bellek, Süre ve Dosya Yükleme Ayarları

PHP Ayarlarını Neden Ciddiye Almalısınız?

Bir web sitesi yayınlarken çoğu kişi tema, eklenti ve tasarıma odaklanıyor; PHP ayarları ise genelde sunucu tarafında bir yerde “varsayılan” bırakılıyor. Sonra yavaş yavaş tanıdık sorunlar başlıyor: Tam yüklenmeyen sayfalar, bitmeyen yedekleme işlemleri, yarıda kalan içe aktarmalar, beyaz ekran hataları, sebebi belirsiz 500 hataları… Bu belirtiler yanlış veya yetersiz PHP limitlerinden kaynaklanabilir; ancak nedeni belirlemek için hata kayıtlarını incelemek gerekir.

Özellikle üç ayar kritik: memory_limit, max_execution_time ve upload_max_filesize. Bu üç değer, sitenizin:

• Bir PHP betiğine ayrılan, PHP tarafından izlenen belleğin sınırını,
• Bir PHP betiğinin en fazla ne kadar süre çalışabileceğini,
• Panel üzerinden ne büyüklükte dosya yükleyebileceğinizi

diğer sunucu ve uygulama limitleriyle birlikte etkiliyor. Yanlış ayarlandıklarında hem performans hem de stabilite bozuluyor; hatta tüm sunucuyu etkileyebilecek kadar büyük problemlere yol açabiliyorlar.

WordPress, WooCommerce, LMS (Moodle vb.), kurumsal PHP uygulamaları ve SaaS projelerinde bu ayarların seçimi, uygulamanın iş yüküne bağlıdır. Bu rehberde, memory_limit, max_execution_time ve upload_max_filesize değerlerini site tipine ve altyapınıza göre nasıl seçmeniz gerektiğini, hangi senaryoda hangi aralıklara çıkmanın mantıklı olduğunu ve bu değerleri nereden, nasıl değiştireceğinizi detaylı şekilde anlatacağız.

Amacımız; “hepsini 1 GB yap, bitsin” gibi riskli yaklaşımlar yerine, kontrollü, test edilebilir ve sürdürülebilir bir yol haritası sunmak. Böylece uygulamanın kaynak ihtiyacını karşılamayı ve gereksiz kaynak tüketimi riskini azaltmayı hedefleyebilirsiniz.

memory_limit Nedir, Kaç Olmalı?

memory_limit Tam Olarak Neyi Sınırlar?

memory_limit, bir betiğin PHP bellek yöneticisi üzerinden ayırabildiği belleği sınırlar. Tipik PHP-FPM web akışında bu, o isteğin betik belleğidir; aynı worker sonraki istekleri de çalıştırabilir. İşletim sisteminin gösterdiği toplam süreç RAM’i veya veritabanı sunucusunun belleğiyle aynı ölçü değildir.

• PHP’nin izlediği ayırmalar sınır kapsamındadır; bazı eklentilerin doğrudan malloc ile aldığı veya kalıcı tuttuğu bellek bu hesaba dahil olmayabilir.
• Bir SQL sorgusunun veritabanı tarafındaki belleği ayrıdır. Büyük sonuç kümesini PHP dizilerine almak veya dönüştürmek ise betik belleğini artırabilir.
• Sınır aşımı Allowed memory size exhausted fatal hatasına yol açabilir. PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 itibarıyla memory_limit yumuşak sınırdır: bazı ayırmalar tamamlanıp ardından hata verilebilir. Yeni memory_hard_limit_percent izlenen bellek için ek sınırdır; toplam süreç RAM’ini sınırlayan bir işletim sistemi kotası değildir.

Limit yükseltmek belleği önceden ayırmaz ve işlemi hızlandırmaz. Uygulama ihtiyacı için PHP tepe kullanımını, sunucu kapasitesi için gerçek worker/servis tüketimini ayrı ölçün. memory_get_peak_usage(true), PHP bellek yöneticisinin ayırdığı alanın tepesini gösterir; RSS veya toplam süreç belleği değildir.

Farklı Site Tipleri İçin Önerilen memory_limit Değerleri

Buradaki değerler genel rehber niteliğindedir; altyapınızın (paylaşımlı hosting, VPS, dedicated), ziyaretçi trafiğinizin ve eklenti yoğunluğunuzun farklı olabileceğini unutmadan okuyun. Bu aralıkları zorunlu gereksinimler değil, deneme başlangıçları olarak değerlendirin; uygulama gereksinimleri, ölçülen tepe bellek kullanımı ve eşzamanlı istek sayısına göre ayarlayın.

• Basit kurumsal site / blog (WordPress, hazır PHP CMS): 128M – 256M
  • Az sayıda eklenti, ağır sorgu yok, basit tema kullanıyorsanız 128M bir deneme değeri olabilir; kurulu sürümün gereksinimini ve yoğun işlemleri doğrulayın.
  • Page builder, çok eklenti, görsel optimizasyon, güvenlik eklentileri varsa 256M denenebilir; eklenti sayısı tek başına gereksinimi belirlemez.
• Yoğun eklentili WordPress, içerik sitesi, küçük WooCommerce: 256M – 512M
  • WooCommerce, form eklentileri, SEO araçları, cache ve güvenlik eklentileri birlikte kullanılıyorsa 256M bir deneme başlangıcı olabilir; yalnızca eklenti listesine bakarak zorunlu bir alt sınır belirlenemez.
  • Büyük ürün kataloğu, sık cron görevleri, raporlama gibi yükler varsa 512M, ölçülen gereksinim ve toplam bütçe destekliyorsa denenebilir.
• Orta–büyük WooCommerce, LMS (Moodle vb.) ve haber/marketplace projeleri: 512M – 768M
  • On binlerce ürün, kullanıcı, içerik var; düzenli toplu dışa aktarım/içe aktarım yapılıyor.
  • Raporları veya sorgu sonuçlarını PHP belleğinde biriktirmek tüketimi artırabilir; eşzamanlı sınav trafiği ayrıca worker bütçesi gerektirir.
• Özel PHP uygulamalar, raporlama ve batch iş yükleri: 768M – 1024M (1G)
  • Büyük CSV/Excel işleyen, ağır rapor üreten, arka planda batch çalışan sistemler için daha yüksek limit gerekebilir.
  • Burada mutlaka kod tarafında optimizasyon ve parçalara bölme stratejisi de olmalı.

Paylaşımlı hosting tarafında, memory_limit değerinden ayrı bir hesap başı RAM limiti de uygulanabilir; seçtiğiniz planın kaynak sınırlarını inceleyin. Bu konuda cPanel’de kaynak limitleri ve Resource Limit Reached hatası yazımızı mutlaka incelemenizi öneririz.

memory_limit Çok Düşükse Ne Olur?

Bu limit aşıldığında karşılaşabileceğiniz belirtiler:

• WordPress yönetim panelinde tema/eklenti güncellerken yarıda kalan işlemler,
• Medya kütüphanesine görsel yüklerken beklenmedik beyaz ekran veya 500 hataları,
• WooCommerce ürün içe aktarımı sırasında Allowed memory size exhausted hataları,
• Büyük sorgu sonuçları PHP belleğine alınırken bellek hatasıyla yarım kalan sayfalar; veritabanı tarafındaki sorgu hataları ayrı incelenmelidir.

Yetersiz memory_limit, beyaz ekranın olası nedenlerinden biridir. Diğer nedenleri ayırt etmek için WordPress beyaz ekran hatası rehberimizde açıklanan hata ayıklama adımlarını izleyebilirsiniz.

memory_limit Çok Yüksekse Ne Olur?

“Nasıl olsa RAM çok, 2G yapayım gitsin” yaklaşımı masum görünse de tehlikelidir:

• Her PHP süreci gerçekten 1–2 GB bellek tüketiyorsa,
• Bu düzeyde bellek tüketen 20–30 istek aynı anda çalıştığında,
• Bu süreçlerin toplam bellek tüketimi yaklaşık 20–60 GB aralığına ulaşabilir.

Toplam bellek ihtiyacı kullanılabilir RAM’i aşarsa olası sonuçlar:

• Swap etkinse swap kullanımı ve disk IO artabilir,
• Bellek yetersizliği nedeniyle süreçler sonlandırılabilir,
• Kaynak izolasyonu yeterli değilse hem sizin siteniz hem de aynı sunucudaki diğer siteler yavaşlayabilir veya yanıt veremeyebilir.

Bu yüzden limit artışını yalnızca tek bir isteğin ihtiyacına göre değil, eşzamanlı yük ve sunucudaki diğer hizmetler için gereken bellek payını da dikkate alarak planlayın.

max_execution_time Nedir, Kaç Olmalı?

PHP Çalışma Süresi Mantığı

max_execution_time, PHP’nin kendi zaman sayacına göre betik yürütmesini sınırlar; her kurulumda gerçek geçen sürenin sınırı değildir. Varsayılan Unix/Linux CPU zamanlayıcısında sistem çağrıları, bekleme ve dış veritabanı işlemlerinde geçen süre genellikle sayılmaz. Windows gerçek geçen süreyi sayar. Ayrıca --enable-zend-max-execution-timers ile derlenen PHP, POSIX iş parçacığı zamanlayıcısıyla geçen süreyi sayar; bu seçenek PHP 8.3’ten itibaren ZTS derlemelerinde varsayılandır. Kullanılan derleme ve SAPI’yi kontrol edin.

• 30 değeri “istek tam 31. saniyede sonlanır” demek değildir. PHP sayacı aşılırsa ilgili fatal hata oluşabilir; ağ, FPM veya proxy farklı bir sınırda isteği kesebilir.
• PHP belgesindeki varsayılan 30, CLI varsayılanı 0’dır; etkin yapılandırma bunları değiştirebilir. CLI pozitif süre limitini yok saymaz.
• FPM request_terminate_timeout, web sunucusu/proxy zaman aşımları ve dış HTTP/veritabanı istemcisinin bağlantı/okuma süreleri ayrıca planlanır. İstemciye hata dönmesi arka plandaki işlemin mutlaka durduğunu göstermez.

Buradaki kritik nokta şu: Her uzun süren işlem hatalı değildir. Özellikle içe aktarım, yedek alma, büyük rapor oluşturma gibi işler doğal olarak uzun sürebilir. Önemli olan, bu uzun işleri bilinçli şekilde yönetmek.

Site Tipine Göre max_execution_time Tavsiyeleri

Hosting ortamınızda etkin süre sınırını kontrol edin. Aşağıdaki aralıklar, iş yükünüze göre değerlendirilecek başlangıç önerileridir; her senaryo için ideal değildir.

• Basit kurumsal site / blog: 30 – 60 sn
  • Normal sayfa görüntülemelerinde hedef, süre sınırına yaklaşmadan yanıt üretmektir.
  • 60 saniye bir test başlangıcıdır; güncellemenin indirme, açma ve uygulama aşamalarını ayrıca gözlemleyin.
• WordPress + WooCommerce (küçük/orta ölçek): 60 – 120 sn
  • Ürün içe aktarımı, toplu kupon veya fiyat güncellemeleri gibi işlemler 30 saniyeyi aşabilir.
  • Planlı cron görevleri (yedekleme, raporlama) için biraz esneklik sağlar.
• Büyük WooCommerce, LMS ve rapor ağırlıklı sistemler: 120 – 300 sn
  • 120–300 saniye, kontrollü ağır bir işlem için değerlendirilebilecek örnektir; kullanıcı veya ürün sayısı tek başına gerekli süreyi belirlemez.
  • Bu tip süreçleri mümkünse CLI (komut satırı) üzerinden çalıştırmak daha sağlıklıdır; CLI için ayrı max_execution_time ayarı kullanılabilir.

Çok kritik bir not: Web isteklerinde, özellikle paylaşımlı hostingde, max_execution_time’ı yalnızca zaman aşımı hatasını gizlemek için 0 yapmayın. Süresiz çalışmaya izin verilen işler için ayrıca süre ve kaynak denetimi planlanmalıdır; hatalı yazılmış bir betik CPU ve RAM’i tüketebilir.

Uzun Süren İşlemler İçin Doğru Strateji

Örnek olarak, 30 saniyelik max_execution_time ayarıyla 15 dakikalık bir içe aktarımı yönetici panelinde tek istekte çalıştırmaya çalıştığınızı düşünün. İşlem zaman aşımına uğrayabilir; yalnızca genel limiti yükseltmek yerine şu stratejileri değerlendirin:

• Uzun sürecek işlemleri, mümkünse komut satırından (php cli) yürütmek,
• İşleri küçük parçalara bölerek queue/cron yapılarına yaymak,
• Gerekirse belirli scriptler için lokal max_execution_time artırmak (genel tüm site için değil).

Uzun işleri kuyruklara taşırken yeniden deneme, kısmi başarı, tekrar çalıştırma güvenliği ve çakışmayı da tasarlayın. Cron yalnızca başlatır; kendi başına süre aşan işi öldüren bir process manager değildir. CLI için 0 süresiz PHP sayacı anlamına gelir; kontrollü uzun worker’da kullanılabilir, ancak gerçek iş süresi, bellek, yeniden deneme ve dış servis zaman aşımları ayrıca sınırlandırılmalıdır.

upload_max_filesize ve post_max_size Nasıl Ayarlanmalı?

upload_max_filesize, post_max_size ve memory_limit İlişkisi

Dosya yükleme tarafında genelde üç ayar birlikte düşünülür:

• upload_max_filesize: Tek bir dosyanın maksimum boyutu.
• post_max_size: Bir POST isteğinde gönderilebilecek toplam veri boyutu (birden fazla dosya + form verisi dahil).
• memory_limit: Yüklenen dosyanın işlenmesi sırasında (özellikle resim yeniden boyutlama, PDF işleme vb.) kullanılabilecek RAM.

Genel kural:

• post_max_size, upload_max_filesize değerinden büyük olmalıdır. Birden çok dosyanın toplamı, diğer form alanları ve multipart sınır/başlıkları için pay bırakın. İki tam 32 MiB dosya, 64M toplam POST sınırına sığmaz.
• PHP’de M, 1024×1024 bayttır. Yüklenen sıkıştırılmış görselin dosya boyutu, açılmış piksel verisinin bellek ihtiyacı değildir. Yükleme geçici dosyaya yazılabilir; dosyanın tamamının PHP belleğinde tutulması zorunlu değildir.
• memory_limit değerini işleme sırasında ölçülen tepeye göre seçin; büyük dosya izni, onun işlenebileceğini kanıtlamaz. file_uploads, max_file_uploads, geçici dizin alanı/izinleri ve max_input_time da sonucu etkiler.

Gerçekçi Dosya Yükleme Senaryolarına Göre Değerler

• Sıradan blog / kurumsal site:
  • upload_max_filesize: 8M – 32M
  • post_max_size: 64M (bu tek dosyalı örnek için)
  • memory_limit: 128M – 256M deneme aralığı
• WordPress + WooCommerce (orta ölçek):
  • upload_max_filesize: 32M – 64M
  • post_max_size: 128M (bu tek dosyalı örnek için)
  • memory_limit: 256M – 512M
• LMS ve ağır doküman yüklenen sistemler (PDF, video kapak görselleri vb.):
  • upload_max_filesize: 64M – 256M (gereksinime göre)
  • post_max_size: beklenen toplam dosya boyutu + form/multipart payı; örneğin tek 256M dosya için 272M
  • memory_limit: 512M ve üzeri senaryolar mümkün

Büyük video gibi dosyalarda, destekleniyorsa SFTP veya kimliği doğrulanmış, boyut ve süre kısıtlı doğrudan object storage yüklemelerini değerlendirin. Parçalı yüklemeler için uygulamanın doğrulama ve birleştirme akışı gerekir. PHP upload limitleri SFTP aktarımını yönetmez; başka bir aktarım yöntemi depolama kotasını veya dosya güvenliğini ortadan kaldırmaz.

Güvenlik ve Kötüye Kullanım Riskleri

Yükleme politikasını belirlerken şu etkileri hesaba katın:

• Büyük veya çok sayıda eşzamanlı yükleme bant genişliği, geçici alan ve disk I/O tüketebilir.
• Boyut limiti dosyanın güvenli olduğunu kanıtlamaz; küçük bir dosya da çalıştırılabilir veya zararlı içerik taşıyabilir.
• Uygulama başına dosya sayısı/boyut kotası, kimlik doğrulama ve erişim yetkisini yükleme politikasına ekleyin.

Uygulamada şu kontrolleri birlikte uygulayın:

• İzin verilen türleri allowlist ile sınırlayın; uzantı ve istemcinin gönderdiği MIME bilgisini tek başına güvenilir kabul etmeyin.
• İçeriği sunucuda doğrulayın, rastgele sunucu dosya adı kullanın ve yükleme dizininde betik yürütmeyi engelleyin; mümkünse web kökü dışında tutun.
• İndirme yetkisi, kotalar, uygun içerik taraması ve WAF tamamlayıcıdır; hiçbiri uygulama doğrulamasının yerini tutmaz.

Amaç, izin verilen en büyük dosyayı iş gereksinimiyle sınırlamak ve o dosyanın güvenle saklanıp işlenmesini sağlamaktır.

Paylaşımlı Hosting, VPS ve dedicated sunucuda PHP Limitleri

Paylaşımlı Hostingde Sınırlar ve Tipik Değerler

Paylaşımlı hostingde düzenlenebilir alanlar ve tavan değerler pakete/handler’a bağlıdır. Aşağıdaki aralıklar bir sağlayıcının güncel paket taahhüdü değil, test için örnek profildir:

• memory_limit: 256M – 512M
• max_execution_time: 60 – 120 sn
• upload_max_filesize: 32M – 64M
• post_max_size: 128M (tek dosyalı örnek)

Profilin yeterliliğini gerçek işlemler ve hesap kaynak sınırları belirler. Ayar artırımı hesabın fiziksel RAM, CPU veya I/O bütçesini büyütmez. Kod ve eşzamanlılık optimizasyonundan sonra kapasite hâlâ yetmiyorsa paylaşımlı hostingden VPS’e geçiş rehberi planlama için kullanılabilir.

DCHost VPS ve Dedicated Altyapısında Esnek Ayarlar

Yönetim yetkiniz olan VPS veya dedicated sunucuda ilgili yapılandırmaları değiştirebilirsiniz. Burada iki önemli nokta var:

• Limitleri yükseltirken toplam RAM, CPU ve eşzamanlı PHP süreci sayısını birlikte düşünmek gerekir.
• PHP-FPM havuz ayarları (pm.max_children vb.) ile memory_limit değerleri bir arada planlanmalıdır.

8 GiB RAM’li bir VPS’te 20–30 worker ve 512M memory_limit seçildiğini düşünün:

• 20–30 × 512 MiB = 10–15 GiB, yalnızca limitlerin toplamıdır; ayrılmış bellek, ölçülen tüketim veya toplam süreç RAM’inin kesin üst sınırı değildir.
• Önce işletim sistemi, veritabanı, cache, web sunucusu ve paylaşılan PHP belleğini ayırın. Worker’ların yoğun işlemdeki özel belleğini veya grup PSS toplamını ölçün; RSS toplamı paylaşılan sayfaları tekrar sayabilir.
• Örneğin PHP’ye kalan bütçe 2 GiB ise, paylaşılan alan ve güvenlik payı için 512 MiB ayırıp worker başına varsayımsal 320 MiB özel tepeyle floor((2048−512)/320)=4 worker elde edilir. Bu ölçülmüş DCHost sonucu değildir; kendi verilerinizle yeniden hesaplayın. Grup PSS kullanıyorsanız paylaşılan belleği ayrıca iki kez düşmeyin.

pm.max_children, havuzun aynı anda işleyebildiği istek sayısını sınırlar. Bekleyen istekler kuyrukta birikebilir; yalnızca belleğe göre hesaplanan sayı CPU ve gecikme hedeflerine göre de sınanmalıdır. WordPress için sunucu tarafı optimizasyon rehberi FPM, OPcache ve cache katmanlarını birlikte ele alır.

Bu Değerleri Nereden ve Nasıl Değiştirebilirsiniz?

cPanel / DirectAdmin Üzerinden PHP Ayarları

Panelin izin verdiği PHP ayarlarını, doğru domain ve PHP sürümü için düzenleyin. Menülerin görünmesi pakete, handler’a ve yüklü eklentilere bağlıdır:

• cPanel: PHP sürümü/handler seçimi MultiPHP Manager ile, izin verilen INI değerleri MultiPHP INI Editor ile yönetilebilir. CloudLinux PHP Selector ayrı bir bileşendir; yalnızca kuruluysa kendi Options ekranı vardır.
• DirectAdmin: PHP Settings veya sağlayıcının sunduğu sürüm/ayar ekranını kontrol edin; arayüz ve değiştirilebilir alanlar sürüme, skin’e ve yapılandırmaya bağlıdır.

Panelin veya PHP-FPM php_admin_value ayarlarının zorladığı bir sınırı yerel dosya ya da ini_set ile aşabileceğinizi varsaymayın. PHP 8.5’te max_memory_limit ayrıca memory_limit için başlangıçta belirlenen tavan koyabilir. Kaydedilen metin yerine hedef web isteğinde etkin değeri doğrulayın.

php.ini, .htaccess ve .user.ini ile Manuel Ayar

VPS veya dedicated sunucuda (veya paylaşımlı ortamda izin veriliyorsa) ayarları direkt dosya düzeyinde de değiştirebilirsiniz:

• php.ini: İlgili PHP sürümü ve SAPI’nin yüklediği dosyayı düzenleyin; CLI ile FPM aynı dosyayı kullanmak zorunda değildir.

  ; Example per-site PHP configuration; validate workload and concurrency.
  memory_limit = 256M
  max_execution_time = 60
  upload_max_filesize = 32M
  post_max_size = 64M

• .htaccess: Bu php_value biçimi Apache mod_php ve uygun AllowOverride izni içindir. Genel FPM çözümü değildir; desteklenmiyorsa 500 hatası verebilir.

  # Only for Apache mod_php with the required AllowOverride permission.
  php_value memory_limit 256M
  php_value max_execution_time 60
  php_value upload_max_filesize 32M
  php_value post_max_size 64M

• .user.ini: CGI/FastCGI SAPI’de etkinse dizin başına okunur. INI_ALL, INI_USER ve INI_PERDIR seçenekleri uygulanabilir; varsayılan yeniden okuma aralığı 300 saniyedir ve değiştirilebilir.

  ; Example per-site PHP configuration; validate workload and concurrency.
  memory_limit = 256M
  max_execution_time = 60
  upload_max_filesize = 32M
  post_max_size = 64M

Değişikliklerden sonra mutlaka:

• Yedeğini aldığınız doğru dosyayı değiştirin; FPM ana/INI yapılandırmasında kurulu servisin doğrulama ve reload prosedürünü kullanın. Her .user.ini değişikliğinde FPM restart gerekmez.
• Web sunucusu yapılandırması değiştiyse onun syntax kontrolü ve reload adımını ayrıca uygulayın; yalnızca PHP ayarı için her katmanı yeniden başlatmayın.
• Aşağıdaki geçici kontrolü yalnızca erişimi kısıtlı bir test yolunda çalıştırın; doğrulama bitince dosyayı kaldırın. Genel erişime açık phpinfo() bırakmayın.

<?php
// Temporary protected diagnostic; remove after verification.
header('Content-Type: application/json');
echo json_encode([
    'sapi' => PHP_SAPI,
    'memory_limit' => ini_get('memory_limit'),
    'max_execution_time' => ini_get('max_execution_time'),
    'upload_max_filesize' => ini_get('upload_max_filesize'),
    'post_max_size' => ini_get('post_max_size'),
], JSON_PRETTY_PRINT);

Kontrolü gerçek domainin web isteğiyle yapın; CLI çıktısı FPM’deki etkin ayarı kanıtlamaz. Yükleme limitleri INI_PERDIR olduğundan, aynı isteğin scriptinde ini_set ile artırılamaz; POST gövdesi betik başlamadan işlenir. memory_limit ve max_execution_time izin verildiğinde çalışma sırasında değişebilir; ini_set false dönerse değişiklik başarısızdır.

Doğru Yapılandırma İçin Pratik Bir Kontrol Listesi

Yeni bir projeyi hazırlarken şu sırayı izleyin:

1. Uygulama sürümünü, PHP SAPI/handler’ını ve ağır işlemleri belirleyin.
2. Bir örnek profil seçmeden önce mevcut etkin değerleri, uygulama gereksinimini ve sunucu/hesap bütçesini kaydedin.
3. Staging’de içe aktarım, yükleme ve eşzamanlı yoğun istekleri temsil eden testler yapın; PHP tepe belleği ile gerçek worker belleğini ayrı izleyin.
4. Hata kayıtları, FPM kuyrukları, CPU, I/O ve gecikmeye göre tek değişkeni küçük adımlarla ayarlayın.
5. Yükleme için sınır altı, tek dosya sınırı üstü ve toplam POST sınırı üstü örnekleri test edin.
6. Etkin web değerini doğrulayın, test dosyasını kaldırın ve eski ayara dönüşü hazır tutun.

Hata Mesajlarından Limit Problemlerini Okumak

memory_limit Hataları

Tipik hata mesajı:

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

Buradaki 268435456, 256M’e karşılık gelir. Bu hata genelde şunlarda karşımıza çıkar:

• WordPress eklenti/tema güncellemeleri,
• WooCommerce ürün içe aktarmaları,
• Büyük sorgular ve raporlama ekranları.

Bu hatayı gördüğünüzde sadece memory_limit’i artırmak yerine, aynı zamanda:

• Hangi script’in bu hatayı ürettiğini loglardan tespit edin,
• Mümkünse sorgu veya işleme mantığını optimize edin,
• Yine de gerekiyorsa memory_limit’i makul bir oranda yükseltin.

Log okumaya alışık değilseniz Apache ve Nginx loglarını okuma rehberimiz bu noktada çok yardımcı olacaktır.

max_execution_time Hataları

Tipik hata mesajı:

PHP Fatal error: Maximum execution time of 30 seconds exceeded...

Bu hatayı gördüğünüzde:

• İlgili işlemin gerçekten ne kadar sürmesinin beklenebilir olduğuna bakın.
• İşlem bir defaya mahsus kurulum/güncelleme ise, geçici olarak max_execution_time değerini artırabilirsiniz.
• İşlem rutin bir cron veya kullanıcı aksiyonu ise, onu daha küçük parçalara bölecek bir mimari düşünmek daha sağlıklıdır.

Dosya Yükleme ile İlgili Tipik Hatalar

upload_max_filesize ve post_max_size ile ilgili sorunlarda genelde:

• Tek dosya upload_max_filesize değerini aşarsa ilgili $_FILES error alanı UPLOAD_ERR_INI_SIZE (1) olabilir.
• POST gövdesi post_max_size değerini aşarsa PHP’nin normal POST işleyişinde $_POST ve $_FILES boş olur; uygulama bunu yakalayıp anlaşılır yanıt vermelidir.
• Web sunucusu daha önce reddederse örneğin HTTP 413 görülebilir ve PHP scripti hiç çalışmayabilir. Geçici dizin veya diske yazma hataları farklı upload hata kodları üretir.

Bu belirtileri PHP ve web sunucusu kayıtlarıyla ayırın; sessiz başarısızlık bütün yüklemeler için kaçınılmaz sonuç değildir:

• Hem upload_max_filesize hem post_max_size değerlerinizi kontrol edin.
• web sunucusu (Nginx/Apache) tarafında ek upload limiti (client_max_body_size vb.) olup olmadığına bakın.
• memory_limit değerinizin, yüklediğiniz dosyanın işlenmesi için yeterli olup olmadığını gözden geçirin.

DCHost Ekibi Olarak Önerdiğimiz Genel PHP Limit Rehberi

Küçük Kurumsal / Blog Siteleri

Aşağıdaki profil, basit blog veya kurumsal siteyi temsil eden staging denemesi içindir; uygulamanın güncel minimum gereksiniminin yerine geçmez:

• memory_limit: 128M – 256M
• max_execution_time: 60 sn
• upload_max_filesize: 16M – 32M
• post_max_size: 64M (tek dosyalı örnek)

Bu değerler başarı garantisi vermez. Güncelleme ve yüklemeyi temsil eden işlerde hata yoksa ve bellek payı yeterliyse limiti artırmak gerekmez; eklenti sayısı tek başına zorunlu 256M eşiği oluşturmaz.

WordPress + WooCommerce Siteleri

WooCommerce için uygulama gereksinimlerini kontrol ettikten sonra aşağıdaki örnek profili mağazanızın sepet, ödeme, yönetim ve içe aktarım işleriyle sınayın:

• memory_limit: 256M – 512M
• max_execution_time: 90 – 120 sn
• upload_max_filesize: 32M – 64M
• post_max_size: 128M (tek dosyalı örnek)

512M ancak ölçülen ağır iş ve toplam eşzamanlılık bütçesi bunu gerektiriyorsa seçilmelidir. Farklı cache katmanlarını da değerlendirebilirsiniz:

• OPcache,
• Object cache (Redis veya Memcached),
• HTTP seviyesinde tam sayfa önbellekleme

OPcache derlenmiş kodu, object cache veriyi, HTTP cache uygun tam yanıtları tekrar kullanır. Kişiselleştirilmiş sepet, ödeme ve hesap yanıtlarını paylaşılan tam sayfa cache’ine koymayın. Cache isabeti PHP iş yükünü azaltabilir; cache dışı ağır bir isteğin bellek ihtiyacını otomatik olarak düşürmez. MySQL/InnoDB tuning rehberi ve PHP 8.x yükseltme kontrol listesi bu planı tamamlar.

LMS, SaaS ve Yoğun İş Yükleri

LMS, SaaS ve raporlama sistemlerinde aşağıdaki değerler yalnızca ağır işlemler için deneme aralıklarıdır; bunları bütün web isteklerine otomatik uygulamayın:

• memory_limit: 512M – 768M (bazı rapor/batch işleri için 1G gerekli olabilir)
• max_execution_time: 120 – 300 sn (kritik işler CLI tarafta ayrı yönetilmeli)
• upload_max_filesize: 64M – 256M (ihtiyaca göre)
• post_max_size: beklenen toplam dosyalar + form/multipart payı; tek 256M dosya için örnek 272M

Bu tip projelerde asıl farkı yaratanlar:

• İyi tasarlanmış veritabanı ve indeksler,
• Queue/kuyruk mimarileri,
• Önbellekleme katmanları (Redis, HTTP cache, CDN),
• Doğru boyutlandırılmış DCHost VPS veya dedicated sunucu altyapısı

oluyor. PHP limitleri burada son kat ayar gibi düşünülmeli; mimari ve kod tarafındaki optimizasyonların yerini tutmuyor.

Sonuç ve Yol Haritası

Bu limitler PHP’nin çalışmasına izin verilen sınırları belirler; tek başlarına hız veya güvenlik sağlamaz. Önce doğru hata nedenini ve etkin yapılandırmayı tespit edin, ardından betik gereksinimini sunucu bütçesiyle birlikte değerlendirin.

DCHost ekibi olarak önerimiz, bu üç ayarı her site için bilinçli bir başlangıç profili ile yapılandırmanız, ardından gerçek kullanım verisine göre küçük adımlarla güncellemeniz. Bunun için:

• Önce site tipinizi (blog, WooCommerce, LMS, SaaS) netleştirin.
• Bu rehberde önerilen aralıklardan makul bir başlangıç noktası seçin.
• Sunucu loglarını ve hata mesajlarını düzenli takip edin.
• Artan trafik ve yeni özellikler geldikçe limitleri gözden geçirin.
• Mümkün olduğunda, uzun süren işlemleri CLI ve queue mimarilerine taşıyın.

DCHost üzerinde çalışan projeniz için destek isterken etkin PHP sürümü/SAPI, hata kaydı, işlem türü ve kaynak ölçümlerini paylaşın; parola veya erişim belirteci göndermeyin. Bu bilgiler uygun ayar veya kapasite değişikliğini değerlendirmeyi kolaylaştırır.