Geçen ay bir iç panel sunucusunda disk %100'e vurdu. PHP 8.1, Debian 11, php-fpm 7.4'ten yükseltilmiş bir kurulum. `du` çıktısı netti: /var/lib/php/sessions altında 6.2 GB, içinde 1.8 milyon dosya. Uy
Paylaşımlı bir sunucuda (PHP 8.2.13, Ubuntu 22.04, php-fpm 8.2) çalışan bir iç panelimiz var. Her sabah 04:00'te bir cron, tedarikçinin REST API'sinden sayfa sayfa 12 bin ürün kaydı çekiyor, her sayfa
Üretimde 8.3.4, Debian 12, php-fpm, memory_limit 256M. Elimde 180 MB'lık, satır başına bir JSON nesnesi olan bir uygulama log dosyası vardı; her satır 1–3 KB, toplam ~140 bin satır. Amacım belirli bir
Geçen ay bir içe aktarma işini devraldım: PHP 8.2, MySQL 8.0, PDO mysql sürücüsü, tek bir worker. Girdi 2.1 milyon satırlık düz metin, satır başına bir UPDATE. İlk hali satır başına connect açıyordu;
Üretimde bir muhasebe entegrasyonu var: kullanıcı 30–45 bin satırlık CSV yüklüyor, PHP 8.1, 512M memory_limit, klasik nginx + php-fpm. Dosyayı `file_get_contents` ile alıp `array_map` ile satırlara bö
Üretimde PHP 8.2, php-fpm 8.2, nginx 1.24, 4 çekirdek / 8 GB bir kutu; günde ~2.1 milyon istek. Saat 14:00 civarı p95 240 ms'den 1.8 s'ye çıkıyor, hata oranı %0.3. Nginx error log'da "upstream timed o
Geçen ay 8.2.14'e geçtikten sonra üretimde bir sorun çıktı: 12 çekirdekli, 32 GB RAM'li iki web sunucusunda php-fpm çocukları 40-60 dakika içinde max_execution_time'a takılmadan yavaşça şişiyordu. Tra
