Alipaşa Mah. Yeni Hükümet Cad. No:14/110, Tokat 0 356 214 70 65 bilgi@sur.com.tr Online mağaza English

Ticari program yavaşladı: SQL Server, Firebird ve MySQL veritabanında ilk kontroller

Ticari programın açılışı, fatura kaydı ve raporları yavaşladığında veritabanı tarafında disk, RAM, bakım ve büyüyen log dosyası kontrollerini sırayla anlattık; sunucu değişimi gereken noktayı da belirttik.

Sunucu Güncellendi: 6 dk okuma

Sabah program geç açılıyor, fatura kaydederken imleç dönüp duruyor, ay sonu raporu yarım saat sürüyor. Bu tablo çoğu zaman bilgisayarlardan değil, ticari programın veritabanından kaynaklanır. Aşağıda SQL Server, Firebird ve MySQL kullanan programlarda sırayla bakılması gereken temel kontrolleri, kendinizin yapabileceği kısımları ve sunucu değişiminin gerçekten gerektiği noktayı anlatıyoruz.

Önce sorunun yerini ayırın: tek bilgisayar mı, herkes mi?

Yavaşlık sadece bir bilgisayarda varsa sorun büyük ihtimalle o bilgisayardadır: eski disk, yetersiz RAM, ağ kartı ya da kablo. Herkes aynı anda yavaşlık yaşıyorsa sunucuya ve veritabanına bakılır. Bir ara test daha: sunucunun kendisinde programı açıp aynı raporu çalıştırın. Sunucuda hızlı, istemcilerde yavaşsa sorun ağdadır; sunucuda da yavaşsa veritabanı ya da donanımdadır.

Ağ tarafında hızlı kontroller

Sorun ağda görünüyorsa ilk bakılacak yer bağlantı hızıdır. İstemcide Ayarlar > Ağ ve İnternet > Ethernet > Özellikler bölümünde bağlantı hızı 100 Mbps görünüyorsa kablo, priz veya switch portunda sorun vardır; gigabit bir ağda bu değerin 1 Gbps olması gerekir. Eski bir switch, ezilmiş bir patch kablo ya da Wi-Fi üzerinden çalışan bir bilgisayar, ticari programda belirgin yavaşlık yaratır. Veritabanı programlarını mümkünse kablolu bağlantıdan kullanın.

Güvenlik yazılımı da sık atlanan bir sebeptir. Sunucudaki antivirüs, veritabanı dosyalarını (SQL Server için .mdf, .ldf; Firebird için .fdb veya .gdb) her erişimde tarıyorsa disk yükü katlanır. Üreticinin önerdiği klasör ve dosya istisnalarını tanımlayın.

Disk: en sık rastlanan darboğaz

Veritabanı sunucusunda işlemci çoğu zaman boştadır, disk ise sürekli çalışır. Kontrol için sunucuda Görev Yöneticisi > Performans > Disk ekranına ya da Kaynak İzleyicisi'nde (resmon) Disk sekmesine bakın.

  • Etkin süre sürekli yüzde yüze yakınsa ve "Yanıt süresi" sütununda değerler onlarca milisaniyenin üzerindeyse disk yetişemiyordur.
  • Veritabanı hâlâ mekanik (HDD) bir diskte duruyorsa, SSD'ye geçmek genellikle tek başına en büyük farkı yaratır.
  • Disk dolulukla da yavaşlar. Veritabanının bulunduğu sürücüde boş alan yüzde 15–20'nin altına düştüyse önce yer açın.
  • Diskin sağlığını da kontrol edin: RAID denetleyicisinde uyarı, SMART hatası veya olay günlüğünde disk hataları varsa yavaşlık, arızanın habercisi olabilir.
Ticari program veritabanı yavaşladığında sırayla yapılacak disk, RAM, bakım ve log kontrolleri
Sunucu değiştirmeden önce bu beş adımı sırayla tamamlayın.

RAM: veritabanı motorunun ne kadar bellek kullandığı

Veritabanları sık kullanılan veriyi bellekte tutar; bellek yetmezse aynı veri tekrar tekrar diskten okunur.

SQL Server

SQL Server varsayılan ayarda bulabildiği belleği alır. Aynı sunucuda başka programlar da çalışıyorsa SQL Server Management Studio'da sunucu adına sağ tıklayıp Özellikler > Bellek bölümünden "Maksimum sunucu belleği" değerini işletim sistemine ve diğer servislere yer bırakacak şekilde ayarlayın. SQL Server Express kullanılıyorsa sınırları akılda tutun: veritabanı başına 10 GB boyut sınırı vardır, kullanabileceği önbellek belleği ve işlemci çekirdeği de kısıtlıdır. Veritabanı bu sınıra yaklaştıysa sorun ayardan çok sürümdedir.

MySQL / MariaDB

InnoDB tablolar için en önemli ayar innodb_buffer_pool_size değeridir. Varsayılan değer küçük bir sunucuya göre ayarlıdır; veritabanına ayrılmış bir sunucuda bu değerin toplam belleğin önemli bir kısmına çıkarılması gerekir.

Firebird

Firebird'de önbellek ayarları firebird.conf dosyasında ve sunucu mimarisine (SuperServer, Classic, SuperClassic) göre farklı çalışır. Ayarı değiştirmeden önce programın üreticisinin önerdiği değerlere bakın.

Bakım: indeks, istatistik ve sweep

Veritabanı hiç bakım görmeden yıllarca çalışabilir, ama zamanla yavaşlar.

  • SQL Server: İndekslerin parçalanması ve eskiyen istatistikler sorgu planlarını bozar. Haftalık bir bakım planında indeks yeniden düzenleme/yeniden oluşturma ve istatistik güncelleme bulunmalıdır. "Auto Shrink" özelliği açıksa kapatın; sürekli küçültme-büyütme performansı düşürür.
  • Firebird: Eski kayıt sürümleri birikir. Düzenli sweep yapılmalı, belirli aralıklarla da gbak ile yedek alınıp geri yüklenerek veritabanı derlenmelidir. Veritabanı başlık bilgisini gstat -h ile görüp en eski aktif işlem ile sonraki işlem numarası arasındaki farkın açılıp açılmadığına bakılabilir.
  • MySQL: Yavaş sorgu günlüğünü (slow query log) açmak, hangi sorgunun yavaş olduğunu doğrudan gösterir. Çok fazla silme yapılan tablolarda OPTIMIZE TABLE yer kazandırır.
Bakım işlemleri çalışma saatlerinde sunucuyu ağırlaştırır ve bazıları tabloları kilitler. Gece veya hafta sonu, öncesinde de mutlaka yedek alınarak yapılmalıdır.

Büyüyen log dosyası: SQL Server'da sık görülen sessiz sorun

Veri dosyası birkaç GB iken log dosyası (.ldf) onlarca GB'a çıkmışsa sebep çoğu zaman aynıdır: veritabanı FULL kurtarma modelindedir ama log yedeği alınmamaktadır. Log, yedeklenmeden boşalmaz ve diski doldurana kadar büyür. İki çıkış yolu var:

  1. Gün içinde belirli bir dakikaya geri dönebilmek istiyorsanız düzenli log yedeği planlayın. Tam, fark ve log yedeği kurgusunu SQL Server yedekleme stratejisi yazımızda anlattık.
  2. Gece alınan tam yedek yeterliyse kurtarma modelini SIMPLE yapın, ardından log dosyasını bir kez makul boyuta küçültün.

Dosya otomatik büyüme ayarlarına da bakın: yüzde 10 gibi oransal büyüme, büyük dosyalarda her seferinde uzun beklemeye yol açar; sabit MB değeri daha öngörülebilirdir.

SQL Server, Firebird ve MySQL veritabanında performans için temel kontrollerin karşılaştırma tablosu
Motor farklı olsa da sıra aynıdır: bellek, düzenli bakım ve büyüyen dosyaların takibi.

Sunucu ne zaman değişmeli?

Yukarıdaki kontroller yapıldıktan sonra hâlâ yavaşlık varsa donanım konuşulmalı. Değişim gerektiren işaretler:

  • Veritabanı SSD'ye taşınamıyor, sunucuda boş yuva veya uyumlu disk yok.
  • Sunucunun desteklediği azami RAM'e ulaşılmış.
  • İşletim sistemi veya SQL Server sürümü artık güvenlik güncellemesi almıyor.
  • Donanım garantisi ve yedek parça bulunabilirliği bitmiş, disklerde uyarı başlamış.
  • Aynı sunucu hem veritabanı, hem dosya paylaşımı, hem uzak masaüstü işi yapıyor ve yük ayrılamıyor.

Değişim kararı verildiyse taşımayı yedekten geri yükleyerek, programın üreticisinin desteklediği sürümlerle ve iş saatleri dışında planlayın.

Veritabanı bakımı ve sunucu taşıma işlerini sunucu kurulum ve bakım kapsamında yapıyoruz; SQL Server, MySQL ve Firebird veritabanlarınızın her gün şifreli ve farklı lokasyonlara yedeklenmesi için de kendi veritabanı yedekleme yazılımımız var. Tokat dışındaki ilçelerde ilk incelemeyi uzaktan bağlanarak yapıyoruz; 0 356 214 70 65'ten ya da WhatsApp hattımızdan ulaşabilirsiniz.

Sık sorulan sorular

SQL Server log dosyası neden sürekli büyüyor?
Veritabanı tam (FULL) kurtarma modelindeyse ve düzenli log yedeği alınmıyorsa log dosyası boşalmaz ve büyümeye devam eder. Ya düzenli log yedeği planlanmalı ya da nokta zamanlı geri dönüş gerekmiyorsa basit (SIMPLE) modele geçilmelidir.
SQL Server Express ticari program için yeterli mi?
Küçük veritabanlarında yeterlidir, ama Express sürümünde veritabanı başına 10 GB boyut sınırı vardır ve kullanabileceği bellek ile işlemci çekirdeği sınırlıdır. Veritabanı bu sınıra yaklaşıyorsa ya da kullanıcı sayısı arttıysa Standard sürüm düşünülmelidir.
Firebird veritabanında sweep ne işe yarar?
Sweep, artık kullanılmayan eski kayıt sürümlerini temizler. Uzun süre sweep yapılmayan veya hiç yedekten geri yüklenmeyen Firebird veritabanlarında bu birikim yavaşlamaya yol açabilir; gbak ile yedek alıp geri yüklemek de veritabanını derler.
Sunucuya RAM eklemek yavaşlığı çözer mi?
Sorun bellek yetersizliğiyse belirgin fark eder. Ama yavaşlık eski bir mekanik diskten, bakımı yapılmamış indekslerden veya ağdan kaynaklanıyorsa RAM eklemek tek başına çözmez; önce darboğazın nerede olduğu ölçülmelidir.

Bu konuda destek mi lazım?

Windows Server ve Linux sunucu kurulumu, bakım ve optimizasyon, Veeam yedekleme, IIS yapılandırması ile SQL Server, MySQL ve Firebird…

Sunucu Kurulum ve Bakım Hizmetleri
Blog

İlgili yazılar