Squid-ийн файлын дескрипторын бодит хязгаарыг тодорхойлох
PAM тохиргоог өөрчлөх эсвэл багтаамжийн жороос тогтмол nofile утгыг хуулахаас өмнө ажиллаж буй проксийн процессын хязгаарыг уншина уу.
Нэвтрэх shell-ийн ulimit -n-д итгэхээс өмнө ажиллаж буй демоныг шалгана уу. squid.service ашигладаг суулгацын хувьд ингэж эхэлнэ үү:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service/proc/PID/limits-ыг бодит процессын ID-аар уншина уу. Олон процессын байршуулалтад холбогдох ажилтныг ч шалгана уу. Тохиргоонд хадгалсан утга нь энэ процесс түүнийг өвлөсөн гэдгийн баталгаа биш.
| Удирдлага | Хамрах хүрээ |
|---|---|
Shell ulimit ба PAM limits.conf | Shell-ийн үр удам эсвэл PAM тохиргоог бодитоор ашигладаг сессүүд |
systemd LimitNOFILE= | Тухайн үйлчилгээний нөөцийн бодлогын дагуу эхэлсэн процессууд |
Squid max_filedescriptors, дэмжигдсэн тохиолдолд | Үйлдлийн системийн хязгаарын доторх програмын хязгаар |
Администратор файлыг өөрчилсөн учраас л системийн үйлчилгээ PAM-ийн өөрчлөлтийг хүлээж авахгүй. systemd-ийн хязгаарыг өөрчлөх нь зүйтэй үед үйлчилгээнд зориулсан drop-in ашиглана уу. Squid-ийн баримтад max_filedescriptors-ыг өөрчлөхөд дахин эхлүүлэх шаардлагатай гэж бичсэн; тохируулахгүй орхивол OS-ийн зөөлөн хязгаарыг өвлөнө.
Хязгаарыг хэрэглэгчдэд биш, дескрипторуудад тохируулан хэмжинэ үү. Клиентүүд хэд хэдэн сокет барих боломжтой, мөн гарч буй холболт, лог, туслах хоолойнууд ч дескриптор зарцуулдаг. Хязгаарыг нэмэгдүүлэх нь боломжит дескриптор бүрд тогтмол RAM нөөцлөхгүйгээр илүү их зарцуулалт хийх боломж олгоно. Сокет тус бүрийн хуучин санах ойн тооцоо ч, 65,535 ч бүх нийтийн багтаамжийн шаардлага эсвэл Linux-ийн дээд хязгаар биш.
Үйлчилгээг өөрчилсний дараа шинэ процессын хязгаарыг зорьсон утгатай харьцуулна уу. Алдаа тэдгээрээс хамаагүй доогуур гарвал бодитоор дуусч буй нөөцийг шалгана уу.