Veritabanı Sunucusu Boyutlandırma

"Veritabanı için nasıl bir sunucu almalıyım?" sorusuna verilen en yaygın cevap yanlıştır: daha çok CPU. Oysa bir veritabanı sunucusunun performansını belirleyen sıra neredeyse her zaman şudur — önce RAM, sonra diskin gecikmesi, en sonda CPU. Yanlış sırada satın alınan bir sunucu, kağıt üzerinde güçlü görünürken gerçek yükte sürekli diske gider ve iki kat pahalı olduğu halde yavaş çalışır.

Bu rehberde veritabanı sunucusu boyutlandırmayı ölçüme dayalı biçimde yapacağız: aktif veri kümenizi nasıl hesaplayacağınızı, buradan RAM ihtiyacına nasıl gideceğinizi, innodb_buffer_pool_size değerini neye göre seçeceğinizi, bağlantı başına harcanan gizli belleği, IOPS ve disk gecikmesinin neden CPU'dan önemli olduğunu, örnek senaryolarla makul başlangıç yapılandırmalarını ve büyümeyi önceden görmenin yollarını ele alacağım.

Her Şey Aktif Veri Kümesiyle Başlar#

Boyutlandırmanın çıkış noktası toplam veritabanı boyutu değil, aktif veri kümesidir: gerçekten sık okunan tablolar ve onların indeksleri. 200 GB'lık bir veritabanının 190 GB'ı üç yıllık arşiv kayıtlarıysa ve günlük trafik yalnızca son üç ayı okuyorsa, ihtiyacınız 200 GB bellek değildir.

Önce toplam boyutu ve tablo dağılımını ölçün:

-- Veritabanı bazında toplam boyut (veri + indeks)
SELECT table_schema AS veritabani,
       ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS gb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY gb DESC;

-- En büyük 10 tablo ve indeks payı
SELECT table_name,
       ROUND(data_length / 1024 / 1024, 1) AS veri_mb,
       ROUND(index_length / 1024 / 1024, 1) AS indeks_mb,
       table_rows AS yaklasik_satir
FROM information_schema.tables
WHERE table_schema = 'uygulama_db'
ORDER BY (data_length + index_length) DESC
LIMIT 10;

Aktif kümeyi kestirmenin pratik yolu, en büyük tabloların ne kadarının güncel dönem verisi olduğunu görmektir. Örneğin siparisler tablosu 60 GB ama son 90 günlük veri 6 GB ise, aktif kümeye 6 GB'ı yazın. Buna sık okunan kataloglar, kullanıcı tablosu ve tüm indeksleri ekleyin. Elinizdeki sayı, RAM hesabının temelidir.

RAM: En Belirleyici Kaynak#

InnoDB, veriyi ve indeksi buffer pool'da tutar; sorgu ihtiyaç duyduğu sayfayı bellekte bulursa mikrosaniyeler, bulamazsa diskten okuma süresi kadar bekler. Bu fark, hızlı bir NVMe diskte bile birkaç yüz kattır. Dolayısıyla hedef basittir: aktif veri kümesi buffer pool'a sığmalı.

Adanmış bir veritabanı sunucusunda innodb_buffer_pool_size değerini toplam RAM'in yaklaşık %60-75'i aralığında tutmak yaygın ve sağlıklı bir başlangıçtır. Kalan bellek işletim sistemine, bağlantı başına tamponlara ve varsa diğer servislere kalır. Sunucuda web sunucusu ve PHP de çalışıyorsa bu oranı %40-50'ye çekin.

# 16 GB RAM'li, yalnızca veritabanı çalıştıran bir sunucu için
[mysqld]
innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 8
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
max_connections = 200

Ayarın yeterli olup olmadığını tahminle değil ölçümle anlarsınız. Buffer pool'da uzun süredir boş sayfa kalmıyorsa ve disk okuma sayacı sürekli artıyorsa bellek yetmiyor demektir:

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Innodb_buffer_pool_pages_total',
  'Innodb_buffer_pool_pages_free',
  'Innodb_buffer_pool_pages_data',
  'Innodb_buffer_pool_reads',
  'Innodb_buffer_pool_read_requests');

Burada dikkat: Innodb_buffer_pool_reads kümülatif bir sayaçtır ve sunucu açıldığından beri toplamı gösterir. Anlamlı olan, dakikadaki artışıdır. Bu ayrımın neden kritik olduğunu veritabanı izleme metrikleri yazısında ayrıntılı anlattım.

Buffer pool'u RAM'in tamamına yakın vermek de klasik bir hatadır: işletim sistemi belleksiz kalır, takas alanına düşer ve veritabanı diske yazmaktan beter bir yavaşlığa girer. Bazı durumlarda OOM mekanizması doğrudan MySQL sürecini sonlandırır.

CPU: Kaç Çekirdek Gerçekten Gerekiyor#

Veritabanı iş yükü çoğunlukla G/Ç ve bellek ağırlıklıdır; CPU ihtiyacı, eşzamanlı çalışan sorgu sayısıyla doğru orantılıdır. Kabaca bir kural: aynı anda gerçekten iş yapan sorgu sayısı (Threads_running) çekirdek sayısının 2-3 katını aşmaya başladığında kuyruk oluşur ve yanıt süreleri hızla bozulur.

-- Tepe saatlerde birkaç kez ölçün
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Threads_connected';

400 bağlantı görüp panikleyen çok kişi var; oysa bunların 390'ı Sleep durumundaysa CPU'ya yük yoktur. Ölçmeniz gereken sayı Threads_running'dir. Tepe anlarda bu değer 8-12 arasındaysa 4-6 çekirdek rahatlıkla yeter; sürekli 30'un üzerindeyse ya çekirdek eklemeniz ya da sorguları hafifletmeniz gerekir.

CPU'nun gerçekten belirleyici olduğu üç durum vardır: yoğun sıralama ve gruplama içeren rapor sorguları, veri sıkıştırma ve şifreleme kullanımı, ve çok sayıda küçük sorgunun aynı anda geldiği yüksek eşzamanlılık. Bunların hiçbiri sizin profiliniz değilse, çekirdek sayısını artırmak yerine aynı bütçeyi belleğe ve diske ayırmak neredeyse her zaman daha iyi sonuç verir. Sorgu tarafındaki iyileştirmeler için MySQL/MariaDB performans optimizasyonu yazısına bakabilirsiniz.

Disk ve IOPS: Sessiz Darboğaz#

Aktif küme belleğe sığmıyorsa performansınızı belirleyen şey diskin gecikmesidir, kapasitesi değil. Aradaki fark, satın alma kararını tamamen değiştirecek kadar büyüktür:

Yazma tarafında da benzer bir tablo vardır ve orada asıl belirleyici, işlem günlüğünün diske yazılma hızıdır. innodb_flush_log_at_trx_commit = 1 ayarı her işlemi diske yazdırır; en güvenli seçenektir ve dayanıklılık gerektiren sistemlerde değiştirilmemelidir. Yavaş diskte bu ayar, saniyedeki işlem sayınızı doğrudan sınırlar.

Diskin gerçekten darboğaz olup olmadığını işletim sistemi tarafından ölçün:

# Cihaz bazında gecikme (await) ve doluluk (%util)
iostat -x 5 3

# await iki haneli ms ve %util 100'e yakınsa disk doygun demektir

Kapasite planlarken de sadece bugünkü veri boyutuna bakmayın. Veritabanı diskinde şunlara yer ayırmanız gerekir: veri dosyaları, indeksler, işlem günlükleri, binlog arşivi, geçici dosyalar ve yeterli boş alan. Pratik kural, veri boyutunun en az iki katı disk almaktır; bazı bakım işlemleri (tablo yeniden oluşturma gibi) tablonun bir kopyasını çıkarır. Binlog'un diski nasıl doldurabileceğini MySQL binlog diski doldurdu yazısında ele aldım.

Bağlantı Sayısı ve Gizli Bellek Çarpanı#

Boyutlandırmada en sık gözden kaçan kalem, bağlantı başına ayrılan tamponlardır. sort_buffer_size, join_buffer_size, read_buffer_size, read_rnd_buffer_size ve tmp_table_size gibi ayarlar global değil, iş parçacığı başınadır. Bu değerleri "daha büyük daha iyidir" mantığıyla yükseltmek, yüksek eşzamanlılıkta belleği bir anda tüketir.

Kaba bir üst sınır hesabı şöyle yapılır:

# Tehlikeli örnek: her bağlantı ihtiyaç halinde bu tamponları ayırabilir
sort_buffer_size = 8M
join_buffer_size = 8M
read_buffer_size = 4M
max_connections = 500
# Teorik tepe: 500 × (8+8+4) MB = 10 GB, buffer pool'un ÜSTÜNE

Sağlıklı yaklaşım, bu tamponları küçük tutup (çoğu iş yükü için 256 KB - 2 MB fazlasıyla yeterlidir) yalnızca ölçülmüş bir ihtiyaç varsa oturum düzeyinde yükseltmektir. max_connections değerini de gerçek ihtiyacın üzerine gereksiz çıkarmayın; asıl çözüm uygulamada bağlantı havuzu kullanmaktır. Bağlantı tükenmesi senaryosunu MySQL Too Many Connections hatası yazısında ayrıntılı anlattım.

Örnek Senaryolar#

Aşağıdaki tablo, sahada sık karşılaştığım profiller için makul başlangıç noktalarıdır. Bunlar bir garanti değil, ölçüme başlayacağınız yerlerdir:

Aynı sunucuda web ve veritabanı birlikte çalışıyorsa tablodaki RAM değerlerini yaklaşık 1,5 katına çıkarın ve buffer pool oranını düşürün. Bir noktadan sonra ayırmak daha doğrudur: veritabanını kendi sunucusuna taşımak, aynı bütçeyle çoğu zaman daha iyi sonuç verir çünkü iki iş yükü bellek için birbiriyle yarışmaz.

Büyümeyi Öngörmek ve Ne Zaman Büyütmeli#

Kapasite planlaması bir kerelik iş değildir. Aylık olarak veri büyümesini kaydedin; basit bir sorgu ve bir tablo yeterlidir:

-- Aylık ölçüm için: toplam boyut
SELECT NOW() AS olcum_tarihi,
       ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS toplam_gb
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys');

Son altı ayın büyüme hızından, aktif kümenin buffer pool'u ne zaman aşacağını hesaplayabilirsiniz. Büyütme kararını şu üç sinyalden herhangi biri geldiğinde verin:

1. Buffer pool'daki boş sayfa sayısı kalıcı olarak sıfıra yapıştı ve disk okuma hızı taban çizgisinin katlarına çıktı.
2. Disk await değeri tepe saatlerde 10 ms üzerine çıkıyor ve %util sürekli doygun.
3. Threads_running tepe anlarda çekirdek sayısının 3 katını aşıyor ve yanıt süreleri bozuluyor.

Bu sinyaller gelmeden yapılacak en ucuz iyileştirmeler ise şunlar: gereksiz indeksleri kaldırmak, eski veriyi arşiv tablosuna taşımak, SELECT * alışkanlığını kırmak ve önbellek katmanı eklemek. Okuma yükü baskınsa dikey büyütme yerine yatay yöne gitmek daha ekonomik olabilir; anlatımı read replica ile okuma yükünü dağıtma yazısında.

Sık Yapılan Hatalar#

Toplam veri boyutunu RAM hedefi sanmak. 500 GB'lık bir veritabanı için 512 GB bellek gerekmez; ihtiyaç aktif küme kadardır. Arşiv verisini ayırmak, donanım maliyetini çoğu zaman yarıya indirir.

Buffer pool'u RAM'in %90'ına çekmek. Kalan bellek işletim sistemine, bağlantı tamponlarına ve dosya sistemi işlemlerine yetmez; sunucu takasa düşer ve performans, düşük bellekli halinden de kötü olur.

Bağlantı tamponlarını global olarak büyütmek. sort_buffer_size gibi ayarlar iş parçacığı başınadır. Yüksek eşzamanlılıkta bu değerler belleği katlayarak tüketir ve sunucu tam yoğun anda çöker.

CPU'ya yatırım yapıp diski görmezden gelmek. Ağ üzerinden bağlı yavaş bir depolamada 16 çekirdek de olsa fark etmez; her sorgu diski bekler. Veritabanı için depolama seçimi neredeyse her zaman CPU seçiminden önce gelir.

Ölçmeden karar vermek. "Site yavaş, sunucuyu büyütelim" refleksi sık sık gereksiz maliyet üretir. Çoğu yavaşlığın kaynağı eksik indeks veya uygulama tarafındaki sorgu deseni olur; büyütme onları düzeltmez, sadece erteler.

Sıkça Sorulan Sorular#

innodb_buffer_pool_size kaç olmalı#

Adanmış bir veritabanı sunucusunda toplam RAM'in yaklaşık %60-75'i iyi bir başlangıçtır; aynı makinede web sunucusu da çalışıyorsa bu oranı %40-50'ye çekin. Asıl hedef, aktif veri kümenizin buffer pool'a sığmasıdır. Aktif küme 6 GB ise 24 GB buffer pool ayırmanın anlamı yoktur; o belleği başka yerde kullanın.

Veritabanı için kaç GB RAM yeterli#

Doğrudan aktif veri kümenize bağlıdır. Sık okunan tablolar ve indeksleri toplamda 3 GB tutuyorsa 8 GB RAM'li bir sunucu rahat çalışır; 15 GB tutuyorsa 32 GB düşünmelisiniz. Formül olarak şunu kullanabilirsiniz: aktif küme + bağlantı tamponları için pay + işletim sistemi için 1-2 GB, hepsinin üzerine yaklaşık %30 büyüme payı.

SSD mi NVMe mi almalıyım#

Veritabanı için NVMe belirgin biçimde daha iyidir; fark IOPS sayısından çok rastgele okuma gecikmesinde ortaya çıkar ve veritabanı iş yükü tam olarak rastgele okumadan oluşur. Bütçe kısıtlıysa SATA SSD de kabul edilebilir, ancak dönen diskler modern bir veritabanı yükü için uygun değildir. Ağ üzerinden bağlı depolamalarda ise ortalama hızdan çok gecikme değişkenliğine bakın.

Aynı sunucuda web ve veritabanı çalıştırmak sorun mu#

Küçük ve orta trafikli projelerde tamamen normaldir ve maliyet avantajı sağlar. Sorun, iki iş yükünün aynı belleği paylaşmasıdır: PHP-FPM süreçleri büyüdükçe buffer pool'a kalan yer azalır ve veritabanı diske gitmeye başlar. Trafik arttığında ilk ayırmanız gereken bileşen veritabanıdır; bu, tek başına donanım eklemekten daha çok kazandırır.

Sunucuyu büyütme zamanının geldiğini nasıl anlarım#

Üç sinyale bakın: buffer pool'da kalıcı olarak boş sayfa kalmaması ve disk okumasının taban çizgisinin katlarına çıkması, disk bekleme süresinin tepe saatlerde 10 ms üzerine çıkması, ve eşzamanlı çalışan sorgu sayısının çekirdek sayısının üç katını aşması. Bu sinyaller yokken yaşanan yavaşlıklar genellikle indeks veya sorgu kaynaklıdır ve donanımla çözülmez.

Bulut sunucuda boyutlandırma farklı mı yapılır#

Mantık aynıdır ama bulutta iki ek konuya dikkat edin: depolama katmanının IOPS ve verim sınırı genellikle disk boyutuna bağlıdır, yani küçük bir disk aynı zamanda düşük IOPS demektir; ve paylaşımlı ortamlarda CPU performansı zaman içinde dalgalanabilir. Bulutun avantajı, ölçüm sonucuna göre kaynağı hızlıca artırabilmenizdir; bunu ölçmeden değil, izleme verisine dayanarak yapın.

Kapanış#

Doğru boyutlandırma tahminle değil ölçümle yapılır ve sıralama neredeyse hiç değişmez: önce aktif veri kümenizi hesaplayın, RAM'i o kümenin buffer pool'a sığacağı şekilde seçin, disk tarafında kapasiteden çok gecikmeye bakın, CPU'yu eşzamanlı çalışan sorgu sayısına göre belirleyin ve bağlantı başına ayrılan tamponları küçük tutun. Büyümeyi aylık ölçüp kaydetmek de bu listeye eklenmeli; kapasite kararları geçmiş veriyle çok daha kolay verilir.

İhtiyacınızı ölçtükten sonra donanım tarafında seçenekleriniz net: hızlı NVMe diskli VDS paketleri çoğu orta ölçekli proje için yeterli, kaynağı esnek biçimde artırmak isterseniz bulut sunucu, yüksek ve öngörülebilir yük için ise dedicated sunucu uygun olur. Ayarların yapılması, izlemenin kurulması ve büyüme planının takibini bizim üstlenmemizi isterseniz sunucu yönetimi hizmetimiz bu kapsamda çalışır.