İş yükünün profilinin çıkartılmasından indekslemenin üç kuralına burada yer alan uzman görüşleri hiç şüphesiz MySQL sunucularınızı coşturacak.
Tüm ilişkisel veritabanlarında olduğu gibi, MySQL de karmaşık bir canavar olduğunu ispat edebilir; bir anda uygulamalarınızı ve online işinizi zor durumda bırakan bir probleme neden olabilir.
İşin gerçeği şu ki, yaygın hatalar çoğunlukla MySQL performans problemleri altında yatıyor. MySQL sunucunuzun en yüksek hızda çalışmasını, istikrarlı ve kesintisiz bir performans temin etmek için sıklıkla anlaşılması güç olan bu hataları ortadan kaldırmak önem arz ediyor.
Çok şükür çoğu MySQL performans problemi benzer çözümlere sahip. Bu da sorunların çözümü ve MySQL’in hassas bir biçimde ayarlanmasını yönetilebilir bir görev yapıyor.
İşte size MySQL’den en iyi performansı elde etmeniz için 10 ipucu.
MySQL performans ipuçları No. 1: İş yükünüzün profilini çıkartın
Sunucunuzun zamanını nasıl harcadığını anlamanın en iyi yolu sunucunuzun iş yükünün profilini çıkartmaktır. İş yükünün profilini çıkartarak daha hassas ayar yapmak üzere en yoğun sorguları açığa çıkartabilirsiniz. Burada zaman önemli bir ölçüttür çünkü sunucu karşısında bir sorgu yayınladığınızda, ne kadar hızlı sonuçlandığı dışında hemen her şeye çok az dikkat edersiniz.
İş yükünün profilini çıkartmanın en iyi yolu MySQL Enterprise Monitor’un sorgu analizcisi veya Percona Toolkit’in pt-query-digest’i gibi bir araçtır. Bu araçlar sunucunun çalıştırdığı sorguları yakalar ve yanıt zamanına göre azalan sırada sınıflandırılmış bir tablo getirir. En yoğun ve zaman harcayan görevleri listesinin başına getirir ki çabalarınızı nereye odaklamanız gerektiğini görebileseniz.
İş yükü profili çıkarma araçları benzer sorguları tek bir sıra içinde gruplar. Böylelikle yavaş çalışan sorguları görmenize imkan tanır. Aynı zamanda hızlı çalışan ancak çok kez çalıştırılan sorguları da bu şekilde görebilirsiniz.
MySQL performans ipuçları No. 2: Dört temel kaynağınızı anlayın
İşlevini yerine getirebilmesi için bir veritabanı sunucusu dört temel kaynağa gereksinim duyar: CPU, bellek, disk ve ağ. Eğer bunlardan biri zayıf ise veyahut aşırı yüklenmişse o zaman veritabanı sunucusunun kötü bir performans göstermesi çok olasıdır.
Temel kaynakları anlamak özellikle iki alan için önemlidir: donanımın seçimi ve problemlerin giderilmesi.
MySQL için donanım seçerken, tüm bileşenlerin iyi bir performansa sahip olduğundan emin olun. Bunların birbirleri karşısında makul bir biçimde dengelenmesi de aynı derecede önemli. Genellikle organizasyonlar hızlı CPU’ları ve diskleri olan sunucuları seçer ama belleği mahrum bırakır. Bazı durumlarda bellek eklemek performansı basamaksal büyüklük olarak arttırmanın en ucuz yoludur; özelikle diskle bağlantılı iş yüklerinde. Bu mantığa aykırı gibi gözükebilir ama çoğu durumda diskler aşırı kullanılır çünkü sunucunun çalıştırdığı veri setlerini saklamaya yeterli bellek yoktur.
Bunun diğer bir güzel örneği CPU’larla ilgili dengedir. Çoğu durumda MySQL hızlı CPU’larla güzel çalışacaktır çünkü her bir sorgu tek bir izlekte (thread) çalışır ve CPU’lar arasında paralel yürütülemez.
Sıra problem çözümüne geldiğinde tüm dört kaynağın performans ve kullanımını dikkatli bir biçimde kontrol edin; performansları zayıf mı ya da çok fazla iş yapması mı isteniyor? Bu bilgi problemlerin hızlıca çözülmesine yardımcı olabilir.
MySQL performans ipuçları No. 3: MySQL’i bir kuyruk olarak kullanmayın
Kuyruklar ve kuyruk benzeri erişim kalıpları siz farkında olmadan uygulamanızın içine gizlice sızabilir. Örneğin, bir nesnenin durumunu öyle ayarladınız ki belirli bir çalışan süreci onu kullanabilmeden önce talep giriyor; işte siz farkında olmadan bir kuyruk oluşturuyorsunuz. E-postaları gönderilmemiş olarak işaretlemek, sonra göndermek ve ardından bunları gönderilmiş olarak işaretlemek yaygın bir örnektir.
Kuyruklar iki temel nedenden dolayı problem çıkartır: İş yükünüzü seri olarak yürütür, görevlerin paralel olarak yapılmasını önler ve sıklıkla uzun süre önce işlenmiş olan işlerin geçmiş verileriyle birlikte yürütülmekte olan işleri içeren bir tablo oluşturur. Her ikisi uygulamada gecikme ve MySQL üzerinde yüke neden olur.
MySQL performans ipuçları No. 4: Sonuçları kolay olanlar önce gelecek şekilde filtreleyin
MySQL’i optimize etmenin harika bir yolu zahmetsiz, kesin olmayan işleri önce ardından da sonuçlanan daha küçük veri setleri üzerinde kesin olan işi yapmaktır.
Söz gelimi, belirli bir coğrafi noktanın çapı dahilindeki bir şeyi arıyorsunuz. Birçok programcının alet kutusundaki ilk araç bir dairenin yüzeyi boyunca bilgiişlem mesafesi için olan büyük-daire (Haversine) formülüdür. Bu teknikteki problem formülün çok fazla trigonometrik operasyona ihtiyaç duymasıdır ki bunlar CPU’yu yoğun bir biçimde kullanır. Büyük daire hesaplamaları yavaş çalışma eğilimindedir ve makinenin CPU kullanımını aşırı yükseltir.
Büyük daire fomülünü uygulamadan evvel, kayıtlarınızı toplamın küçük bir alt kümesine indirin ve sonuç setlerini kesin bir daireye ayarlayın. Daireyi kapsayan bir kare (kesin veya kesin olmayan) bunu gerçekleştirmenin kolay bir yoludur. Bu şekilde karenin dışındaki dünya hiçbir zaman o masraflı trigonometrik fonksiyonlarla buluşmaz.
MySQL performans ipuçları No. 5: İki Ölçeklenebilirlik tuzağını bilin
Ölçeklenebilirlik sizin inanıyor olabildiğiniz gibi belirsiz bir şey değil. Haddi zatında ölçeklenebilirliğin denklem olarak ifade edilen kesin matematik tanımları mevcut. Bu denklemler sistemlerin neden olması gerektiği kadar ölçeklenmediğini işaret ediyor.
Evrensel Ölçeklenebilirlik Kanunu’nu ele alın; bu bir sistemin ölçeklenebilirlik karakterinin ifadesi ve ölçülmesinde kullanışlı olan bir tanım. Bu kanun ölçekleme problemlerini iki temel maliyet anlamında açıklıyor: serileşme ve parazit.
Gerçekleşmek için serileşen bir şey için durması gereken paralel süreçlerin ölçeklenebilirliği kaçınılmaz olarak kısıtlıdır. Benzer biçimde, eğer paralel süreçler işlerini koordine etmek üzere sürekli birbirleriyle konuşmaya gereksinim duyuyorsalar onlar birbirlerini kısıtlar.
Serileşme ve parazitten kaçının; böylelikle uygulamanız çok daha iyi ölçeklenecektir. Peki bunun MySQL’deki tercümesi ne? Duruma göre değişiyor ancak sıralardaki özel kilitlerden kaçınmak örnek olarak gösterilebilir. No. 3’deki Kuyruklar, işte bu nedenden ötürü kötü bir biçimde ölçeklenme eğiliminde.
MySQL performans ipuçları No. 6: Konfigürasyona fazla odaklanmayın
DBA’ler hassas ayarlamalarda çok fazla zaman harcama eğilimindedir. Bunun sonucu genellikle büyük bir ilerleme değildir ve bazı zamanlarda fazlasıyla zarar verici olabilir. “Optimize” edildiği halde sık sık çöken, belleği taşan ve iş yükü biraz yoğunlaştığında performansı kötüleşen sunucularla karşılaştım.
MySQL’e birlikte gelen varsayılan ayarlar herkes için uygun değildir ve zamanı geçmiştir. Fakat siz her şeyi ayarlamak zorunda değilsiniz. Temel şeyleri doğrudan almak ve diğer şeyleri sadece ihtiyaç olduğunda değiştirmek daha iyidir. Çoğu durumda, yaklaşık 10 seçeneği doğru ayarlayarak sunucunun maksimum performansının yüzde 95’ini elde edersiniz. Bunun geçerli olmadığı size özel olan çok az durum vardır.
Çoğu durumda sunucu “ince ayar” araçları tavsiye edilmez çünkü onlar belirli durumlar için anlamlı olmayan talimatları verme eğilimindedir. Hatta bazıları içlerine kodlanmış tehlikeli, doğru olmayan önerileri sunar; cache sonuç oranları ve bellek tüketim formülleri gibi. Bunlar hiçbir zaman doğru değildir ve zaman geçtikçe doğruluklarını daha da kaybettiler.
MySQL performans ipuçları No. 7: Sayfalama sorgularına dikkat edin
Sayfalandıran uygulamalar sunucuyu dizlerine çökertme eğilimindedir. Bir sonraki sayfaya götüren bir bağlantının bulunduğu sonuç sayfasını gösterirken, bu uygulamalar tipik olarak indeksleri kullanamayan yollardan gruplar ve sınıflandırır. Ve onlar satırları üretip ardından elemek için sunucunun çok fazla çalışmasına neden olan LIMIT ve offset kullanır.
Optimizasyonlar çoğunlukla kullanıcı arayüzünün kendisinin içinde bulunabilir. Sonuçlar içinde sayfaların tam sayısını göstermek ve her bir sayfaya ayrı ayrı bağlantı vermek yerine, sadece bir sonraki sayfaya olan bağlantıyı gösterebilirsiniz. Ayrıca insanların ilk sayfadan çok uzakta olan sayfalara gitmesini de önleyebilirsiniz.
Sorgu tarafında offset’li LIMIT kullanmak yerine, ihtiyacınızdan bir fazla sıra seçebilir ve kullanıcı “sonraki sayfa” bağlantısına tıkladığında bir sonraki sonuç seti için nihai sırayı başlangıç noktası olarak tasarlayabilirsiniz. Örneğin, eğer bir kullanıcı 101 ve 120 sıraları arasındaki bir sayfayı gördüyse, siz 121’nci sırayı da seçebilirsiniz; bir sonraki sayfayı derlemek için 121, limit 21’den büyük veya eşit olan sıralar için sunucuyu sorgulayabilirsiniz.
MySQL performans ipuçları No. 8: İstatistikleri isteyerek, uyarıları zoraki saklayın
Görüntüleme ve uyarı olmazsa olmazdır ama tipik görüntüleme sistemine ne olacak? O yanlış pozitif değerler göndermeye başlar ve sistem yöneticileri paraziti durdurmak için e-posta filtreleme kurallarını oluşturur. Kısa zamanda görüntüleme sisteminiz tamamen kullanışsız hale gelir.
Görüntüleme hakkında iki şekilde düşünmeyi seviyorum: ölçümleri yakalamak ve uyarı vermek. Yapabileceğiniz tüm ölçümleri yakalayıp kaydetmeniz çok önemli çünkü sisteminizde neyin değiştiğini anlamaya çalıştığınızda bunlara sahip olmaktan memnun olacaksınız. Bir gün tuhaf bir problem orataya çıkacak ve bir grafiğe bakıp sunucunun iş yükündeki değişimi görme yeteneğini seveceksiniz.
Diğer taraftan çok fazla uyarı vermeye bir eğilim söz konusu. İnsanlar buffer hit oranı veya saniyede oluşturulan geçici tabloların sayısı gibi şeyler üzerinde uyarı verir. Problem şu ki bu tür bir oran için iyi bir eşik yoktur. Doğru eşik sadece sunucudan sunucuya farklılık göstermez aynı zamanda iş yükünüzdeki saatlik değişim için de farklıdır.
Sonuç itibariyle, uyarıları tutumlu ve sadece kesin, işlenebilir bir problemi işaret eden durumlarda kullanın. Düşük bir buffer hit oranı ne işlenebilirdir ne de gerçek bir sorunu işaret eder ancak bir bağlantı denemesine yanıt vermeyen sunucu çözülmeyi gerektiren gerçek bir problemdir.
MySQL performans ipuçları No. 9: İndekslemenin üç kuralını öğrenin
İndeksleme muhtemelen veritabanları içerisindeki en yanlış anlaşılan başlıktır çünkü indekslerin nasıl çalıştığına ve sunucuların bunları nasıl kullandığına dair kafanızı karıştıracak çok yol bulunuyor. Gerçekten neler olduğunu anlamak çok fazla efor gerektiriyor.
İndeksler düzgün tasarlandıklarında bir veritabanı sunucusu içinde üç önemli hizmeti sunar:
1- Sunucunun yalnız sıralar yerine bitişik sıra gruplarını bulmasına izin verirler. Birçok insan indeksin amacının ayrı sıraları bulmak olduğunu düşünür oysa yalnız sıraları bulmak rasgele disk operasyonlarına yöneltir ki bu da yavaştır. Sıra gruplarını bulmak çok daha iyidir; her seferinde birini bulmak yerine tümünü ya da çoğunu.
2- Sunucunun sıraları istenen bir sırada okuyarak sınıflandırmadan kaçınmasına imkan tanır. Sınıflandırma masraflıdır. Sıraları istenen bir sırada okumak çok daha hızlıdır.
3- Sunucunun tüm sorguları indeksin kendisinden sağlamasına izin verir. Bu da tabloya erişim ihtiyacını kaldırır. Bu ayrıca kapsayan indeks (covering index) veya yalnız indeks sorgusu olarak da bilinir.
Eğer bu üç fırsatı açığa çıkartmak için indeks ve sorgularınızı tasarlayabilirseniz, sorgularınızın birkaç kat daha hızlı olmasını sağlayabilirsiniz.
MySQL performans ipuçları No. 10: Arkadaşlarınızın uzmanlığından faydalanın
Tek başınıza ilerlemeye çalışmayın. Eğer bir problem üzerinde kafa yoruyor ve size mantıklı geleni yapıyorsanız, bu harika. Bu 20 defada yaklaşık 19 kez çalışacaktır. Diğer zamanlarda ise sizi tavşan deliğine sokacak, çok maliyetli ve zaman tüketecektir hiç şüphesiz. Çünkü denediğiniz çözüm oldukça mantıklı gözüküyordur.
MySQL bağlantılı kaynaklardan bir network inşa edin; bu araç setlerinin ve sorun giderme rehberlerinin ötesinde olan bir şey. Mail listelerinde, forumlarda, Soru&Cevap sitelerinde vs. oldukça bilgili insanlar bulunuyor. Konferanslar, fuarlar ve yerel kullanıcı grubu etkinlikleri anlayış kazanmak ve zorlu bir zamanda size yardımcı olacak arkadaşlarla ilişki inşa etmek için değerli fırsatlar sağlıyor.
Bu ipuçlarını desteklemek isteyenler MySQL konfigürasyon aracını (https://tools.percona.com/wizard), Query Advisor aracını (https://tools.percona.com/query-advisor) ve Percona Monitoring Plugins’i (https://www.percona.com/software/percona-monitoring-plugins/) kontrol edebilir. Konfigürasyon aracı yeni bir sunucu için sunucuyla birlikte gelen örnek dosyalarından daha üstün olan temel my.cnf dosyasını oluşturmanıza yardımcı oluyor. Query Advisor, SQL’inizin sıralama sorguları (No 7) gibi potansiyel kötü kalıpları tespit etmenize yardım ediyor. Percona Monitoring ise istatistikleri zevkle kaydetmenize yardımcı olan bir dizi görüntüleme ve grafik plugin’i. Bunların üçü de ücretsiz uygulamalar.