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 இன் உச்சவரம்போ அல்ல.
சேவை மாற்றத்திற்குப் பிறகு புதிய செயல்முறையின் வரம்புகளை எண்ணப்பட்ட மதிப்புகளுடன் ஒப்பிடுங்கள். அவற்றை விட மிகக் கீழே தோல்விகள் ஏற்பட்டால், உண்மையில் தீர்ந்துவரும் வளத்தை ஆராயுங்கள்.