Konuyu Açan
#1
Merhaba topluluk, MariaDB'de Performans Şeması (Performance Schema) kullanırken erişim ve konfigürasyon konularında deneyimlerimi paylaşmak istiyorum. Performans Şeması, sunucunun davranışını ayrıntılı şekilde izlemek için çok değerli, ancak doğru şekilde yapılandırılmazsa performansı etkileyebiliyor. Aşağıdaki noktaları netleştirmek isterim ve sizlerin tecrübelerinizi duymak isterim.
1) Performans Şeması nedir ve temel işlevler
Performans Şeması, MySQL/MariaDB sunucusunun çalışma anında çeşitli olayları toplar: istemci-tabanlı, kaynak kullanımı, indikatörler ve alt izlerin ölçümü. Özellikle bekleme durumları, I/O, önceki sorgu katmanları ve iş parçacığı düzeyindeki olaylar için ayrıntılı tablolar sağlar. Doğru kullanımla, yüklü sorguların darboğazlarını, kilitlenmeleri ve tampon/CPU dağılımlarını netleştirmek mümkün olur.
2) Erişim kontrolü ve güvenlik düşünceleri
Performans Şeması tablolarına erişim genelde SUPER veya PROXY karakteristiğine ihtiyaç duyar. Uygulama hesaplarına minimum yetki prensibini uygulamak akıllıca: sadece gerekli bölümleri izleyen kullanıcılar için READ_ONLY yetkileri veya belirli şema (performance_schema) tablolarına sınırlı erişim. Loglar ve hassas olaylar için çerezlenebilir alanlar dikkatli şekilde sınırlandırılmalı. Tutarlı bir güvenlik politikası, hem geliştirme hem üretim ortamlarında olası yanlış yapılandırmaları engeller.
3) Kaynak etkisi ve yapılandırma önerileri
Izleme yükü sunucuya ek yük getirir; bu nedenle başlıklar ve olaylar için sadece ihtiyaç duyulanları etkinleştirmek akıllı bir tercihtir. Örneğin:
- belirli olay sınıflarını (waits, stages) açıp kapama,
- LEDGER benzeri süreleri kısa aralıklarla örneklemek yerine makul ölçekte tutmak,
- olay filtreleriyle istenen kullanıcılar veya sorgu türleri için odaklanmak,
- global_wait_instances ve per_statement_wait birimlerini gerektiği kadar kullanmak.
4) Sorgu performansı ile ilişkilendirme
Performans Şeması, uzun süren sorguların nedenlerini bulmak için özellikle kullanışlı olabilir. Ancak çok geniş kapsamlı ölçümler, yüzlerce satır veri üretebildiğinden, izleme başlatmadan önce hedefleri net belirlemek gerekir. Örneğin, yeni bir indeks veya kilitlenme sorunu üzerinde çalışırken, ilgili event sınıfını izlemek yeterli olabilir; ansiklopedik bir tablo kümesi yerine spike odaklı reprizler daha değerlidir.
5) Deneyim paylaşımı ve pratik örnekler
- Üretimde bellek kullanımı çok hızlı artıyorsa, memory_consumed gibi sayaçlar üzerinden kısa vadeli dalgalanmalara bakmak faydalı.
- Kilitlenme sürelerini analiz ederken wait/idle bölümlerini karşılaştırmak, hangi süreçlerin kaynakları baskıladığını çıkarmaya yardımcı olur.
- GUI/CLI araçları ile yapılan hızlı taramalar, hangi tabloların olay üretimini tetiklediğini hızlıca gösterir; ancak ayrıntılar için doğrudan performans_schema tablolarını incelemek gerekir.
Siz hangi senaryolarda Performans Şeması’nı etkin kullanıyorsunuz? Hangi olay sınıflarını öncelediniz ve gözlemlerinizi hangi ölçütlerle doğruladınız? Deneyimleriniz ve önerileriniz için paylaşımları bekliyorum.
