লিনাক্সে মেমরি লিক নিয়ে সম্পূর্ণ টিউটোরিয়াল

আপনার রান্নাঘরের সিঙ্কের কল থেকে যদি কখনো ধীরে ধীরে জল চুইয়ে পড়ে, তবে আপনি জানেন যে এই চুইয়ে পড়া জল কতটা মারাত্মক হতে পারে: প্রথমে এগুলোকে তেমন কিছু মনে হয় না, কিন্তু সময়ের সাথে সাথে এগুলো একটি বড় সমস্যা তৈরি করতে পারে। লিনাক্সে মেমোরি লিকগুলো হুবহু একই রকম।এগুলো প্রায় অলক্ষ্যনীয় ক্ষীণ ধারার মতো শুরু হয় এবং শেষ পর্যন্ত একটি পরিষেবা, একটি গুরুত্বপূর্ণ মাইক্রোসার্ভিস, বা এমনকি একটি সম্পূর্ণ সার্ভারকেও অচল করে দেয়।

যে সিস্টেমকে সবসময় উপলব্ধ থাকতে হয় (যেমন সার্ভার, প্রোডাকশন কন্টেইনার, এমবেডেড ডিভাইস ইত্যাদি), সেখানে কারও নজরদারিতে না থাকা একটি মেমোরি লিক একটি টাইম বোমার মতো। পর্যবেক্ষণ না করলে শনাক্ত করা যায় না এবং সংশোধনও করা যায় না।অন্যথায়, আপনাকে OOM কিলার দ্বারা বন্ধ হয়ে যাওয়া প্রসেস, হঠাৎ ক্র্যাশ এবং কী ঘটেছে তা ঠিক বুঝতে না পারা ক্ষুব্ধ ব্যবহারকারীদের মতো সমস্যার সম্মুখীন হতে হবে। এই টিউটোরিয়ালে, আমরা সহজবোধ্য ভাষায় বিস্তারিতভাবে দেখব, কীভাবে কিছু সাধারণ টুল ব্যবহার করে লিনাক্সে মেমোরি লিক শনাক্ত ও বিশ্লেষণ করা যায়, যেমন... শীর্ষ/এইচটপ এমনকি উন্নত প্রোফাইলারদের মতো Valgrind, memleax বা gdb, যেমন ইউটিলিটি ছাড়াও /proc, pmap অথবা smem.

লিনাক্সে মেমোরি লিক কী এবং এটি এত বিপজ্জনক কেন?

মেমরি লিক ঘটে যখন একটি প্রোগ্রাম এটি সিস্টেম মেমরি (হিপ, স্ট্রাকচার, বাফার ইত্যাদি) সংরক্ষণ করে এবং তা কখনো মুক্ত করে না। যখন এটির আর প্রয়োজন হয় না। C বা C++ এর মতো ভাষায়, এর অর্থ সাধারণত কল করা। malloc, calloc, new যেগুলির সাথে তাদের সংশ্লিষ্টগুলি নেই free o deleteঅথবা এমন রেফারেন্সের ক্ষেত্রে যা আটকে যায় এবং সেই মেমরি পুনরায় ব্যবহার করা অসম্ভব করে তোলে।

বাস্তবে, প্রক্রিয়াটি স্বাভাবিকভাবে চলতে থাকে, কিন্তু এর মেমরি ব্যবহার ধীরে ধীরে বৃদ্ধি পায় প্রতিটি অনুরোধ, প্রতিটি কর্মচক্র বা প্রতিটি নতুন কাজের সাথে এই বৃদ্ধি খুব ধীর হতে পারে (প্রতিদিন কয়েক কিলোবাইট বা মেগাবাইটের মতো), যার ফলে ভালো পর্যবেক্ষণ ছাড়া এক নজরে এটি শনাক্ত করা বিশেষভাবে কঠিন।

এই সমস্যাটি উপেক্ষা করার পরিণতি সুস্পষ্ট: পারফরম্যান্সের অবনতি, ক্রমাগত অদলবদল, বিশাল লেটেন্সিএবং একটি নির্দিষ্ট পর্যায়ে, সিস্টেমের উপলব্ধ মেমরি শেষ হয়ে যায়। সেখানেই সমস্যাটি দেখা দেয়। লিনাক্স কার্নেল OOM কিলারযা সবচেয়ে বেশি মেমরি ব্যবহারকারী প্রসেসগুলোকে (অথবা অ্যালগরিদম যেগুলোকে সবচেয়ে ব্যয়যোগ্য বলে মনে করে) বন্ধ করে দেয়, যাতে পুরো সিস্টেমটি ক্র্যাশ করা থেকে রক্ষা পায়।

এই আচরণটি সাধারণত মনিটরিং গ্রাফে সবচেয়ে ভালোভাবে দেখা যায়: যেমন কোনো প্রসেসের RSS মেমরি। এটি বেশ কয়েক দিন ধরে ধীরে ধীরে বৃদ্ধি পায়। হঠাৎ করেই, OOM কিলার এটিকে বন্ধ করে দিয়ে সার্ভিসটি পুনরায় চালু করার মুহূর্তে এর মান সজোরে কমে যায়। যদি কেউ এই ঘটনাগুলো বিশ্লেষণ না করে, তাহলে এই লিকটি থেকেই যাবে এবং চক্রটি পুনরাবৃত্তি হতে থাকবে।

এজন্যই এটা বোঝা গুরুত্বপূর্ণ যে মেমরি লিক শুধু কোডের সমস্যা নয়তবে এর পাশাপাশি পরিচালনা ও পর্যবেক্ষণের বিষয়টিও গুরুত্বপূর্ণ: প্রোডাকশনে এগুলোকে কীভাবে শনাক্ত করতে হয়, সিস্টেম ইভেন্টের সাথে এদের সম্পর্ক স্থাপন করতে হয় এবং ইতিমধ্যে চলমান প্রসেস ও টেস্ট এনভায়রনমেন্ট উভয় ক্ষেত্রেই এগুলো বিশ্লেষণ করার জন্য টুলস থাকা প্রয়োজন।

স্মৃতিভ্রংশের সাধারণ কারণ ও সুস্পষ্ট লক্ষণসমূহ

বিকাশগত দৃষ্টিকোণ থেকে, স্মৃতিভ্রংশের সবচেয়ে সাধারণ কারণগুলো হলো সাধারণত প্রোগ্রামিং ত্রুটি এবং দুর্বল সম্পদ ব্যবস্থাপনা অনুশীলনসবচেয়ে সাধারণ কারণগুলোর মধ্যে রয়েছে: মেমরি মুক্ত করতে ভুলে যাওয়া, এমন মেমরি স্ট্রাকচার বজায় রাখা যা কখনও ছাঁটাই করা হয় না, সংশ্লিষ্ট বাফারযুক্ত ডেসক্রিপ্টর বন্ধ না করা, অথবা অভ্যন্তরীণ ত্রুটিযুক্ত থার্ড-পার্টি লাইব্রেরি ব্যবহার করা।

দীর্ঘক্ষণ ধরে চলা অ্যাপ্লিকেশন, যেমন ডেমন, ওয়েব সার্ভিস বা ব্যাচ প্রসেস যা কখনও রিস্টার্ট হয় না, সেগুলোর ক্ষেত্রে সমস্যা আরও বেড়ে যায়, কারণ যেকোনো ছোট ছিদ্র সময়ের সাথে সাথে জমে ওঠে।এমনকি একটি বিরল বাগ, যা কেবল নির্দিষ্ট কিছু ক্ষেত্রে ঘটে, সেটিও যদি মাসের পর মাস সক্রিয় থাকে, তবে র‍্যামের ব্যাপক ব্যবহার করতে পারে।

যে লক্ষণগুলো আপনাকে সতর্ক করবে, সেগুলো বেশ সহজেই চেনা যায়, যদি আপনি জানেন কীসের দিকে নজর রাখতে হবে। সবচেয়ে সুস্পষ্ট লক্ষণ হলো দেখা যে কীভাবে একটি প্রসেসের মেমোরি (RES/RSS) ক্রমাগত বৃদ্ধি পায়। কাজের চাপ স্থিতিশীল থাকলেও। এটা অনেকটা পার্ক করা গাড়ির ফুয়েল গেজ নেমে যেতে দেখার মতো।

আরেকটি সাধারণ প্রভাব হল কর্মক্ষমতার ক্রমবর্ধমান অবনতিসিস্টেমটি সোয়াপ ব্যবহার করা শুরু করে, ল্যাটেন্সি আকাশচুম্বী হয়ে যায়, যে কোয়েরি বা রিকোয়েস্টগুলো আগে দ্রুত ছিল সেগুলো অন্তহীন হয়ে পড়ে, এবং হোস্টের বাকি প্রসেসগুলোও ক্ষতিগ্রস্ত হয়, যদিও সেগুলো সরাসরি দায়ী নয়।

অবশেষে, সবচেয়ে নাটকীয় লক্ষণটি দেখা দেয়: অপ্রত্যাশিত প্রক্রিয়া বা সিস্টেম ব্যর্থতাবরাদ্দ করার মতো কোনো মেমরি না থাকায় কার্নেল ‘আউট-অফ-মেমরি কিলার’ সক্রিয় করে এবং প্রসেসগুলো বন্ধ করে দেয়। যদি ক্র্যাশ হওয়া প্রসেসটি একটি বিচ্ছিন্ন মাইক্রোসার্ভিস হয়, তবে এটি একটি সামান্য সমস্যা, কিন্তু যদি বন্ধ হয়ে যাওয়া প্রসেসটি, উদাহরণস্বরূপ, ডেটাবেস বা কিউ ম্যানেজার হয়, তবে এর প্রভাব খুব গুরুতর হতে পারে।

উৎপাদনে এই ক্ষেত্রগুলি সনাক্ত করার একটি অত্যন্ত কার্যকর উপায় হল মেমরি গ্রাফগুলিকে একত্রিত করা। সিস্টেম ইভেন্ট সংগ্রহOOM কিলার দ্বারা সৃষ্ট ইভেন্টগুলোও এর অন্তর্ভুক্ত। যদি আপনি আপনার ড্যাশবোর্ডে মেমরি ব্যবহারের এমন একটি প্যাটার্ন দেখতে পান যা ধীরে ধীরে বাড়ে, তারপর হঠাৎ কমে যায়, এবং ঠিক সেই মুহূর্তে আপনার এক বা একাধিক OOM কিলার ইভেন্ট ঘটে, তাহলে প্রায় নিশ্চিতভাবেই আপনি সেই প্রসেসটিতে একটি মেমরি লিকের সম্মুখীন হচ্ছেন।

top এবং htop দিয়ে প্রাথমিক পর্যবেক্ষণ

প্রাথমিক পদক্ষেপের জন্য বিষয়টিকে অতিরিক্ত জটিল করার কোনো প্রয়োজন নেই: যেমন সরঞ্জাম শীর্ষ এবং সর্বোপরি, htop কোন প্রসেসগুলো আপনার মেমোরি ব্যবহার করছে তা রিয়েল টাইমে দেখার জন্য এগুলো একদম উপযুক্ত। দোষীদের শনাক্ত করার জন্য এগুলো একটি দ্রুত কন্ট্রোল প্যানেলের মতো।

বেশিরভাগ ডিস্ট্রিবিউশনে আপনি ইনস্টল করতে পারেন htop প্যাকেজ ম্যানেজারের সাহায্যে সহজেই করা যায়। ডেবিয়ান-ভিত্তিক সিস্টেমে, এই ধরনের কিছু হলেই চলবে:

sudo apt install htop

একবার ইনস্টল হয়ে গেলে, যখন আপনি চালাবেন htop আপনি রঙ, সিপিইউ ও মেমরি বার এবং বিভিন্ন কলাম সহ প্রসেসগুলোর একটি ইন্টারেক্টিভ ভিউ দেখতে পাবেন। লিক শনাক্ত করার জন্য মূল কলামগুলি এগুলো হলো প্রক্রিয়াটির স্থায়ী স্মৃতি এবং ভার্চুয়াল স্মৃতি:

- আরইএস / আরএসএস (রেসিডেন্ট সেট সাইজ): প্রসেসটির বর্তমানে র‍্যামে থাকা ফিজিক্যাল মেমরি।
- ভিআইআরটি (ভার্চুয়াল মেমরি): প্রসেস কর্তৃক বরাদ্দকৃত মোট ভার্চুয়াল মেমরি (এর মধ্যে ম্যাপড এবং সম্ভাব্য সোয়াপড মেমরি অন্তর্ভুক্ত)।
- % MEMমোট সিস্টেম র‍্যামের মধ্যে প্রসেসটি যে পরিমাণ ফিজিক্যাল র‍্যাম ব্যবহার করছে, তার শতাংশ।

যদি আপনি অর্ডার করেন RES বা %MEM আর যদি আপনি htop কিছুক্ষণ খোলা রাখেন, তাহলে প্রসেসগুলো কীভাবে এগোচ্ছে তা দেখতে পারবেন। যদি সেগুলোর মধ্যে একটি... এটা কখনোই নিচে নেমে না এসে ধীরে ধীরে এই স্তম্ভগুলো বেয়ে উঠতে থাকে।এটি স্মৃতিভ্রংশ অথবা অন্ততপক্ষে এর অস্বাস্থ্যকর ব্যবহারের ইঙ্গিত দেয়।

top, যদিও আরও সংযত, এটিও আপনাকে এই মানগুলি দেখতে এবং একটি নির্দিষ্ট সময় ধরে পর্যবেক্ষণ করতে দেয়, কিন্তু htop আপনার আগ্রহের নির্দিষ্ট প্রক্রিয়াগুলির দীর্ঘমেয়াদী পর্যবেক্ষণ এবং ফিল্টারিং অনেক সহজ করে তোলে।

/proc ফাইল সিস্টেমের গভীরে অনুসন্ধান

অগভীর দৃষ্টিভঙ্গি থেকে আরও পরিশীলিত বিশ্লেষণে যেতে, লিনাক্স উন্মোচন করে ছদ্ম ফাইলসিস্টেমের প্রতিটি প্রক্রিয়া সম্পর্কে বিস্তারিত তথ্য /procপ্রতিটি পিআইডি-র নিজস্ব ডিরেক্টরি রয়েছে /procএবং সেখানে আপনি মেমরি সম্পর্কিত মেট্রিকসহ সব ধরনের মেট্রিক যাচাই করতে পারেন।

একটি ক্লাসিক এন্ট্রি পয়েন্ট হলো ফাইল /proc//status, যেখানে আপনি এই ধরনের ক্ষেত্রগুলি খুঁজে পাবেন যেমন VmRSS, VmSize বা VmDataআপনি একটি সহজ উপায়ে সেগুলি দেখে নিতে পারেন:

cat /proc/<pid>/status

সেই আউটপুটে, মেমরি লিক শনাক্ত করার জন্য সবচেয়ে গুরুত্বপূর্ণ ফিল্ডগুলো হলো:

- ভিএমআরএসএসসেই মুহূর্তে প্রসেসটির র‍্যামে থাকা স্থায়ী মেমোরি (কিলোবাইটে)।
- ভিএমসাইজপ্রসেসটির সাথে সংশ্লিষ্ট মোট ভার্চুয়াল মেমরি (ম্যাপ করা সবকিছু সহ)।
- ভিএমডেটাডেটা সেগমেন্ট মেমরি, যেখানে সাধারণত ডাইনামিক স্ট্রাকচার এবং হিপ থাকে, এটি এমন একটি এলাকা যা মেমরি লিকের জন্য অত্যন্ত ঝুঁকিপূর্ণ।

মূল ধারণাটি হলো এই মানগুলো নিয়মিত যাচাই করতে থাকা। নিয়মিত বিরতিতে (ম্যানুয়ালি অথবা স্ক্রিপ্টের মাধ্যমে) এবং লক্ষ্য করুন যে এগুলো একটি ধারাবাহিক ঊর্ধ্বমুখী প্রবণতা অনুসরণ করছে কিনা। যদি আপনি দেখেন যে কম লোডের সময়ে VmRSS এবং বিশেষ করে VmData না কমে ক্রমাগত বাড়ছে, তবে এটি একটি বেশ জোরালো ইঙ্গিত যে অ্যাপ্লিকেশনটি মেমোরি লিক করছে।

ছাড়াও status, ইন /proc/ মেমরি ম্যাপ বিশ্লেষণ করার জন্য আপনার কাছে অন্যান্য আকর্ষণীয় ফাইল রয়েছে, যেমন maps o smapsযদিও সেগুলি আরও বিশদ এবং প্রায়শই অন্যান্য সরঞ্জামগুলির সাথে একত্রে ব্যবহৃত হয়, যেমন পিম্যাপ তথ্যকে আরও পাঠযোগ্য করে তোলার জন্য।

pmap ব্যবহার করে একটি প্রসেসের মেমরি ম্যাপ বিশ্লেষণ

ইউটিলিটি পিম্যাপ কোনো নির্দিষ্ট প্রসেসের মেমরি ম্যাপের একটি সুসংগঠিত চিত্র পাওয়ার জন্য এটি একটি অত্যন্ত দরকারি কমান্ড। মূলত, এটি দেখায় যে প্রসেসটি কোন কোন অ্যাড্রেস রেঞ্জ ম্যাপ করেছে, প্রতিটি রেঞ্জের আকার, সেটির পারমিশন এবং এটি কোন ফাইল, লাইব্রেরি বা মেমরি টাইপের সাথে সম্পর্কিত।

এটি ব্যবহার করতে, শুধু চালু করুন:

pmap

আউটপুটে আপনি শুরুর ঠিকানা, আকার, অনুমতি (পড়া, লেখা, চালানো) এবং উৎস (উদাহরণস্বরূপ, প্রধান এক্সিকিউটেবল, একটি শেয়ার্ড লাইব্রেরি যেমন) সহ লাইন দেখতে পাবেন। libcঅজ্ঞাত এলাকা, স্তূপ, ইত্যাদি)। বেনামী মেমরি অঞ্চল এবং হিপ জোন এগুলোই সাধারণত মেমোরি লিকের সূত্র দেয়।

অগ্রগতি পর্যবেক্ষণের একটি কার্যকর উপায় হলো পুনরাবৃত্তি করা। pmap কিছুক্ষণ পরপর পরীক্ষা করে দেখুন নির্দিষ্ট কিছু সেগমেন্ট (বিশেষ করে হিপ-সম্পর্কিত বেনামী সেগমেন্টগুলো) তারা বৃদ্ধি বন্ধ করে নাআপনি আউটপুট ফিল্টার বা সংক্ষিপ্ত করতেও পারেন, উদাহরণস্বরূপ:

pmap <pid> | grep total

এটি আপনাকে প্রসেসটি দ্বারা ব্যবহৃত মোট মেমরির একটি সারসংক্ষেপ দেবে। যদি সেই সংখ্যাটি বেশ কয়েক ঘন্টা ধরে ক্রমাগত বাড়তে থাকে এবং প্রত্যাশিত সময়ে স্থিতিশীল বা হ্রাস না পায়, তবে সন্দেহটি আবারও মেমরি লিক বা অভ্যন্তরীণ বাফারগুলির অদক্ষ ব্যবস্থাপনার দিকেই ইঙ্গিত করে।

smem: শেয়ার্ড মেমরি এবং প্রতিটি প্রসেসের প্রকৃত ব্যবহারের মধ্যে পার্থক্য নিরূপণ

top, htop, বা pmap-এর মতো টুলগুলো একটি প্রসেস যে সমস্ত মেমোরি ব্যবহার করে তা গণনা করে, কিন্তু সেগুলো সেই প্রসেসের নিজস্ব মেমোরি এবং অন্যদের সাথে শেয়ার করা মেমোরির (যেমন, শেয়ার্ড লাইব্রেরি) মধ্যে স্পষ্টভাবে পার্থক্য করে না। এখানেই [নিম্নলিখিত বিষয়টির ভূমিকা আসে]। smemআরও সঠিক চিত্র প্রদানের জন্য একটি বিশেষ পরিষেবা।

smem-এর সবচেয়ে বড় সুবিধা হলো এটি বিভিন্ন মেট্রিক গণনা করে, যেমন ইউএসএস (অনন্য সেট আকার), পিএসএস (আনুপাতিক সেট আকার) এবং আরএসএসযা প্রতিটি প্রসেসের প্রকৃত মেমরি ব্যবহার সম্পর্কে আরও ভালো ধারণা দেয়: এর মধ্যে কতটা মেমরি শুধু তার নিজের এবং কতটা অন্যান্য প্রসেসের সাথে ভাগ করা হয়, যারা একই লাইব্রেরি লোড করে বা পেজ শেয়ার করে।

smem আউটপুটে আপনি যে কয়েকটি সবচেয়ে প্রাসঙ্গিক মেট্রিক দেখতে পাবেন, সেগুলো হলো:

- ইউএসএস (ইউনিক সেট সাইজ): মেমরি যা শুধুমাত্র সেই প্রসেসটি ব্যবহার করে; যদি প্রসেসটি অদৃশ্য হয়ে যায়, তাহলে মেমরির ঐ অংশটি সম্পূর্ণরূপে মুক্ত হয়ে যায়।
- PSS (আনুপাতিক সেট সাইজ): এটি ব্যবহারকারী সমস্ত প্রসেসের মধ্যে শেয়ার্ড মেমরি বন্টন করে, যা এর প্রকৃত ফুটপ্রিন্টের একটি মোটামুটি ন্যায্য আনুপাতিক চিত্র প্রদান করে।
- আরএসএস (রেসিডেন্ট সেট সাইজ): অন্যান্য টুলের মতোই রেসিডেন্ট মেমরি, কিন্তু তুলনার জন্য এটি উপরেরটির সাথে একত্রে উপস্থাপন করা হয়েছে।

এরকম কিছু চালানোর সময় smem -k আপনি পিআইডি, ইউজার, কমান্ড এবং এই মেমরি ব্যবহারের কলামগুলো সহ একটি টেবিল পাবেন। মেমরি লিকের ক্ষেত্রে, আকর্ষণীয় বিষয়টি হলো প্রাথমিকভাবে এর উপর মনোযোগ দেওয়া। ইউএসএসকারণ এটি অ্যাপ্লিকেশনটির নিজস্ব মেমরিকে প্রতিফলিত করে, যেখানে সাধারণত সবচেয়ে গুরুতর মেমরি লিকগুলো দেখা যায়।

যদি আপনি smem পর্যায়ক্রমে চালু রাখেন (অথবা এটিকে মনিটরিং স্ক্রিপ্টে অন্তর্ভুক্ত করেন) এবং দেখেন যে একটি নির্দিষ্ট প্রসেসের USS... সময়ের সাথে সাথে এটি বাড়তে থাকে।এর লোড না বাড়লেও, এই আচরণটি ওই প্রসেসটির একক মেমরি অংশে একটি মেমরি লিকের জোরালো ইঙ্গিত দেয়।

মেমলিক্স: চলমান প্রক্রিয়াগুলিতে স্বয়ংক্রিয় লিক সনাক্তকরণ

একবার আপনি এমন একটি প্রসেস শনাক্ত করে ফেললে যেটি থেকে মেমোরি লিক হচ্ছে বলে মনে হয় এবং সেটিকে রিস্টার্ট না করেই আরও এক ধাপ এগিয়ে যেতে চান, সেক্ষেত্রে একটি অত্যন্ত কার্যকরী টুল হলো... মেমলেক্সএর সবচেয়ে বড় শক্তি হলো যে এর মাধ্যমে আপনি চলমান কোনো প্রসেসের মেমোরি লিক রিয়েল টাইমে শনাক্ত করতে পারবেন।এটিকে পুনরায় কম্পাইল করার বা কোনো বিশেষ কমান্ড দিয়ে পুনরায় চালু করার প্রয়োজন ছাড়াই।

মেমলিক্স প্রধানত প্যাকেজ আকারে বিতরণ করা হয়। .rpm y .debএটি আর্চ লিনাক্স এবং ফ্রিবিএসডি-র মতো কিছু রিপোজিটরিতে পাওয়া যায়। ডেবিয়ান-ভিত্তিক সিস্টেমে, এটি ইনস্টল করার একটি সাধারণ উপায় হলো এর অফিসিয়াল গিটহাব রিপোজিটরি থেকে প্যাকেজটি ডাউনলোড করে তারপর ব্যবহার করা। dpkg এটি ইনস্টল করতে, আপনার প্যাকেজ ম্যানেজারের সাহায্যে নির্ভরতাগুলো সমাধান করুন।

একবার ইনস্টল হয়ে গেলে, আপনি নিম্নলিখিত উপায়ে memleax-কে একটি প্রসেসের সাথে সংযুক্ত করতে পারেন:

sudo memleax -p

সেই মুহূর্ত থেকে, memleax মেমরি বরাদ্দের কলগুলিকে (যেমন mallocএবং প্রক্রিয়াটির জন্য সংরক্ষিত ঠিকানা ও আকারগুলো রেকর্ড করে। যখন এটি শনাক্ত করে যে একটি বরাদ্দ সঠিকভাবে মুক্ত করা হয়নিএটি ব্লক সাইজ এবং দায়ী অ্যাড্রেস উল্লেখ করে এটিকে স্পষ্টভাবে একটি মেমরি লিক হিসেবে চিহ্নিত করে।

সাধারণ আউটপুটে এই শৈলীর লাইনগুলো দেখা যায়। malloc(128) = 0x... এরপরে, যখন কোনো সমস্যা হয়, তখন এমন বার্তা আসে যা এইরকম কিছু নির্দেশ করে। মেমরি লিক শনাক্ত করা হয়েছে একটি নির্দিষ্ট ব্লকের জন্য। এই তথ্যটি খুবই দরকারি, কারণ এটি আপনাকে জানিয়ে দেয় যে, প্রসেসটি সক্রিয় ও সচল থাকা সত্ত্বেও কিছু ব্লক অনাথ হয়ে পড়ছে।

memlax বিশেষত প্রোডাকশন বা প্রি-প্রোডাকশন পরিবেশের জন্য আকর্ষণীয় যেখানে আপনার পক্ষে পরিষেবাটি পুনরায় চালু করা সম্ভব নয়। ডিবাগারের সাহায্যে অথবা একেবারে গোড়া থেকে ভ্যালগ্রাইন্ড দিয়ে, কিন্তু ডাইনামিক মেমোরি ম্যানেজমেন্টের ক্ষেত্রে ভেতরে কী ঘটছে তা আপনাকে বুঝতে হবে।

কোনো প্রসেসের মেমরি গভীরভাবে পরীক্ষা করার জন্য gdb ব্যবহার করা

যদি আপনার আরও বিশদ তথ্যের প্রয়োজন হয় এবং আরও পুঙ্খানুপুঙ্খ ডিবাগিং করার সামর্থ্য থাকে, তাহলে গ্নু ডিবাগার (gdb) এটি আপনার মিত্র। এটি একটি অত্যন্ত শক্তিশালী হাতিয়ার যা আপনাকে সক্ষম করে তোলে একটি বিদ্যমান প্রক্রিয়ায় যোগদান করুনভেরিয়েবল, কল স্ট্যাক এবং অবশ্যই, হিপ স্টেট পরীক্ষা করুন।

শুরু করার জন্য, আপনাকে আপনার ডিস্ট্রিবিউশনের রিপোজিটরি থেকে gdb ইনস্টল করতে হবে (উদাহরণস্বরূপ, এর মাধ্যমে sudo apt install gdb (ডেবিয়ান/উবুন্টুতে) এবং তারপর এটিকে একটি প্রসেসের সাথে সংযুক্ত করুন এভাবে:

sudo gdb -p

একবার gdb সেশনে প্রবেশ করলে, আপনি বিভিন্ন হিপ-সম্পর্কিত কমান্ড ব্যবহার করতে পারেন। কিছু পরিবেশে, কমান্ডটি সরাসরি উপলব্ধ থাকে। heap (অথবা যে এক্সটেনশনগুলো এই সুবিধা দেয়) বর্তমানে ব্যবহৃত ডাইনামিক মেমরি ব্লকগুলোর ঠিকানা ও আকারসহ তালিকা প্রকাশ করে। আউটপুটে মেমরি চাঙ্কের একটি তালিকা দেখা যায়, যার প্রতিটির একটি ঠিকানা ও আকার থাকে এবং যা চিহ্নিত করা থাকে। ব্যাবহৃত হচ্ছে.

এছাড়াও, gdb থেকে আপনি libc ফাংশনগুলি কল করতে পারেন, যেমন malloc_stats() মাধ্যম:

(gdb) call malloc_stats()

এই ধরনের কল আপনাকে মেমরি অ্যালোকেটরের অবস্থার একটি সারসংক্ষেপ দেয়: কী পরিমাণ মেমরি বরাদ্দ করা হয়েছে, হিপ কীভাবে বিভক্ত হয়েছে, ইত্যাদি। প্রসেস দ্বারা বরাদ্দ করা মেমরি অনিয়ন্ত্রিতভাবে বাড়ছে কিনা, তা দেখার এটি একটি তুলনামূলকভাবে দ্রুত উপায়।

আরেকটি শক্তিশালী পদ্ধতি হলো স্থাপন করা ফাংশনগুলিতে ব্রেকপয়েন্ট যেমন malloc o free রিয়েল টাইমে কোডটি কীভাবে আচরণ করছে তা পর্যবেক্ষণ করা: এটি কতবার মেমরি রিজার্ভ করে, কোন কোন পয়েন্টে তা রিলিজ করে, কোডের কোন অংশে অনেক বেশি অ্যালোকেশন কিন্তু কম ফ্রি করা হয়… যদিও এর জন্য আরও বেশি ডিবাগিং দক্ষতার প্রয়োজন, এটি মেমরি লিকের সঠিক উৎস খুঁজে বের করার একটি সরাসরি উপায়।

ভ্যালগ্রাইন্ড: লিনাক্সের ক্লাসিক মেমরি প্রোফাইলার

লিনাক্স পরিবেশে মেমরি লিক সনাক্তকরণ নিয়ে কথা বলতে গেলে, এর উল্লেখ না করে পারা যায় না। ভালগ্রাইন্ডভ্যালগ্রাইন্ড শুধু একটি টুলই নয়, এটি একটি ডিবাগিং এবং প্রোফাইলিং ফ্রেমওয়ার্ক যার মধ্যে বেশ কয়েকটি মডিউল রয়েছে, যার মধ্যে সবচেয়ে সুপরিচিত এবং ব্যবহৃত হল মেমচেকবিশেষভাবে স্মৃতিশক্তির সমস্যা শনাক্ত করার জন্য ডিজাইন করা হয়েছে।

মেমচেক আপনার প্রোগ্রামটিকে এক ধরনের ভার্চুয়াল মেশিনের ভেতরে চালানোর মাধ্যমে কাজ করে, যা এটি মেমরি-সম্পর্কিত সমস্ত কার্যক্রমকে আটক করে এবং পর্যবেক্ষণ করে।মেমরি বরাদ্দ, মেমরি মুক্তকরণ, অ্যাড্রেস অ্যাক্সেস ইত্যাদি। এছাড়াও, এটি C-এর স্ট্যান্ডার্ড মেমরি অ্যালোকেটরকে নিজের অ্যালোকেটর দিয়ে প্রতিস্থাপন করে, যা সংরক্ষিত ব্লকগুলোর চারপাশে অতিরিক্ত সুরক্ষা ব্যবস্থা যোগ করে সীমার বাইরের অ্যাক্সেস শনাক্ত করে।

মেমচেক যেসব ধরনের ত্রুটি শনাক্ত করতে পারে, তার মধ্যে রয়েছে: অপ্রারম্ভিক মেমরি ব্যবহার, মেমরি মুক্ত করার পরে পঠন/লিখনপ্রোগ্রামের অন্তর্ভুক্ত নয় এমন মেমোরি এলাকায় অবৈধ প্রবেশ এবং অবশ্যই, বিভিন্ন ধরণের মেমোরি লিক (নিশ্চিতভাবে হারিয়ে যাওয়া ব্লক, সম্ভাব্য হারিয়ে যাওয়া ব্লক, এখনও পৌঁছানো সম্ভব এমন ব্লক, ইত্যাদি)।

এর মৌলিক ব্যবহার তুলনামূলকভাবে সহজ। আপনি আপনার প্রোগ্রামটি ডিবাগিং প্রতীক (উদাহরণস্বরূপ, এর সাথে) দিয়ে কম্পাইল করেন। -g o -gstabsএবং তারপর আপনি ভ্যালগ্রিন্ডের অধীনে এটি চালান, অনেকটা এইরকম কিছু দিয়ে:

valgrind --tool=memcheck --leak-check=full -v ./tu_programa

যে প্রোগ্রাম ভালোভাবে মেমরি পরিচালনা করে, তাতে Memcheck-এর আউটপুট দেখাবে শূন্য ঘটনা সহ ত্রুটিগুলির সারাংশঅর্থাৎ, প্রোগ্রামটি বন্ধ হওয়ার সময় কোনো অবৈধ রিড, সীমার বাইরের রাইট এবং কোনো হিপ বাইট ব্যবহৃত হবে না। সাধারণত এটাই প্রথম ধাপ: একটি ‘ক্লিন’ এক্সিকিউশন দেখতে কেমন হয়, তা যাচাই করা।

যদি আপনি ইচ্ছাকৃতভাবে একটি এর সংশ্লিষ্ট free ছাড়া mallocঅথবা অন্য কোনো লিক প্যাটার্ন, এবং আপনি Valgrind দিয়ে বাইনারিটি আবার চালালে, আউটপুটে একটি দেখতে পাবেন হিপ সারাংশ অ্যাপ্লিকেশনটি বন্ধ হওয়ার পর কী পরিমাণ মেমরি 'ব্যবহৃত' থাকে তা নির্দেশ করে। এই বিভাগের অধীনে ফাঁসের সারসংক্ষেপ যেসব বাইট এবং ব্লক রিলিজ করা হয়নি, সেগুলোর সাথে “নিশ্চিতভাবে হারিয়ে গেছে”-এর মতো লাইন দেখা যাবে।

এছাড়াও, মেমচেক আপনাকে সঠিকভাবে বলে দেবে যেখানে লিকের কারণ হওয়া বরাদ্দটি ঘটেছিলআপনি ফাংশন, সোর্স ফাইল এবং লাইন নম্বর সহ একটি কল ট্রেস দেখতে পাবেন। উদাহরণস্বরূপ, এটি দেখাতে পারে যে একটি malloc আপনার ফাইলের একটি নির্দিষ্ট লাইনে .c এটি এমন একটি প্রতিবন্ধকতা তৈরি করেছে যা কখনও মুক্ত হয়নি, এবং সাথে সাথেই সমস্যার উৎসের উপর আলোকপাত করেছে।

Valgrind অন্যান্য চিরাচরিত ত্রুটি শনাক্ত করতেও খুব কার্যকর: উদাহরণস্বরূপ, স্মৃতিতে অবৈধ লেখা (যেমন অ্যাড্রেস 0-তে বা অ্যারের সীমার বাইরে লেখা), অনির্দিষ্ট ভেরিয়েবলের ব্যবহার (যার ফলে “শর্তসাপেক্ষ জাম্প বা মুভ অনির্দিষ্ট মানের উপর নির্ভরশীল” এর মতো বার্তা প্রদর্শিত হয়) অথবা ভুল রিলিজ কীভাবে করতে হয় free এমন একটি পয়েন্টারে যা থেকে আসে না malloc, অথবা একই ব্লক দুইবার ছেড়ে দিন)।

এই সমস্ত ক্ষেত্রে, মেমচেক রিপোর্টটি বিশদভাবে বর্ণনা করে যে কোথায় ত্রুটিপূর্ণ অ্যাক্সেস বা অবৈধ ফ্রি অ্যাক্সেস ঘটেছে, কোন ফাংশন থেকে এর উৎপত্তি হয়েছে, এবং কোডের কোন অংশে সেই ভেরিয়েবলটি তৈরি করা হয়েছিল বা সেই মেমরিটি সংরক্ষিত করা হয়েছিল, যা এটিকে কার্যত একটি অপরিহার্য টুলে পরিণত করে। C এবং C++ এ মেমরি ম্যানেজমেন্ট পুঙ্খানুপুঙ্খভাবে ডিবাগ করতে.

অন্যান্য মেমরি প্রোফাইলার: gperftools, Massif, এবং অন্যান্য

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

ভ্যালগ্রিন্ড পরিবারের আরেকটি সরঞ্জাম হল প্রচুরবিশেষভাবে মনোনিবেশ করা হয়েছে হিপ মেমরি প্রোফাইলিংশুধুমাত্র ত্রুটির উপর মনোযোগ দেওয়ার পরিবর্তে, ম্যাসিফ প্রোগ্রাম চলাকালীন হিপ সাইজ পরিমাপ করে এবং এমন ডেটা তৈরি করে যা আপনি ভিজ্যুয়ালাইজ করতে পারেন। এর মাধ্যমে আপনি বুঝতে পারেন যে আপনার প্রোগ্রামের কোন পর্যায়ে মেমরি সবচেয়ে বেশি বৃদ্ধি পায় এবং এর জন্য কোন স্ট্রাকচার বা ফাংশনগুলো দায়ী।

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

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

সক্রিয় কৌশল: লোড টেস্টিং, সীমা এবং সর্বোত্তম অনুশীলন

উপরোক্ত সবগুলোই সমস্যা তৈরি হয়ে যাওয়ার পর তা শনাক্ত করতে সাহায্য করে, কিন্তু আদর্শ কৌশলটি হলো উৎপাদন পর্যন্ত ফুটো পৌঁছানো প্রতিরোধ করুন অথবা অন্তত যত তাড়াতাড়ি সম্ভব সেগুলোকে শনাক্ত করুন। এর জন্য টেস্টিং, সিস্টেম কনফিগারেশন এবং কোডের মান সম্পর্কিত বিভিন্ন কৌশল একত্রিত করার পরামর্শ দেওয়া হয়।

প্রথমত, এটা করা খুবই যুক্তিযুক্ত। প্রি-প্রোডাকশন পরিবেশে লোড এবং স্ট্রেস টেস্টিং যেগুলো যথাসম্ভব বাস্তবসম্মত। যেমন সরঞ্জাম অ্যাপাচি জেমেটার, Locust, stress অনুরূপ টুলগুলো আপনাকে একই সাথে একাধিক ব্যবহারকারী, নিবিড় অনুরোধ বা দীর্ঘস্থায়ী পরিস্থিতি অনুকরণ করার সুযোগ দেয়। এই পরীক্ষাগুলোর সময়, কোনো সমস্যা আছে কিনা তা দেখার জন্য আপনার মেমরি মেট্রিক্স (RSS, হিপ, ইত্যাদি) সতর্কতার সাথে পর্যবেক্ষণ করা উচিত। ধীর কিন্তু অবিচ্ছিন্ন বৃদ্ধি.

এর পাশাপাশি, শুধু মূল মেট্রিকগুলোই নয়, বরং আরও অনেক কিছু পর্যবেক্ষণ করা বাঞ্ছনীয়। OOM কিলারের মতো সিস্টেম ইভেন্টলগ মনিটরিং এবং অবজার্ভেবিলিটি প্ল্যাটফর্মগুলো এই তথ্য একত্রিত করতে পারে এবং আপনাকে সতর্ক করতে পারে, যেমন, যখন কোনো নির্দিষ্ট হোস্টে OOM ইভেন্ট জমা হতে থাকে, যা সাধারণত ত্রুটিপূর্ণ প্রসেস বা রিসোর্সের অভাব নির্দেশ করে।

সিস্টেম কনফিগারেশন স্তরে, লিনাক্স বিভিন্ন ব্যবস্থা প্রদান করে এমন একটি প্রক্রিয়ার প্রভাব সীমিত করুন যা “নিয়ন্ত্রণের বাইরে চলে যাচ্ছে”। উদাহরণস্বরূপ, সাথে ulimit আপনি কোনো নির্দিষ্ট ব্যবহারকারীর দ্বারা চালু করা প্রসেসগুলোর ওপর মেমরি সীমাবদ্ধতা আরোপ করতে পারেন, যার মাধ্যমে তাদের ভার্চুয়াল মেমরির আকার সীমিত করা যায়। যেমন— ulimit -v <kilobytes> এর ফলে কোনো একটি সার্ভিস হোস্টের সমস্ত র‍্যাম ব্যবহার করতে পারবে না।

আরও উন্নত পরিস্থিতিগুলির জন্য, সিগ্রুপ (নিয়ন্ত্রণ গোষ্ঠী) এগুলো আপনাকে প্রসেসের গ্রুপ অনুযায়ী রিসোর্সের (সিপিইউ, মেমরি, আই/ও, ইত্যাদি) ব্যবহার আলাদা করতে এবং সীমিত করতে সাহায্য করে। আপনি একটি নির্দিষ্ট মেমরি সীমা সহ একটি সি-গ্রুপ তৈরি করতে পারেন এবং এতে একটি সার্ভিস যুক্ত করতে পারেন, যাতে মেমরি লিক হলেও ক্ষতির পরিমাণ সীমিত থাকে। সেই গোষ্ঠীর মধ্যে আবদ্ধ এবং পুরো সিস্টেমকে প্রভাবিত করবে না।

অবশেষে, উন্নয়নের দিক থেকে, সর্বোত্তম প্রতিরক্ষা হলো শুরু থেকেই এমন কোড লিখুন যা মেমরি ভালোভাবে পরিচালনা করে।C/C++ এ, এর অর্থ হলো প্রতিটি বিষয়ে কঠোর হওয়া। malloc/new এবং এটি সম্পর্কিত free/deleteRAII প্যাটার্ন, স্মার্ট পয়েন্টার (যেমন std::shared_ptr, std::unique_ptrএবং অপ্রয়োজনীয় তথ্যসূত্র রাখা পরিহার করুন। আপনি একজনের সাথেও পরামর্শ করতে পারেন। রাস্ট টিউটোরিয়াল মেমরি-সেফ বিকল্পের জন্য। গার্বেজ কালেক্টরযুক্ত ভাষাগুলিতে (যেমন জাভা, সি#, গো, পাইথন, জাভাস্ক্রিপ্ট ইত্যাদি) অপ্রয়োজনীয় অবজেক্টের লাইভ রেফারেন্স রেখে দিলে সহজেই সিউডো-লিক হতে পারে।

সরঞ্জাম cppcheck, SonarQube-এর মতো স্ট্যাটিক বিশ্লেষণ এই টুল এবং পদ্ধতিগুলো ডেভেলপমেন্টের সময় সন্দেহজনক কোড প্যাটার্ন শনাক্ত করতে সাহায্য করে। এর সাথে সতর্ক কোড রিভিউ, লোডের অধীনে আচরণ যাচাইকারী ইউনিট টেস্ট এবং CI এনভায়রনমেন্টে নিয়মিত Valgrind বা অন্যান্য প্রোফাইলার চালানোর ফলে, কোনো গুরুতর দুর্বলতা প্রোডাকশনে পৌঁছানোর সম্ভাবনা অনেকাংশে কমে যায়।

পরিশেষে, লিনাক্সে মেমরি লিক নিয়ন্ত্রণে রাখার জন্য সমন্বয় প্রয়োজন। নিরবচ্ছিন্ন পর্যবেক্ষণ, শক্তিশালী ডায়াগনস্টিক টুল এবং ভালো প্রোগ্রামিং অনুশীলনtop, htop, /proc, pmap, এবং smem ব্যবহার করে আপনি সন্দেহজনক প্রসেসগুলো সনাক্ত করতে পারেন; memleax এবং gdb দিয়ে আপনি লাইভ পরিদর্শন করতে পারেন; Valgrind, gperftools, বা Massif দিয়ে আপনি পুঙ্খানুপুঙ্খভাবে ডিবাগ এবং প্রোফাইল করতে পারেন; এবং লোড টেস্টিং, সিস্টেম লিমিট ও সুগঠিত কোডের মাধ্যমে আপনি সবচেয়ে খারাপ মুহূর্তে সমস্যাটির ভয়াবহ রূপ নেওয়া প্রতিরোধ করতে পারেন।