Squid ର ପ୍ରକୃତ ଫାଇଲ୍-ଡିସ୍କ୍ରିପ୍ଟର ସୀମା ଖୋଜିବା
PAM ସେଟିଂ ପରିବର୍ତ୍ତନ କିମ୍ବା କ୍ଷମତା ରେସିପିରୁ ନିର୍ଦ୍ଦିଷ୍ଟ nofile ମୂଲ୍ୟ କପି କରିବା ପୂର୍ବରୁ ଚାଲୁଥିବା ପ୍ରକ୍ସିର ପ୍ରକ୍ରିୟା ସୀମା ପଢ଼ନ୍ତୁ।
ଲଗଇନ୍ ସେଲ୍ର ulimit -n ଉପରେ ଭରସା କରିବା ପୂର୍ବରୁ ଚାଲୁଥିବା ଡେମନ୍ ଯାଞ୍ଚ କରନ୍ତୁ। squid.service ବ୍ୟବହାର କରୁଥିବା ସ୍ଥାପନ ପାଇଁ ଏହିରୁ ଆରମ୍ଭ କରନ୍ତୁ:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceପ୍ରକୃତ ପ୍ରକ୍ରିୟା ID ବ୍ୟବହାର କରି /proc/PID/limits ପଢ଼ନ୍ତୁ। ବହୁ-ପ୍ରକ୍ରିୟା ନିୟୋଜନରେ ସମ୍ପୃକ୍ତ ୱାର୍କର୍ ମଧ୍ୟ ଯାଞ୍ଚ କରନ୍ତୁ। କନଫିଗୁରେସନ୍ରେ ସଞ୍ଚିତ ମୂଲ୍ୟ ଏହି ପ୍ରକ୍ରିୟା ଏହାକୁ ଉତ୍ତରାଧିକାର ପାଇଛି ବୋଲି ପ୍ରମାଣ ନୁହେଁ।
| ନିୟନ୍ତ୍ରଣ | ପରିସର |
|---|---|
ସେଲ୍ ulimit ଏବଂ PAM limits.conf | ସେଲ୍ର ଉତ୍ତରସୂରୀ କିମ୍ବା PAM ସେଟିଂ ପ୍ରକୃତରେ ବ୍ୟବହାର କରୁଥିବା ସେସନ୍ |
systemd LimitNOFILE= | ସେହି ସେବାର ସମ୍ପଦ ନୀତି ଅଧୀନରେ ଆରମ୍ଭ ହୋଇଥିବା ପ୍ରକ୍ରିୟା |
Squid max_filedescriptors, ଯେଠାରେ ସମର୍ଥିତ | ଅପରେଟିଂ ସିଷ୍ଟମ୍ର ସୀମା ମଧ୍ୟରେ ଆପ୍ଲିକେସନ୍ ସୀମା |
ପ୍ରଶାସକ ଫାଇଲ୍ ପରିବର୍ତ୍ତନ କରିଛନ୍ତି କେବଳ ସେଥିପାଇଁ ସିଷ୍ଟମ୍ ସେବା PAM ସମ୍ପାଦନା ଗ୍ରହଣ କରେ ନାହିଁ। systemd ସୀମା ପରିବର୍ତ୍ତନ ଉପଯୁକ୍ତ ହେଲେ ସେବା-ନିର୍ଦ୍ଦିଷ୍ଟ drop-in ବ୍ୟବହାର କରନ୍ତୁ। Squid ଦଲିଲଭୁକ୍ତ କରେ ଯେ max_filedescriptors ପରିବର୍ତ୍ତନ ପାଇଁ ପୁନଃଆରମ୍ଭ ଆବଶ୍ୟକ; ସେଟ୍ ନକରି ଛାଡ଼ିଲେ OS ର ନରମ ସୀମା ଉତ୍ତରାଧିକାର ହୁଏ।
ସୀମାକୁ ବ୍ୟବହାରକାରୀ ପାଇଁ ନୁହେଁ, ଡିସ୍କ୍ରିପ୍ଟର ପାଇଁ ମାପନ୍ତୁ। ଗ୍ରାହକମାନେ ଏକାଧିକ ସକେଟ୍ ରଖିପାରନ୍ତି, ଏବଂ ବାହାରକୁ ଯାଉଥିବା ସଂଯୋଗ, ଲଗ୍ ଓ ସହାୟକ ପାଇପ୍ ମଧ୍ୟ ଡିସ୍କ୍ରିପ୍ଟର ଖର୍ଚ୍ଚ କରେ। ସୀମା ବଢ଼ାଇଲେ ପ୍ରତ୍ୟେକ ସମ୍ଭାବ୍ୟ ଡିସ୍କ୍ରିପ୍ଟର ପାଇଁ ତୁରନ୍ତ ନିର୍ଦ୍ଦିଷ୍ଟ RAM ସଞ୍ଚୟ ନକରି ଅଧିକ ଖର୍ଚ୍ଚ ସମ୍ଭବ ହୁଏ। ପୁରୁଣା ପ୍ରତି-ସକେଟ୍ ମେମୋରୀ ଅନୁମାନ କିମ୍ବା 65,535 କୌଣସିଟି ସାର୍ବଜନୀନ କ୍ଷମତା ଆବଶ୍ୟକତା କିମ୍ବା Linux ର ଉପର ସୀମା ନୁହେଁ।
ସେବା ପରିବର୍ତ୍ତନ ପରେ ନୂଆ ପ୍ରକ୍ରିୟାର ସୀମାକୁ ଉଦ୍ଦିଷ୍ଟ ମୂଲ୍ୟ ସହିତ ତୁଳନା କରନ୍ତୁ। ସେଗୁଡ଼ିକଠାରୁ ବହୁତ ତଳେ ବିଫଳତା ଘଟିଲେ ପ୍ରକୃତରେ ଶେଷ ହେଉଥିବା ସମ୍ପଦର ଅନୁସନ୍ଧାନ କରନ୍ତୁ।