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 ઉપરી મર્યાદા નથી.

સેવા ફેરફાર પછી નવી પ્રક્રિયાની મર્યાદા ઇચ્છિત મૂલ્યો સાથે સરખાવો. તેમની ઘણી નીચે નિષ્ફળતા થાય તો ખરેખર ખાલી થતું સંસાધન તપાસો.

સંબંધિત લેખો