ആരെയും കാത്തിരിപ്പിക്കാതെ വലിയ വർക്ക്‌സ്‌പേസുകളിലേക്ക് മാറ്റം

Mythex-ലെ ഓരോ പ്രോജക്റ്റിനും സ്വന്തമായി ഒരു വർക്ക്‌സ്‌പേസ് കിട്ടും: ഏജന്റ് കോഡ് എഴുതുകയും നിങ്ങളുടെ ആപ്പിന്റെ പ്രിവ്യൂ പ്രവർത്തിക്കുകയും ചെയ്യുന്ന ഒരു ചെറിയ ക്ലൗഡ് കമ്പ്യൂട്ടർ. പുതിയ വർക്ക്‌സ്‌പേസുകൾക്ക് 1 GB മെമ്മറിയിൽ നിന്ന് 2 GB ആക്കിയിരുന്നു, പക്ഷേ പഴയവ 1 GB-യിൽ തന്നെ തുടർന്നു. ഞങ്ങൾ പരിശോധിച്ച ദിവസം അവയിൽ ഏകദേശം നാലിലൊന്ന് ഉണ്ടായിരുന്നു. ഞങ്ങളുടെ ആദ്യ പരിഹാരം, ഒരു പ്രോജക്റ്റ് വീണ്ടും തുറക്കുമ്പോൾ അതിനെ വലിയ വർക്ക്‌സ്‌പേസിലേക്ക് മാറ്റുക എന്നതായിരുന്നു. പ്രൊഡക്ഷനിലെ ആദ്യ ദിവസം അത് ഒരാളെ ഏഴ് മിനിറ്റ് കാത്തിരുത്തി. പിന്നീട് ഞങ്ങൾ അതിന് കർശനമായ സമയപരിധി വെച്ചു, ഒടുവിൽ പ്രോജക്റ്റ് തുറക്കുന്നതിൽ നിന്ന് ആ മാറ്റം തന്നെ നീക്കം ചെയ്തു.

പഴയ വർക്ക്‌സ്‌പേസുകൾ ചെറുതായി തുടർന്നത് എന്തുകൊണ്ട്

ഞങ്ങളുടെ സാൻഡ്‌ബോക്സ് ദാതാവ് ഒരു വർക്ക്‌സ്‌പേസിന്റെ വലുപ്പം അത് സൃഷ്ടിക്കുമ്പോൾ തന്നെ നിശ്ചയിക്കുന്നു, ഓരോ താൽക്കാലിക നിർത്തലിലും തുടരലിലും അത് അതേപടി നിലനിൽക്കും. ടെംപ്ലേറ്റ് മാറ്റുന്നത് — അതായത് പുതിയ വർക്ക്‌സ്‌പേസുകൾ നിർമ്മിക്കുന്ന പാചകക്കുറിപ്പ് — മാറ്റത്തിന് ശേഷം സൃഷ്ടിക്കുന്ന വർക്ക്‌സ്‌പേസുകളെ മാത്രമേ ബാധിക്കൂ. നിലവിലുള്ളവയുടെ വലുപ്പം ആരും മാറ്റുന്നില്ല.

അത് പ്രധാനമായിരുന്നു. ചെറിയ വർക്ക്‌സ്‌പേസുകളിലൊന്ന് ഒരു git push സമയത്ത് മെമ്മറി തീർന്നു, അതിന്റെ പ്രിവ്യൂ തുടങ്ങുമ്പോൾ തന്നെ, 11 മിനിറ്റ് പ്രതികരിക്കാതെ നിന്നു. അതുകൊണ്ട് ഒരു പബ്ലിഷ് പരാജയപ്പെട്ടു.

ആദ്യ ശ്രമം: ഉണരുമ്പോൾ പ്രോജക്റ്റ് മാറ്റുക

ആരും ഉപയോഗിക്കാത്തപ്പോൾ വർക്ക്‌സ്‌പേസുകൾ താൽക്കാലികമായി നിർത്തും, പ്രോജക്റ്റ് തുറക്കുമ്പോൾ ഉണരും. ഉണരുന്ന നിമിഷം പ്രോജക്റ്റ് മാറ്റാൻ പറ്റിയ സമയമെന്ന് തോന്നി, കാരണം ആരും അതിൽ പണിയെടുക്കുന്നുണ്ടാകില്ല.

മാറ്റം ഇങ്ങനെയായിരുന്നു:

1. വലുപ്പം പരിശോധിക്കുക. വർക്ക്‌സ്‌പേസ് 2 GB-യിൽ കുറവാണെങ്കിൽ അത് മാറ്റുക. വലുപ്പം അറിയില്ലെങ്കിൽ ഒന്നും ചെയ്യരുത്.
2. ഒരു പബ്ലിഷിനെ ശല്യപ്പെടുത്തരുത്. പബ്ലിഷ് വർക്ക്‌സ്‌പേസിലെ ഫയലുകൾ വായിക്കുന്നതിനാൽ അത് നടക്കുന്നുണ്ടെങ്കിൽ മാറ്റം ഒഴിവാക്കുക.
3. പ്രോജക്റ്റ് പാക്ക് ചെയ്യുക. പ്രോജക്റ്റിലെ എല്ലാം ആർക്കൈവ് ചെയ്യുക — അതിന്റെ git ചരിത്രവും, അതായത് പ്രോജക്റ്റിന് ഉള്ള എല്ലാ checkpoint-ഉം, ഉടമയുടേതായ ആപ്പിന്റെ .env ഫയലും ഉൾപ്പെടെ — എന്നാൽ പുനഃസ്ഥാപിക്കാവുന്ന ഇൻസ്റ്റാൾ ചെയ്ത ഡിപെൻഡൻസികൾ (node_modules) ഒഴിവാക്കുക.
4. നേരിട്ട് പകർത്തുക. പഴയ വർക്ക്‌സ്‌പേസിൽ നിന്ന് ആർക്കൈവ് പുതിയ 2 GB വർക്ക്‌സ്‌പേസിലേക്ക് നേരിട്ട് സ്ട്രീം ചെയ്യുക. അങ്ങനെ അത് ഞങ്ങളുടെ സ്വന്തം സെർവറിന്റെ മെമ്മറിയിൽ ഒരിക്കലും ഉൾക്കൊള്ളേണ്ടി വരില്ല.
5. മാറുന്നതിന് മുമ്പ് താരതമ്യം ചെയ്യുക. രണ്ട് വർക്ക്‌സ്‌പേസുകളിലും ഫയലുകൾ എണ്ണുക, ഏറ്റവും പുതിയ checkpoint വായിക്കുക, checkpoint-കൾ എണ്ണുക. മൂന്നും ഒത്തുവന്നാൽ മാത്രം മാറുക.
6. ഏതെങ്കിലും പരാജയത്തിൽ പഴയത് നിലനിർത്തുക. ഏതെങ്കിലും പിശകോ പൊരുത്തക്കേടോ ഉണ്ടായാൽ പുതിയ വർക്ക്‌സ്‌പേസ് ഒഴിവാക്കി, പ്രോജക്റ്റ് മുമ്പത്തെപ്പോലെ പഴയ വർക്ക്‌സ്‌പേസിൽ തുറക്കും.

താരതമ്യത്തിലെ ഒരു വിശദാംശം തോന്നുന്നതിനേക്കാൾ പ്രധാനമായിരുന്നു. പരിശോധന അഡ്മിനിസ്ട്രേറ്റർ അക്കൗണ്ടിൽ ആണ് നടക്കുന്നത്, മറ്റൊരു ഉപയോക്താവിന്റെ ഉടമസ്ഥതയിലുള്ള ഒരു repository വായിക്കാൻ git വിസമ്മതിക്കും. രണ്ട് വശത്തും അത് ഒന്നും പ്രിന്റ് ചെയ്തില്ല — "ഒന്നുമില്ല" എന്നത് "ഒന്നുമില്ല" എന്നതുമായി ഒത്തുപോയി, അതിനാൽ ഒരു ചരിത്രവും താരതമ്യം ചെയ്യാതെ പരിശോധന കടന്നുപോയി. ഡയറക്ടറിയെ വിശ്വസിക്കാൻ git-നോട് പറഞ്ഞു, അത് തിരികെ വരാതിരിക്കാൻ ഒരു ടെസ്റ്റും ചേർത്തു.

ആദ്യ ദിവസത്തെ പ്രശ്നം

പ്രൊഡക്ഷനിലെ ആദ്യ ദിവസം, ഒരു പ്രോജക്റ്റ് പാക്ക് ചെയ്യുമ്പോൾ ഉണർച്ചയ്ക്കുള്ളിൽ തന്നെ അഞ്ച് മിനിറ്റ് കമാൻഡ് സമയപരിധിയിൽ തട്ടി. ഉടമ തന്റെ വർക്ക്‌സ്‌പേസ് തുറക്കാൻ ഏഴ് മിനിറ്റ് കാത്തിരുന്നു. മാറ്റം പരാജയപ്പെട്ടതിനാൽ പ്രോജക്റ്റ് ഇപ്പോഴും ചെറുതായിരുന്നു, അതിനാൽ അടുത്ത തവണ തുറക്കുമ്പോഴും ശ്രമം ആവർത്തിക്കപ്പെടുമായിരുന്നു, അവർക്ക് വീണ്ടും കാത്തിരിക്കേണ്ടി വരുമായിരുന്നു.

സ്വന്തം പ്രോജക്റ്റ് തുറക്കുമ്പോൾ ഒരാളെ കാത്തിരുത്തുന്ന ഒരു മൈഗ്രേഷൻ നല്ല കച്ചവടമല്ല. ഉണരുമ്പോൾ അത് ചെയ്തതിന്റെ മുഴുവൻ ഉദ്ദേശ്യവും ആരും അത് ശ്രദ്ധിക്കരുത് എന്നതായിരുന്നു.

രണ്ടാം ശ്രമം: കർശനമായ ഒരു ബജറ്റ്

അതേ ദിവസം ഞങ്ങൾ നാല് കാര്യങ്ങൾ മാറ്റി:

• മുഴുവൻ മാറ്റത്തിനും ഒരു മിനിറ്റ്. ഓരോ ഘട്ടവും — വലുപ്പം പരിശോധിക്കൽ, പാക്ക് ചെയ്യൽ, പുതിയ വർക്ക്‌സ്‌പേസ് സൃഷ്ടിക്കൽ, പകർത്തൽ, അൺപാക്ക് ചെയ്യൽ, താരതമ്യം — ഒരു 60 സെക്കൻഡ് ബജറ്റ് പങ്കിടുന്നു. അത് തീർന്നാൽ പ്രോജക്റ്റ് പഴയ വർക്ക്‌സ്‌പേസിൽ തുറക്കും.
• കാത്തിരിപ്പ് മാത്രമല്ല, ജോലിയും നിർത്തുക. ഞങ്ങളുടെ ഭാഗത്ത് കാത്തിരിപ്പ് ഉപേക്ഷിച്ചാൽ മതിയാകില്ല, ഉടമ ഉപയോഗിക്കാൻ പോകുന്ന വർക്ക്‌സ്‌പേസിനുള്ളിൽ ആർക്കൈവിംഗ് ഇപ്പോഴും നടക്കുന്നുണ്ടെങ്കിൽ. ഇപ്പോൾ ഓരോ ആർക്കൈവ് കമാൻഡും ബജറ്റ് അവസാനിക്കുന്നതിന് തൊട്ടുമുമ്പ് വർക്ക്‌സ്‌പേസിനുള്ളിൽ തന്നെ നിർത്തപ്പെടുന്നു. ഞങ്ങൾ ഉപേക്ഷിച്ചതിന് ശേഷം പുതിയ വർക്ക്‌സ്‌പേസ് എത്തിയാൽ അത് ഒഴിവാക്കപ്പെടും.
• ഉടമയെ വൃത്തിയാക്കലിനായി കാത്തിരുത്തരുത്. താൽക്കാലിക ആർക്കൈവ് ഇല്ലാതാക്കുന്നത് ഇപ്പോൾ പശ്ചാത്തലത്തിലാണ് നടക്കുന്നത്.
• ഓരോ തുറക്കലിലും വീണ്ടും ശ്രമിക്കരുത്. മാറ്റാൻ കഴിയാത്ത പ്രോജക്റ്റ് 24 മണിക്കൂർ വിട്ടിടും, അതിനാൽ ഒരു പരാജയം ഓരോ തുറക്കലിനും ഒന്നല്ല, ദിവസത്തിൽ ഒരു കാലതാമസം മാത്രമേ ഉണ്ടാക്കൂ.

മൂന്നാം ശ്രമം: ഉണർച്ചയിൽ നിന്ന് മാറ്റുക

ഇത് ഏറ്റവും മോശം സാഹചര്യം ഒരു മിനിറ്റാക്കി. പക്ഷേ ഒരു മിനിറ്റും ഒരു മിനിറ്റ് തന്നെയാണ്. മാറ്റം ആരുടെയും വഴിയിൽ വേണ്ടായിരുന്നു എന്ന് ഞങ്ങൾ തിരിച്ചറിഞ്ഞു.

ഇപ്പോൾ 1 GB-യിൽ ഒരു വർക്ക്‌സ്‌പേസും സൃഷ്ടിക്കപ്പെടുന്നില്ല. അതിനാൽ ഇത് നടന്നുകൊണ്ടിരിക്കുന്ന ഒരു പ്രക്രിയയല്ല; നിശ്ചിത വർക്ക്‌സ്‌പേസുകളുടെ ഒരു പട്ടികയ്ക്കുള്ള ഒറ്റത്തവണ ജോലി മാത്രമാണ്. ഉണർച്ചയ്ക്കുള്ളിൽ ചെയ്തപ്പോൾ ഓരോ മന്ദഗതിയിലുള്ള മാറ്റത്തിനും ഒരു യഥാർത്ഥ മനുഷ്യൻ വില നൽകി, ഒരു വർക്ക്‌സ്‌പേസ് മാറില്ല എന്ന് അറിയാൻ ഒരേയൊരു വഴി, ആരോ അത് കാത്തിരുന്നതിനു ശേഷമായിരുന്നു.

അതുകൊണ്ട് ഉണർച്ചയിൽ നിന്ന് മാറ്റം പൂർണമായി നീക്കം ചെയ്തു. പ്രോജക്റ്റ് തുറക്കുന്നത് മുമ്പത്തെപ്പോലെ തന്നെ പ്രവർത്തിക്കുന്നു. ബാക്കിയുള്ള ചെറിയ വർക്ക്‌സ്‌പേസുകൾ ഒരു മേൽനോട്ടത്തിലുള്ള ബാച്ചായി കൈകാര്യം ചെയ്യുന്നു: ആരും അതിനായി കാത്തിരിക്കുന്നില്ല, മാറാത്ത വർക്ക്‌സ്‌പേസ് ബാച്ചിന്റെ റിപ്പോർട്ടിൽ കാണിക്കും, അവിടെ അതിനെ നോക്കാം, ഉടമയുടെ മുന്നിലല്ല.

ഞങ്ങൾ പഠിച്ചത്

• വലുപ്പം മാറ്റുന്നത് എപ്പോഴും സാധ്യമല്ല. സൃഷ്ടിക്കുമ്പോൾ പ്ലാറ്റ്‌ഫോം വലുപ്പം ഉറപ്പിക്കുമ്പോൾ, സ്ഥിര വലുപ്പം ഉയർത്തിയാൽ അത് പുതിയവയ്ക്ക് മാത്രമേ ഗുണം ചെയ്യൂ. പഴയവയ്ക്കായി പദ്ധതി ഇടണം.
• "ആരും ഇതുവരെ ഉപയോഗിച്ചിട്ടില്ല" എന്നതിനർത്ഥം ആരെങ്കിലും കാത്തിരിക്കുന്നു എന്നാണ്. ഒരു ഉൽപ്പന്നത്തിലേക്ക് കടക്കുന്ന വഴിയിൽ ചെയ്യുന്ന ജോലി ഒരാൾ നോക്കിയിരിക്കുന്ന ജോലിയാണ്.
• ഉപയോക്താവിന്റെ പാതയിലുള്ള ഏതിനും ഒരു ബജറ്റ് വെക്കുക, അത് തീരുമ്പോൾ ജോലി നിർത്തുക. ഞങ്ങളുടെ ഭാഗത്ത് സമയം കഴിഞ്ഞതായി പ്രഖ്യാപിക്കുമ്പോഴും കമാൻഡ് മറ്റെവിടെയോ ഓടിക്കൊണ്ടിരുന്നാൽ പ്രശ്നം മാറുന്നില്ല, അത് മാറ്റി വെക്കുക മാത്രമേ ചെയ്യൂ.
• ഒറ്റത്തവണ മൈഗ്രേഷൻ ഒറ്റത്തവണ ജോലിയിൽ ആയിരിക്കണം. ദൈനംദിന പ്രവർത്തനങ്ങൾക്കുള്ളിൽ അത് ഒളിപ്പിച്ചാൽ എഴുതാൻ എളുപ്പമാകും, പക്ഷേ പ്രവർത്തിപ്പിക്കാൻ ചെലവേറും.
• നിങ്ങളുടെ സുരക്ഷാ പരിശോധനകൾ പരീക്ഷിക്കുക. ഒന്നും താരതമ്യം ചെയ്യാത്ത ഒരു താരതമ്യം വിജയിച്ച ഒന്നിനെ പോലെ തന്നെ കാണപ്പെടും.

Mythex-ൽ നിർമ്മിക്കുന്നവർക്ക് ചെയ്യാൻ ഒന്നുമില്ല: ലക്ഷ്യം ഓട്ടത്തിൽ കുറഞ്ഞ വർക്ക്‌സ്‌പേസുകൾ മെമ്മറി തീർന്നുപോകുന്നതാണ്, പ്രോജക്റ്റ് തുറക്കുന്നത് മുമ്പത്തെപ്പോലെ വേഗത്തിലാകും. വർക്ക്‌സ്‌പേസുകൾ എങ്ങനെ താൽക്കാലികമായി നിർത്തുകയും ഉണരുകയും ചെയ്യുന്നു എന്നത് private workspace എന്ന ഡോക്സിൽ വിശദീകരിച്ചിട്ടുണ്ട്. മറ്റൊരു മെമ്മറി തീർന്ന കഥയ്ക്ക്, a progress label-ൽ ഒളിഞ്ഞിരിക്കുന്ന out-of-memory ക്രാഷ് കാണുക.