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 മേൽപരിധിയോ അല്ല.
സേവന മാറ്റത്തിന് ശേഷം പുതിയ പ്രോസസിന്റെ പരിധികൾ ഉദ്ദേശിച്ച മൂല്യങ്ങളുമായി താരതമ്യം ചെയ്യുക. അവയേക്കാൾ വളരെ താഴെ പരാജയങ്ങൾ സംഭവിക്കുന്നുവെങ്കിൽ, യഥാർത്ഥത്തിൽ തീർന്നുപോകുന്ന റിസോഴ്സ് അന്വേഷിക്കുക.