লিনাক্স কার্নেল অপ্টিমাইজ করার এবং ল্যাটেন্সি কমানোর জন্য উন্নত নির্দেশিকা

ইনফরমেটেক ডিজিটাল » রিসোর্স » লিনাক্স কার্নেল অপ্টিমাইজ করা এবং ল্যাটেন্সি কমানোর উন্নত নির্দেশিকা

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

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

লিনাক্স কার্নেল আর্কিটেকচার এবং ল্যাটেন্সির মূল বিষয়গুলি

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

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

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

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

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

লেটেন্সি এবং কর্মক্ষমতা উন্নত করতে sysctl এর মাধ্যমে সমন্বয়

sysctl ইন্টারফেস আপনাকে পুনরায় কম্পাইল না করেই /proc/sys এর মাধ্যমে তাৎক্ষণিকভাবে কার্নেল প্যারামিটার পরিবর্তন করার সুযোগ দেয় । কম্পাইলেশনের জটিলতায় না জড়িয়ে টিউনিং করার জন্য এটি একটি আদর্শ সূচনা বিন্দু।

নেটওয়ার্ক পরিবেশে, net.core.rmem_max, net.core.wmem_max, এবং net.ipv4.tcp_congestion_control- এর মতো প্যারামিটারগুলো থ্রুপুট, ল্যাটেন্সি এবং TCP কানেকশনের আচরণকে সরাসরি প্রভাবিত করে। উচ্চ-ট্র্যাফিকের ওয়েব সার্ভার বা কম-ল্যাটেন্সির ক্লাউড ইনস্ট্যান্সের জন্য বাফার এবং কনজেশন অ্যালগরিদম সঠিকভাবে সমন্বয় করা অত্যন্ত জরুরি।

মেমোরির জন্য, vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure, এবং vm.overcommit_memory-এর মতো ভ্যালুগুলো আপনাকে নিয়ন্ত্রণ করতে দেয় যে কী পরিমাণ সোয়াপ ব্যবহৃত হবে, পেজ ক্যাশে কীভাবে পরিচালিত হবে, এবং ভার্চুয়াল মেমোরির আচরণ কেমন হবে। সোয়াপিনেস কমালে (উদাহরণস্বরূপ, ১০-এ) সাধারণত সিস্টেমকে খুব ঘন ঘন সোয়াপ ব্যবহার করা থেকে বিরত রাখা যায়, যা ডিস্ক I/O-এর কারণে সৃষ্ট ল্যাটেন্সি স্পাইক কমিয়ে দেয়।

আপনি যদি বড় ডেটাবেস বা এমন অ্যাপ্লিকেশন নিয়ে কাজ করেন যা প্রচুর পরিমাণে শেয়ার্ড মেমরি ব্যবহার করে, তাহলে kernel.shmmax, kernel.shmall এবং fs.file-max ও fs.nr_open ব্যবহার করে খোলা ফাইলের সর্বোচ্চ সংখ্যা সমন্বয় করা অত্যন্ত গুরুত্বপূর্ণ । অনুপযুক্তভাবে নির্ধারিত সীমাগুলো লোডের অধীনে বাধা এবং এমন ত্রুটি সৃষ্টি করতে পারে যা নির্ণয় করা কঠিন।

পরামর্শ দেওয়া হয় যে, ছোট ছোট পরিবর্তন করুন, মনিটরিং টুল দিয়ে সেগুলোর প্রভাব পরিমাপ করুন এবং তারপরেই সেগুলোকে /etc/sysctl.conf বা /etc/sysctl.d/ -এ কমিট করুন । কন্টেইনারাইজড পরিবেশে মনে রাখবেন যে, অনেক কার্নেল প্যারামিটার হোস্টের জন্য গ্লোবাল হয়: অসাবধানতাবশত করা পরিবর্তন সমস্ত সার্ভিসকে প্রভাবিত করতে পারে, তাই sysctl-এর সাথে cgroups এবং namespaces-এর সমন্বয় করা প্রায় বাধ্যতামূলক।

কাস্টম কার্নেল কম্পাইল এবং রক্ষণাবেক্ষণ

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

ক্লাসিক ওয়ার্কফ্লোতে কোড ডাউনলোড করা জড়িত থেকে kernel.org অথবা প্যাচড ট্রি যেমন xanmod অথবা লিকোরিক্সএবং এর মতো সরঞ্জাম ব্যবহার করুন make menuconfig বিকল্পগুলি বেছে নিতে। বিল্ড স্ক্রিপ্টগুলির সাথে আপনার নিজস্ব গিট রিপোজিটরিতে .config ফাইলটি সংরক্ষণ করলে, আপনি বিল্ডগুলি পুনরুত্পাদন করতে এবং সংস্করণগুলির মধ্যে সামঞ্জস্য বজায় রাখতে পারবেন।

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

বাস্তব জগতে, পুরোনো বা খুব সীমিত হার্ডওয়্যার নিয়ে কাজ করার সময় হাতে কম্পাইল করাই প্রায়শই যুক্তিযুক্ত । এর একটি সাধারণ উদাহরণ হলো অ্যাটম সিপিইউ এবং ১ জিবি র‍্যামযুক্ত একটি পুরোনো নেটবুক , যেখানে অপ্রয়োজনীয় ড্রাইভার এবং সার্ভার-গ্রেড অপশনে পরিপূর্ণ একটি আধুনিক জেনেরিক কার্নেল এমন ল্যাটেন্সি ও অতিরিক্ত সিপিইউ ব্যবহার তৈরি করে যা আপনি বহন করতে পারবেন না।

একটি প্রচলিত কৌশল হলো বর্তমান কার্নেল কনফিগারেশন দিয়ে শুরু করা (উদাহরণস্বরূপ, /boot থেকে কনফিগারেশন ফাইলটি কপি করে ) এবং তারপর সেটিকে ছাঁটাই বা সামঞ্জস্য করা। আপনি ডেস্কটপের ইন্টারেক্টিভ প্রতিক্রিয়াকে অগ্রাধিকার দিতে প্রিএম্পশন মডেলটিকে " Preemptible Kernel (Low-Latency Desktop) "-এ পরিবর্তন করতে পারেন, অথবা মেকানিক্যাল ডিস্কের অভিজ্ঞতা উন্নত করতে BFQ-এর মতো নির্দিষ্ট I/O শিডিউলারকে একটি মডিউল হিসেবে যোগ করতে পারেন।

কম্পাইল করতে দীর্ঘ সময় ব্যয় করা এড়াতে, আরও শক্তিশালী মেশিনে বিল্ড করা এবং প্রয়োজনে ক্রস-কম্পাইলিং ব্যবহার করা যুক্তিযুক্ত (উদাহরণস্বরূপ, শুধু ARCH এবং সংশ্লিষ্ট টুলচেইনগুলো সামঞ্জস্য করে একটি x86_64 পিসি থেকে Atom-এর জন্য একটি 32-বিট কার্নেল কম্পাইল করা)। এরপর আপনাকে শুধু টার্গেট মেশিনে .deb ফাইলগুলো ইনস্টল করতে হবে এবং GRUB-এ উপযুক্ত এন্ট্রিটি যোগ করতে হবে।

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

কম-বিলম্বিত সিস্টেমের জন্য প্রিম্পশন মডেল এবং PREEMPT_RT প্যাচ

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

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

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

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

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

সিপিইউ শিডিউলিং টিউনিং, টিকলেস অপারেশন এবং কোর আইসোলেশন

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

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

এই কনফিগারেশনটি উপযুক্ত পরামিতি যোগ করে করা হয় GRUB-তে কার্নেল কমান্ড লাইনকনফিগারেশন পুনঃজেনারেট করা, এবং তারপর গুরুত্বপূর্ণ কার্নেল থ্রেডের অ্যাফিনিটি সামঞ্জস্য করা, যেমন RCU থ্রেড বা থ্রেড bdi-flush, যাতে তারা রক্ষণাবেক্ষণের জন্য সংরক্ষিত কোরে থাকে।

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

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

লেটেন্সির উপর জোর দিয়ে মেমোরি এবং স্টোরেজ ব্যবস্থাপনা

কার্নেল যেভাবে মেমরি এবং ডিস্ক আই/ও পরিচালনা করে, তা অ্যাপ্লিকেশনগুলোর অনুভূত লেটেন্সির উপর ব্যাপক প্রভাব ফেলে , বিশেষ করে ডেটাবেস এবং সেইসব সার্ভিসের ক্ষেত্রে যেগুলো অনেক ছোট ছোট ও ঘন ঘন অপারেশন সম্পাদন করে।

মেমোরির ক্ষেত্রে, vm.swappiness কমালে সোয়াপের ব্যবহার কমে যায় (যা প্রায় সবসময়ই র‍্যামের চেয়ে অনেক ধীরগতির), vm.vfs_cache_pressure নিয়ন্ত্রণ করে সিস্টেমকে কত দ্রুত ইনোড ও ডেন্ট্রি ক্যাশ খালি করতে হবে, এবং vm.nr_hugepages আপনাকে ডেটাবেস বা JVM-এর মতো ভারী কাজের জন্য স্ট্যাটিক HugePages সংরক্ষণ করার সুযোগ দেয়, যা TLB ওভারহেড কমায়।

স্টোরেজে, বেছে নিন ডিস্কের ধরণ অনুসারে উপযুক্ত I/O শিডিউলার এটা খুবই গুরুত্বপূর্ণ। আধুনিক SSD গুলিতে, সাধারণত এটি ব্যবহার করা ভালো... none o mq-deadlineযেখানে মেকানিক্যাল ডিস্ক এবং মাল্টিটাস্কিং সিস্টেমে, ন্যায্যতার জন্য ডিজাইন করা অ্যালগরিদমগুলি আরও ভাল হতে পারে, যেমন বিএফকিউঅতিরিক্তভাবে, ফাইল সিস্টেম মাউন্ট করা যেমন বিকল্প সহ noatime y nodiratime প্রতিবার কোনও ফাইল বা ডিরেক্টরি অ্যাক্সেস করার সময় অপ্রয়োজনীয় লেখা এড়িয়ে চলুন।

ফাইল সিস্টেমের ক্ষেত্রে, ext4 এবং XFS সবচেয়ে প্রচলিত পছন্দ হিসেবে রয়ে গেছে: একটি ভালোভাবে টিউন করা ext4 একটি নিরাপদ বিকল্প, অন্যদিকে উচ্চ কনকারেন্সির অধীনে XFS আরও ভালোভাবে স্কেল করতে পারে। অত্যন্ত চাহিদাপূর্ণ পরিস্থিতির জন্য, একটি ভালো শিডিউলারের সাথে RAID (ডাটাবেসের জন্য RAID 10, অস্থায়ী স্ক্র্যাচ স্টোরেজের জন্য RAID 0) ব্যবহার করলে গড় ল্যাটেন্সি এবং সর্বোপরি, পরিবর্তনশীলতা কমানো সম্ভব।

লিনাক্স এবং EC2-তে কম ল্যাটেন্সির জন্য নেটওয়ার্ক এবং কার্নেল অপ্টিমাইজেশন

উচ্চ-পারফরম্যান্স নেটওয়ার্কিং অ্যাপ্লিকেশনগুলিতে, লেটেন্সি কেবল হার্ডওয়্যার বা দূরত্বের উপরই নির্ভর করে না, বরং TCP/IP স্ট্যাক এবং কার্নেল নিজে কীভাবে কনফিগার করা হয়েছে তার উপরও নির্ভর করে । ENA ইন্টারফেসযুক্ত Amazon EC2-এর মতো ক্লাউড ইনস্ট্যান্সগুলিতে এটি বিশেষভাবে লক্ষণীয়।

প্রথমত, প্যাকেটের নেটওয়ার্ক হপের সংখ্যার মতো বাহ্যিক কারণগুলো কমানো অত্যন্ত গুরুত্বপূর্ণ : আরও সরাসরি টপোলজি, ব্যাকএন্ডের কাছাকাছি লোড ব্যালেন্সার অথবা অপ্টিমাইজড অ্যাভেইলেবিলিটি জোন ব্যবহার করলে অপারেটিং সিস্টেমে পৌঁছানোর আগেই প্যাকেটের ভ্রমণ সময় মিলিসেকেন্ডে কমে আসে।

কার্নেলের মধ্যে নেটওয়ার্ক কনফিগারেশনের জন্য ফাইল ডেসক্রিপ্টর বৃদ্ধি করা (ulimit -n) , net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem ব্যবহার করে রিসিভ ও সেন্ড বাফারের আকার নির্ধারণ করা এবং সংযোগ স্থাপনের বিলম্ব কমাতে TCP Fast Open- এর মতো অপশন সক্রিয় করা প্রয়োজন ।

AWS ENA ইন্টারফেসে, ইন্টারাপ্ট মডারেশন একটি গুরুত্বপূর্ণ ভূমিকা পালন করে: ডিফল্টরূপে, ড্রাইভার IRQ-এর সংখ্যা কমাতে প্যাকেটগুলিকে গ্রুপ করে। rx-usecs এবং tx-usecsআপনি যদি ল্যাটেন্সি সর্বনিম্ন পর্যায়ে কমাতে চান, তাহলে আপনি এই মডারেশনটি অক্ষম করতে পারেন ethtool -Crx-usecs এবং tx-usecs কে শূন্যে সেট করলে ল্যাটেন্সি কমবে কিন্তু ইন্টারাপ্ট ওভারহেড বৃদ্ধি পাবে, তাই লোডের উপর নির্ভর করে একটি ব্যালেন্স খুঁজে বের করতে হবে।

আপনি একাধিক কোরের মধ্যে IRQ বন্টন করতে irqbalance ব্যবহার করতে পারেন , অথবা এটিকে নিষ্ক্রিয় করে নির্দিষ্ট কোরের জন্য ইন্টারাপ্ট এবং নেটওয়ার্ক কিউ (RSS/RPS) অ্যাফিনিটি ম্যানুয়ালি সেট করতে পারেন, যা অতি-স্বল্প লেটেন্সির পরিবেশে অথবা DPDK ব্যবহার করে কার্নেল স্ট্যাকের একটি বড় অংশ এড়িয়ে যাওয়ার ক্ষেত্রে খুবই প্রচলিত।

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

ল্যাটেন্সি কমাতে CPU, পরিষেবা এবং অ্যাপ্লিকেশন অপ্টিমাইজেশন

স্বয়ং কার্নেল ছাড়াও, সামগ্রিক লেটেন্সির ক্ষেত্রে পারিপার্শ্বিক পরিবেশের অনেক প্রভাব থাকে: সিস্টেমে সক্রিয় সার্ভিসগুলো থেকে শুরু করে প্রতিটি অ্যাপ্লিকেশনের নির্দিষ্ট কনফিগারেশন পর্যন্ত।

একটি উচ্চ-কার্যক্ষমতা সম্পন্ন সার্ভার শুধুমাত্র চালানো উচিত যে ভূতগুলো সত্যিই প্রয়োজনীয়ব্যাকএন্ড মেশিনে ব্লুটুথ, প্রিন্টিং, অথবা নেটওয়ার্ক অটো-ডিসকভারি (CUPS, Avahi, ইত্যাদি) এর মতো পরিষেবাগুলি কোনও সুবিধা প্রদান না করে কেবল CPU, মেমরি এবং I/O ব্যবহার করে। পর্যালোচনা করুন systemctl list-unit-files --state=enabled আর অপ্রয়োজনীয় জিনিস বন্ধ করা আপনার করা সবচেয়ে সস্তা এবং কার্যকর কাজগুলির মধ্যে একটি।

গুরুত্বপূর্ণ প্রসেসগুলোকে অগ্রাধিকার দিতে, আপনি renice, chrt, এবং taskset-এর মতো টুল ব্যবহার করতে পারেন । কোনো প্রসেসের অগ্রাধিকার সমন্বয় করা (renice), সেটিকে রিয়েল-টাইম শিডিউলিং দেওয়া (chrt -f 99), অথবা নির্দিষ্ট কোরে বরাদ্দ করা (taskset) অন্যান্য টাস্কের সাথে এর হস্তক্ষেপ কমিয়ে দেয়, যা ডাটাবেস, ভিওআইপি, স্ট্রিমিং বা ট্রেডিং সার্ভিসের জন্য সিপিইউ-এর পূর্বাভাসযোগ্যতা উন্নত করে।

অ্যাপ্লিকেশন পর্যায়ে টিউনিং ঠিক কার্নেল টিউনিংয়ের মতোই গুরুত্বপূর্ণ। Nginx বা Apache-এর মতো ওয়েব সার্ভারগুলোর ওয়ার্কার, কিপঅ্যালাইভ, ক্যাশ এবং কম্প্রেশনের সূক্ষ্ম টিউনিং প্রয়োজন হয়। PostgreSQL বা MySQL-এর মতো ডেটাবেসগুলোতে কম ও স্থিতিশীল ল্যাটেন্সি অর্জনের জন্য বাফার সাইজ, চেকপয়েন্ট, কানেকশন পুল এবং সিনক্রোনাস রাইট প্যারামিটার পর্যালোচনা করা প্রয়োজন।

JVM-এরও একটি ভূমিকা রয়েছে: G1GC বা ZGC-এর মতো গার্বেজ কালেক্টর নির্বাচন এবং হিপ সাইজ সমন্বয় করার মাধ্যমে সেইসব বিরতি কমানো যায়, যা বাইরে থেকে ল্যাটেন্সি হিসেবে প্রতীয়মান হয়। ভার্চুয়ালাইজড এবং কন্টেইনারাইজড পরিবেশে, vCPU, vRAM এবং I/O কোটা সঠিকভাবে বরাদ্দ করলে সাইলেন্ট কনটেনশন প্রতিরোধ করা যায়, যা পরবর্তীতে অন্তহীন ডিস্ক কিউ বা সিপিইউ ওভারলোড হিসেবে প্রকাশ পায়।

কার্নেল এবং সিস্টেম পর্যবেক্ষণ এবং বেঞ্চমার্কিং

এর প্রভাব পরিমাপ না করলে এই সমস্ত সূক্ষ্ম সমন্বয় বৃথা। মূল বিষয় হলো নিরবচ্ছিন্ন পর্যবেক্ষণের সাথে পুনরাবৃত্তিযোগ্য পারফরম্যান্স পরীক্ষার সমন্বয় করা , যাতে কার্নেল বা sysctl-এর প্রতিটি পরিবর্তন বস্তুনিষ্ঠ তথ্য দিয়ে মূল্যায়ন করা যায়।

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

প্রোডাকশন এনভায়রনমেন্টে, প্রোমিথিউস, কালেক্টডি, বা সিসস্ট্যাট-এর মতো মেট্রিক্স সিস্টেমগুলো এমন এক্সপোর্টারসহ স্থাপন করার পরামর্শ দেওয়া হয় , যা সিপিইউ কাউন্টার, আই/ও, ডিস্ক ও নেটওয়ার্ক ল্যাটেন্সি, প্রসেস কিউ ইত্যাদি ডেটা প্রকাশ করে। গ্রাফানা বা অনুরূপ টুলে এই ডেটা ভিজ্যুয়ালাইজ করলে, এন্ড ইউজারের সমস্যা নজরে আসার আগেই রিগ্রেশন বা অসঙ্গতি শনাক্ত করতে সাহায্য করে।

বেঞ্চমার্কিংয়ের মূল উদ্দেশ্য হলো প্রকৃত ওয়ার্কলোডকে হুবহু নকল করা এবং প্রতিটি পরিবর্তনের 'আগের ও পরের' অবস্থা তুলনা করা। sysbench (সিপিইউ এবং ডেটাবেসের জন্য), fio (ডিস্কের জন্য), বা iperf3 (নেটওয়ার্কের জন্য)-এর মতো টুলগুলো আপনাকে পুনরাবৃত্তিযোগ্য সিনারিও তৈরি করতে সাহায্য করে। কার্নেল ভার্সন, sysctl কনফিগারেশন, হার্ডওয়্যার এবং টেস্ট প্যারামিটারগুলো নথিভুক্ত করা অপরিহার্য, যাতে সময়ের সাথে সাথে তুলনাগুলো অর্থবহ হয়।

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

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