VDS'de MySQL ve MariaDB Performans Optimizasyonu

Paylasimli hosting'ten sanal sunucuya gecen ekiplerin ilk fark ettigi sey, veritabanindan tam yetkiyle sorumlu olmanin getirdigi ozgurluk ve yuk. Varsayilan ayarlarla gelen bir MySQL ya da MariaDB kurulumu, elinizdeki donanimin cogunlukla yarisini bile kullanmaz; gercek kazanc, motoru sunucunuzun RAM, CPU ve disk profiline gore yeniden kalibre etmekten geliyor.

Once Donanim ve Is Yukunu Tani

Optimizasyona baslamadan once iki seyi netlestirmek gerekir: sunucuda kac GB RAM var ve veritabani is yuku okuma agirlikli mi yoksa yazma agirlikli mi? Bir blog ya da kurumsal site genellikle okuma agirlikliyken, siparis isleyen bir e-ticaret arka ucu yazma ve kilitleme baskisi yasar. SHOW ENGINE INNODB STATUS ciktisindaki buffer pool hit rate ve row lock waits degerleri, hangi tarafa egildiginizi hizla gosterir.

• CPU cekirdek sayisi: Paralel sorgu ve baglanti is parcaciklari icin belirleyicidir; yuksek frekansli cekirdekler tekil sorgu gecikmesini dusurur.
• Disk turu: NVMe SSD, donen diske gore rastgele I/O'da kat kat hizlidir; InnoDB redo log ve tablo erisiminde bu fark dogrudan hissedilir.
• Kullanilabilir RAM: Buffer pool boyutunu ve dolayisiyla diske inmeden yanitlanan sorgu oranini belirler.

Yuksek saatli cekirdekler ve NVMe depolamayla gelen bir Ryzen tabanli VDS planinin tek sorgu gecikmesini nasil dusurdugunu, yogun yazma yapan tablolarda InnoDB log akisini izleyerek somut olarak gozlemleyebilirsiniz.

Surum Secimi: MySQL mi MariaDB mi?

Iki motor ortak bir kokten geliyor, ama bugun ayri yollarda. MariaDB, Galera Cluster ile cok-master replikasyona ve Aria gibi ek depolama motorlarina daha entegre yaklasirken, MySQL 8.0 tarafinda gelismis optimizer, atomik DDL ve veri sozlugu iyilestirmeleri one cikiyor.

Cogu cPanel ve DirectAdmin kurulumu bugun MariaDB ile geliyor; mevcut uygulamalariniz iki motorda da sorunsuz calisir. Karar verirken, kullandiginiz panelin desteklenen surum matrisini ve uygulamanizin replikasyon ihtiyacini esas alin.

Buffer Pool'u Dogru Boyutla

InnoDB icin tek en etkili ayar innodb_buffer_pool_size'dir. Veritabanina ayrilmis bir sunucuda bunu fiziksel RAM'in yaklasik %60-70'ine cekmek genellikle iyi bir baslangic noktasidir; ayni kutuda web sunucusu da kosuyorsa bu orani dusurmek gerekir. Buffer pool 1 GB'in uzerindeyse, eszamanli erisim icin innodb_buffer_pool_instances degerini birden fazla yapmak kilitlenmeyi azaltir.

[mysqld]
innodb_buffer_pool_size      = 4G
innodb_buffer_pool_instances = 4
innodb_log_file_size         = 512M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method          = O_DIRECT
innodb_io_capacity           = 2000
max_connections              = 200
tmp_table_size               = 64M
max_heap_table_size          = 64M

Bu parametreleri Debian/Ubuntu tarafinda /etc/mysql/mariadb.conf.d/50-server.cnf, RHEL tarafinda ise /etc/my.cnf.d/server.cnf icinde tanimlarsiniz. innodb_flush_log_at_trx_commit = 2, her islemde diske fsync zorlamadigi icin yazma yogun is yukunde belirgin hizlanma saglar; karsiliginda ani guc kesintisinde son saniyenin islemlerini riske atar, dolayisiyla finansal kayitlarda 1 degerinde kalmak daha guvenlidir.

Yavas Sorgulari Yakala ve Indeksle

Performans sorunlarinin buyuk cogunlugu yanlis konfigurasyondan degil, indekssiz sorgulardan kaynaklanir. Once yavas sorgu kaydini acin, sonra biriken kayitlari analiz edin.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Birikenleri ozetlemek icin:
-- mysqldumpslow -s t /var/log/mysql/slow.log | head -20

Supheli bir sorguyu EXPLAIN ile inceleyin. Ciktida type: ALL goruyorsaniz tam tablo taramasi yapiliyor demektir; WHERE, JOIN ve ORDER BY kolonlarina uygun indeks eklemek cogu durumda gecikmeyi dramatik bicimde dusurur.

• Bilesik indeks sirasi: En secici kolonu en basa koyun; sira yanlissa indeks kullanilmaz.
• SELECT * kacinin: Sadece ihtiyac duydugunuz kolonlari secmek, kapsayan indekslerin devreye girmesini saglar.
• Gereksiz indeksten kacinin: Her indeks yazma maliyetini artirir; kullanilmayanlari sys.schema_unused_indexes ile tespit edip kaldirin.

Bogahost Onerisi: Production'da herhangi bir my.cnf degisikligi yapmadan once mevcut dosyanin yedegini alin (cp /etc/my.cnf /etc/my.cnf.bak-$(date +%F)) ve degisiklikleri tek tek uygulayip her adimda izleyin; toplu degisiklik sonrasi cikan bir sorunun kaynagini bulmak cok daha zordur.

Depolama Motorunu Bilincli Sec

Eski sistemlerden tasinan tablolarin bir kismi hala MyISAM olabilir. MyISAM tablo seviyesinde kilit kullanir ve islem (transaction) destegi sunmaz; eszamanli yazma yapan herhangi bir uygulamada bu, ciddi bir darbogaza donusur. Cogu durumda en saglikli adim, bu tablolari satir seviyesinde kilitleme ve crash recovery sunan InnoDB'ye tasimaktir.

-- Hangi tablolar hala MyISAM:
SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'uygulama_db' AND engine = 'MyISAM';

-- Donusturme (yogun olmayan saatte calistirin):
ALTER TABLE eski_tablo ENGINE = InnoDB;

Donusum islemi tabloyu yeniden olusturdugu icin buyuk tablolarda kilitlenmeye ve I/O baskisina yol acabilir; bu yuzden trafigin dusuk oldugu bir bakim penceresinde ve mutlaka guncel bir yedek aldiktan sonra calistirin.

Baglanti ve Bellek Tablolarini Dengele

Her baglanti is parcacigi belirli bir bellek tuketir, bu yuzden max_connections degerini gercek ihtiyacin uzerine sismek RAM'i hizla tuketebilir. PHP-FPM havuz boyutlariniz ve uygulama baglanti havuzunuzla uyumlu bir deger secin; gereginden yuksek bir limit, tum havuz dolduguda sunucuyu OOM ile karsi karsiya birakir. Diske dusen gecici tablolari azaltmak icin tmp_table_size ve max_heap_table_size degerlerini birlikte, ayni rakamda artirmak gerekir; yalnizca birini buyutmek ise yaramaz. Bos kalan baglantilarin kaynak tutmamasi icin wait_timeout degerini de uygulama davranisina gore makul bir seviyeye cekin.

Izleme ve Surekli Iyilestirme

Ayar bir kez yapilip unutulan bir is degil. mysqltuner.pl betigi, calisan bir sunucuda hizli bir saglik taramasi sunar ve buffer pool kullanimi, sorgu onbellegi, tablo onbellegi gibi kalemler icin somut oneriler verir. Daha kalici bir gozlem icin Prometheus mysqld_exporter ile metrikleri toplayip Grafana'da QPS, baglanti sayisi ve InnoDB satir islemlerini gorsellestirebilirsiniz. Hangi izleme yontemini secerseniz secin, asil amac degisikliklerin etkisini sayisal olarak dogrulayabilmektir.

Kaynak siniri zorlanan, surekli yavaslayan bir veritabani icin tek cozum optimizasyon olmayabilir; bazen is yuku donanimin kapasitesini gercekten asmistir. Boyle durumlarda olceklenebilir bir sanal sunucu altyapisina gecmek, RAM ve I/O tavanini yukseltip buffer pool'a nefes alani acar.

Ozetle

Iyi bir veritabani performansi; dogru buffer pool boyutu, indekslenmis sorgular, donanimla uyumlu baglanti limitleri ve surekli izlemenin bilesimidir. Her ayari kucuk adimlarla uygulayip etkisini olcerek ilerlerseniz, ayni VDS uzerinde catlamadan calisan, tahmin edilebilir bir veritabani katmanina ulasirsiniz.