MySQL Kurulumdan Sonra Temel Performans Ayarları

MySQL kurulumlarında Innodb storage engine default storage engine olarak belirlendikten sonra — ki bu 5.5 sürümüne denk geliyor — kurulum sonrası ilk ayarlar, üstünde yazma yükü sistemler için performans açısından kritik bir öneme sahiptir. Kurulum sonrasında performans açısından baktığımızda 3 ayar karşımıza çıkmaktadır.

innodb_flush_method

Bu ayar öndeğer olarak fsync almaktadır. Hem windows hem linux kurulumlarda ortalama bir performans verdiği için fsync ayarının öntanımlı verildiğini tahmin ediyorum. Ancak eğer linux üzerinde bir kurulumunuz varsa bu değeri O_DIRECT olarak belirlemeniz size disk işlemlerinde belirgin bir performans artışı sağlayacaktır.

Bu noktada MySQL diski nasıl kullanır şeklide bir parantez açmak da gerekiyor sanırım. Çünkü sanılanın aksine çok fazla insert, update, delete (DML) işleminiz olmasa bile MySQL hatırı sayılır miktarda transaction log üretmekte ve diskte undo, redo log dosyaları üzerinde IO yapmaktadır. MySQL in ön tanımlı transaction isolation seviyesinin REPEATABLE_READ olmasının bunda etkisi büyüktür. Ayrıca her DML işlemi sırasında binary log, ve sonrasında checkpointlerde datafile lar üzerinde yazma işlemi yapılmaktadır.

innodb_buffer_pool_size

MySQL kurulumundan sonra performans açısından değiştirmemiz gereken ikinci config olarak innodb_buffer_pool_size ı söyleyebiliriz. MySQL in çalışma mantığında innodb tablolarda bir veri kümesi (page) okunduğu zaman verinin bir kopyası memory de bu config ile büyüklüğü belirlenen alanda saklanır. Herhangi bir transaction herhangi bir DML işlemi yaptığında eğer ilgili veri satırı memory üzerine çekilmiş ise değişiklik memory de yapılır. Eş zamanlı olarak checkpoint tamamlanana kadar crash durumunda veri kaybı yaşanmaması için redo loglarına da aynı transaction yazılır.

Ön değer olarak 128 MB tır, ancak okuduğunuz makalelerde tavsiye edilen miktar olarak dedike bir veritabanı sunucusunda toplam memory nin %80 inine kadar büyüyebilir şeklinde ifadeler görebilirsiniz. Mantık olarak olabildiğince büyük olmasının performansa olumlu etkisi olacağı değerlendirilir ancak sistem üzerinde veritabanının diğer ihtiyaçları için yeterli memory kalmaması da başka problemlere yol açabilmektedir.

innodb_log_file_size

Performansın üçüncü ayağı olarak innodb_log_file_size parametresini ele almak gerekmektedir. MySQL içerisinde gerçekleşen her transaction commitlendiği zaman innodb log dosyalarında bir kayda yol açar. Ön tanımlı olarak 2 tane olarak oluşturulan (innodb_log_files_in_group) bu dosyaların — aksi config yapılmadıysa — boyutu 48MB tır. Olması gereken boyut ne olacağını hesaplamanız için basit formüller vardır. Ancak o formüller sisteme hangi yoğunluk altında uygulandığına göre farklı sonuçlar verebilmektedir.

Bu yüzden size doğru ayarı bulmanız için farklı bir deneme yanılma yolu söylemek isterim. Aşağıdaki örnekte config default değerde olduğu halde innodb log dosyalarının son değişiklik zamanları arasında büyük bir zaman farkı olduğunu görebiliyoruz. Bu da bize log dosyalarının sık switch olmadığını, sistemdeki transaction yükünün düşük olduğunu gösteriyor. Eğer dosyaların son değişiklik zamanları birbileri ile aynı gitse idi, ve çok sık switch olduklarını farketseydik bu config in arttırılması gerektiğini anlayacaktık.

Son Söz

Burada anlatmak istediğim performansın tek bir configden ziyade sistemin ahenk içerisinde akmasını sağlayan birbiri ile uyumlu parametreler olarak düşünülmelidir. Performansa direk etkisi olacağından emin olmadığınız performans parametreleri ile oynamak sistemin beklemediğiniz şekilde davranmasına sebep olabilir. (örn: innodb log dosyalarının boyutunu gereksiz şekilde aşırı büyütmek crash recovery sürelerinizi dramatik şekilde arttıracaktır.)

Bu yüzden sistemin amacını ve ihtiyaçlarını analiz ettikten sonra parametre değişikliğine gitmek en sağlıklı yol olacaktır kanaatindeyim.