worker_connections உயர்த்துவதற்கு முன் NGINX ப்ராக்ஸி சாக்கெட்டுகளை பட்ஜெட் செய்யுங்கள்
ப்ராக்ஸி இணைப்பு பொதுவாக கிளையண்ட் மற்றும் upstream ஆகிய இரு சாக்கெட்டுகளையும் பயன்படுத்துகிறது; worker இன் இணைப்பு வரம்பையும் சேவையின் கோப்பு விவரிப்பான் வரம்பையும் வேறுபடுத்துங்கள்.
நீண்ட காலம் நீடிக்கும் ஒரு ப்ராக்ஸி இணைப்பு பொதுவாக இரு சாக்கெட்டுகளை எடுக்கிறது: கிளையண்டின் மற்றும் upstream இன். worker_connections இரு பக்கங்களையும் கணக்கிடுகிறது. எனவே அதை worker_processes ஆல் பெருக்குவது ப்ராக்ஸி பயனர்களுக்கு திறன் உறுதியைத் தராது.
இணைப்புகள் தோல்வியடையும்போது, அறிவிக்கப்பட்ட வரம்பைப் பின்பற்றுங்கள்:
| ஆதாரம் | பரிசோதிக்க வேண்டிய அமைப்பு அல்லது செயல்முறை நிலை |
|---|---|
| worker_connections தீர்ந்துபோதல் | upstream சாக்கெட்டுகள் உட்பட worker இன் இணைப்பு பட்ஜெட் |
| இயக்க முறைமையின் “அதிக கோப்புகள் திறந்துள்ளன” | உண்மையான சேவை செயல்முறை மரபுரிமையாகப் பெறும் கோப்பு விவரிப்பான் வரம்பு |
கேட்கும் சாக்கெட்டுகள், பதிவுகள் மற்றும் பிற திறந்த கோப்புகளும் விவரிப்பான்களைப் பயன்படுத்துகின்றன. இணைப்பு மீள்பயன்பாடு மற்றும் போக்குவரத்து கலவை பயனர்களுக்கும் சாக்கெட்டுகளுக்கும் இடையிலான உறவை மாற்றுகின்றன.
worker_rlimit_nofile சூழலின் அனுமதிகளுக்கு உட்பட்டு worker வரம்புகளைச் சரிசெய்கிறது. systemd அலகு LimitNOFILE அமைக்க முடியும்; ஊடாடும் ஷெல்லின் ulimit இயங்கும் சேவையை மாற்றாது.
பணிச்சுமைக்கேற்ப வரம்புகளை அளவிடுங்கள், அவற்றை யார் பயன்படுத்துகிறார்கள் என்பதைப் பரிசோதியுங்கள். எதிர்பாராத கிளையண்டுகள் அல்லது திரும்பத் திரும்பத் தோல்வியடையும் upstream இணைப்புகள் முன்பு போதுமானதாக இருந்த பட்ஜெட்டைத் தீர்த்துவிடலாம். அதிக செயல்முறை எண்ணிக்கை அல்லது நினைவக வரம்பு விவரிப்பான் பற்றாக்குறையைச் சரிசெய்யாது.