Yükleniyor
Trafik patlamalarinda veritabaninizin Linux OOM Killer tarafindan aniden oldurulmesini (mysqld/postgres crash) engelleyin. Baglanti basina RAM tuketimini ve guvenli max_connections sinirini olcun.
Baglanti adedi ve oturum tamponlarinin (sort_buffer / work_mem) OOM riskini simule edin.
Geriye kalan baglantilar bosta (idle/sleep) bekler ve yalnizca taban bellek tutar.
Baglantilarinizin tamami agir sorgu calistirsa bile sunucu fiziki bellek sinirlari icinde kalmaktadir.
OOM Killer riskini sifirlayan, hesaplanmis guvenli baglanti ve tampon limitleri.
# MySQL / MariaDB my.cnf Guvenli Baglanti ve Bellek Yapilandirmasi # Sunucu RAM: 8192 MB | Rol: Ayrilmis DB [mysqld] # Global Tamponlar innodb_buffer_pool_size = 4916M innodb_log_buffer_size = 16M key_buffer_size = 32M # Guvenli Baglanti Limiti max_connections = 250 max_connect_errors = 10000 # Baglanti Basina Guvenli Tamponlar (OOM Killer'dan Korunmak Icin Kucuk Tutun) thread_stack = 256K sort_buffer_size = 2048K join_buffer_size = 2048K read_buffer_size = 1024K read_rnd_buffer_size = 1024K binlog_cache_size = 32K # Gecici Tablolarin RAM Tasmasini Sinirla tmp_table_size = 64M max_heap_table_size = 64M
Pek cok sistem yoneticisi, web sitesinde "Too many connections" hatasi gordugunde cozum olarak dogrudanmax_connections = 1000 yapar ve yavas sorgulari cozmek icinsort_buffer_size = 32M gibi yuksek degerler tanimlar. Ancak bu degisiklikler, ani bir reklam kampanyasinda veya trafik sicramasinda veritabaninin fiziki RAM'den kat kat fazla bellek talep etmesine yol acar. Sistem RAM'i tukendiginde Linux cekirdegi en cok bellek tuketen sureci (genellikle mysqld veya postgres)aniden sonlandirir (SIGKILL).
MySQL her baglanti icin bir is parcacigi (thread) acar. Bir sorgu calistirildiginda; siralama icinsort_buffer_size, join islemleri icin join_buffer_size ve disk okumalari icinread_buffer_size baglanti basina dinamik olarak tahsis edilir. 500 baglanti ayni anda siralama yaptiginda bu tamponlar toplanarak onlarca gigabayt RAM tuketir.
PostgreSQL her istemci icin bagimsiz bir isletim sistemi prosesi (backend process) baslatir (~6-8 MB taban bellek). En kritik tehlike ise work_mem ayaridir: work_mem baglanti basina degil, sorgu icindeki her bir siralama ve hash islemi basina tahsis edilir. Karmasik bir SQL sorgusu 4 farkli join ve siralama iceriyorsa, tek bir baglanti 4 x work_mem bellek harcayabilir.
Temel kural sudur: Toplam Kullanilabilir RAM >= Global Tamponlar + (max_connections x Baglanti Basina Zirve Bellek). Eger sunucunuz 8 GB RAM'e sahipse ve MySQL Buffer Pool icin 5 GB ayirdiysaniz, baglantilar icin yalnizca ~1.5 GB guvenli alan kalir. Bu durumda baglanti basina 10 MB bellek tuketiliyorsa, guvenli azami baglanti siniri 150 civarinda tutulmalidir.
Binlerce eszamanli web kullanicisini karsilamak icin veritabaninin max_connections degerini binlere cikarmak yerine; onune PgBouncer (PostgreSQL icin) veya ProxySQL (MySQL icin) kurularak baglantilar 50 ila 100 kalici islemci uzerinde paylastirilmalidir. Bu sayede veritabaninin bellek tuketimi sabit kalir ve OOM cokmeleri imkansiz hale gelir.