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 ਦੀ ਉੱਪਰੀ ਸੀਮਾ ਹੈ।

ਸੇਵਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੀ ਤੁਲਨਾ ਲੋੜੀਂਦੇ ਮੁੱਲਾਂ ਨਾਲ ਕਰੋ। ਜੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਹੁਤ ਹੇਠਾਂ ਅਸਫਲਤਾਵਾਂ ਹੋਣ ਤਾਂ ਅਸਲ ਵਿੱਚ ਖ਼ਤਮ ਹੋ ਰਹੇ ਸਰੋਤ ਦੀ ਜਾਂਚ ਕਰੋ।

ਸੰਬੰਧਿਤ ਲੇਖ