কোর্স ছাত্রদের জন্য প্রস্তুত নিবন্ধের অনুবাদ "লিনাক্স প্রশাসক".

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

পার্ট 1: লিনাক্সে বিশাল পৃষ্ঠাগুলি সক্ষম করা হয়েছে তা যাচাই করা (মূল এখানে)

সমস্যা:
আপনার সিস্টেমে HugePages সক্ষম করা আছে কিনা তা আপনাকে পরীক্ষা করতে হবে।

সমাধান:
এটা বেশ সহজ:

cat /sys/kernel/mm/transparent_hugepage/enabled

আপনি এই মত কিছু পাবেন:

always [madvise] never

আপনি উপলব্ধ বিকল্পগুলির একটি তালিকা দেখতে পাবেন (সর্বদা, পাগলামী, কখনই না), এবং বর্তমানে সক্রিয় বিকল্পটি বন্ধনীতে আবদ্ধ থাকবে (ডিফল্টরূপে পাগল করা).

পাগল করা মানে হল transparent hugepages শুধুমাত্র মেমরি ক্ষেত্রগুলির জন্য সক্রিয় করা হয়েছে যা স্পষ্টভাবে বিশাল পৃষ্ঠাগুলি ব্যবহার করে অনুরোধ করে পাগল করা (2).

সর্বদা মানে হল transparent hugepages সবসময় সব প্রক্রিয়ার জন্য সক্রিয়. এটি সাধারণত কর্মক্ষমতা উন্নত করে, কিন্তু আপনার যদি এমন একটি ব্যবহারের ক্ষেত্রে থাকে যেখানে অনেক প্রক্রিয়া অল্প পরিমাণে মেমরি গ্রাস করছে, তাহলে সামগ্রিক মেমরির লোড নাটকীয়ভাবে বৃদ্ধি পেতে পারে।

না মানে হল transparent hugepages madvise ব্যবহার করে অনুরোধ করা হলেও অন্তর্ভুক্ত করা হবে না। আরো জানতে, যোগাযোগ করুন ডকুমেন্টেশন লিনাক্স কার্নেল।

ডিফল্ট মান পরিবর্তন কিভাবে

অপশন 1: সরাসরি পরিবর্তন sysfs (রিবুট করার পরে প্যারামিটারটি তার ডিফল্ট মানতে ফিরে আসবে):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

অপশন 2: একটি পরিবর্তিত কনফিগারেশনের সাথে কার্নেল পুনরায় কম্পাইল করে সিস্টেমের ডিফল্ট পরিবর্তন করুন (আপনি একটি কাস্টম কার্নেল ব্যবহার করলেই এই বিকল্পটি সুপারিশ করা হয়):

• সর্বদা ডিফল্টরূপে সেট করতে, ব্যবহার করুন:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

• ডিফল্ট হিসাবে madvise সেট করতে, ব্যবহার করুন:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

পার্ট 2: বিশাল পেজের সুবিধা এবং অসুবিধা

আমরা Hugepages ব্যবহার করার সুবিধা, অসুবিধা এবং সম্ভাব্য ক্ষতিগুলি বেছে বেছে ব্যাখ্যা করার চেষ্টা করব। যেহেতু একটি প্রযুক্তিগতভাবে জটিল এবং শিক্ষামূলক নিবন্ধটি সম্ভবত এমন লোকেদের জন্য বোঝা কঠিন হবে যারা বিশাল পাতাগুলিকে একটি প্রতিষেধক ভেবে বিভ্রান্ত হয়েছেন, তাই আমি সরলতার জন্য নির্ভুলতা ত্যাগ করব। এটা মনে রাখা মূল্যবান যে অনেক বিষয় সত্যিই জটিল এবং তাই ব্যাপকভাবে সরলীকৃত।

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

আমি নীচের লিঙ্কগুলিতে আরও প্রযুক্তিগত বিবরণ সংযুক্ত করব।

ভার্চুয়াল স্মৃতি

আপনি যদি একজন C++ প্রোগ্রামার হন, আপনি জানেন যে মেমরিতে থাকা বস্তুর নির্দিষ্ট ঠিকানা (পয়েন্টার মান) আছে।

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

এই পদ্ধতির অনেক সুবিধা আছে, কিন্তু সবচেয়ে গুরুত্বপূর্ণ হল:

• কর্মক্ষমতা (বিভিন্ন কারণে);
• প্রোগ্রাম আইসোলেশন, অর্থাৎ কোন প্রোগ্রাম অন্য প্রোগ্রামের মেমরি থেকে পড়তে পারে না।

পেজ কি?

ভার্চুয়াল মেমরি পৃষ্ঠাগুলিতে বিভক্ত। প্রতিটি পৃথক পৃষ্ঠা একটি নির্দিষ্ট শারীরিক মেমরির দিকে নির্দেশ করে, এটি RAM-তে একটি এলাকা নির্দেশ করতে পারে, বা এটি একটি ভিডিও কার্ডের মতো একটি শারীরিক ডিভাইসে নির্ধারিত ঠিকানা নির্দেশ করতে পারে।

আপনি যে পৃষ্ঠাগুলির সাথে মোকাবিলা করেন তার বেশিরভাগই হয় RAM-এর দিকে নির্দেশ করে বা অদলবদল করা হয়, মানে সেগুলি আপনার হার্ড ড্রাইভ বা SSD-এ সংরক্ষিত থাকে৷ কার্নেল প্রতিটি পৃষ্ঠার শারীরিক বিন্যাস পরিচালনা করে। যদি একটি স্পুফড পৃষ্ঠা অ্যাক্সেস করা হয়, কার্নেল সেই থ্রেডটিকে থামিয়ে দেয় যা মেমরি অ্যাক্সেস করার চেষ্টা করছে, হার্ড ড্রাইভ/এসএসডি থেকে র‌্যামে পৃষ্ঠাটি পড়ে এবং তারপর থ্রেড চালানো চালিয়ে যায়।

এই প্রক্রিয়াটি স্বচ্ছ স্ট্রীম, যার মানে এটি HDD/SSD থেকে সরাসরি পড়তে হয় না। সাধারণ পৃষ্ঠাগুলির আকার 4096 বাইট। বিশাল পৃষ্ঠাগুলির আকার 2 মেগাবাইট।

অনুবাদ-সহযোগী বাফার (TLB)

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

কার্নেলের একটি ডাটা স্ট্রাকচার (পৃষ্ঠা টেবিল) রয়েছে যাতে ব্যবহৃত পৃষ্ঠাগুলির সমস্ত তথ্য থাকে। এই ডেটা স্ট্রাকচার ব্যবহার করে, আপনি একটি ভার্চুয়াল ঠিকানাকে একটি প্রকৃত ঠিকানায় ম্যাপ করতে পারেন।

যাইহোক, পৃষ্ঠা টেবিলটি বেশ জটিল এবং ধীরগতির, তাই আমরা যখনই কোনও প্রক্রিয়া মেমরি অ্যাক্সেস করে তখন সম্পূর্ণ ডেটা কাঠামো বিশ্লেষণ করতে পারি না।

সৌভাগ্যবশত, আমাদের প্রসেসরের একটি TLB রয়েছে যা ভার্চুয়াল এবং শারীরিক ঠিকানাগুলির মধ্যে ম্যাপিং ক্যাশ করে। এর মানে হল যে যদিও প্রথম অ্যাক্সেসের প্রচেষ্টায় আমাদের পৃষ্ঠা টেবিলটি পার্স করতে হবে, পৃষ্ঠায় পরবর্তী সমস্ত অ্যাক্সেসগুলি দ্রুত অপারেশনের অনুমতি দিয়ে TLB-তে পরিচালনা করা যেতে পারে।

কারণ এটি একটি ভৌত ​​যন্ত্র হিসাবে প্রয়োগ করা হয় (যা এটিকে প্রথম স্থানে দ্রুত করে তোলে), এর ক্ষমতা সীমিত। তাই আপনি যদি আরও পৃষ্ঠাগুলি অ্যাক্সেস করতে চান, TLB তাদের সকলের জন্য ম্যাপিং সংরক্ষণ করতে সক্ষম হবে না, যার ফলে আপনার প্রোগ্রামটি অনেক ধীর গতিতে চলে।

বিশাল পাতাগুলি উদ্ধার করতে আসে

তাই TLB ওভারফ্লো এড়াতে আমরা কি করতে পারি? (আমরা অনুমান করি যে প্রোগ্রামটির এখনও একই পরিমাণ মেমরির প্রয়োজন)।

এখানেই বিশাল পেজ আসে। 4096 বাইটের পরিবর্তে শুধুমাত্র একটি TLB এন্ট্রি প্রয়োজন, একটি TLB এন্ট্রি এখন 2 মেগাবাইটকে নির্দেশ করতে পারে। ধরা যাক TLB-তে 512টি এন্ট্রি রয়েছে, এখানে বিশাল পৃষ্ঠাগুলি ছাড়াই আমরা মেলাতে পারি:

4096 b⋅512=2 MB

তাহলে আমরা কিভাবে তাদের সাথে তুলনা করতে পারি:

2 MB⋅512=1 GB

এই কারণেই বিশাল পাতাগুলি দুর্দান্ত। তারা অনেক প্রচেষ্টা ছাড়াই উত্পাদনশীলতা উন্নত করতে পারে। কিন্তু এখানে উল্লেখযোগ্য সতর্কতা আছে।

বিশাল পাতা স্পুফিং

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

ধরা যাক আমাদের এইরকম একটি প্রোগ্রাম আছে:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

এই ক্ষেত্রে, একটি বাইট পড়ার জন্য কার্নেলটিকে হার্ড ড্রাইভ/এসএসডি থেকে 2 মেগাবাইটের মতো তথ্য প্রতিস্থাপন (পড়তে) করতে হবে। নিয়মিত পৃষ্ঠাগুলির জন্য, হার্ড ড্রাইভ/এসএসডি থেকে শুধুমাত্র 4096 বাইট পড়তে হবে।

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

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

স্মৃতিতে বরাদ্দ

আপনি যদি C লেখেন, আপনি জানেন যে আপনি স্তূপ থেকে যথেচ্ছভাবে ছোট (বা প্রায় ইচ্ছাকৃতভাবে বড়) পরিমাণ মেমরির অনুরোধ করতে পারেন malloc(). ধরা যাক আপনার 30 বাইট মেমরির প্রয়োজন:

char* mymemory = malloc(30);

একজন প্রোগ্রামারের কাছে, এটা মনে হতে পারে যে আপনি অপারেটিং সিস্টেম থেকে 30 বাইট মেমরির "অনুরোধ" করছেন এবং কিছু ভার্চুয়াল মেমরিতে একটি পয়েন্টার ফিরিয়ে দিচ্ছেন। কিন্তু আসলে malloc () শুধুমাত্র একটি সি ফাংশন যা ফাংশনের মধ্যে থেকে কল করে brk এবং sbrk অনুরোধ করতে বা অপারেটিং সিস্টেম থেকে মেমরি বিনামূল্যে.

যাইহোক, প্রতিটি বরাদ্দের জন্য আরও বেশি মেমরির অনুরোধ করা অদক্ষ; সম্ভবত কিছু মেমরি সেগমেন্ট ইতিমধ্যেই মুক্ত করা হয়েছে (free()), এবং আমরা এটি পুনরায় ব্যবহার করতে পারি। malloc() মুক্ত মেমরি পুনরায় ব্যবহার করার জন্য বেশ জটিল অ্যালগরিদম প্রয়োগ করে।

একই সময়ে, আপনার জন্য সবকিছু অলক্ষিত হয়, তাহলে কেন এটি আপনাকে উদ্বিগ্ন করবে? কিন্তু চ্যালেঞ্জের কারণে free() এর মানে এই নয় মেমরি অগত্যা অবিলম্বে অপারেটিং সিস্টেমে ফিরে আসে.

মেমরি ফ্র্যাগমেন্টেশন হিসাবে যেমন একটি জিনিস আছে. চরম ক্ষেত্রে, সেখানে স্তূপ সেগমেন্ট রয়েছে যেখানে শুধুমাত্র কয়েকটি বাইট ব্যবহার করা হয়, যখন এর মধ্যে সবকিছু মুক্ত করা হয়েছে (free()).

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

বিশাল পৃষ্ঠাগুলির নির্বাচনী ব্যবহার

এই নিবন্ধটি পড়ার পরে, আপনি নির্ধারণ করেছেন যে আপনার প্রোগ্রামের কোন অংশগুলি বিশাল পৃষ্ঠাগুলি ব্যবহার করে উপকৃত হতে পারে এবং কোনটি করতে পারে না৷ তাই বিশাল পৃষ্ঠাগুলি আদৌ সক্রিয় করা উচিত?

ভাগ্যক্রমে আপনি ব্যবহার করতে পারেন madvise()শুধুমাত্র মেমরির সেই জায়গাগুলির জন্য বিশাল পেজিং সক্ষম করতে যেখানে এটি দরকারী হবে।

প্রথমে দেখুন বিশাল পেজগুলি madvise() মোডে চলছে কিনা নির্দেশাবলী নিবন্ধের শুরুতে।

তারপর, ব্যবহার করুন madvise()কার্নেলকে ঠিক কোথায় বিশাল পেজ ব্যবহার করতে হবে তা জানাতে।

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

মনে রাখবেন যে এই পদ্ধতিটি শুধুমাত্র কার্নেলকে কীভাবে মেমরি পরিচালনা করতে হয় তার পরামর্শ। এর মানে এই নয় যে কার্নেল একটি প্রদত্ত মেমরির জন্য স্বয়ংক্রিয়ভাবে বিশাল পৃষ্ঠাগুলি ব্যবহার করবে।

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

কি পড়তে হবে?

• বিশাল পৃষ্ঠাগুলিতে আইবিএম ওপেনস্ট্যাক নিবন্ধ
• স্বচ্ছ বিশাল পেজ বনাম অ-স্বচ্ছ বিশাল পেজ
• TLB সম্পর্কে উইকিপিডিয়া নিবন্ধ
• স্বচ্ছ বিশাল পৃষ্ঠাগুলিতে লিনাক্স কার্নেল ডকুমেন্টেশন
• স্ট্যাকওভারফ্লো: বিশাল পৃষ্ঠাগুলি মেমরি ফ্র্যাগমেন্টেশনের প্রবণ
• ভার্চুয়াল মেমরি পরিচালনার উপর মাইক্রোসফ্ট নিবন্ধ

একটি প্রশ্ন আছে? মন্তব্যে লিখুন!

উত্স: www.habr.com