Linux Sunucularda Ulimit Nedir? Kaynak Limitleri ve Süreç Yönetimi Rehberi

Son Güncelleme: Nisan 2026

Ulimit, Linux sunucularda bir kullanıcıya veya sürece uygulanabilecek kaynak limitlerini belirlemek için kullanılan temel mekanizmalardan biridir. Özellikle hosting, VPS/VDS, uygulama sunucuları ve çok kullanıcılı sistemlerde; açık dosya sayısı, süreç limiti, bellek kullanımı ve çekirdek dökümü gibi kritik sınırların doğru yönetilmesi, performans ve güvenlik açısından büyük önem taşır.

İçindekiler

• Ulimit Nedir?
• Ulimit Neden Önemlidir?
• Soft ve Hard Limit Arasındaki Fark
• Temel Ulimit Parametreleri
• Mevcut Limitleri Görüntüleme
• Geçici Olarak Ulimit Değiştirme
• Kalıcı Limit Tanımlama
• systemd ile Limit Yönetimi
• Pratik Kullanım Senaryoları
• Yaygın Hatalar ve Çözümler
• En İyi Uygulamalar
• Sıkça Sorulan Sorular
• Sonuç

Ulimit Nedir?

Ulimit, Linux ve Unix benzeri işletim sistemlerinde kabuk (shell) üzerinden süreçlere uygulanabilen kaynak sınırlarını gösteren ve değiştiren bir mekanizmadır. Bu yapı sayesinde bir kullanıcının veya uygulamanın sistem kaynaklarını aşırı tüketmesi önlenebilir.

Örneğin bir web uygulaması aynı anda çok fazla dosya açmaya çalışıyorsa, düşük bir open files limiti nedeniyle hata verebilir. Benzer şekilde, bir servis aşırı sayıda alt süreç (child process) üretirse sistem kararsız hale gelebilir. İşte bu noktada ulimit yapılandırması devreye girer.

Özellikle Linux Hosting altyapılarında, çok sayıda kullanıcı veya uygulama aynı sunucuyu paylaştığında kaynakların dengeli dağıtılması gerekir. Bu tür senaryolarda doğru planlanmış limitler, hem istikrarı hem de güvenliği artırır. Uygulama veya sanal sunucu ihtiyacınız için Linux Hosting ve Sanal Sunucu çözümleri değerlendirilebilir.

Ulimit Neden Önemlidir?

Kaynak limitleri, yalnızca performans ayarı değildir; aynı zamanda sistem dayanıklılığı ve operasyonel güvenlik açısından kritik bir kontrol katmanıdır.

• Kaynak tükenmesini önler: Tek bir uygulamanın tüm dosya tanıtıcılarını (file descriptor) tüketmesini engeller.
• Kararlılığı artırır: Süreç, bellek ve çekirdek dökümü limitleri sayesinde sistem genelinde kontrol sağlanır.
• Çok kiracılı yapılarda faydalıdır: Aynı sunucuda birden fazla müşteri, site veya servis çalışıyorsa izolasyon katkısı sağlar.
• Güvenliği destekler: Hatalı veya kötü niyetli süreçlerin aşırı kaynak tüketmesi sınırlandırılabilir.
• Uygulama uyumluluğunu artırır: Yüksek bağlantı alan Nginx, Apache, veritabanı ve Node.js servisleri için uygun limitler gerekir.

Özellikle yüksek trafikli projelerde yalnızca CPU ve RAM değil, açık dosya ve süreç limitleri de darboğaz oluşturabilir. Bu nedenle performans sorunlarında ulimit kontrolleri mutlaka değerlendirilmelidir.

Soft ve Hard Limit Arasındaki Fark

Linux sistemlerde ulimit değerleri genellikle iki seviyede değerlendirilir: soft limit ve hard limit.

Basitçe ifade etmek gerekirse, soft limit kullanıcının şu anda kullandığı sınır, hard limit ise çıkabileceği tavan değerdir. Bu yapı, kontrolsüz değişikliklerin önüne geçer.

Temel Ulimit Parametreleri

Ulimit ile yönetilebilen pek çok kaynak türü vardır. Ancak sunucu yönetiminde en sık karşılaşılan parametreler aşağıdakilerdir:

• -n: Açık dosya sayısı (open files). Web sunucuları ve veritabanları için kritik değerdir.
• -u: Kullanıcının oluşturabileceği maksimum süreç (process) sayısıdır.
• -c: Çekirdek dökümü (core dump) boyutunu belirler.
• -f: Oluşturulabilecek maksimum dosya boyutunu sınırlar.
• -s: Yığın bellek (stack size) sınırını tanımlar.
• -l: Kilitlenebilen bellek (locked memory) miktarını ayarlar.
• -v: Sanal bellek (virtual memory) sınırını ifade eder.
• -t: CPU süresi (CPU time) sınırını belirler.

Her parametre her senaryoda aktif olarak kullanılmasa da özellikle -n ve -u ayarları, üretim ortamlarında en çok müdahale edilen değerlerdir.

Mevcut Limitleri Görüntüleme

Bir Linux sunucuda mevcut limitleri görmek için kabuk üzerinden çeşitli komutlar kullanılabilir. En pratik yöntemlerden biri aşağıdaki komutlardır:

ulimit -a

Bu komut, aktif oturum için geçerli olan tüm limitleri listeler. Sadece açık dosya sayısını görmek için:

ulimit -n

Süreç limitini görmek için:

ulimit -u

Belirli bir çalışan sürecin limitlerini incelemek için /proc yapısı da kullanılabilir:

cat /proc/PID/limits

Buradaki PID kısmına ilgili uygulamanın süreç numarası yazılır. Bu yöntem özellikle servis bazlı hata analizlerinde oldukça faydalıdır.

Geçici Olarak Ulimit Değiştirme

Geçici değişiklikler, yalnızca mevcut oturum veya ilgili kabuk süreci için geçerlidir. Oturum kapandığında ayarlar kaybolur.

Örneğin açık dosya limitini geçici olarak 65535 yapmak için:

ulimit -n 65535

Süreç limitini değiştirmek için:

ulimit -u 4096

Bu yaklaşım, test ortamlarında veya hızlı doğrulama işlemlerinde işe yarar. Ancak üretim ortamlarında kalıcı yapılandırma tercih edilmelidir. Aksi halde sistem yeniden başlatıldığında veya servis yeniden yüklendiğinde eski değerlere dönülür.

Kalıcı Limit Tanımlama

Linux sistemlerde kalıcı ulimit ayarları çoğunlukla /etc/security/limits.conf veya /etc/security/limits.d/ altındaki dosyalar üzerinden yapılır. Bu dosyalar, PAM (Pluggable Authentication Modules - Takılabilir Kimlik Doğrulama Modülleri) oturumları için limit tanımlamada kullanılır.

Örnek bir yapılandırma aşağıdaki gibidir:

* soft nofile 65535
* hard nofile 65535
* soft nproc 4096
* hard nproc 8192

Belirli bir kullanıcı için tanım yapmak da mümkündür:

www-data soft nofile 65535
www-data hard nofile 65535

Bu satırlarda:

• İlk alan: Kullanıcı adı veya grup bilgisidir.
• İkinci alan: soft ya da hard limit türüdür.
• Üçüncü alan: Limit tipi, örneğin nofile veya nproc.
• Dördüncü alan: Uygulanacak sayısal değerdir.

Değişikliklerden sonra kullanıcının yeniden oturum açması gerekebilir. Bazı servislerde ise yalnızca kullanıcı oturumu değil, servis yöneticisi yapılandırması da ayrıca güncellenmelidir.

systemd ile Limit Yönetimi

Modern Linux dağıtımlarının büyük bölümünde servisler systemd ile yönetilir. Bu nedenle sadece limits.conf dosyasını değiştirmek her zaman yeterli olmaz. Özellikle Nginx, Apache, MySQL, Redis, Elasticsearch veya özel uygulama servislerinde systemd unit ayarları da kontrol edilmelidir.

Bir servis için açık dosya limitini artırmak amacıyla override dosyası oluşturulabilir:

systemctl edit nginx

Açılan dosyaya şu yapı eklenebilir:

[Service]
LimitNOFILE=65535
LimitNPROC=8192

Ardından yapılandırma yeniden yüklenir ve servis yeniden başlatılır:

systemctl daemon-reload
systemctl restart nginx

Bu yöntem, servis bazında daha güvenilir ve daha öngörülebilir bir limit yönetimi sağlar. Özellikle yüksek bağlantılı web uygulamalarında yalnızca kullanıcı bazlı ayar değil, servis bazlı limit tanımı da yapılmalıdır.

Pratik Kullanım Senaryoları

1. Yüksek Trafikli Web Sunucularında Açık Dosya Limiti

Nginx veya Apache gibi web sunucuları aynı anda binlerce istemci bağlantısı aldığında her bağlantı için dosya tanıtıcısı kullanabilir. Bu limit düşükse too many open files hatası görülür. Bu durumda nofile değeri artırılmalıdır.

2. Worker Tabanlı Uygulamalarda Süreç Limiti

Queue worker, arka plan işleyici veya çoklu süreç mimarisi kullanan uygulamalarda nproc limiti kritik hale gelir. Düşük limitler, yeni süreç oluşturulamamasına ve işlerin kuyrukta birikmesine neden olabilir.

3. Veritabanı Sunucularında Bağlantı Yoğunluğu

MySQL, MariaDB veya PostgreSQL gibi veritabanı servisleri; eşzamanlı bağlantı sayısı arttıkça daha fazla dosya tanıtıcısına ihtiyaç duyar. Bu nedenle veritabanı ayarları ile işletim sistemi limitleri birbiriyle uyumlu olmalıdır.

4. Geliştirme ve Test Ortamlarında Çekirdek Dökümü

Uygulama çökme analizlerinde core dump dosyaları yararlı olabilir. Ancak üretim ortamında bu dosyalar hem disk alanı tüketebilir hem de hassas veri riski doğurabilir. Bu nedenle geliştirme ve üretim ayarları ayrı düşünülmelidir.

5. Sanal Sunucu ve Uygulama Sunucularında Kaynak Planlaması

VPS, VDS veya özel amaçlı uygulama sunucularında limitler; barındırılan servisin türüne göre planlanmalıdır. Eğer yoğun uygulama çalıştıran bir yapı kuruyorsanız Uygulama Sunucuları, sanallaştırılmış kaynak ihtiyacı için Türkiye VDS Sunucu ve daha esnek kullanım için Bulut Sunucu seçenekleri değerlendirilebilir.

Yaygın Hatalar ve Çözümler

Too many open files

En sık görülen ulimit kaynaklı hatalardan biridir. Genellikle web sunucuları, veritabanları, log işleyicileri veya yoğun dosya erişimi yapan uygulamalarda ortaya çıkar. Çözüm için hem kabuk bazlı hem de systemd bazlı nofile değerleri kontrol edilmelidir.

fork: Resource temporarily unavailable

Bu hata çoğunlukla süreç limiti aşıldığında görülür. Özellikle yanlış yapılandırılmış worker süreçleri veya döngüye giren komutlar bu soruna neden olabilir. nproc değeri incelenmeli, ayrıca uygulamanın neden bu kadar çok süreç açtığı analiz edilmelidir.

Servis yeniden başladıktan sonra limitin eskiye dönmesi

Bu durumda çoğu zaman yalnızca ulimit komutu ile geçici değişiklik yapılmıştır. Kalıcı çözüm için limits.conf, limits.d ve systemd override yapılandırmaları birlikte gözden geçirilmelidir.

limits.conf değişti ama etki etmedi

Bunun nedeni ilgili oturumun PAM üzerinden açılmaması veya servisin doğrudan systemd tarafından farklı limitlerle başlatılması olabilir. Özellikle daemon servislerde systemd limitleri daha belirleyicidir.

En İyi Uygulamalar

• Ölçmeden artırmayın: Rastgele çok yüksek limitler vermek yerine uygulamanın gerçek ihtiyacını izleyin.
• Servis bazlı yaklaşın: Her uygulamanın ihtiyacı farklıdır; tüm sisteme tek tip ayar uygulamayın.
• systemd kontrolü yapın: Modern dağıtımlarda servis limitlerini ayrıca doğrulayın.
• Log ve izleme kullanın: Hata kayıtları ve metrikler üzerinden limit kaynaklı darboğazları tespit edin.
• Güvenliği unutmayın: Özellikle çok kullanıcılı sistemlerde gereksiz yüksek süreç limitleri risk oluşturabilir.
• Test ortamında doğrulayın: Üretime almadan önce yük testi ile limitlerin yeterliliğini kontrol edin.

Doğru yapılandırılmış limitler, yalnızca performansı değil operasyonel öngörülebilirliği de artırır. Bu nedenle ulimit ayarları, sunucu kurulum kontrol listesinde mutlaka yer almalıdır.

Sıkça Sorulan Sorular

Sonuç

Ulimit, Linux sunucularda süreçlerin ve kullanıcıların sistem kaynaklarını nasıl tüketeceğini belirleyen temel yönetim araçlarından biridir. Açık dosya sayısı, süreç limiti, çekirdek dökümü ve bellek sınırları gibi değerlerin doğru yapılandırılması; hem performans sorunlarını azaltır hem de sistem istikrarını güçlendirir.

Özellikle üretim ortamlarında yalnızca uygulama ayarlarını değil, işletim sistemi ve servis limitlerini birlikte düşünmek gerekir. İster web projesi, ister veritabanı servisi, ister arka plan işleyici çalıştırıyor olun; doğru kaynak planlaması için altyapının da doğru seçilmesi önemlidir. Bu noktada Kiralık Sunucu, Sanal Sunucu, Hosting ve Yedekleme Hizmeti çözümleriyle Corelux, farklı ölçeklerdeki projeler için güçlü bir altyapı sunar.