Bilmek istediğin her şeye ulaş

Milyon kaydı olan tablolarda MySQL performansını nasıl arttırırız?

Sürekli kafama takılan bir türlü net bir sonuç bulamadığım. Büyük firmaların bu işi hala nasıl yaptığını merak eden bir yazılımcı.. Düzenle
[Alıntı] - Yardımı olmak istedim.
ozgurkuru.net/ozgur/index.php/tag/mysql-...

Bu yazımla yıllardır edindiğim tecrübeler ve araştırmalar sonucu elde ettiğim bilgiler dahilinde bir MySQL sunucusunda dikkat edilmesi gereken performans noktalarını anlatacağım. Ayrıca teknik komut ve kodlardan çok teorik bir anlatım olacak. Mümkün olduğu kadar çok konudan bahsetmek istesem de epey uzun ve dallı bir konu aslında. Bu yüzden bazı yerlerde köşeli parantezler içerisinde dip notlar ekledim ve bu notları konunun dağılmaması için yazının sonunda açıklamaya çalıştım. Umarım faydalı bir yazı olmuştur. Zaman buldukça bu yazıda bahsettiğim ayarlarla ilgili olarak örnek içeren yazılar yazmaya çalışacağım.
Bir sistem için performans ayarlaması yaparken birçok etken göz önünde bulundurulmalı. Veri tabanı sunucuları için ise aşağıdaki etkenler önemli rol oynar:
  1. Table Engine
  2. Read/Write oranı
  3. Tutulan verilerin ortalama büyüklükleri ve türleri (text, int vs), toplam veri tabanı boyutu.
  4. Bağlantı sayıları
  5. Sorguların yapıları ve içerikleri.
Bu maddelerin bazıları sadece veri tabanı için önemli bazıları ise veri tabanı sunucusunu kuracağınız işletim sistemi ve donanım özellikleri içinde önemli etkenler. Örneğin Read/Write oranı size nasıl bir disk yapısı kuracağınız, kullandığınız disklerin yapılarını hatta işletim sisteminde kullanacağınız dosya sistemini bile değiştirebilir.
Verilerin boyutu özellikle dosya sistemi üzerinde önemli bir rol oynar. Bu etken sadece veri tabanı içerisinde tutulacak verilerle sınırlı değildir. Örneğin bir statik içerik sunucusu içinde önemli bir etkendir.
Bunların yanı sıra kullandığınız/tercih ettiğiniz teknoloji, sistem ve yazılımların çeşitli darboğazları olabilir. Örneğin, dosya sistemi olarak ReiserFS tercih etmeniz, çabuk yıpranan ve kolayca bozulabilen bir dosya sistemi sağlar. Fakat küçük dosya boyutları için ideal bir çözüm olabilir.
Bu tarz durumlar nedeniyle özellikle veri tabanı gibi verilerin kararlı bir şekilde saklanması gereken sistemleri tasarlarken iyi araştırmalar ve testler uygulamak gerekiyor. Günümüzde bu testler sıklıkla yapıldığı için sizin bu testlere göre sistem kurmanız yanlış değildir. Tabi yaptığınız ayarlamaları sadece testlere göre değil bilerek yaptığınızı ve verilerinizi iyi tanıdığınızı düşünerek ele alıyorum.
Bu genel açıklamalardan sonra adım adım bir performans noktalarını inceleyelim. Bu noktadan sonra anlatacağım tüm adımlar Linux ve MySQL üzerine olacaktır.
Dosya sistemi:
Dosya sistemi oldukça tartışmalı bir konu. Konu veritabanı olduğunda tercih edilebilecek en iyi dosya sistemi ZFS olarak görünmekte. Fakat ZFS’nin sadece Solaris üzerinde tam manasıyla desteği olduğunu düşünürsek bu tercih Linux sunucular için gerçekçi değil[1]. Linux üzerinde ise EXT3/EXT4 ve XFS ön plana çıkan dosya sistemleri. XFS ile EXT4 arasında performans konusunda çok çok büyük farklar bulunmamakla birlikte XFS, EXT4 ‘e göre biraz daha hızlı bir dosya sistemi. Fakat en büyük artısı XFS’in EXTx sistemlerde var olan inode yapısını kullanmıyor olması. Bu sayede EXTx sistemlerin zaman zaman yaşadığı Inode tükenme sorununu[2] yaşamıyor. Bunun yanında her iki sistemde journaling desteği ile geliyor.
Eğer dosyalara erişim tarihleri sizi ilgilendirmiyorsa mutlaka diskler “noatime” parametresi ile mount edilmeli. Böylece sistemin dosya erişim tarihlerini tutması engellenecek böylece gereksiz bir Input/Output yükünden[3] kurtulacaksınız.
RAM Meselesi:
RAM, veri tabanları için can alıcı bir donanımdır. Bir çok işlem ram üzerinde gerçekleştirerek oldukça hızlı işlemler yapılması sağlanır. Özellikle InnoDB index ve keyleri buffer olarak ram üzerinde tutar. InnoDB kullandığınız veri tabanlarınız varsa formül kısaca: “Ram miktarı = toplam innodb tabloların boyutu” olacaktır. Örneğin 20 Gb boyutunda 10 tabloluk bir veri tabanınız var. Bu tabloların 3 tanesi InnoDB ve toplam 4 Gb veriye sahip. Bu varsayımda sadece InnoDB için ayırmanız gereken ram miktarı => 4Gb olmalı[4].
InnoDB pool buffer size ayarının basit formülü “RAM miktarı – Sisteme ayrılan ram” veya RAM miktarının maksimum %80’i kadardır.
İşlemci Seçimi:
Mümkün olduğunca 64Bit destekli işlemciler tercih edilmeli. boyutuna ve gelen yüke göre 4 çekirdek olması MySQL için ideal çözümdür. MySQL ancak ciddi trafik altında ve/veya yanlış ram ayarlaması sonucunda gereksiz ve aşırı bir işlemci tüketimi yapar. Yine de ekstra işlemci ihtiyacınız varsa 8 veya 16 çekirdekli işlemciler yeterli olacaktır. Bu noktadan sonra yapacağınız şey replication, sharding gibi sunucu sayılarını arttırmaya yönelik olmalıdır[5].
Disk Seçimi:
Mümkünse SSD, değilse en az 15K RPM SAS diskler kullanılmalı. Raid yapısı olarak RAID10 veya RAID5 ideal yapılardır. Fakat RAID5 RAID01 ‘e göre yazma işleminde daha yavaş kalabilir.
Linux Kernel Optimizasyonu:
MySQL sunucusu koşturduğunuz bir linux sistem üzerinde yapmanız gereken ilk ayar kesinlikle “Open File Limit” ayarıdır. File Limit kısaca aynı anda kaç adet dosyanın açık olabileceğini belirler. Linux sistemlerde her işlem bir dosya açarak yapılır. Bu yüzden bu limitin arttırılması gerekmektedir. Varsayılan olarak 1024 adet dosya aynı anda açılabilir.
Bunun yanı sıra aşağıda ki ayaları da ihtiyacınız doğrultusunda yapmanız gerekir:
  • Bağlantılar için kullanılacak buffer ayarları
  • SYN Floodlar için maksimum kuyruk sayısı
  • TCP Fin durumları için timeout süresi. düşük tutmak daha hızlı TCP işlemleri yapacağı için CPU kullanımı düşecektir
  • Keepalive time
  • Zaman damgasının kapatılması. Böylece yoğun trafikte gereksiz IP Stack işlemlerinin önüne geçilmiş olunur.
  • Gelen bağlantı sayısı
  • Optmem Arttırımı
  • Read/Write memory ayarlaması
  • Dosya cache miktarı
Bu adımlara dikkat ettiğiniz sürece başarılı ve sorunsuz bir veri tabanı sunucusuna sahip olmuş olacaksınız.
Notlar:
[1] zfsonlinux.org/ adresinde görebileceğiniz gibi ZFS’in linux sistemlere port edilmesi mümkündür. Fakat kararlılık ve performans açısından tercih edilmemektedir.
[2] EXT sistemlerde her dosya bir Inode ile temsil edilir. Yoğun write işlemleri olan dosya sistemlerinde zaman zaman silinden dosyalar Inode tablolarından silinemeyebilirler. Bu durumda Inode tablosu dolacağı için hali hazırda disk dolmamış olsa bile diske yazma işlemi yapılamaz. Bu durumda fsck ile disk check yapılması gerekmektedir. XFS sisteminde Inode yapısı olmadığı için böyle bir risk yoktur.
[3] Noatime özelliği ile linux kernel bir dosyaya yapılan her erişimi dosya headerlarına yazar. Bu da yoğun disk işlemlerinde gereksiz bir IO yaratır. Tabi access bilgisine ihtiyaç duyuyorsanız bu maliyete katlanmanız gerekecektir.
[4] Teoride ve düşük trafikli sistemlerde InnoDB Buffer Pool Size toplam InnoDB verisinden daha küçük olabilir. Fakat buffer pool üzerinde tutulmayan veriler çağrıldığında ciddi performans kayıpları olur. Çünkü MySQL Buffer dahilinde olmayan veriler için disk erişimi yapar bu da veri tabanı sistemlerinde kaçınılması gereken bir durumdur. Eğer buffer için ayırdığınız ram dolduysa MySQL performans daha da düşecektir.
[5] Sharding ve Replication tamamı ile ayrı birer yazı konusu olacak nitelikte konulardır. Bu yüzden çok detaylı olarak bu noktada anlatmak istemedim.
  • Paylaş
1

Ömer Ilik, Mysql optimizasyonunun server tarafı bu

MySQL'de olan kayıt sayısı pek önemli değil önemli olan ne kadar istek aldığıdır. İsteğe bağlı olarak yapılacaklar öncelikle gerekli optimizasyonu yaparak yazılım tarafından sıkıntı yaratmayacak hale getirmektir (tablo dizaynını milyon kayda göre hazırlamış olmanızda gerekmektedir). Bu işlem yeterli gelmiyorsa MySQL sunucu sayınızı attırmanız gerekir. Büyük firmalarda bu şekilde işlemler yapmaktadırlar.
  • Paylaş
Gerekli basliklari arkadaslar yazmis. Eger bunlari yaptiniz ama hala mysql'den verim alamiyorsaniz. Oracle kadar guclu ama mysql gibi bedava olan PostgreSQL gecme zamaniniz gelmis demektir!
Sole bir tanimlama yaparsak; Mysql benzinli motor; PostgreSQL dizel motor. Hic hata almassiniz. Gayet saglamdir. Milyon deyil milyaryarca veri tutabilirsiniz. Cok kiritik onemli verilerde kesinlikle PostgreSQL
  • Paylaş
Sonraki Soru
HESAP OLUŞTUR

İstatistikler

989 Görüntülenme6 Takipçi3 Yanıt