একটি মাত্র ডাইনামিক আইকন ইমপোর্ট ১৬ জিবি (16 GB) উইন্ডোজ সাবসিস্টেম ফর লিনাক্স ২ (WSL2) মেশিনে ডেভ সার্ভার অচল করে দিয়েছিল, যার ফলে vmmemWSL প্রসেসটি সমস্ত উপলব্ধ মেমরি দখল করে নেয় এবং পুরো লিনাক্স উইন্ডোটি ফ্রিজ করে দেয়। ক্র্যাশটি ঘটেছিল Turbopack ব্যবহার করা একটি Next.js 16 প্রজেক্ট চালানোর সময়, এবং এটি .wslconfig ফাইল দিয়ে VM-এর RAM ব্যবহারের সীমা নির্ধারণ করা সত্ত্বেও ঘটেছিল।

কেন একটি ছোট ইমপোর্ট দানবীয় আকার ধারণ করতে পারে

ডেভেলপার ডাইনামিক এন্ট্রি পয়েন্টের মাধ্যমে রানটাইমে আইকনগুলো রেজলভ করার চেষ্টা করেছিলেন। এই ইমপোর্টটি এমন একটি আইকন প্যাকেজকে টেনে এনেছিল যাতে প্রায় ৯,০০০টি মডিউল রয়েছে। Turbopack, যা Rust-ভিত্তিক একটি বান্ডলার এবং Next.js 16-এর ডেভ সার্ভারকে সচল রাখে, এটি প্রতিটি প্যাকেজের জন্য একটি পূর্ণাঙ্গ মডিউল ম্যাপ তৈরি করে। ডেভ মোডে এই ম্যাপটি মেমরিতে থাকে এবং প্রতিটি ফাইল পরিবর্তনের সাথে সাথে আপডেট হয়। পুরো আইকন প্যাকেজটি লোড করার ফলে Turbopack প্রচুর পরিমাণে RAM বরাদ্দ করতে বাধ্য হয়, যা দ্রুত .wslconfig ফাইলে নির্ধারিত কঠোর সীমা অতিক্রম করে ফেলে। একবার সীমা অতিক্রম হওয়ার পর, WSL VM রেসপন্স করা বন্ধ করে দেয়; Ctrl + C কাজ করছিল না এবং একমাত্র উপায় ছিল উইন্ডোজ হোস্টকে জোরপূর্বক শাটডাউন করা।

একই কোডের একটি প্রোডাকশন বিল্ড সফল হয়েছিল কারণ বান্ডলারটি একবার গ্রাফ কম্পাইল করে, অ্যাসেটগুলো তৈরি করে এবং প্রসেসটি বন্ধ করে দেয়। তবে, ডেভ সার্ভার হট-রিলোডিং সুবিধা দেওয়ার জন্য গ্রাফটিকে মেমরিতে রেখে দেয়। তাই একটি সফল (green) বিল্ড এই নিশ্চয়তা দেয় না যে ডেভ এনভায়রনমেন্ট একই ধরনের ইমপোর্ট প্যাটার্ন সহ্য করতে পারবে।

বৃহত্তর প্রভাব

উইন্ডোজের ভেতরে লিনাক্স-ভিত্তিক টুলচেইন নিয়ে কাজ করা ডেভেলপাররা রিসোর্স ব্যবহার আলাদা রাখতে WSL2-এর ওপর নির্ভর করেন। যখন একটি মাত্র ইমপোর্ট VM-এর মেমরি শেষ করে ফেলে, তখন পুরো হোস্ট স্লো বা আনরেসপন্সিভ হয়ে যেতে পারে, যা একই মেশিনে থাকা অন্যান্য কন্টেইনার বা অ্যাপ্লিকেশনকেও প্রভাবিত করে। এই ঘটনাটি সাধারণ Node.js মেমরি-টিউনিং ফ্ল্যাগ এবং Turbopack-এর আর্কিটেকচারের মধ্যে একটি অমিলকেও তুলে ধরে: Turbopack Rust-এ চলে, V8-এ নয়, তাই Node --max-old-space-size ফ্ল্যাগ বাড়ানো এর RAM ব্যবহার কমানোর ক্ষেত্রে কোনো কাজে আসে না।

আসলে কী ঘটেছিল

  • ডাইনামিক এন্ট্রি পয়েন্ট: ইমপোর্ট স্টেটমেন্টটি বান্ডলারকে পুরো আইকন প্যাকেজটিকে একটি একক, লেজি-লোডেড (lazily-loaded) মডিউল হিসেবে বিবেচনা করতে বলেছিল। Turbopack এর বিপরীতে মডিউল ম্যাপ তৈরির জন্য প্রতিটি ফাইল সক্রিয়ভাবে (eagerly) পার্স করতে শুরু করে।
  • ডেভ-সার্ভার গ্রাফ: একবারের প্রোডাকশন কম্পাইলের মতো নয়, ডেভ সার্ভার ফাইল পরিবর্তনের তাৎক্ষণিক ফিডব্যাক দেওয়ার জন্য সম্পূর্ণ ডিপেন্ডেন্সি গ্রাফ RAM-এ ধরে রাখে।
  • মেমরি ক্যাপ: .wslconfig ফাইলটি VM-এর মেমরি হোস্টের RAM-এর একটি ক্ষুদ্র অংশে সীমাবদ্ধ করে রেখেছিল। যখন Turbopack-এর চাহিদা সেই সীমা ছাড়িয়ে যায়, তখন VM ফ্রিজ হয়ে যায়।

মেমরি অর্ধেক কমিয়ে দেওয়ার সমাধানসমূহ

ডেভেলপার তিনটি ব্যবহারিক পরিবর্তন প্রয়োগ করেছিলেন যা RAM ব্যবহার ৩.৬ জিবি থেকে কমিয়ে ১.৮৭ জিবি করে দেয় এবং স্থিতিশীলতা ফিরিয়ে আনে:

১. ছোট অ্যাসেটের জন্য ডাইনামিক এন্ট্রি পয়েন্ট ব্যবহার করা বন্ধ করুন – শুধুমাত্র প্রয়োজনীয় আইকনগুলো ইমপোর্ট করুন, যেমন: import { SearchIcon } from 'icon-pack/search'। যদি মাত্র কয়েকটি আইকন লাগে, তবে ইনলাইন SVG ব্যবহার করা আরও হালকা। ২. next.config.ts-এ optimizePackageImports সক্রিয় করুন – এই অপশনটি Turbopack-কে প্যাকেজ রুট ব্যবহার না করে ইমপোর্টগুলোকে তাদের নির্দিষ্ট ফাইল পাথে রেজলভ করতে বলে, যা পুরো প্যাকেজ ট্রি লোড হওয়া প্রতিরোধ করে। ৩. Node heap ফ্ল্যাগের ওপর নির্ভর করবেন না – যেহেতু Turbopack-এর মেমরি ব্যবহার এর Rust রানটাইম দ্বারা নিয়ন্ত্রিত হয়, তাই --max-old-space-size এই সমস্যার সমাধানে কোনো প্রভাব ফেলে না।

.wslconfig-এর সীমা বজায় রাখা এখনও বুদ্ধিমানের কাজ। একটি কঠোর সীমা (hard cap) থাকলে উইন্ডোজ হোস্ট ক্র্যাশ করার পরিবর্তে VM সাময়িকভাবে থেমে যেতে পারে, যা আপনাকে সবকিছু অচল হওয়ার আগে ব্যবস্থা নেওয়ার সুযোগ দেয়।

আপনার কাজের ক্ষেত্রে যা খেয়াল রাখা উচিত

  • মেমরি ড্যাশবোর্ড: WSL-এর ভেতরে htop বা উইন্ডোজ টাস্ক ম্যানেজার ব্যবহার করে দেখা যেতে পারে কখন vmmemWSL স্পাইক করছে। মেমরি ব্যবহার আপনার নির্ধারিত সীমার কাছাকাছি পৌঁছালে অ্যালার্ট সেট করে রাখুন।
  • প্যাকেজ সাইজ অডিট: কোনো লাইব্রেরি যোগ করার আগে এটি দেখে নিন যে এতে কতগুলো মডিউল আছে। বড় আইকন প্যাক, ইউটিলিটি কালেকশন বা কম্পোনেন্ট লাইব্রেরি নিঃশব্দে ডেভ গ্রাফকে ফুলিয়ে তুলতে পারে।
  • সিলেক্টিভ ইমপোর্ট: ওয়াইল্ডকার্ড বা ডাইনামিক ইমপোর্টের পরিবর্তে নেমড ইমপোর্ট (named imports) বা সরাসরি ফাইল পাথ ব্যবহার করুন, বিশেষ করে ডেভ এনভায়রনমেন্টে যেখানে বান্ডলার সবকিছু মেমরিতে রাখে।
  • প্রোডাকশন বনাম ডেভ প্যারিটি: একটি সফল প্রোডাকশন বিল্ডকে আলাদা ভ্যালিডেশন ধাপ হিসেবে বিবেচনা করুন। হট-রিলোডিংয়ের সময় যেসব সমস্যা দেখা দেয় তা ধরার জন্য মেমরি মনিটর দিয়ে ডেভ সার্ভার চালান।

সারকথা

একটি মাত্র ডাইনামিকালি-ইমপোর্ট করা আইকন প্যাকেজ একটি WSL2-ভিত্তিক Next.js ডেভ সার্ভারকে অচল করে দেওয়ার মতো যথেষ্ট RAM খরচ করতে পারে, এমনকি যখন হোস্টের রিসোর্স ইচ্ছাকৃতভাবে সীমিত রাখা হয়। ব্যাপক ডাইনামিক ইমপোর্ট এড়িয়ে চলা, প্যাকেজ-লেভেল ইমপোর্ট অপ্টিমাইজেশন সক্রিয় করা এবং মেমরি ব্যবহার মনিটর করার মাধ্যমে ডেভেলপাররা তাদের উইন্ডোজের ভেতরের লিনাক্স এনভায়রনমেন্টকে রেসপন্সিভ রাখতে পারেন এবং জোরপূর্বক শাটডাউন এড়াতে পারেন।