Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
MySQL InnoDB buffer pool, tablo ve index verisini RAM'de cache'ler. MySQL dokümantasyonu dedicated database sunucularında fiziksel belleğin büyük bölümünün buffer pool'a ayrılabildiğini belirtir.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
MySQL/MariaDB sunucusunu RAM, InnoDB buffer pool, connection sayısı, NVMe IOPS/latency, redo log, swap ve workload tipine göre boyutlandırın.
MySQL InnoDB buffer pool, tablo ve index verisini RAM'de cache'ler. MySQL dokümantasyonu dedicated database sunucularında fiziksel belleğin büyük bölümünün buffer pool'a ayrılabildiğini belirtir.
MySQL 8.4 dokümantasyonu genel memory-use rehberinde buffer pool için tipik olarak sistem belleğinin yaklaşık %50-75 aralığını önerir; dedicated-server otomasyonu 4 GB üzerindeki sistemlerde yaklaşık %75 kullanır. Bu oran web+DB aynı node'da körlemesine uygulanmamalıdır.
Dedicated database VM'de RAM'in büyük bölümü InnoDB buffer pool'a ayrılabilir çünkü PHP, web server, mail ve diğer servisler başka node'dadır. Tek VPS içinde cPanel/Plesk, PHP-FPM, Redis ve MySQL birlikte çalışıyorsa DB'ye aynı oranı vermek OOM veya swap yaratabilir.
Önce workload'u ayırın: OLTP küçük random query, raporlama/analitik büyük scan, WordPress/WooCommerce metadata yoğun sorgular ve API transaction workload'ları farklı kaynak davranışı gösterir.
Amaç aktif working set'in mümkün olduğunca RAM'de kalmasıdır. Buffer pool çok küçükse aynı sayfalar sürekli diskten okunur; çok büyükse işletim sistemi ve connection/query memory için alan kalmaz. MySQL'in %50-75 rehberi başlangıç noktasıdır, gerçek workload ile ölçülmelidir.
MariaDB de InnoDB buffer pool'u temel cache katmanı olarak kullanır. Sürüm ve workload farkları nedeniyle MySQL ayarını birebir MariaDB'ye kopyalamak yerine kendi dokümantasyonu ve status metrikleri kullanılmalıdır.
mysql -e "SELECT @@version, @@innodb_buffer_pool_size;"mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';"mysql -e "SHOW ENGINE INNODB STATUS\G"MySQL'in toplam RAM'i yalnız buffer pool değildir. Her connection sort/join/read buffer gibi per-session allocation oluşturabilir; temp table, thread cache ve performance schema da memory kullanır. `max_connections` değerini 1000 yapmak tek başına kapasite yaratmaz.
Application connection pool kullanıyorsa gerçek eşzamanlı DB connection sayısı ve idle connection davranışı ölçülmelidir. Connection spike sırasında OOM oluşması, normal saatlerde RAM boş görünmesine rağmen mümkündür.
Buffer pool miss, redo log flush, fsync, temp table spill ve checkpoint işlemleri storage latency'ye duyarlıdır. Database için sıralı 3 GB/s benchmark'tan çok 4K random latency ve p95/p99 completion time anlamlı olabilir.
Sanal sunucuda NVMe etiketi fiziksel media türünü söyleyebilir ama storage backend ve IOPS limitini söylemez. Aynı provider içinde farklı paketleri gerçek fio ve DB workload ile test etmek daha güvenlidir.
Swap'ın varlığı başlı başına hata değildir; fakat aktif working set'in sürekli swap'e taşınması DB latency'sini ciddi artırır. OOM'dan korunmak için swap olabilir ama sürekli swap-in/out memory pressure işaretidir.
free -hvmstat 1 20iostat -x 1 20mysqladmin processlistYüksek concurrency OLTP ve parallel query workload daha fazla core'dan faydalanabilir. Düşük concurrency ama ağır query, lock veya tek thread darboğazında single-core performansı daha önemli olabilir. Query optimizasyonu kötü ise daha fazla CPU yalnız sorunu geciktirir.
Küçük WordPress DB: 2-4 vCPU, 4-8 GB RAM, düşük latency NVMe. Orta WooCommerce/API DB: 4-8 vCPU, 8-32 GB RAM. Dedicated yoğun DB: 8-16+ güçlü core, 32-128+ GB ECC, enterprise NVMe mirror ve ayrı backup. Gerçek sizing working set ve query profiline göre yapılır.
| Workload | CPU | RAM | Storage |
|---|---|---|---|
| WordPress/WooCommerce | Orta-yüksek single-core | Working set + cache | Düşük random latency |
| Yoğun OLTP | Çok core | Büyük buffer pool | Yüksek IOPS |
| Raporlama | Parallel CPU | Büyük RAM | Sequential + random mix |
Minimum sistem gereksinimini production kapasitesi sanmayın. Gerçek seçimde peak workload, yedekleme, büyüme payı, kaynak paylaşım politikası ve geri dönüş planı birlikte değerlendirilmelidir.
Dedicated DB'de MySQL rehberi yaklaşık %50-75 aralığını başlangıç olarak kullanabilir; web+DB aynı node'da diğer servislerin RAM'i ayrılmadan bu oran uygulanmamalıdır.
Şart değildir ama düşük latency ve yüksek IOPS yoğun workload'da ciddi avantaj sağlar. Gerçek VM storage performansı ölçülmelidir.
CPU, RAM, disk, network ve yönetim ihtiyacınızı birlikte değerlendirin; darboğazı bilinmeden yalnız daha büyük paket satın almak çoğu zaman kalıcı çözüm değildir.