SQL Too Many Open Files Sorunu ve Çözümü

0 Yanıt 2 Görüntülenme
Puanlayanlar
Katılımcılar
Konuyu Açan #1
SQL Too Many Open Files Sorunu ve Çözümü

Bir veritabanı sunucusunda “Too many open files” hatasıyla karşılaşmak, çoğu zaman sistem limitiyle veritabanı süreci arasındaki uyumsuzluktan kaynaklanır. Bu yazıda, hatanın kökenini adım adım analiz eder, temel konfigürasyon değişikliklerini ve uygulama düzeyinde alınabilecek önlemleri somut örneklerle ortaya koyarım. Amacım, hatayı oluşturan mekanizmayı netleştirerek kalıcı bir çözüme ulaşmanıza destek olmak.


  • Olayın nereden kaynaklandığını belirlemek
    Veritabanı sunucunuzda “Too many open files” hatası geldiğinde, ilk adım hangi süreçlerin fazla dosya açtığını tespit etmektir. Linux ortamında genelde mysqld, mariadb veya postgres süreçleri bu hataya yol açar. Log dosyalarında, açılan dosya descriptor sayısının limitleri aştığına dair mesajlar bulunur. Sistem tarafında ise, /proc/sys/fs/file-max veya kullanıcı başına limitler (ulimit -n) bu sınırları belirler. Örneğin, bir MySQL sunucusu yoğun bağlantı talebi altında açılan dosya tanımlayıcılarını hızla doldurabilir.
  • Sistem limitlerini incelemek ve yükseltmek
    Çözüm süreci iki katmanda ilerler:
    i) Çalışan süreç kısıtlamaları: ulimit -n komutu ile mevcut kullanıcı için açık dosya limitini kontrol edin. Genelde mysql kullanıcısı için 1024 veya 4096 değerleri kullanılır. Bunu kalıcılaştırmak için /etc/security/limits.conf dosyasına şu satırları ekleyin:
    mysql soft nofile 65535
    mysql hard nofile 65535
    ii) Sistem genel limiti: /etc/sysctl.conf dosyasına fs.file-max değeri eklenir veya mevcut değeri artırılır. Ardından sysctl -p ile uygulanır. Ayrıca açık dosya yöneticisi tablosunun boyutu da artırılabilir:
    fs.inotify.max_user_watches=524288
    fs.file-max = 1000000
  • Veritabanı konfigürasyonu ve bağlantı havuzu
    Bağlantı havuzunun doğru konfigüre edilmesi kritik. Çok sayıda kısa ömürlü bağlantı, açılan dosya descriptor’larını hızla tüketir. Aşağıdaki ayarlar gözden geçirilebilir:
    • MySQL/MariaDB için:

    max_connections, table_open_cache, open_files_limit değerleri artırılabilir.
    open_files_limit = 65535
    table_open_cache = 5120 veya daha yüksek değerler
    connect_timeout ve wait_timeout süreleriyle aşırı bağlantı açılmasının önüne geçilir.
    • PostgreSQL için:

    max_connections, shared_buffers, max_files_per_backend gibi parametreler ince ayara tabi tutulur. open_files_limit benzeri bir parametre PostgreSQL’de otomatik değildir; işletim sistemi limiti ile uyumlu olması gerekir.
  • Uygulama düzeyi tedbirler
    • Bağlantı havuzunu doğru ölçeklendirmek: too many connections problemi, havuz büyüklüğünün sistem limitlerini zorlamasıyla da ortaya çıkar. Uygulama tarafında bağlantı havuzunu izlemek, maksimum bağlantı sayısını loglarda takip etmek ve gerektiğinde dinamik olarak küçültmek gerekir.
    • Uzun süren işlemleri optimize etmek: büyük batch işlemleri veya bekleyen sorgular, açık dosya descriptor’larını meşgul eder. Sorguları azaltmak, indeksleri iyileştirmek ve gerektiğinde partitioning ile çalışma yoğunluğunu dağıtmak faydalı olur.
  • Gözden geçirme ve izleme rutini kurmak
    • Periyodik olarak/open_files ve fds gibi değerler izlemek için tetikleyiciler kurun. Sunucuya her gün veya hafta sonunda bakımlar ekleyin; özellikle güncelleme sonrası dosya descriptor sayısında ani artışlar ortaya çıkarsa, konfigürasyonları yeniden değerlendirip test edin.
  • Kapsamlı örnek senaryo
    Bir kullanıcı, yoğun bir satış sezonunda PostgreSQL çalıştıran bir sunucuda open files hatası alıyordu. Kaynak analizinde: ulimit 1024, fs.file-max 100000, open_files_per_backend gibi benzer parametreler düşüktu. Sistemin genel limitini yükselttik, PostgreSQL için max_connections değerini düşürüp, çalışan bağlantı havuzunu optimize ettik. Sonuç olarak, hatadan kurtulduk ve performans istikrarlı kaldı.


Sonuç olarak, Too Many Open Files hatası, hem işletim sistemi seviyesinde limitlerin hem de veritabanı ile uygulama arasındaki etkileşimin uyumsuzluğundan doğabilir. Sistem ve veritabanı konfigürasyonlarının uyumlu bir şekilde genişletilmesi, izleme ve bakım routine’larının oluşturulması, bu tür hataların tekrarını önlemek için en güvenli yoldur. Yukarıdaki adımları, kendi ortamınıza göre adım adım uygulayın ve sonuçları dikkatlice izleyin.

Yanıt vermek için giriş yapmış olmalısınız.

Bu konuyu görüntüleyen kullanıcılar (Toplam: 5, Üyeler: 5, Misafirler: 0)
Toplam: 5 (üyeler: 5, misafirler: 0)
0 alıntı seçildi