எங்கள் சர்வர்களை உறையச் செய்த காணாமல் போன swap கோப்பு

செப்டம்பர் 24 அன்று, எங்கள் production சர்வர்களில் ஒன்று பதில் சொல்வதை நிறுத்தியது. Load balancer அதை unhealthy எனக் குறித்தது. எங்கள் remote-command tool அதை அடைய முடியவில்லை. ஆனால் எதுவும் செயலிழக்கவில்லை. அதிக நினைவகம் பயன்படுத்தியதற்காக எதுவும் கொல்லப்படவில்லை. சர்வர் thrashing செய்துகொண்டிருந்தது. swap இடம் இல்லாமலும், கொள்கலன்கள் இயந்திரத்தில் இருந்ததைவிட அதிக நினைவகம் பயன்படுத்த அனுமதிக்கப்பட்டதாலும், Linux தன் நேரத்தை இயங்குவதற்குத் தேவையான கோப்புகளை வெளியேற்றுவதிலும் மீண்டும் படிப்பதிலும் செலவிட்டது. அதனால் கிட்டத்தட்ட எந்த முன்னேற்றமும் இல்லை. ஒவ்வொரு சர்வரிலும் 2 GB swap கோப்பைச் சேர்த்தது அதைச் சரிசெய்தது. இதில் மிகவும் சுவாரஸ்யமான பாடம் health checks பற்றியது.

"உறைந்தது" எப்படித் தெரிந்தது

• அந்த சர்வரில் load balancer-இன் health checks நேர முடிவை அடைந்தன.
• AWS Systems Manager வழியாக அனுப்பிய commands "Pending" நிலையில் நின்றன. ஒருபோதும் இயங்கவில்லை.
• logs-இல் out-of-memory kill எதுவும் இல்லை. எந்த process-உம் இறக்கவில்லை.

ஒரு வாரத்துக்கு முன், production-ஐ 2 GB RAM கொண்ட சிறிய ARM சர்வர்களுக்கு மாற்றியிருந்தோம். எங்கள் staging சர்வர் — இன்னும் சிறியது — deploy-இன் போது ஒரு container image-ஐ அவிழ்க்கும்போது அதே முறையில் உறைந்திருந்தது.

நினைவகப் பிழை ஏன் இல்லை?

Linux ஒரு process-ஐ, மீட்டெடுக்கக்கூடிய நினைவகம் உண்மையிலேயே தீர்ந்தால் மட்டுமே கொல்லும். அதற்கு முன், அது page cache-இலிருந்து நினைவகத்தை மீட்டெடுக்கிறது. அதாவது RAM-இல் அது வைத்திருக்கும் கோப்புகளின் நகல்கள், இயங்கும் ஒவ்வொரு நிரலின் குறியீடும் உட்பட.

எங்கள் சர்வர்களில், ஏறத்தாழ 1.8 GB பயன்படக்கூடிய இயந்திரத்தில், கொள்கலன்களின் கூட்டு நினைவக வரம்புகள் சுமார் 3.3 GB ஆகச் சேர்ந்தன. பொதுவாக அவை அனைத்தும் ஒரே நேரத்தில் தங்கள் வரம்பைப் பயன்படுத்துவதில்லை. ஆனால் பயன்படுத்தியபோது, இடம் உருவாக்க kernel cache-இலிருந்து நிரலின் குறியீட்டை வெளியேற்றிக்கொண்டே இருந்தது. அந்தக் குறியீடு மீண்டும் இயங்கியதும், அதை வட்டிலிருந்து மீண்டும் படிக்க வேண்டியிருந்தது. அந்தச் சுழற்சி — thrashing — ஒரு இயந்திரத்தை நடைமுறையில் முற்றிலும் பதிலளிக்காததாக மாற்றும். ஆனால் தொழில்நுட்ப ரீதியாக நினைவகம் தீர்ந்திருக்காது. எனவே எதுவும் கொல்லப்படுவதில்லை, எதுவும் மீள்வதில்லை.

Swap இல்லாவிட்டால், ஒதுக்கப்பட்டாலும் அரிதாகப் பயன்படுத்தப்படும் நினைவகத்தை வைக்க kernel-க்கு இடம் இல்லை. அதனால் அதை cache-இலிருந்து எடுக்க வேண்டியிருக்கிறது.

சரி

சர்வர் bootstrap script இப்போது ஒவ்வொரு முறையும் சர்வர் துவங்கும்போதோ பழுதுபார்க்கப்படும்போதோ 2 GB swap கோப்பை குறைந்த swappiness அமைப்புடன் (10) உருவாக்குகிறது. குறைந்த swappiness என்றால் kernel இன்னும் வேலை செய்யும் நினைவகத்தை RAM-இல் வைத்திருக்க விரும்பும். ஆனால் அரிதாகத் தொடப்படும் pages வட்டுக்கு நகரலாம். நிரலின் குறியீட்டை cache-இலிருந்து வெளியேற்ற வேண்டியதில்லை. இதை இரண்டு production சர்வர்களுக்கும் staging-க்கும் நேரடியாகப் பயன்படுத்தினோம். ஒவ்வொரு production deploy-இலும் deploy pipeline bootstrap script-ஐ மீண்டும் வெளியிடுகிறது. எனவே மாற்றப்பட்ட சர்வருக்கும் அது கிடைக்கும்.

எங்களை அதிகம் கவலைப்படுத்திய பகுதி: unhealthy சர்வர் அங்கேயே இருந்தது

எங்கள் server group EC2 health checks பயன்படுத்தியது — "இயந்திரம் இயங்குகிறதா?" — load balancer health checks அல்ல — "அது கோரிக்கைகளுக்குப் பதில் சொல்கிறதா?". எனவே load balancer கைவிட்ட ஒரு சர்வர், group-ஐப் பொறுத்தவரை இன்னும் ஆரோக்கியமாக இருந்தது. அது ஒருபோதும் மாற்றப்படாது. யாராவது கவனித்து மற்றொன்றை மீண்டும் துவக்கும் வரை production அமைதியாக ஒரே சர்வரில் இயங்கிக்கொண்டிருக்கும்.

Group-ஐ load-balancer health checks-க்கு மாற்றுவது வெளிப்படையான சரி போலத் தெரிகிறது. ஆனால் எங்களுக்கு அது நேரடியானதல்ல. deploy-இன் போது, சர்வர்கள் balancer அவற்றை வடிகட்டுவதற்காக வேண்டுமென்றே தங்கள் health endpoint-க்கு பிழையுடன் பதில் சொல்கின்றன (deploy-களை பூஜ்ஜிய 502களுக்குக் கொண்டுவந்தது எப்படி என்று பார்க்கவும்). அந்தச் சமிக்ஞையின் பேரில் சர்வர்களை மாற்றும் group, ஒவ்வொரு deploy-இன் நடுவிலும் அவற்றை மாற்றிவிடும்.

எனவே இப்போதைக்கு எங்கள் deploy checklist-இல் ஒரு படியைச் சேர்த்தோம்: ஒவ்வொரு deploy-க்குப் பின்னும், deploy job வெற்றியடைந்ததா என்று மட்டும் பார்க்காமல், load balancer-இல் ஒவ்வொரு target-இன் ஆரோக்கியத்தையும் சரிபார்க்கவும். ஒரு சர்வருக்கான commands "Pending" நிலையில் நின்றால், அது thrashing செய்கிறது. அதை மீண்டும் துவக்குங்கள். அது ஏற்கனவே சுழற்சியிலிருந்து வெளியே உள்ளது.

இதிலிருந்து நாங்கள் எடுத்துக்கொண்டவை

• "செயலிழக்கவில்லை" என்பது "ஆரோக்கியமாக இருக்கிறது" என்று பொருள் அல்ல. Thrashing எந்தப் பிழையையும் உருவாக்காது. இயந்திரம் பதில் சொல்வதை நிறுத்தும் அளவுக்கு மிக மெதுவாகும்.
• சிறிய சர்வர்களுக்கு swap தேவை. குறைந்த swappiness உடன் கொஞ்சம் இருந்தாலும், குளிர்ந்த நினைவகத்தை வைக்க kernel-க்கு ஒரு இடம் கிடைக்கும்.
• இயந்திரத்தைவிட கூடுதலாகச் சேரும் நினைவக வரம்புகள் ஒரு பந்தயம். சில நேரங்களில் அதை இழப்பீர்கள். எப்போது பந்தயம் கட்டினீர்கள் என்று தெரிந்திருக்க வேண்டும்.
• உங்கள் autoscaling எந்த health check-ஐ நம்புகிறது என்று தெரிந்துகொள்ளுங்கள். "VM இயங்குகிறதா?" என்று மட்டும் கேட்கும் health check, வேலை செய்வதை நிறுத்திய சர்வரை மாற்றாது.