GlusterFS এর জন্য লিনাক্স কার্নেল সেট আপ করা হচ্ছে

নিবন্ধটির অনুবাদ কোর্স শুরুর প্রাক্কালে প্রস্তুত করা হয়েছিল অ্যাডমিনিস্ট্রেটর লিনাক্স। পেশাদার».

পর্যায়ক্রমে, এখানে এবং সেখানে, কার্নেল টিউনিং সম্পর্কিত Gluster-এর সুপারিশ এবং এর জন্য প্রয়োজন আছে কিনা সে সম্পর্কে প্রশ্ন ওঠে।

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

বেশিরভাগ ক্ষেত্রে, এটি সূক্ষ্ম কাজ করে, তবে ভারী লোডের অধীনে এটি সমস্যার কারণ হতে পারে।

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

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

যখন এটি মেমরি টিউনিংয়ের ক্ষেত্রে আসে, প্রথমে যে জিনিসটি দেখতে হবে তা হল ভার্চুয়াল মেমরি সাবসিস্টেম (ভিএম, ভার্চুয়াল মেমরি), যেখানে প্রচুর সংখ্যক বিকল্প রয়েছে যা আপনাকে বিভ্রান্ত করতে পারে।

vm.swappiness

স্থিতিমাপ vm.swappiness RAM এর তুলনায় কার্নেল কতটা সোয়াপ (swap, পেজিং) ব্যবহার করে তা নির্ধারণ করে। এটিকে সোর্স কোডে "ম্যাপ করা মেমরি চুরি করার প্রবণতা" হিসাবেও সংজ্ঞায়িত করা হয়েছে। একটি উচ্চ অদলবদল মানে কার্নেল ম্যাপ করা পৃষ্ঠাগুলি অদলবদল করার জন্য আরও বেশি ঝুঁকবে। একটি কম swappiness মান বিপরীত মানে: কার্নেল মেমরি থেকে কম পৃষ্ঠা হবে. অন্য কথায়, মান তত বেশি vm.swappiness, সিস্টেম যত বেশি সোয়াপ ব্যবহার করবে।

অদলবদল করার একটি বড় ব্যবহার অবাঞ্ছিত, যেহেতু ডেটার বিশাল ব্লকগুলি র‌্যামে লোড এবং আনলোড করা হয়। অনেক লোক যুক্তি দেয় যে অদলবদল মান বড় হওয়া উচিত, কিন্তু আমার অভিজ্ঞতায়, এটি "0" তে সেট করা আরও ভাল পারফরম্যান্সের দিকে পরিচালিত করে।

আপনি এখানে আরও পড়তে পারেন - lwn.net/Articles/100978

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

vm.vfs_cache_pressure

এই সেটিং ক্যাশিং ডিরেক্টরি এবং ইনোড অবজেক্টের (ডেন্ট্রি এবং ইনোড) জন্য কার্নেল দ্বারা গ্রাস করা মেমরি নিয়ন্ত্রণ করে।

100 এর ডিফল্ট মান সহ, কার্নেল পেজক্যাশে এবং সোয়াপক্যাশে "ন্যায্য" ভিত্তিতে ডেন্ট্রি এবং ইনোড ক্যাশে মুক্ত করার চেষ্টা করবে। vfs_cache_pressure হ্রাস করার ফলে কার্নেল ডেন্ট্রি এবং ইনোড ক্যাশে রাখতে পারে। যখন মান "0" হয়, তখন কার্নেল কখনই মেমরির চাপের কারণে ডেন্ট্রি এবং ইনোড ক্যাশে ফ্লাশ করবে না এবং এটি সহজেই মেমরির বাইরের ত্রুটির দিকে নিয়ে যেতে পারে। 100-এর উপরে vfs_cache_pressure বাড়ানোর ফলে কার্নেল ডেন্ট্রি এবং ইনোড ফ্লাশিংকে অগ্রাধিকার দেয়।

GlusterFS ব্যবহার করার সময়, প্রচুর পরিমাণে ডেটা এবং অনেক ছোট ফাইল সহ অনেক ব্যবহারকারী সহজেই ইনোড/ডেন্ট্রি ক্যাশিংয়ের কারণে সার্ভারে উল্লেখযোগ্য পরিমাণে RAM ব্যবহার করতে পারে, যা কার্যক্ষমতার অবনতি ঘটাতে পারে কারণ কার্নেলকে একটি সিস্টেমে ডেটা স্ট্রাকচার প্রক্রিয়া করতে হয়। 40 জিবি মেমরি সহ। এই মানটি 100-এর উপরে সেট করা অনেক ব্যবহারকারীকে ন্যায্য ক্যাশিং এবং উন্নত কার্নেল প্রতিক্রিয়াশীলতা অর্জনে সহায়তা করেছে।

vm.dirty_background_ratio এবং vm.dirty_ratio

প্রথম প্যারামিটার (vm.dirty_background_ratio) নোংরা পৃষ্ঠাগুলির সাথে মেমরির শতাংশ নির্ধারণ করে, যেখানে পৌঁছানোর পরে পটভূমিতে নোংরা পৃষ্ঠাগুলি ডিস্কে ফ্লাশ করা শুরু করা প্রয়োজন৷ এই শতাংশে পৌঁছানো পর্যন্ত, কোনও পৃষ্ঠা ডিস্কে ফ্লাশ করা হয় না। এবং যখন রিসেট শুরু হয়, এটি চলমান প্রক্রিয়াগুলিকে বাধা না দিয়ে পটভূমিতে চলে।

দ্বিতীয় প্যারামিটার (vm.dirty_ratio) জোরপূর্বক ফ্ল্যাশ শুরু হওয়ার আগে নোংরা পৃষ্ঠাগুলি দ্বারা দখল করা যায় এমন মেমরির শতাংশ নির্ধারণ করে। একবার এই থ্রেশহোল্ডে পৌঁছে গেলে, সমস্ত প্রক্রিয়া সিঙ্ক্রোনাস (অবরুদ্ধ) হয়ে যায় এবং তাদের অনুরোধ করা I/O আসলে সম্পূর্ণ না হওয়া পর্যন্ত এবং ডেটা ডিস্কে না থাকা পর্যন্ত চালিয়ে যাওয়ার অনুমতি দেওয়া হয় না। ভারী I/O এর সাথে, এটি একটি সমস্যা সৃষ্টি করে কারণ কোন ডেটা ক্যাশিং নেই এবং I/O করার সমস্ত প্রক্রিয়া I/O-এর জন্য অপেক্ষা করা অবরুদ্ধ। এটি প্রচুর সংখ্যক হ্যাং প্রসেস, উচ্চ লোড, সিস্টেমের অস্থিরতা এবং দুর্বল কর্মক্ষমতার দিকে পরিচালিত করে।

এই সেটিংস হ্রাস করার ফলে ডেটা আরও ঘন ঘন ডিস্কে ফ্লাশ করা হয় এবং RAM এ সংরক্ষণ করা হয় না। এটি মেমরি-ভারী সিস্টেমগুলিকে সাহায্য করতে পারে যেখানে 45-90 GB পৃষ্ঠার ক্যাশে ডিস্কে ফ্লাশ করা স্বাভাবিক, যার ফলে ফ্রন্ট-এন্ড অ্যাপ্লিকেশনগুলির জন্য বিশাল লেটেন্সি, সামগ্রিক প্রতিক্রিয়াশীলতা এবং ইন্টারঅ্যাক্টিভিটি হ্রাস পায়।

"1" > /proc/sys/vm/pagecache

একটি পৃষ্ঠা ক্যাশে এমন একটি ক্যাশে যা ফাইল এবং এক্সিকিউটেবল প্রোগ্রামগুলির ডেটা সঞ্চয় করে, অর্থাৎ, এগুলি ফাইল বা ব্লক ডিভাইসের প্রকৃত বিষয়বস্তু সহ পৃষ্ঠা। এই ক্যাশে ডিস্ক পড়ার সংখ্যা কমাতে ব্যবহার করা হয়। "1" এর মান মানে হল ক্যাশের জন্য RAM এর 1% ব্যবহার করা হয় এবং RAM থেকে ডিস্ক থেকে বেশি রিড হবে। এই সেটিংটি পরিবর্তন করার প্রয়োজন নেই, তবে আপনি যদি পৃষ্ঠার ক্যাশে নিয়ন্ত্রণ করার বিষয়ে বিভ্রান্ত হন তবে আপনি এটি ব্যবহার করতে পারেন।

"সময়সীমা" > /sys/block/sdc/queue/scheduler

I/O শিডিউলার হল একটি লিনাক্স কার্নেল উপাদান যা পঠন ও লেখার সারিগুলি পরিচালনা করে। তাত্ত্বিকভাবে, একটি স্মার্ট RAID কন্ট্রোলারের জন্য "noop" ব্যবহার করা ভাল, কারণ Linux ডিস্কের ভৌত জ্যামিতি সম্পর্কে কিছুই জানে না, তাই ডিস্কের জ্যামিতি ভালোভাবে জানে এমন নিয়ামককে যত তাড়াতাড়ি অনুরোধ প্রক্রিয়াকরণ করতে দেওয়া আরও কার্যকর। সম্ভব. কিন্তু দেখে মনে হচ্ছে "সময়সীমা" কর্মক্ষমতা উন্নত করে। আপনি লিনাক্স কার্নেল সোর্স কোড ডকুমেন্টেশনে শিডিউলার সম্পর্কে আরও পড়তে পারেন: linux/Documentation/block/*osched.txt. এবং আমি মিশ্র অপারেশনের সময় রিড থ্রুপুট বৃদ্ধি দেখেছি (অনেক লিখেছেন)।

"256" > /sys/block/sdc/queue/nr_requests

শিডিউলারের কাছে পাঠানোর আগে বাফারে I/O অনুরোধের সংখ্যা। কিছু কন্ট্রোলারের অভ্যন্তরীণ সারির আকার (সারির_গভীরতা) I/O শিডিউলারের nr_requests থেকে বড়, তাই I/O শিডিউলারের সঠিকভাবে অগ্রাধিকার দেওয়ার এবং একত্রিত করার অনুরোধের সম্ভাবনা কম। সময়সীমা এবং CFQ শিডিউলারের জন্য, যখন nr_requests কন্ট্রোলারের অভ্যন্তরীণ সারির 2 গুণ হয় তখন এটি আরও ভাল। অনুরোধগুলিকে একত্রিত করা এবং পুনর্বিন্যাস করা শিডিউলারকে ভারী বোঝার মধ্যে আরও প্রতিক্রিয়াশীল হতে সাহায্য করে।

echo "16" > /proc/sys/vm/page-cluster

পৃষ্ঠা-ক্লাস্টার প্যারামিটার এক সময়ে অদলবদলে লেখা পৃষ্ঠার সংখ্যা নিয়ন্ত্রণ করে। উপরের উদাহরণে, RAID স্ট্রাইপের আকার 16 KB অনুযায়ী মান "64" এ সেট করা হয়েছে। swappiness = 0 এর সাথে এর কোন মানে হয় না, কিন্তু আপনি যদি 10 বা 20 তে swappiness সেট করেন তাহলে RAID স্ট্রাইপের আকার 64K হলে এই মানটি ব্যবহার করা আপনাকে সাহায্য করবে।

ব্লকডেভ --সেট্রা 4096 /dev/<devname> (-sdb, hdc বা dev_mapper)

অনেক RAID কন্ট্রোলারের জন্য ডিফল্ট ব্লক ডিভাইস সেটিংস প্রায়ই ভয়ানক কর্মক্ষমতার কারণ হয়। উপরের বিকল্পটি যুক্ত করা 4096 * 512-বাইট সেক্টরের জন্য রিড-এ্যাড সেট আপ করে। অন্ততপক্ষে, স্ট্রিমিং ক্রিয়াকলাপের জন্য, I/O প্রস্তুত করতে কার্নেল দ্বারা ব্যবহৃত সময়ের মধ্যে অন-চিপ ডিস্ক ক্যাশে রিড-এ্যাড দিয়ে পূরণ করে গতি বাড়ানো হয়। ক্যাশে ডেটা থাকতে পারে যা পরবর্তী পড়ার জন্য অনুরোধ করা হবে। অত্যধিক প্রিফেচ বড় ফাইলের জন্য এলোমেলো I/O কে মেরে ফেলতে পারে যদি এটি সম্ভাব্য দরকারী ডিস্ক সময় ব্যবহার করে বা ক্যাশের বাইরে ডেটা লোড করে।

নীচে ফাইল সিস্টেম স্তরে আরও কয়েকটি সুপারিশ রয়েছে৷ কিন্তু তাদের এখনও পরীক্ষা করা হয়নি। নিশ্চিত করুন যে আপনার ফাইল সিস্টেম স্ট্রাইপের আকার এবং অ্যারের ডিস্কের সংখ্যা জানে। উদাহরণস্বরূপ, এটি ছয়টি ডিস্কের একটি 5K স্ট্রাইপ raid64 অ্যারে (আসলে পাঁচটি, কারণ একটি ডিস্ক সমতার জন্য ব্যবহৃত হয়)। এই সুপারিশগুলি তাত্ত্বিক অনুমানের উপর ভিত্তি করে এবং RAID বিশেষজ্ঞদের দ্বারা বিভিন্ন ব্লগ/নিবন্ধ থেকে সংকলিত।

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

বড় ফাইলগুলির জন্য, উপরে তালিকাভুক্ত স্ট্রাইপের আকার বাড়ানো বিবেচনা করুন।

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

অতিরিক্ত উপকরণ:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

আরও পড়ুন

• Red Hat Enterprise Linux 8-এ nftables ব্যবহার করা হচ্ছে

উত্স: www.habr.com