Mencari Had Deskriptor Fail Squid yang Sebenar
Baca had proses proksi yang berjalan sebelum menukar tetapan PAM atau menyalin nilai nofile tetap daripada resipi kapasiti.
Periksa daemon yang berjalan sebelum mempercayai ulimit -n shell log masuk. Untuk pemasangan yang menggunakan squid.service, mulakan dengan:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceBaca /proc/PID/limits menggunakan ID proses sebenar. Dalam penggunaan berbilang proses, periksa juga pekerja yang berkaitan. Nilai yang disimpan dalam konfigurasi bukan bukti bahawa proses ini mewarisinya.
| Kawalan | Skop |
|---|---|
Shell ulimit dan PAM limits.conf | Keturunan shell atau sesi yang benar-benar menggunakan tetapan PAM |
systemd LimitNOFILE= | Proses yang dimulakan di bawah dasar sumber perkhidmatan itu |
Squid max_filedescriptors, jika disokong | Had aplikasi dalam kekangan sistem pengendalian |
Perkhidmatan sistem tidak menerima pakai suntingan PAM semata-mata kerana pentadbir mengubah fail. Gunakan drop-in khusus perkhidmatan apabila mengubah had systemd-nya wajar. Squid mendokumenkan bahawa max_filedescriptors memerlukan mula semula untuk berubah; jika dibiarkan tidak ditetapkan, ia mewarisi had lembut OS.
Saiz had untuk deskriptor, bukan pengguna. Klien boleh memegang beberapa soket, dan sambungan keluar, log serta paip pembantu juga menggunakan deskriptor. Menaikkan had membolehkan penggunaan lebih besar tanpa menempah jumlah RAM tetap serta-merta untuk setiap deskriptor yang mungkin. Sama ada anggaran memori setiap soket yang lama atau 65,535 bukan keperluan kapasiti sejagat atau siling Linux.
Selepas perubahan perkhidmatan, bandingkan had proses baharu dengan nilai yang dimaksudkan. Jika kegagalan berlaku jauh di bawahnya, siasat sumber yang benar-benar kehabisan.