Linux’ta `ulimit` Komutu ile Sistem Kaynaklarını Yönetme

`ulimit` komutu, Unix ve Linux sistemlerinde yerleşik bir kabuk yardımcı programıdır; işlem başına ve kullanıcı başına kaynak sınırlarını uygulayarak tek bir işlemin veya kullanıcının CPU süresi, bellek, açık dosya tanımlayıcıları ve işlem sayısı gibi sistem kaynaklarını tüketmesini önler. `setrlimit()` sistem çağrısı aracılığıyla çekirdek düzeyinde çalışır ve bu da onu sistem yöneticilerinin kaynak yönetimi için kullanabileceği en doğrudan ve düşük ek yüklü mekanizmalardan biri haline getirir.

Yoğun trafikli bir web uygulaması, veritabanı motoru veya konteynerleştirilmiş mikro hizmet yığını olsun, üretim iş yükü çalıştıran herhangi bir sunucuda yanlış yapılandırılmış veya eksik `ulimit` ayarları, zincirleme arızaların, kontrolden çıkmış işlemlerin ve tam sistem kesintilerinin başlıca nedenidir. Bu sınırları doğru ayarlamak isteğe bağlı değildir; temel altyapı hijyenidir.

`ulimit` Arka Planda Nasıl Çalışır

Bir kabuk işlemi `ulimit` çağırdığında, POSIX standardında tanımlanan `getrlimit()` ve `setrlimit()` sistem çağrılarını başlatır. Her sınır, bir çift değer olarak temsil edilir: yumuşak sınır ve sert sınır. Bunlar, çekirdek işlem tanımlayıcısında işlem başına depolanır ve `fork()` zamanında alt işlemler tarafından miras alınır.

Bu miras modeli kritik öneme sahiptir. Bir kabuk oturumunda `ulimit` değerleri ayarlarsanız, init betikleri aracılığıyla başlatılan daemon’lar dahil olmak üzere o kabuktan oluşturulan her işlem bu sınırları miras alır. Tersine, `/etc/security/limits.conf` içinde ayarlanan sınırlar çalışma zamanında değil, PAM oturum açma zamanında uygulanır; bu da yalnızca yeni oturum açma oturumları için geçerli olduğu ve halihazırda çalışan hizmetleri etkilemediği anlamına gelir.

Yumuşak Sınırlar ve Sert Sınırlar

Yaygın bir operasyonel hata, sert sınırı yumuşak sınıra eşit olarak ayarlamaktır. Bu, bir işlemin kendi sınırlarını geçici olarak yükseltmesi için tüm esnekliği ortadan kaldırır; bazı uygulamalar (belirli JVM uygulamaları ve veritabanı motorları gibi) bunu başlatma sırasında meşru olarak yapar.

Tam Referans: `ulimit` Kaynak Bayrakları

Gerçek Dünya Bağlamıyla Pratik `ulimit` Kullanımı

Mevcut Sınırları Görüntüleme

“`bash

ulimit -a # All soft limits for the current shell

ulimit -aH # All hard limits for the current shell

“`

Belirli bir çalışan işlemin (PID) sınırlarını incelemek için doğrudan proc dosya sisteminden okuyun — bu yetkili kaynaktır ve kabuk düzeyindeki raporlamayı atlar:

“`bash

cat /proc/<PID>/limits

“`

Bu, systemd veya bir init betiği tarafından başlatılan bir hizmetin sorunlarını giderirken son derece değerlidir; kabuk düzeyindeki `ulimit -a` işlemin gerçek sınırlarını yansıtmaz.

Yumuşak ve Sert Sınırları Ayarlama

“`bash

Set soft limit for open file descriptors

ulimit -Sn 65536

Set hard limit for open file descriptors

ulimit -Hn 131072

Set both simultaneously (soft = hard = value)

ulimit -n 65536

“`

Üretimde Çekirdek Dökümlerini Devre Dışı Bırakma

“`bash

ulimit -c 0

“`

Çekirdek dökümleri, yüksek bellekli bir işlem çöktüğünde saniyeler içinde gigabaytlarca disk alanı tüketebilir. Aktif olarak hata ayıklamıyorsanız, bunları üretimde devre dışı bırakmak standart bir uygulamadır. Geliştirme ortamları için, sıfır olmayan bir çekirdek sınırıyla birlikte `sysctl kernel.core_pattern` kullanarak özel bir yol belirleyin.

Güvenilmeyen İşlemler için CPU Süresini Kısıtlama

“`bash

ulimit -t 30

“`

Bu, işlem yumuşak CPU süresi sınırına ulaştığında `SIGXCPU` gönderir ve sert sınırda `SIGKILL` gönderir. Bu, özellikle paylaşımlı barındırma ortamlarında veya kullanıcı tarafından gönderilen betikler çalıştırılırken kullanışlıdır.

Yüksek Eşzamanlılıklı Hizmetler için Açık Dosya Tanımlayıcı Sınırını Yükseltme

Nginx, HAProxy, PostgreSQL ve Redis, yük altında çok sayıda açık dosya tanımlayıcısı gerektirir. Sistem genelindeki varsayılan 1024 değeri üretim için tehlikeli derecede düşüktür:

“`bash

ulimit -n 65536

“`

Ancak bu yalnızca mevcut kabuk oturumunu etkiler. Kalıcı yapılandırma için bir sonraki bölümde açıklanan yöntemleri kullanın.

`ulimit` Ayarlarını Kalıcı Hale Getirme

Yöntem 1: `/etc/security/limits.conf`

Bu, kullanıcı düzeyinde kalıcı sınırlar için standart PAM tabanlı yaklaşımdır:

“`

/etc/security/limits.conf

<domain> <type> <item> <value>

• soft nofile 65536
• hard nofile 131072

nginx soft nproc 4096

nginx hard nproc 8192

postgres soft nofile 65536

postgres hard nofile 65536

postgres soft memlock unlimited

postgres hard memlock unlimited

“`

`*` joker karakteri tüm kullanıcılar için geçerlidir ancak root için geçerli değildir. Root için açık bir giriş gereklidir:

“`

root soft nofile 65536

root hard nofile 131072

“`

PAM modülünün yüklendiğinden emin olun. `/etc/pam.d/common-session` (Debian/Ubuntu) veya `/etc/pam.d/system-auth` (RHEL/CentOS) dosyasının şunları içerdiğini doğrulayın:

“`

session required pam_limits.so

“`

Yöntem 2: `/etc/security/limits.d/` Eklenti Dosyaları

Özellikle Ansible veya Puppet gibi yapılandırma yönetim sistemlerinde daha temiz yönetim için, hizmete özgü sınır dosyalarını eklenti dizinine yerleştirin:

“`bash

/etc/security/limits.d/99-nginx.conf

nginx soft nofile 65536

nginx hard nofile 131072

“`

Bu dizindeki dosyalar `limits.conf` dosyasından sonra işlenir ve onu geçersiz kılar; bu da temel yapılandırmayı değiştirmeden uygulamaya özgü ayarlama için ideal hale getirir.

Yöntem 3: systemd Hizmet Birimleri (Modern Standart)

systemd tarafından yönetilen hizmetler için — ki bu modern Linux dağıtımlarının büyük çoğunluğudur — `limits.conf` varsayılan olarak uygulanmaz. systemd, hizmet birimi başına kendi kaynak sınırlarını yönetir:

“`ini

/etc/systemd/system/nginx.service.d/limits.conf

[Service]

LimitNOFILE=65536

LimitNPROC=4096

LimitCORE=0

LimitMEMLOCK=infinity

“`

Düzenledikten sonra yeniden yükleyin ve yeniden başlatın:

“`bash

systemctl daemon-reload

systemctl restart nginx

“`

Uygulanan sınırları doğrulayın:

“`bash

cat /proc/$(systemctl show -p MainPID nginx | cut -d= -f2)/limits

“`

Bu, üretim hizmetleri için en güvenilir yöntemdir ve systemd çalıştıran herhangi bir sistemde (Ubuntu 16.04+, CentOS 7+, Debian 8+) varsayılan yaklaşım olmalıdır.

Yöntem 4: Kabuk Profil Dosyaları

Etkileşimli olarak uygulanan kullanıcı oturumu sınırları için, `/etc/profile` (sistem genelinde) veya `~/.bashrc` / `~/.profile` (kullanıcı başına) dosyalarına `ulimit` komutları ekleyin. Bu yaklaşım geliştirici iş istasyonları için uygundur ancak daemon işlemleri için uygun değildir.

Role Dayalı `ulimit` Yapılandırma Profilleri

Farklı sunucu rolleri, temelden farklı kaynak sınırı profilleri gerektirir. Tüm sunucu türlerine genel varsayılanlar uygulamak, ince ve teşhis edilmesi zor arızaların yaygın bir kaynağıdır.

Web Sunucusu (Nginx / Apache)

“`

nofile: 65536–131072 # High concurrency requires many open sockets + files

nproc: 4096 # Worker processes + threads

core: 0 # Disable core dumps in production

“`

İlişkisel Veritabanı (PostgreSQL / MySQL)

“`

nofile: 65536 # Many concurrent connections = many file descriptors

memlock: unlimited # Required for shared memory and huge pages

nproc: 4096

stack: 8192 KB

core: 0

“`

Java Uygulama Sunucusu (Tomcat / Spring Boot)

“`

nofile: 65536

nproc: 65536 # JVM thread-per-connection models spawn many threads

data: unlimited # JVM heap is allocated from the data segment

stack: 512 KB # Reduce stack size to fit more threads in memory

“`

Redis / Bellek İçi Veri Deposu

“`

nofile: 65536

memlock: unlimited # Prevents swapping of memory-mapped data

“`

Kritik Tuzaklar ve Uç Durumlar

`nproc` sınırı yalnızca işlemleri değil, iş parçacıklarını da sayar. Linux’ta iş parçacıkları, hafif işlemler (paylaşılan bellekli `clone()`) olarak uygulanır. 500 iş parçacığına sahip bir Java uygulaması, `nproc` sınırına karşı 500 olarak sayılır. Bu durum, muhafazakâr `nproc` değerleri belirleyen ve ardından JVM’lerinin neden `OutOfMemoryError: unable to create new native thread` ile çöktüğünü merak eden birçok yöneticiyi şaşırtır.

`ulimit -v` fiziksel RAM’i değil, sanal adres alanını sınırlar. Birçok yönetici, bellek kullanımını sınırladıklarını düşünerek `-v` ayarlar. Gerçekte, bellek eşlemeli dosyaları, paylaşılan kütüphaneleri ve JVM meta alanını içeren sanal adres alanını sınırlarlar. Bunu çok düşük ayarlamak `mmap()` hatalarına ve anlaşılması güç uygulama hatalarına neden olur.

`ulimit` geriye dönük olarak uygulanmaz. `limits.conf` veya bir systemd birim dosyasındaki sınırları değiştirmek, halihazırda çalışan işlemleri etkilemez. Yeni sınırların geçerli olması için hizmeti yeniden başlatmanız gerekir.

Konteyner ortamları `ulimit`’yi beklenmedik şekillerde atlar. Docker’da `ulimit` varsayılanları daemon düzeyinde (`/etc/docker/daemon.json`) ayarlanır ve `–ulimit` ile konteyner başına geçersiz kılınabilir. Ancak konteynerin sınırları, ana çekirdek sınırlarıyla kısıtlıdır. Ana makinede `nofile=65536` varken bir konteynerde `nofile=1048576` ayarlamak, sessizce ana makine sınırına geri döner.

`nofile` sistem genelindeki tavan, işlem başına sınırlardan ayrıdır. `fs.file-max` çekirdek parametresi (`sysctl` aracılığıyla ayarlanır), tüm sistem genelindeki toplam dosya tanımlayıcı sayısını kontrol eder. İşlem başına `nofile` yüksek ayarlanmış olsa bile, `fs.file-max`’ye ulaşmak sistem genelinde `ENFILE` hatalarına neden olur. Her ikisini de kontrol edin ve ayarlayın:

“`bash

sysctl fs.file-max

sysctl -w fs.file-max=2097152

“`

`ulimit` ve cgroups: Doğru Aracı Seçmek

`ulimit`, hızlı oturum başına sınırlar, dosya tanımlayıcı üst sınırları ve çekirdek döküm kontrolü için doğru araç olmaya devam eder. Kapsamlı kaynak yalıtımı için — özellikle çok kiracılı ortamlarda veya konteynerleştirilmiş iş yüklerinde — cgroups v2 daha üstün bir mekanizmadır. İyi yapılandırılmış bir VPS Hosting veya Dedicated Server ortamında, her iki mekanizma da genellikle birlikte kullanılır: işlem başına koruma rayları için `ulimit` ve toplu kaynak bütçeleri için cgroups.

Kaynak Sınırlarını İzleme ve Doğrulama

Proaktif izleme, sınırla ilgili arızaların üretim olaylarına dönüşmesini önler.

Sistem genelinde mevcut dosya tanımlayıcı kullanımını kontrol edin:

“`bash

cat /proc/sys/fs/file-nr

Output: <allocated> <unused> <max>

“`

`nofile` sınırına yaklaşan işlemleri bulun:

“`bash

for pid in /proc/[0-9]*; do

pid_num=${pid##*/}

limit=$(awk '/Max open files/{print $4}' /proc/$pid_num/limits 2>/dev/null)

current=$(ls /proc/$pid_num/fd 2>/dev/null | wc -l)

[ -n "$limit" ] && [ "$limit" != "unlimited" ] &&

awk -v c=$current -v l=$limit -v p=$pid_num

'BEGIN{if(c/l>0.8) printf "PID %s: %d/%d (%.0f%%)n",p,c,l,c/l*100}'

done

“`

Süregelen izleme için araçlar:

• `lsof -u <username>` — bir kullanıcı için tüm açık dosyaları listeler
• `ss -s` — soket istatistikleri (`nofile` baskısıyla ilişkilendirilir)
• İşlem ağacı görünümüyle `htop` — kullanıcı başına işlem sayılarını görselleştirir
• `sar -v` — sysstat aracılığıyla geçmiş dosya tanımlayıcı ve inode kullanımı
• Prometheus `node_exporter` — uyarı için `node_filefd_allocated` ve `node_filefd_maximum` metriklerini açığa çıkarır

cPanel ile VPS veya diğer kontrol panellerini çalıştıran ortamlar için bu sınırların çoğu panel yükleyicisi tarafından önceden yapılandırılmıştır, ancak trafik arttıkça sıklıkla yukarı doğru ayarlanmaları gerekir. Panel belgelerine güvenmek yerine `/proc/<PID>/limits` üzerinden gerçek sınırları her zaman doğrulayın.

`ulimit`’nin Güvenlik Etkileri

Kaynak sınırları aynı zamanda bir güvenlik kontrolüdür. Bunlar olmadan, güvenliği ihlal edilmiş veya hatalı bir işlem, mevcut tüm işlem yuvalarını tüketen ve sistemi yanıt veremez hale getiren bir fork bomb (`:(){ :|:& };:`) gerçekleştirebilir. Kullanıcı başına muhafazakâr bir `nproc` sınırı, birincil azaltma yöntemidir:

“`

• hard nproc 4096

“`

Benzer şekilde, çekirdek dökümlerini devre dışı bırakmak (`-c 0`), şifreleme anahtarları, parolalar ve oturum belirteçleri dahil olmak üzere hassas bellek içeriklerinin dünya tarafından okunabilir bir dosyaya yazılmasını önler.

Paylaşımlı barındırma ortamları veya birden fazla kullanıcının kabuk erişimine sahip olduğu herhangi bir sunucu için `ulimit` zorunlu bir güvenlik katmanıdır. Paylaşımlı Web Hosting altyapısında bu sınırlar genellikle platform düzeyinde uygulanır, ancak kendi çok kullanıcılı VPS’lerini çalıştıran yöneticiler bunları açıkça yapılandırmalıdır.

Sunucunuz SSL sonlandırma veya sertifika yönetimi gerçekleştiriyorsa, TLS’yi işleyen işlemin (örneğin Nginx, HAProxy) yeterli `nofile` sınırlarına sahip olduğundan emin olun; zira her TLS bağlantısı birden fazla dosya tanımlayıcısı gerektirir. Bunu, sertifikayla ilgili bağlantı hatalarının kaynak sorunlarını daha da kötüleştirmesini önlemek için düzgün yapılandırılmış SSL Sertifikaları ile eşleştirin.

Posta sunucusu dağıtımları için Postfix ve Dovecot, her eşzamanlı e-posta bağlantısı ve posta kutusu erişimi dosya tanımlayıcıları tükettiğinden `nofile` sınırlarına özellikle duyarlıdır. Yönetilen E-posta Hosting kullanmak yerine kendi posta altyapınızı çalıştırıyorsanız, orta düzeyde yüklü herhangi bir sunucuda posta kullanıcısı için `nofile`’yi en az 65536’ya ayarlamak tartışmasız bir zorunluluktur.

Karar Matrisi: Ne Yapılandırılmalı ve Nerede

Teknik Temel Çıkarımlar Kontrol Listesi

• Çalışan hizmetler için kabuk düzeyindeki `ulimit -a` yerine her zaman `/proc/<PID>/limits` aracılığıyla uygulanan sınırları doğrulayın.
• systemd hizmetleri için, `Limit*` yönergelerini kullanarak birim dosyasında sınırları yapılandırın — `limits.conf` varsayılan olarak systemd tarafından okunmaz.
• Ağ bağlantılarını işleyen herhangi bir hizmet için `nofile`’yi en az `65536` olarak ayarlayın; yüksek eşzamanlılıklı iş yükleri için `131072` veya daha yüksek.
• Belirli bir güvenlik gereksinimiz olmadıkça sert sınırı yumuşak sınıra eşit olarak ayarlamayın — uygulamaların kendilerini ayarlamaları için alana ihtiyaçları vardır.
• Üretimde çekirdek dökümlerini devre dışı bırakın (`LimitCORE=0`); hazırlık ortamında kontrollü bir yolla etkinleştirin.
• `nproc` sınırı Linux’ta iş parçacıklarını sayar — JVM veya Go çalışma zamanı uygulamalarını yapılandırırken bunu göz önünde bulundurun.
• Sistem genelinde `ENFILE` tükenmesini önlemek için işlem başına `nofile` sınırlarıyla birlikte `sysctl` aracılığıyla `fs.file-max`’yi ayarlayın.
• Konteynerleştirilmiş ortamlarda, ana çekirdek sınırları sert tavandır — konteyner düzeyindeki `ulimit` ayarları bunları aşamaz.
• Bellek ve I/O uygulaması için cgroups v2 kullanın; dosya tanımlayıcı üst sınırları, işlem sayıları ve çekirdek döküm kontrolü için `ulimit` kullanın.
• `limits.conf` veya systemd birim dosyalarındaki herhangi bir sınır değişikliğinden sonra, etkilenen hizmeti yeniden başlatın ve `/proc/<PID>/limits` ile doğrulayın.

SSS

`ulimit` root işlemleri için geçerli midir?

`/etc/security/limits.conf` içindeki `*` joker karakteri root’u açıkça hariç tutar. Root işlemleri ayrıca çoğu kaynak türü için sert sınır uygulamasını atlar — root kendi sert sınırlarını yükseltebilir. Root’a sınır uygulamak için `limits.conf` içine açık bir `root` girişi ekleyin; ancak root olarak çalışan birçok sistem hizmeti, bir oturum açma oturumu dışında başlatılırsa PAM tarafından uygulanan sınırları yok sayar.

Neden `limits.conf` değişikliğim çalışan bir hizmette etkili olmuyor?

`limits.conf` PAM tarafından oturum açma zamanında uygulanır. systemd, SysVinit veya Upstart tarafından başlatılan hizmetler PAM’den geçmez ve bu nedenle `limits.conf` ayarlarını miras almaz. Sınırları doğrudan systemd birim dosyasında `LimitNOFILE` ve ilgili yönergeler kullanarak yapılandırın, ardından `systemctl daemon-reload && systemctl restart <service>` çalıştırın.

`nofile` için ayarlayabileceğim maksimum değer nedir?

İşlem başına maksimum, çekirdeğin `fs.nr_open` parametresiyle sınırlıdır (çoğu çekirdekte varsayılan: 1.048.576). Sistem genelindeki toplam `fs.file-max` ile sınırlıdır. `sysctl` aracılığıyla `fs.nr_open`’yi yükseltebilirsiniz, ancak 1.048.576’nın üzerindeki değerler eski çekirdeklerde çekirdek yeniden derlenmesini gerektirir. Pratikte, 524.288 veya 1.048.576 neredeyse tüm üretim kullanım durumlarını karşılar.

Bir işlemin `ulimit` sınırına ulaşıp ulaşmadığını nasıl kontrol edebilirim?

`dmesg | grep -i "ulimit|RLIMIT|too many open|cannot allocate"` ile çekirdek günlüğünü kontrol edin. Uygulama günlükleri genellikle `EMFILE` (çok fazla açık dosya), `ENOMEM` (bellek tahsis hatası) veya `EAGAIN` (kaynak geçici olarak kullanılamıyor) gösterir. `/proc/<PID>/limits` ve `ls /proc/<PID>/fd | wc -l` aracılığıyla mevcut tanımlayıcı sayısıyla çapraz referans yapın.

`ulimit` çok kiracılı bir ortamda kaynak yalıtımı için yeterli midir?

Hayır. `ulimit` işlem başına ve kullanıcı başına koruma rayları sağlar ancak bellek bant genişliği, disk I/O veya ağ verimi sınırlarını uygulamaz. Gerçek çok kiracılı yalıtım için `ulimit`’yi cgroups v2 kaynak denetleyicileriyle birleştirin ve daha güçlü güvenlik sınırları için ad alanı yalıtımını (kullanıcı ad alanları, PID ad alanları) göz önünde bulundurun. Yönetilen altyapıda bu kontroller genellikle hiper yönetici ve konteyner çalışma zamanı düzeyinde katmanlanır.