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 ఉపయోగించండి. max_filedescriptors మారడానికి పునఃప్రారంభం అవసరమని Squid నమోదు చేస్తుంది; సెట్ చేయకుండా వదిలేస్తే OS యొక్క మృదు పరిమితి వారసత్వంగా వస్తుంది.
పరిమితిని వినియోగదారుల కోసం కాదు, డిస్క్రిప్టర్ల కోసం కొలవండి. క్లయింట్లు అనేక సాకెట్లను ఉంచుకోగలరు, మరియు బయటకు వెళ్లే కనెక్షన్లు, లాగ్‌లు, సహాయక పైపులు కూడా డిస్క్రిప్టర్లను వినియోగిస్తాయి. పరిమితిని పెంచడం వల్ల ప్రతి సాధ్యమైన డిస్క్రిప్టర్‌కు స్థిరమైన RAM ను వెంటనే కేటాయించకుండా ఎక్కువ వినియోగాన్ని అనుమతిస్తుంది. పాత ప్రతి-సాకెట్ మెమరీ అంచనా గానీ 65,535 గానీ సార్వత్రిక సామర్థ్య అవసరం లేదా Linux పైపరిమితి కాదు.
సేవ మార్పు తర్వాత కొత్త ప్రక్రియ పరిమితులను ఉద్దేశించిన విలువలతో పోల్చండి. వాటి కంటే చాలా దిగువన వైఫల్యాలు సంభవిస్తే, నిజంగా ఖాళీ అవుతున్న వనరును పరిశోధించండి.