16 GB Windows Subsystem for Linux 2 (WSL2) மெஷினில் ஒரு சிறிய டைனமிக் ஐகான் இம்போர்ட் (dynamic icon import) டெவ் சர்வரை முடக்கிவிட்டது. இது vmmemWSL செயல்முறையை (process) அனைத்துக் கிடைக்கும் நினைவகத்தையும் (memory) பயன்படுத்தத் தூண்டி, முழு லினக்ஸ் விண்டோவையும் உறையச் செய்தது (freeze). .wslconfig கோப்பு VM-ன் RAM பயன்பாட்டைக் கட்டுப்படுத்திய போதிலும், Turbopack பயன்படுத்தும் Next.js 16 திட்டத்தை இயக்கும்போது இந்தத் தவறு ஏற்பட்டது.
ஒரு சிறிய இம்போர்ட் ஏன் ஒரு ராட்சதப் பிரச்சனையாக மாறுகிறது
டெவலப்பர் ரன்டைமில் (runtime) ஒரு டைனமிக் என்ட்ரி பாயிண்ட் மூலம் ஐகான்களைத் தீர்மானிக்க முயன்றார். அந்த இம்போர்ட் சுமார் 9,000 மாடியூல்களைக் கொண்ட ஒரு ஐகான் பேக்கேஜை உள்ளே இழுத்தது. Next.js 16-ன் டெவ் சர்வரை இயக்கும் ரஸ்ட் (Rust) அடிப்படையிலான பண்டலர் (bundler) ஆன Turbopack, அது தொடும் ஒவ்வொரு பேக்கேஜுக்கும் ஒரு முழுமையான மாடியூல் மேப்பை (module map) உருவாக்குகிறது. டெவ் மோடில், இந்த மேப் நினைவகத்தில் (memory) இருக்கும் மற்றும் ஒவ்வொரு கோப்பு மாற்றத்திலும் புதுப்பிக்கப்படும். முழு ஐகான் பேக்கேஜையும் லோட் செய்ததால், Turbopack அதிகப்படியான RAM-ஐ ஒதுக்க வேண்டிய கட்டாயம் ஏற்பட்டது, இது .wslconfig கோப்பால் நிர்ணயிக்கப்பட்ட வரம்பை விரைவாக எட்டியது. அந்த வரம்பு எட்டப்பட்டவுடன், WSL VM பதிலளிக்காமல் போனது; Ctrl + C செய்தும் எந்தப் பயனும் இல்லை, விண்டோஸ் ஹோஸ்ட்டை (Windows host) கட்டாயமாக அணைப்பது மட்டுமே ஒரே வழியாக இருந்தது.
அதே குறியீட்டின் புரொடக்ஷன் பில்ட் (production build) வெற்றிகரமாக முடிந்தது, ஏனெனில் பண்டலர் ஒருமுறை வரைபடத்தை (graph) உருவாக்கி, அசெட்களை (assets) வெளியிட்டுவிட்டு வெளியேறிவிடும். ஆனால், டெவ் சர்வர் ஹாட்-ரீலோடிங் (hot-reloading) வசதிக்காக அந்த வரைபடத்தை நினைவகத்திலேயே வைத்திருக்கும். எனவே, ஒரு புரொடக்ஷன் பில்ட் வெற்றிகரமாக அமைவது மட்டுமே, டெவ் சூழல் (dev environment) அதே இம்போர்ட் முறையைத் தாங்கும் என்பதற்கு உத்தரவாதம் அளிக்காது.
பரந்த பாதிப்புகள்
விண்டோஸிற்குள் லினக்ஸ் அடிப்படையிலான டூல்chains-களில் வேலை செய்யும் டெவலப்பர்கள், வளப் பயன்பாட்டைத் தனிமைப்படுத்த WSL2-ஐ நம்பியிருக்கிறார்கள். ஒரு இம்போர்ட் மட்டும் VM-ன் நினைவகத்தை முழுமையாகப் பயன்படுத்தும்போது, முழு ஹோஸ்ட்டும் மந்தமாகவோ அல்லது பதிலளிக்காமலோ போகலாம், இது அதே மெஷினில் உள்ள மற்ற கன்டெய்னர்கள் அல்லது பயன்பாடுகளையும் பாதிக்கும். இந்தச் சம்பவம், வழக்கமான Node.js மெமரி-டியூனிங் ஃபிளாக்ஸிற்கும் (memory-tuning flags) Turbopack-ன் கட்டமைப்பிற்கும் இடையே உள்ள முரண்பாட்டையும் எடுத்துக்காட்டுகிறது: Turbopack ரஸ்டில் (Rust) இயங்குகிறது, V8-இல் அல்ல, எனவே Node --max-old-space-size ஃபிளாக்கை அதிகரிப்பது அதன் RAM பயன்பாட்டைக் குறைக்க உதவாது.
உண்மையில் என்ன நடந்தது
- Dynamic entry point: இம்போர்ட் ஸ்டேட்மெண்ட் பண்டலரை ஒரு முழு ஐகான் பேக்கேஜையும் லேஸிலியாக்-லோட் (lazily-loaded) செய்யப்படும் ஒரு மாடியூலாகக் கருதச் சொன்னது. Turbopack அதற்குப் பதிலாக மாடியூல் மேப்பை உருவாக்க ஒவ்வொரு கோப்பையும் தீவிரமாகப் பகுப்பாய்வு (parsing) செய்தது.
- Dev-server graph: ஒருமுறை மட்டும் செய்யப்படும் புரொடக்ஷன் கம்பைலை விட, டெவ் சர்வர் கோப்பு மாற்றங்களின் போது உடனடித் தகவல்களை வழங்க முழு டிபென்டென்சி கிராஃபையும் (dependency graph) RAM-இல் வைத்திருக்கும்.
- Memory cap: .wslconfig கோப்பு VM-ன் பயன்பாட்டை ஹோஸ்ட்டின் RAM-ன் ஒரு பகுதிக்குக் கட்டுப்படுத்தியது. Turbopack-ன் தேவை அந்த வரம்பைத் தாண்டியபோது, VM உறையத் தொடங்கியது.
நினைவகப் பயன்பாட்டை பாதியாகக் குறைக்கும் தீர்வுகள்
டெவலப்பர் மூன்று நடைமுறை மாற்றங்களைச் செய்ததன் மூலம் RAM பயன்பாடு 3.6 GB-லிருந்து 1.87 GB ஆகக் குறைந்து நிலைத்தன்மை திரும்பியது:
- சிறிய அசெட்களுக்கு டைனமிக் என்ட்ரி பாயிண்ட்களைப் பயன்படுத்துவதை நிறுத்துங்கள் – உங்களுக்குத் தேவையான ஐகான்களை மட்டும் இம்போர்ட் செய்யுங்கள், உதாரணத்திற்கு
import { SearchIcon } from 'icon-pack/search'. உங்களுக்குச் சில ஐகான்கள் மட்டுமே தேவை என்றால், இன்லைன் SVGs (inline SVGs) இன்னும் லேசானவை. next.config.ts-இல்optimizePackageImports-ஐ எனேபிள் செய்யவும் – இந்த விருப்பம், Turbopack-ஐ பேக்கேஜ் ரூட்டிற்குப் பதிலாக அவற்றின் குறிப்பிட்ட கோப்புப் பாதைகளுக்கு (concrete file paths) இம்போர்ட்களைத் தீர்க்கச் சொல்கிறது, இது முழு பேக்கேஜ் மரத்தையும் (package tree) லோட் செய்வதைத் தடுக்கிறது.- Node heap ஃபிளாக்குகளை நம்பியிருக்க வேண்டாம் – Turbopack-ன் நினைவகப் பயன்பாடு அதன் ரஸ்ட் ரன்டைமால் (Rust runtime) நிர்வகிக்கப்படுவதால்,
--max-old-space-sizeஇதற்கு எந்தப் பயனும் அளிக்காது.
.wslconfig வரம்புகளை அப்படியே வைத்திருப்பது இப்போதும் நல்லது. ஒரு கடுமையான வரம்பு (hard cap) இருந்தால், விண்டோஸ் ஹோஸ்ட் முடங்குவதற்குப் பதிலாக VM தற்காலிகமாகத் தற்காப்பு நிலைக்குச் செல்லக்கூடும், இது அனைத்தும் முடங்குவதற்கு முன் நீங்கள் தலையிட ஒரு வாய்ப்பைத் தரும்.
உங்கள் பணிப்பாய்வில் (workflow) கவனிக்க வேண்டியவை
- Memory dashboards: WSL-க்குள் இருக்கும்
htopஅல்லது விண்டோஸ் டாஸ்க் மேனேஜர் (Windows Task Manager) போன்ற கருவிகள் vmmemWSL எப்போது உயர்கிறது என்பதைக் கண்டறிய உதவும். பயன்பாடு உங்கள் நிர்ணயிக்கப்பட்ட வரம்பை நெருங்கினால் எச்சரிக்கைகளை (alerts) அமைக்கவும். - Package size audits: ஒரு லைப்ரரியைச் சேர்ப்பதற்கு முன், அது எத்தனை மாடியூல்களைக் கொண்டுள்ளது என்பதைச் சரிபார்க்கவும். பெரிய ஐகான் பேக் அல்லது யூட்டிலிட்டி தொகுப்புகள் டெவ் கிராஃபை அமைதியாகப் பெருக்கக்கூடும்.
- Selective imports: வைல்ட்கார்டு (wildcard) அல்லது டைனமிக் இம்போர்டுகளை விட, பெயரிடப்பட்ட இம்போர்டுகளை (named imports) அல்லது நேரடி கோப்புப் பாதைகளைத் தேர்ந்தெடுங்கள், குறிப்பாக பண்டலர் அனைத்தையும் நினைவகத்தில் வைத்திருக்கும் டெவ் சூழலில்.
- Production vs. dev parity: வெற்றிகரமான புரொடக்ஷன் பில்டை ஒரு தனி சரிபார்ப்புப் படிநிலையாகக் கருதுங்கள். ஹாட்-ரீலோடிங்கின் போது மட்டுமே தோன்றும் சிக்கல்களைக் கண்டறிய மெமரி மானிட்டருடன் டெவ் சர்வரை இயக்கவும்.
சுருக்கம்
ஒரு சிறிய டைனமிக் இம்போர்ட் செய்யப்பட்ட ஐகான் பேக்கேஜ், ஹோஸ்ட்டின் வளங்கள் திட்டமிட்டு மட்டுப்படுத்தப்பட்டிருந்தாலும், ஒரு WSL2-அடிப்படையிலான Next.js டெவ் சர்வரை முடக்கும் அளவுக்குப் போதுமான RAM-ஐ நுகரக்கூடும். பரந்த டைனமிக் இம்போர்ட்களைத் தவிர்ப்பதன் மூலமும், பேக்கேஜ் அளவிலான இம்போர்ட் ஆப்டிமைசேஷனை (import optimization) எனேபிள் செய்வதன் மூலமும், நினைவகப் பயன்பாட்டைக் கண்காணிப்பதன் மூலமும், டெவலப்பர்கள் தங்கள் லினக்ஸ்-இன்சைடு-விண்டோஸ் சூழலைத் தடையின்றி வைத்திருக்க முடியும்.