10 Mart 2017 Cuma

Veritabanı sunucunuzun "rutin" durumu gerçekten normal mi?

Son zamanlarda bir firma ile kısa bir çalışma yaptık. Microsoft SQL Server veritabanı sunucusu sağlık kontrolü çalışması yaparken, sunucunun işlemci kaynaklarının neredeyse sürekli %100 kullanıldığını gözlemledim. Açıkçası ben her ne kadar o anda veritabanı sunucusu sağlık kontrolü çalışmasını erteleyip sorunlara göz atmak için sabırsızlansam da, müşteri bu durum ile yaşamaya alışıktı. Bu nedenle o gün sağlık kontrolü çalışmamıza devam ettik.


Kontrollerde sunucunun CPU durumu (temsilidir).

Aslında benimle çalışmak istemelerinin nedenlerinden biri de işlemcinin bu durumuydu, ama bu sorun hakkında çok da kaygılı değillerdi. Sonuç itibariyle günlük operasyonlarını durduran, kesintiye neden olan bir durum yoktu ortada. Sadece zaman zaman ağırlık hissediliyordu ve Deadlock'lar oluşuyordu. Muhtemelen kullanıcılar da zaten sistemin böyle bir performansla çalışmasına alışmışlardı, o yüzden kimse yadırgamıyordu, sonuç itibariyle sistemin "rutin" hali bu idi.

Şahsen sağlık kontrolü çalışmasınının tamamlanmasını ve ertesi gün yapacağımız performans iyileştirme çalışmasını iple çekiyordum. Ertesi gün performans iyileştirme çalışması için yalnızca birkaç saat ayırabildik. Bu kadarlık bir sürede bile, yaptığımız müdahalelerle işlemci kullanımının (sıçramaları hariç tutarsak) %1'lere indiğini gözlemledim. Zaman zaman işlemci kullanımını %100'e çıkartan bir (ve muhtemel başka zaman aralıklarında çalışan birkaç tane daha) sorgu hala vardı ve en sorunlu görünen sorguyu da tespit edip ilgili yöneticiye bildirmiştim; fakat sorgular uygulamada gömülü olduğundan hemen o gün müdahale edip sorun düzeltilemedi. Birkaç saatte bu kadar iyileştirme sağlanabildiyse çalışmak için 1 ekstra günümüz daha olsa, stabil olarak işlemci kaynaklarını %5'in altına indirebileceğimize eminimdim. Tabii tüm ortamlar için mümkün olan bir sonuç değil bu, bazı çalışmalar daha uzun sürüyor; ama bu müşterim için durum böyleydi.


Önceden de benzer senaryolara ve konulara değinmiştim. Sorunları CPU ve RAM ekleyerek ancak bir yere kadar öteleyebilirsiniz. Tabii CPU ve RAM eklemek de yetmiyor, bu donanımlar için Microsoft SQL Server lisansı da satın almanız gerekiyor. Örneğin Microsoft SQL Server 2016 Enterprise Edition veritabanı sunucunuzu Per Core modeliyle lisanslamak istediğinizde tek bir CPU Core'u için lisans bedeli 14,256$ ve sunucunuzdaki tüm fiziksel Core'lar için lisans satın almanız gerekiyor.


Güncelleme (2017-03-13): Per Core lisanslama modelinde çekirdek başına lisanslama yapılıyor ve 2 çekirdek paketiyle satılıyor. Yani 14,256$, 2 Core'luk paket fiyatı. Eğer sunucunuz 8 çekirdekliyse, o zaman 4 tane 2 Core'luk paket almanız gerekiyor. Tabii her lisanslama senaryosu bu kadar basit hesaplanmıyor. Senaryoya göre lisans hesabı çok daha ayrıntılı olabiliyor. Her halükarda bu konuyu yetkili bir satış kanalıyla görüşmenizde fayda var.

Bu konuda size bazı önerilerim var:


  • Yazılımcıların veritabanı kodlaması konusunda en iyi pratikleri bildiğinden ve uyguladığından emin olun, 
  • Veritabanı sunucunuza kod taşımalarını yapmadan önce taşınacak değişiklikleri iyi ve sistemli bir şekilde test edin, 
  • Testleri küçük boyutlarda, gerçekçi olmayan verilerle yapmayın, 
  • Test ortamınızın hem donanım olarak, hem yapılandırma olarak, hem de veri olarak üretim ortamınıza olabildiğince benzer ve güncel olmasını sağlayın, 
  • Kod taşımalarından önce ve sonra, üretim ortamınızdaki performans değişikliklerini takip edin, kodu taşıyıp hiçbir şey olmamış gibi üretim ortamını kendi haline bırakmayın,
  • Performans sorunlarınızı donanım kaynaklarını arttırarak değil, öncelikle veritabanı yapılandırmanızı ve kodlarınızı iyileştirerek gidermeyi deneyin,
  • Bu değişikliklerin yaratacağı olası performans sorunları takip edilmediğinde ve gerekli müdahaleler zamanında yapılmadığında bir noktada artık sistemin sağlıklı çalışamaz hale geleceğini unutmayın.

Microsoft SQL Server ile ilgili profesyonel bir desteğe ihtiyacınız varsa beklerim efendim.

Ekrem Önsoy