--- title: "Cara Mengatur Batas File dan Proses dengan ulimit di Linux" description: "Kenali soft dan hard limit, cek batas proses yang berjalan, lalu naikkan batas file terbuka lewat limits.conf atau LimitNOFILE di systemd." url: "https://nivelva.com/insight/cara-mengatur-batas-file-proses-ulimit-linux" category: "Server \u0026 Infrastruktur" tags: ["ulimit","linux","systemd","too many open files","server"] author: "Lucas Tan" published: "2026-11-11T12:50:00+07:00" updated: "2026-11-11T12:50:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Cara Mengatur Batas File dan Proses dengan ulimit di Linux > **Jawaban singkat:** ulimit mengatur berapa banyak file dan proses yang boleh dipakai satu proses atau user. Untuk sesi login, ubah lewat /etc/security/limits.conf. Untuk layanan systemd seperti Nginx atau database, ubah LimitNOFILE di unit service, karena limits.conf tidak berlaku di sana. Untuk menaikkan batas file terbuka di Linux, ubah `LimitNOFILE` di unit systemd bila aplikasinya berjalan sebagai service, atau ubah `/etc/security/limits.conf` bila aplikasinya dijalankan dari sesi login. Perintah `ulimit` sendiri hanya mengubah batas untuk shell yang sedang aktif. Kenapa ini penting? Error `Too many open files` di log Nginx, database, atau aplikasi Node.js sering muncul justru saat trafik sedang ramai. Di Linux, setiap koneksi jaringan juga dihitung sebagai file terbuka, jadi server yang sibuk bisa menabrak batas bawaan jauh sebelum CPU atau RAM habis. ## Apa itu ulimit, soft limit, dan hard limit? ulimit adalah batas sumber daya (resource limit) yang dikenakan kernel pada setiap proses. Batas ini diwariskan ke proses anak, jadi proses yang dijalankan dari shell mendapat batas yang sama dengan shell tersebut. Setiap batas punya dua nilai: - **Soft limit** adalah batas yang benar-benar berlaku. User biasa boleh menaikkannya sendiri, tetapi tidak boleh melewati hard limit. - **Hard limit** adalah plafon. User biasa hanya boleh menurunkannya, sedangkan menaikkannya butuh hak root. Batas yang paling sering diurus admin server adalah dua ini: | Batas | Opsi ulimit | Direktif systemd | Gejala bila terlalu kecil | |:--|:--|:--|:--| | File terbuka (termasuk socket) | `-n` | `LimitNOFILE=` | `Too many open files` | | Jumlah proses atau thread per user | `-u` | `LimitNPROC=` | `Resource temporarily unavailable` saat membuat proses | | Ukuran core dump | `-c` | `LimitCORE=` | Tidak ada core dump saat aplikasi crash | | Memori yang dikunci | `-l` | `LimitMEMLOCK=` | Aplikasi gagal mengunci memori | ## Cara mengecek batas yang sedang berlaku Untuk shell yang sedang kamu pakai: ```bash ulimit -a # semua soft limit ulimit -Sn # soft limit file terbuka ulimit -Hn # hard limit file terbuka ``` Yang lebih penting adalah batas proses yang benar-benar bermasalah, karena bisa berbeda dengan shell-mu: ```bash cat /proc/$(pgrep -o nginx)/limits ls /proc/$(pgrep -o nginx)/fd | wc -l ``` Baris pertama menampilkan semua batas proses Nginx yang paling tua. Baris kedua menghitung berapa file yang sedang dibuka. Kalau angkanya mendekati `Max open files`, kamu sudah menemukan penyebabnya. Ganti `nginx` dengan nama proses yang kamu periksa. ## Menaikkan batas untuk sesi login dengan limits.conf File `/etc/security/limits.conf` (atau file baru di `/etc/security/limits.d/`) dibaca oleh modul PAM `pam_limits` saat user login, misalnya lewat SSH. Contoh untuk user `deploy`: ```text deploy soft nofile 65535 deploy hard nofile 65535 deploy soft nproc 4096 deploy hard nproc 4096 ``` Kolomnya berurutan: user atau grup (pakai awalan `@` untuk grup), jenis limit, nama batas, dan nilainya. Perubahan berlaku pada sesi login berikutnya, jadi keluar lalu masuk lagi, kemudian cek dengan `ulimit -n`. > **limits.conf tidak berlaku untuk service systemd:** > > Layanan yang dijalankan systemd tidak melewati PAM login, sehingga isi limits.conf tidak memengaruhinya. Ini penyebab paling umum "sudah diubah tapi tidak berefek". Untuk Nginx, MariaDB, PostgreSQL, atau aplikasi yang kamu jadikan service, pakai cara di bagian berikut. ## Bagaimana mengubah batas untuk service systemd? Buat drop-in agar file unit bawaan paket tidak tertimpa saat update: ```bash sudo systemctl edit nginx ``` Isi dengan: ```ini [Service] LimitNOFILE=65535 ``` Simpan, lalu muat ulang dan restart: ```bash sudo systemctl daemon-reload sudo systemctl restart nginx cat /proc/$(pgrep -o nginx)/limits | grep "open files" ``` `LimitNOFILE=65535` mengatur soft dan hard sekaligus. Bila ingin berbeda, tulis `LimitNOFILE=soft:hard`, misalnya `LimitNOFILE=65535:131072`. Cara yang sama berlaku untuk service buatanmu sendiri, seperti yang dibahas di [membuat service systemd untuk aplikasi](https://nivelva.com/insight/membuat-service-systemd). Beberapa aplikasi punya setelan sendiri yang juga perlu disesuaikan. Nginx misalnya punya `worker_rlimit_nofile` dan `worker_connections`. MySQL dan MariaDB punya `open_files_limit`. Menaikkan batas di systemd tanpa menyesuaikan setelan aplikasi kadang tidak mengubah apa pun. Untuk batas jumlah proses, systemd punya dua lapis. `LimitNPROC=` adalah rlimit klasik yang dihitung per user, sedangkan `TasksMax=` membatasi jumlah proses dan thread di dalam satu service lewat cgroup. Aplikasi yang membuat banyak thread, seperti server Java atau database, bisa menabrak `TasksMax` walau `LimitNPROC` sudah besar. Cek nilai yang berlaku dengan `systemctl show nama-service -p TasksMax`. ## Mengubah batas proses yang sudah berjalan Kalau server sedang kewalahan dan restart belum memungkinkan, `prlimit` bisa mengubah batas proses yang sedang jalan: ```bash sudo prlimit --pid 1234 --nofile=65535:65535 ``` Ini solusi darurat. Perubahan hilang saat proses di-restart, jadi tetap tuliskan setelan permanen di unit systemd. ## Apakah ada batas di level seluruh sistem? Ada. Kernel punya `fs.file-max` sebagai jumlah maksimal file terbuka di seluruh sistem, dan `fs.nr_open` sebagai plafon tertinggi yang boleh diberikan ke satu proses. Cek dengan: ```bash sysctl fs.file-max fs.nr_open cat /proc/sys/fs/file-nr ``` Di kernel modern nilai bawaannya sudah besar, sehingga yang paling sering kena adalah batas per proses, bukan batas sistem. Bila kamu ingin `LimitNOFILE` di atas `fs.nr_open`, naikkan dulu `fs.nr_open` lewat file di `/etc/sysctl.d/`. Jangan juga menaikkan batas setinggi-tingginya tanpa alasan. Batas ada untuk melindungi server dari aplikasi yang bocor, misalnya membuka koneksi tanpa pernah menutupnya. Bila jumlah file terbuka terus naik walau trafik stabil, masalahnya di aplikasi, bukan di ulimit. Pantau angkanya bersama metrik lain, misalnya dengan [Netdata](https://nivelva.com/insight/cara-memantau-server-linux-netdata), dan cek [load average](https://nivelva.com/insight/load-average-tinggi-linux-artinya-solusinya) saat server terasa berat. ## Pertanyaan yang sering diajukan ### Kenapa ulimit -n di terminal sudah besar tapi Nginx tetap error Too many open files? Karena Nginx dijalankan oleh systemd, bukan dari shell-mu. Batasnya diatur di unit service lewat LimitNOFILE, dan Nginx sendiri butuh worker_rlimit_nofile yang sesuai. ### Berapa nilai LimitNOFILE yang wajar? Tidak ada angka tunggal. Hitung perkiraan koneksi bersamaan ditambah file yang dibuka aplikasi, beri ruang cadangan, lalu pantau. Untuk web server dan database sibuk, nilai puluhan ribu sudah umum dipakai. ### Apakah perubahan ulimit di terminal permanen? Tidak. Perintah ulimit hanya berlaku untuk shell itu dan proses yang dijalankan darinya. Begitu shell ditutup, nilainya hilang. ## Sumber - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/cara-mengatur-batas-file-proses-ulimit-linux Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com