Windows-এ আসলে কতটা মেমরি মুক্ত করা যায়

সংক্ষিপ্ত উত্তর

বাস্তবে “মেমরি অপ্টিমাইজার”-রা যতটা প্রতিশ্রুতি দেয়, তার চেয়ে কম মেমরি মুক্ত করা সম্ভব। এই পরীক্ষায় ব্যাকগ্রাউন্ড কম্পোনেন্ট বন্ধ করে 1,0–1,5 গিগাবাইট উপলব্ধ মেমরি মুক্ত হয়েছে এবং সিরিজ 2-এ কমিট (commit) পরিমাণ 52 % কমেছে। কিন্তু জনপ্রিয় দ্রুত পদ্ধতিগুলো কাজ করে না: শেল প্রসেস বন্ধ করা — Windows প্রায় 20 সেকেন্ডের মধ্যে সেগুলো নিজেই পুনরায় চালু করে; working set পরিষ্কার করা — আনলোড করা পেজ RAM-এ ক্যাশ হিসেবে থেকে যায়; মেমরি ম্যানেজারের রেজিস্ট্রি প্যারামিটার — কোনো নিশ্চিত উপকার নেই। ইতিমধ্যে অপ্টিমাইজ করা সিস্টেমের উপর নির্দিষ্ট কিছু বন্ধ করা সৎভাবে +22–30 মেগাবাইট দিয়েছে। standby তালিকার মেমরি হলো ক্যাশ, যা ইতিমধ্যে “উপলব্ধ”-তে হিসাব করা আছে।

স্ট্যাটাস: চূড়ান্ত সংখ্যাগুলো Windows 11 (26H2, build 26300.9457) সহ 8 গিগাবাইট RAM-এর ভার্চুয়াল মেশিনে পাওয়া গেছে। দিকনির্দেশগুলো Microsoft-এর ডকুমেন্টেশন এবং আমাদের নিয়ন্ত্রিত পরীক্ষায় নিশ্চিত হয়েছে; অন্য কনফিগারেশনে পরম মান ভিন্ন হবে।

যাচাইযোগ্য দাবিসমূহ

আমরা চারটি দাবি যাচাই করেছি:

1. “অপ্রয়োজনীয়” ব্যাকগ্রাউন্ড প্রসেস বন্ধ করা মেমরি মুক্ত করে।
2. working set বা standby তালিকা পরিষ্কার করা (“RAM অপ্টিমাইজার”-দের পদ্ধতি) মেমরি মুক্ত করে।
3. মেমরি ম্যানেজারের রেজিস্ট্রি প্যারামিটার লক্ষণীয়ভাবে মেমরি মুক্ত করে।
4. ব্যাকগ্রাউন্ড কম্পোনেন্ট বন্ধ করা প্রচুর পরিমাণ মেমরি মুক্ত করে।

исследования পরিধি

• Windows 11 Pro, build 26300.9457 (26H2); ভার্চুয়াল মেশিন, 8 গিগাবাইট RAM;
• একই ইনস্টলেশনের দুটি অবস্থা: প্রাথমিক (“আগে”) এবং BoosterX অপ্টিমাইজেশন প্রোফাইল প্রয়োগের পরে — পরিমাপ দুটি স্বাধীন সিরিজে সম্পন্ন হয়েছে (বিস্তারিত প্রোটোকল এবং বাকি মেট্রিক — «শান্ত অলসতা: অপ্টিমাইজেশনের আগে ও পরে Windows-এর ব্যাকগ্রাউন্ড»-এ);
• “পরে” অবস্থার উপর — নির্দিষ্ট ব্যাকগ্রাউন্ড উৎস বন্ধ করার প্যাকেজ (ডায়াগনস্টিক ETW অটোলগার, নোটিফিকেশন, শ্যাডো কপি এবং আপডেট অর্কেস্ট্রেটর সার্ভিস);
• মেট্রিক: উপলব্ধ ও দখলকৃত মেমরি, কমিট (commit) পরিমাণ, nonpaged/paged pool, প্রসেস অনুযায়ী working set ও private bytes, পেজ ফল্ট (hard faults)।

অন্তর্ভুক্ত করা হয়নি: ভৌত হার্ডওয়্যার, ভিন্ন RAM 용량ের সিস্টেম, pagefile বন্ধ করার পরীক্ষা এবং তৃতীয় পক্ষের “মেমরি অপ্টিমাইজেশন” ইউটিলিটি।

পদ্ধতি

• মেমরি ইনভেন্টরি স্থিতিশীল অলসতায় নেওয়া হয়েছে: সিস্টেম কাউন্টার (উপলব্ধ, দখলকৃত, commit, পুল) এবং working set ও private bytes সহ প্রসেসের তালিকা।
• নিয়ন্ত্রিত পরীক্ষা “শেল প্রসেস বন্ধ করা”: ইন্টারফেসের দুটি প্রসেস (SearchHost.exe এবং StartMenuExperienceHost) বন্ধ করা হয়েছে, 20 ও 40 সেকেন্ড পরে অবস্থা যাচাই করা হয়েছে; commit আগে ও পরে রেকর্ড করা হয়েছে।
• নির্দিষ্ট বন্ধ করার প্যাকেজ “পরে” অবস্থায় প্রয়োগ করা হয়েছে, তারপর রিবুট করে প্যাকেজ ছাড়া একই অবস্থার চারটি নিয়ন্ত্রণ বুটের সাথে তুলনা করা হয়েছে; বুট পরীক্ষায় পারফরম্যান্স রিগ্রেশনের অনুপস্থিতি যাচাই করা হয়েছে।
• পরিমাপ স্তর (ট্রেসিং, কাউন্টার, সংগ্রহ স্ক্রিপ্ট) নিজেই মেমরি দখল করে — কিছু পরিমাপে একশ বা তার বেশি মেগাবাইট working set; এটি সীমাবদ্ধতায় উল্লেখ করা হয়েছে।

ফলাফল

ব্যাকগ্রাউন্ড কতটা দখল করে

অলসতায় ইনভেন্টরি স্ন্যাপশট (সিরিজ 1):

	আগে	পরে	পরিবর্তন
মোট working set, মেগাবাইট	3 841	1 868	−51 %
মোট private bytes, মেগাবাইট	1 524	660	−57 %
উপলব্ধ মেমরি, মেগাবাইট	5 490	6 518	+1 028

সিরিজ 2: দখলকৃত মেমরি 3 017 → 1 538 মেগাবাইট, উপলব্ধ 5 174 → 6 653 মেগাবাইট, কমিট পরিমাণ 2 617 → 1 249 মেগাবাইট। দিকনির্দেশ উভয় সিরিজেই মিলে যায়: ব্যাকগ্রাউন্ড কম্পোনেন্ট এই প্রোফাইলের দখলকৃত মেমরির প্রায় অর্ধেক ধরে রাখে।

দখলকৃত মেমরির গঠন

“পরে” অবস্থায় মেমরি এভাবে বণ্টিত ছিল (মোট working set, সিরিজ 1):

• শেল (ফাইল এক্সপ্লোরার, DWM, স্টার্ট মেনুতে অনুসন্ধান, সেশন হোস্ট) — প্রায় 640 মেগাবাইট;
• ব্যাকগ্রাউন্ড সার্ভিস — প্রায় 640 মেগাবাইট (39টি হোস্ট প্রসেসে 57টি সার্ভিস);
• অনুসন্ধানের ওয়েব কম্পোনেন্ট — প্রায় 320 মেগাবাইট;
• কার্নেল পুল — প্রায় 167 মেগাবাইট, যার মধ্যে প্রায় 76 মেগাবাইট রেজিস্ট্রি পুল দখল করে।

প্রসেসের working set মুক্ত হওয়া মেমরির সমান নয়: এতে শেয়ারকৃত পেজ (সিস্টেম লাইব্রেরির কোড, সাধারণ ডেটা) অন্তর্ভুক্ত, যা প্রতিটি প্রসেসে একইসাথে হিসাব করা হয়। সিরিজ 1-এর “পরে” অবস্থায় 75টি প্রসেসের working set-এর যোগফল ছিল 1 868 মেগাবাইট, আর private bytes-এর যোগফল — 660 মেগাবাইট; নির্দিষ্ট বন্ধ করার পরীক্ষার নিয়ন্ত্রণ বুটে মোট working set ছিল 2 036 মেগাবাইট। ইন্টারফেসের বৃহত্তম প্রসেস (সিরিজ 2):

প্রসেস	Working set, মেগাবাইট	Private, মেগাবাইট
SearchHost.exe (অনুসন্ধান)	187	80
explorer.exe (ফাইল এক্সপ্লোরার)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

“পরে” অবস্থায় standby তালিকা ছিল 711 মেগাবাইট। এটি হারানো মেমরি নয়, বরং ক্যাশ: standby ইতিমধ্যে “উপলব্ধ”-তে হিসাব করা আছে, এবং কোনো অ্যাপ্লিকেশন মেমরি চাইলে Windows এই পেজগুলো তাৎক্ষণিকভাবে পুনর্ব্যবহার করে।

পরীক্ষা: শেল প্রসেস বন্ধ করা

SearchHost.exe এবং StartMenuExperienceHost বন্ধ করার পরে (সিরিজ 2):

• উভয় প্রসেস প্রায় 20 সেকেন্ডের মধ্যে নতুন আইডেন্টিফায়ার নিয়ে স্বয়ংক্রিয়ভাবে পুনরায় চালু হয়েছে; 40 সেকেন্ড পরে তারা এখনও চলছিল;
• কমিট পরিমাণ কমেনি, বরং 12,6 মেগাবাইট বেড়েছে (1 386,9 থেকে 1 399,5 মেগাবাইট) — শেল প্রসেস পুনরায় চালু হওয়া নিজেই নতুন কাজ তৈরি করে;
• “উপলব্ধ” মেমরির স্বল্পমেয়াদী 93 মেগাবাইট বৃদ্ধি সাশ্রয় নয়: লক্ষ্য প্রসেসগুলো ফিরে এসেছে, commit বেড়েছে।

আলাদা পরিমাপে ফাইল এক্সপ্লোরার বন্ধ করাও (সিরিজ 1) মুক্ত মেমরির স্থিতিশীল বৃদ্ধি দেয়নি: এই উইন্ডোতে মুক্ত মেমরি এমনকি 97 মেগাবাইট কমেছে, standby 13 মেগাবাইট বেড়েছে — আনলোড করা পেজ সিস্টেমে ক্যাশ হিসেবে থেকে যায়, আর শেল ও সংশ্লিষ্ট প্রসেস কাজ চালিয়ে যায়।

পরীক্ষার সিদ্ধান্ত: সিস্টেম প্রসেস জোরপূর্বক বন্ধ করা মেমরি মুক্ত করে না। Windows শেল কম্পোনেন্ট স্বয়ংক্রিয়ভাবে পুনরায় চালু করে, এবং সাশ্রয়ের বদলে আপনি অতিরিক্ত লোড পান।

working set ও standby তালিকা পরিষ্কার করা

পদ্ধতিটি Microsoft-এ ডকুমেন্টেড। working set থেকে পেজ আনলোড করা (যেমন EmptyWorkingSet ফাংশন বা “খালি” আকারের SetProcessWorkingSetSize — “RAM অপ্টিমাইজার”-রা ঠিক এগুলোই ব্যবহার করে) পেজগুলোকে একটি অন্তর্বর্তী অবস্থায় নিয়ে যায়: সেগুলো RAM-এ ক্যাশ হিসেবে থেকে যায়, যতক্ষণ না আবার প্রয়োজন হয় বা পুনর্ব্যবহৃত হয়। প্রসেসের পরবর্তী অ্যাক্সেস সেই পেজে একটি সফট পেজ ফল্ট এবং working set-এ প্রত্যাবর্তন ঘটায়।

তাই working set পরিষ্কার করা কাউন্টারে “মুক্ত” সংখ্যাটি বদলায়, কিন্তু ভৌতভাবে উপলব্ধ মেমরি তৈরি করে না: পেজগুলো কোথাও হারায় না, বরং সেগুলোতে পুনরায় অ্যাক্সেস ব্যয়বহুল হয়ে ওঠে। standby তালিকা পরিষ্কার করাও একই কারণে অর্থহীন: standby — সিস্টেমের কাছে ইতিমধ্যে উপলব্ধ মেমরি। আমাদের পরিমাপে উভয় অবস্থাতেই মেমরির উপর pressure ছিল না (hard faults কম ছিল), তাই অতিরিক্ত আনলোড কিছুই উন্নত করেনি।

এই পরীক্ষা থেকে আমাদের মানদণ্ড: “মেমরি মুক্ত করার” ফলাফল commit, পেজ ফল্ট এবং মেমরি পুনর্ব্যবহারের সময় বিলম্ব দিয়ে মূল্যায়ন করা উচিত, “মুক্ত” লাইনের স্বল্পমেয়াদী বৃদ্ধি দিয়ে নয়।

নির্দিষ্ট বন্ধ করা: সৎ বৃদ্ধি

“পরে” অবস্থার উপর আমরা নয়টি ডায়াগনস্টিক ETW অটোলগার এবং চারটি ব্যাকগ্রাউন্ড সার্ভিস (নোটিফিকেশন, শ্যাডো কপি, আপডেট অর্কেস্ট্রেটর) বন্ধ করেছি এবং ফলাফল চারটি নিয়ন্ত্রণ বুটের সাথে তুলনা করেছি:

মেট্রিক	নিয়ন্ত্রণ বুট	প্যাকেজ সহ	পার্থক্য
মুক্ত মেমরি, মেগাবাইট	6 664–6 674	6 696	+22…+30
Nonpaged pool, মেগাবাইট	69,8–71,8	58,7	−11…−13
মোট working set, মেগাবাইট	2 036	1 959	−77
পরীক্ষার পারফরম্যান্স	অপরিবর্তিত	অপরিবর্তিত	—

শুধু অটোলগারগুলো −13,2 মেগাবাইট nonpaged pool দিয়েছে (আলাদাভাবে পরিমাপ করা)। গুরুত্বপূর্ণ: ইনভেন্টরি অনুযায়ী বন্ধ করা কম্পোনেন্টের working set-এর যোগফল ছিল প্রায় 78 মেগাবাইট, কিন্তু মুক্ত মেমরির প্রকৃত বৃদ্ধি — +22–30 মেগাবাইট। পার্থক্যের কারণ, “বন্ধ করা” অংশের কিছু আগেই চালু ছিল না। এটাই সিস্টেম কম্পোনেন্ট না মুছে নির্দিষ্ট বন্ধ করার সৎ সীমা; পাশাপাশি একই প্যাকেজ অলসতার ব্যাকগ্রাউন্ড সক্রিয়তা আরও 24 % কমিয়েছে।

মেমরি ম্যানেজারের রেজিস্ট্রি প্যারামিটার (পুলের আকার, সিস্টেম ক্যাশ এবং অনুরূপ) এই পরীক্ষায় লাভের উৎস হিসেবেই বিবেচনা করা হয়নি: সেগুলোর পাঠ ও ব্যবহারিক উপযোগিতা «Memory Manager এবং সিস্টেম cache»-এ বিশ্লেষণ করা হয়েছে — RAM মুক্ত করার জন্য তাদের কোনো নিশ্চিত উপকার নেই।

যা নিশ্চিত হয়েছে

• পুনরুৎপাদিত (দুটি সিরিজ): ব্যাকগ্রাউন্ড কম্পোনেন্ট বন্ধ করা 1,0–1,5 গিগাবাইট উপলব্ধ মেমরি মুক্ত করে; মোট working set 51 % কমেছে (সিরিজ 1), দখলকৃত মেমরি — 49 % এবং কমিট (commit) পরিমাণ — 52 % (সিরিজ 2)।
• পরিমাপকৃত: বন্ধ করা শেল প্রসেস 20 সেকেন্ডের মধ্যে স্বয়ংক্রিয়ভাবে পুনরায় চালু হয়; এতে commit কমে না (আমাদের পরীক্ষায় 12,6 মেগাবাইট বেড়েছে)।
• পরিমাপকৃত: ফাইল এক্সপ্লোরার বন্ধ করা মুক্ত মেমরির স্থিতিশীল বৃদ্ধি দেয় না; আনলোড করা পেজ standby-তে থেকে যায়।
• ডকুমেন্টেড: working set থেকে পেজ আনলোড করা সেগুলোকে RAM-এ ক্যাশকৃত অন্তর্বর্তী অবস্থায় নিয়ে যায়; standby মেমরি উপলব্ধ মেমরিতে হিসাব করা হয়।
• পরিমাপকৃত: অপ্টিমাইজ করা সিস্টেমের উপর নির্দিষ্ট বন্ধ করা অপরিবর্তিত পারফরম্যান্সে +22–30 মেগাবাইট মুক্ত মেমরি দেয়; বন্ধ করা কম্পোনেন্টের working set-এর যোগফল মুক্ত মেমরির বৃদ্ধির সমান নয়।

যা নিশ্চিত হয়নি

• তৃতীয় পক্ষের “RAM অপ্টিমাইজার” সরাসরি পরীক্ষা করা হয়নি: যে পদ্ধতির (working set পরিষ্কার) উপর তারা দাঁড়িয়ে আছে, তা যাচাই করা হয়েছে।
• pagefile বন্ধ করা পরিমাপ করা হয়নি; শুধু জানা যে pagefile crash dump এবং মেমরি কমিট সীমার জন্য প্রয়োজন।
• ভিন্ন RAM 용량, ভিন্ন build এবং ভৌত হার্ডওয়্যারের মেশিনে মান স্থানান্তর।
• দীর্ঘ উইন্ডোতে সাশ্রয়ের স্থায়িত্ব: পরিমাপ স্থিতিশীল অলসতায় সম্পন্ন হয়েছে।

সীমাবদ্ধতা

• 8 গিগাবাইট RAM-এর ভার্চুয়াল মেশিন: পরম সংখ্যাগুলো এই কনফিগারেশনের সাথে বাঁধা; বেশি ব্যাকগ্রাউন্ড কম্পোনেন্টের প্রোফাইল বেশি মুক্ত করবে, “শান্ত” সিস্টেম — কম।
• প্রসেস অনুযায়ী working set-এর যোগফল শেয়ারকৃত পেজের কারণে অনন্য ফুটপ্রিন্ট বাড়িয়ে দেখায়; ঠিক এ কারণেই আমরা পাশে private bytes দিয়েছি।
• পরিমাপ স্তর নিজেই লক্ষণীয় মেমরি দখল করেছিল (কিছু পরিমাপে কয়েকশ মেগাবাইট working set পর্যন্ত) — অবস্থার সংখ্যাগুলোতে পরিমাপের উপস্থিতি অন্তর্ভুক্ত।
• পরীক্ষায় মেমরির চাপ ছিল না (hard faults কম), তাই RAM-এর ঘাটতির পরিস্থিতিতে সাশ্রয় трешинг কমায় কি না, তা আমরা যাচাই করিনি।
• মুক্ত করার একটি অংশ Microsoft Defender সুরক্ষা কম্পোনেন্ট বন্ধ করার সাথে সম্পর্কিত — এটি নিরাপত্তার সাথে একটি সমঝোতা, বিনামূল্যে পাওয়া মেমরি নয়।

исследования এবং ব্যবহৃত টুলগুলো BoosterX ডেভেলপারের মালিকানাধীন, আর BoosterX — একটি Windows অপ্টিমাইজার, তাই অপ্টিমাইজেশনের প্রভাব পরিমাপ করা তার সরাসরি স্বার্থ। পদ্ধতি ও প্রযোজ্যতার সীমা উপরে বর্ণিত, এবং সিদ্ধান্তগুলো খোলা ডেটা ও উল্লিখিত পাবলিক সূত্র দিয়ে যাচাই করা যায়। “মেমরি মুক্ত করার” জনপ্রিয় পদ্ধতিগুলোর নেতিবাচক ফলাফল ইতিবাচকগুলোর সমানভাবে প্রকাশিত হয়েছে।

ব্যবহারিক সিদ্ধান্ত

এই পরীক্ষা অনুযায়ী যা সত্যিই মেমরি মুক্ত করে:

• অব্যবহৃত অ্যাপ্লিকেশন বন্ধ করা — তাদের private bytes সম্পূর্ণ মুক্ত হয়;
• সত্যিই অপ্রয়োজনীয় ব্যাকগ্রাউন্ড কম্পোনেন্ট বন্ধ করা — পরিমাপকৃত সম্মিলিত প্রভাব «শান্ত অলসতা»-এ বর্ণিত; যাচাইকৃতগুলোর মধ্যে এটিই একমাত্র পদ্ধতি যা গিগাবাইট দিয়েছে, এবং এর মূল্য — সংশ্লিষ্ট ফাংশন হারানো;
• ফলাফল commit এবং উপলব্ধ মেমরি দিয়ে মূল্যায়ন করা (টাস্ক ম্যানেজার → “পারফরম্যান্স” → “মেমরি”), “মুক্ত” লাইন দিয়ে নয়।

যা কাজ করে না:

• সিস্টেম প্রসেস জোরপূর্বক বন্ধ করা: Windows সেগুলো সেকেন্ডের মধ্যে পুনরায় চালু করে, commit বাড়ে;
• “RAM অপ্টিমাইজার” এবং standby পরিষ্কার: আনলোড করা পেজ RAM-এ ক্যাশ হিসেবে থেকে যায়, আর সেগুলোকে কাজে ফিরিয়ে আনার খরচ সফট পেজ ফল্ট;
• মেমরি ম্যানেজারের রেজিস্ট্রি প্যারামিটার।

Standby মেমরি সমস্যা নয়, বরং ক্যাশের কাজ: “উপলব্ধ” ইতিমধ্যে এটিকে অন্তর্ভুক্ত করে। pagefile সিস্টেমের নিয়ন্ত্রণে রাখুন: এটি মেমরি কমিট সীমা এবং ক্র্যাশ ডাম্পের জন্য প্রয়োজন।

অবস্থা পুনরুদ্ধার

পরীক্ষাগুলো বিচ্ছিন্ন ভার্চুয়াল মেশিনে অবস্থার পরীক্ষামূলক ব্রাঞ্চে সম্পন্ন হয়েছে; পরিমাপের পরে পরীক্ষামূলক ব্রাঞ্চ রিসেট করা হয়েছে, মেশিন প্রাথমিক অবস্থায় ফিরিয়ে আনা হয়েছে। নিবন্ধটি সিস্টেম প্রসেস বন্ধ করা বা pagefile নিষ্ক্রিয় করার সুপারিশ করে না, তাই ব্যবহারকারীর কম্পিউটারে আলাদা পুনরুদ্ধার পদক্ষেপের প্রয়োজন নেই।

পাবলিক প্রাথমিক সূত্র

• Microsoft: Working Set — working set-এর গঠন, পেজ আনলোড, RAM-এ ক্যাশকৃত অন্তর্বর্তী পেজ, এবং EmptyWorkingSet/SetProcessWorkingSetSize ফাংশন; যাচাই করা হয়েছে 2026-09-20।
• Microsoft: EmptyWorkingSet — “মেমরি অপ্টিমাইজেশন” ইউটিলিটিগুলোর ব্যবহৃত API; যাচাই করা হয়েছে 2026-09-20।
• Microsoft: About Memory Management — ভার্চুয়াল মেমরি এবং শেয়ারকৃত পেজের মডেল; যাচাই করা হয়েছে 2026-09-20।
• Microsoft: Introduction to the page file — commit charge, কমিট সীমা এবং pagefile-এর ভূমিকা; যাচাই করা হয়েছে 2026-09-20।
• Memory Manager এবং সিস্টেম cache — মেমরি ম্যানেজারের রেজিস্ট্রি প্যারামিটারের исследования।
• শান্ত অলসতা: অপ্টিমাইজেশনের আগে ও পরে Windows-এর ব্যাকগ্রাউন্ড — পরিমাপ প্রোটোকল এবং এই একই পরীক্ষার বাকি মেট্রিক।
• আমরা কীভাবে Windows исследования করি — প্রমাণের স্তর এবং পরিমাপের নিয়ম।

পরিবর্তনের ইতিহাস

• 2026-09-20: সংখ্যাগুলো সিরিজের টেবিলের সাথে মিলিয়ে আনা হয়েছে: সিরিজ 1-এর “পরে” — 1 868/660 মেগাবাইট, মেট্রিক ও সিরিজ অনুযায়ী শতাংশের অ্যাট্রিবিউশন স্পষ্ট করা হয়েছে; স্বার্থের সংঘাতের ডিসক্লেইমার পূর্ণ সূত্রায়ন পর্যন্ত জোরদার করা হয়েছে।
• 2026-09-20: প্রথম প্রকাশ — দুটি সিরিজে মেমরি ইনভেন্টরি, প্রসেস বন্ধ করা ও পরিষ্কার করার নেতিবাচক পরীক্ষা, নির্দিষ্ট বন্ধ করার সৎ বৃদ্ধি।