Menemukan Batas Deskriptor Berkas Squid yang Sebenarnya
Baca batas proses proksi yang berjalan sebelum mengubah pengaturan PAM atau menyalin nilai nofile tetap dari resep kapasitas.
Periksa daemon yang berjalan sebelum memercayai ulimit -n pada shell login. Untuk pemasangan yang memakai squid.service, mulai dengan:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceBaca /proc/PID/limits memakai ID proses yang sebenarnya. Pada penerapan multiproses, periksa juga worker terkait. Nilai yang tersimpan dalam konfigurasi bukan bukti bahwa proses ini mewarisinya.
| Kendali | Cakupan |
|---|---|
Shell ulimit dan PAM limits.conf | Keturunan shell atau sesi yang benar-benar memakai pengaturan PAM |
systemd LimitNOFILE= | Proses yang dimulai di bawah kebijakan sumber daya layanan itu |
Squid max_filedescriptors, bila didukung | Batas aplikasi dalam kendala sistem operasi |
Layanan sistem tidak serta-merta memakai perubahan PAM hanya karena administrator mengubah berkasnya. Gunakan drop-in khusus layanan bila mengubah batas systemd-nya memang tepat. Squid mendokumentasikan bahwa max_filedescriptors memerlukan mulai ulang untuk diubah; bila dibiarkan tidak diatur, ia mewarisi batas lunak OS.
Ukur batas untuk deskriptor, bukan pengguna. Klien dapat memegang beberapa soket, dan koneksi keluar, log, serta pipa pembantu juga memakai deskriptor. Menaikkan batas memungkinkan konsumsi lebih besar tanpa langsung mencadangkan jumlah RAM tetap untuk setiap deskriptor yang mungkin. Baik perkiraan memori per soket yang lama maupun 65,535 bukan persyaratan kapasitas universal atau plafon Linux.
Setelah perubahan layanan, bandingkan batas proses baru dengan nilai yang dituju. Jika kegagalan terjadi jauh di bawahnya, selidiki sumber daya yang benar-benar habis.