পারফরম্যান্স আর observability — top, vmstat, perf আর তদন্তের পদ্ধতি

১ · “সাইট স্লো” — অনুমান নয়, পদ্ধতি

রাত দশটা। ডেভেলপার রিয়ার ফোনে বার্তা: “চেকআউট পাতা খুলতে ১০ সেকেন্ড লাগছে!” এমন মুহূর্তে প্রায় সবাই যা মনে আসে তা-ই বদলান — সার্ভার রিস্টার্ট, cache বাড়ানো, “নিশ্চয়ই নেটওয়ার্কের দোষ।” কখনো সমস্যা চলে যায়, কিন্তু কেন গেল কেউ জানেন না, আর পরের সপ্তাহে সেটি ফিরে আসে।

এই পর্ব আপনাকে একটি অন্য অভ্যাস শেখাবে: পারফরম্যান্সকে তদন্ত হিসেবে দেখা। আর সেই তদন্তের জন্য OS যে জানালাগুলো খুলে রাখে — /proc, /sys, counter, tracepoint — সেগুলো পড়তে শেখা। একটি সিস্টেম বাইরে থেকে কতটা “পড়া যায়”, তার নাম observability.

যে পথে যাবেন না — তিনটি anti-method

পারফরম্যান্স-প্রকৌশলী Brendan Gregg তাঁর লেখা আর বইয়ে কিছু ভুল অভ্যাসের নাম দিয়েছেন — “anti-method”. নাম দেওয়াটা কাজের, কারণ নামওয়ালা ভুল চেনা সহজ।

• Streetlight anti-method: পুরোনো কৌতুক — এক মাতাল রাতে ল্যাম্পপোস্টের নিচে চাবি খুঁজছেন। জিজ্ঞেস করা হলো, চাবি কি এখানেই হারিয়েছে? “না, পার্কে। কিন্তু আলো তো এখানে!” যে টুল আপনি চেনেন (ধরুন শুধু top), শুধু সেটি দিয়ে দেখলে যা সেই টুলে দেখা যায় না — ডিস্কের সারি, নেটওয়ার্কের retransmit — তা কখনো খুঁজে পাবেন না।
• Random change anti-method: একটি সেটিং বদলান, দেখুন ভালো হলো কি না, না হলে আরেকটি। ফল: অনেক সময় নষ্ট, আর কিছু বদল যা আসলে ক্ষতি করছিল, সেগুলোও থেকে যায়, কারণ কেউ ফেরত দেননি।
• Blame-someone-else: “নেটওয়ার্কের দোষ” — প্রমাণ ছাড়াই অন্য দলের দিকে ঠেলে দেওয়া।

যে পথে যাবেন — বৈজ্ঞানিক পদ্ধতি আর baseline

এর বদলে বিজ্ঞানের পরিচিত চক্রটি নিন: প্রশ্ন (কী ধীর, কার জন্য, কবে থেকে?) → অনুমান (hypothesis: “মেমরি কম পড়ায় swap হচ্ছে”) → ভবিষ্যদ্বাণী (“তাহলে vmstat-এ si/so শূন্য নয় হবে”) → পরীক্ষা (মাপুন) → বিশ্লেষণ (মিলল? না মিললে অনুমান বাদ)। একবারে একটিই পরিবর্তন করুন, আর পরিবর্তনের আগে-পরে একই সংখ্যা মাপুন। DBMS কোর্সের performance tuning পর্বে ডেটাবেসের জন্য ঠিক এই চক্রটি দেখেছেন; এখানে একই চিন্তা পুরো OS-এর জন্য।

সবচেয়ে অবহেলিত হাতিয়ার baseline — স্বাভাবিক দিনের সংখ্যা। load average ৬ কি বেশি? ৩২-CPU যন্ত্রে স্বাভাবিক, ২-CPU যন্ত্রে বিপদ। p99 ৩০০ ms খারাপ? গত মাসে সবসময় ২৮০–৩২০ থাকলে না। তাই নিয়মিত সংগ্রহ (sar-এর collector বা Prometheus-এর মতো monitoring) চালু রাখা নিজেই একটি পারফরম্যান্স-কাজ।

২ · USE আর RED — দুটি চেকলিস্ট, দুই দিক থেকে

বৈজ্ঞানিক পদ্ধতি সাধারণ; বাস্তবে শুরু করার জন্য একটি নির্দিষ্ট চেকলিস্ট লাগে। সবচেয়ে পরিচিত দুটি এখানে।

USE method — প্রতিটি সম্পদে তিনটি প্রশ্ন

Brendan Gregg ২০১২ সালের দিকে USE method প্রচার করেন। নিয়মটি ছোট: প্রতিটি সম্পদের জন্য তিনটি প্রশ্ন করুন।

• U — Utilization: সম্পদটি সময়ের কত অংশ ব্যস্ত ছিল? (CPU ৭০% ব্যস্ত, ডিস্ক ৯৫% সময় কাজ করছিল)
• S — Saturation: সম্পদটি যা সামলাতে পারে, তার বাড়তি কাজ কি সারিতে দাঁড়িয়ে আছে? (CPU-র অপেক্ষায় ১২টি thread, ডিস্কের সারিতে ৪০টি অনুরোধ)
• E — Errors: কোনো error ঘটছে কি? (ডিস্কের I/O error, নেটওয়ার্কের প্যাকেট ফেলে দেওয়া, OOM kill)

শক্তিটা “প্রতিটি সম্পদ” কথাটায়: একটি তালিকা ধরে এগোলে (CPU, মেমরি, ডিস্ক, নেটওয়ার্ক, তারপর file descriptor, thread pool, lock) streetlight-এর ফাঁদে পড়েন না। কোথাও খারাপ পেলে সেখানে গভীরে যান; সব ঠিক থাকলে সমস্যা সম্ভবত সফটওয়্যারের ভেতরে (lock, অপেক্ষা, ভুল অ্যালগরিদম)।

RED method আর golden signals — সার্ভিসের দিক থেকে

USE দেখে যন্ত্রের দিক থেকে। কিন্তু ব্যবহারকারী CPU দেখেন না, দেখেন তাঁর অনুরোধের উত্তর। সার্ভিসের দিক থেকে দেখার জন্য Tom Wilkie (Weaveworks-এ থাকাকালে, ২০১৫ সালের দিকে) প্রস্তাব করেন RED method: প্রতিটি সার্ভিসের Rate (সেকেন্ডে কত অনুরোধ), Errors (কতগুলো ব্যর্থ) আর Duration (কত সময় লাগছে, percentile-এ)। Google-এর Site Reliability Engineering বইয়ের (২০১৬) four golden signals — latency, traffic, errors, saturation — প্রায় একই চিন্তা, সাথে saturation যোগ করা।

বাস্তবে দুটি একসাথে চলে: RED বলে কোন সার্ভিস অসুস্থ, USE বলে কোন সম্পদের কারণে। একটি microservice-ব্যবস্থায় RED dashboard দেখে খুঁজে পান কোন সার্ভিসের p99 লাফিয়েছে; তারপর সেই সার্ভিসের যন্ত্রগুলোতে USE চালান।

৩ · মাপের ভাষা — গড়, percentile, histogram আর চারটি জোড়া শব্দ

ভুল সংখ্যা দেখে ঠিক সিদ্ধান্ত নেওয়া যায় না। পারফরম্যান্সের আলাপে চারটি জোড়া শব্দ প্রায়ই গুলিয়ে যায়।

৪ · সারির অঙ্ক — কেন ৯০% ব্যবহারে সিস্টেম হঠাৎ ধীর

পারফরম্যান্সের সবচেয়ে গুরুত্বপূর্ণ অন্তর্দৃষ্টি একটি অঙ্ক থেকে আসে। পর্ব ১৬-এ (CPU scheduling-এর ভিত্তি) Little's law দেখেছেন: L = λ × W — সিস্টেমে গড়ে কতগুলো কাজ (L) = আগমন-হার (λ) × প্রতিটির গড় সময় (W). এটি যেকোনো স্থিতিশীল সারিতে খাটে, বণ্টন যা-ই হোক। কিন্তু এটি বলে না ব্যবহার বাড়লে W কীভাবে বদলায়। তার জন্য একটি queueing model লাগে।

M/M/1 — সবচেয়ে সরল মডেল, সবচেয়ে বড় শিক্ষা

M/M/1 মানে: আগমন এলোমেলো (Poisson, গড় হার λ), সেবা-সময় এলোমেলো (exponential, গড় হার μ — service rate), একজন সেবাদাতা। ব্যবহার ρ = λ/μ, আর গড় সেবা-সময় S = 1/μ. মূল ফলগুলো:

এক লাইনের যুক্তি (পরীক্ষায় কাজে লাগে): M/M/1-এ সিস্টেমে ঠিক n জন থাকার স্থিতিশীল সম্ভাবনা P(n) = (1 − ρ)ρⁿ — প্রতিটি অবস্থা থেকে ওপরে ওঠার হার λ আর নিচে নামার হার μ সমান হতে হয় (balance), তাই P(n+1) = ρ·P(n). এই geometric বণ্টনের গড় L = ρ/(1 − ρ). তারপর Little's law: R = L/λ = ρ/(λ(1 − ρ)) = 1/(μ − λ). আরও জানা ফল: FIFO M/M/1-এ একটি অনুরোধের মোট সময় নিজেই exponential, হার (μ − λ) — তাই P(R > t) = e^{−(μ−λ)t}, আর p95 পেতে e^{−(μ−λ)t} = 0.05 সমাধান করলে t = −ln(0.05)/(μ − λ) ≈ 3.0/(μ − λ). p99-এ গুণক −ln(0.01) ≈ 4.6.

হাতে করা উদাহরণ: μ = ১০০/s (S = ১০ ms). ρ = ০.৫ হলে λ = ৫০, μ − λ = ৫০ ⇒ R = ১/৫০ s = ২০ ms, p95 = ৩.০০/৫০ ≈ ৬০ ms. ρ = ০.৯ হলে μ − λ = ১০ ⇒ R = ১০০ ms, p99 = ৪.৬১/১০ ≈ ৪৬১ ms. ρ = ০.৯৯ হলে μ − λ = ১ ⇒ R = ১,০০০ ms — সেবা-সময়ের ১০০ গুণ। নিচের ক্যালকুলেটর একই সূত্রে পুরো টেবিল বানায়:

// M/M/1 queue: random (Poisson) arrivals at rate lambda, exponential service at rate mu, one server, FIFO.
// rho = lambda/mu;  mean number in system L = rho/(1-rho);  mean response time R = 1/(mu-lambda).
// In M/M/1 the response time is exponential with rate (mu-lambda), so its p-quantile = -ln(1-p)/(mu-lambda).
const mu = 100;                                     // service rate 100 requests/s -> service time S = 10 ms
const ms = x => (1000 * x).toFixed(1).padStart(8);
console.log('  rho  lambda/s  L(in sys)   mean R    p50 ms    p95 ms    p99 ms    R/S');
for (const rho of [0.5, 0.7, 0.8, 0.9, 0.95, 0.99]) {
  const lam = rho * mu, gap = mu - lam;
  const L = rho / (1 - rho), R = 1 / gap;
  const q = p => -Math.log(1 - p) / gap;            // percentile of an exponential distribution
  console.log(`${rho.toFixed(2).padStart(5)} ${lam.toFixed(0).padStart(8)} ${L.toFixed(2).padStart(10)} ` +
    `${ms(R)}  ${ms(q(0.50))}  ${ms(q(0.95))}  ${ms(q(0.99))} ${(R * mu).toFixed(1).padStart(6)}`);
}
const lam = 90, R = 1 / (mu - lam);                 // Little's law check at rho = 0.9
console.log(`Little: lambda x R = ${lam}/s x ${R.toFixed(3)} s = ${(lam * R).toFixed(1)} requests in the system`);
for (const rho of [0.5, 0.8, 0.9]) {                // the same +10% traffic at three starting loads
  const before = 1 / (mu - rho * mu), after = 1 / (mu - 1.1 * rho * mu);
  console.log(`+10% traffic at rho=${rho}: mean R ${ms(before).trim()} -> ${ms(after).trim()} ms (x${(after / before).toFixed(2)})`);
}

  rho  lambda/s  L(in sys)   mean R    p50 ms    p95 ms    p99 ms    R/S
 0.50       50       1.00     20.0      13.9      59.9      92.1    2.0
 0.70       70       2.33     33.3      23.1      99.9     153.5    3.3
 0.80       80       4.00     50.0      34.7     149.8     230.3    5.0
 0.90       90       9.00    100.0      69.3     299.6     460.5   10.0
 0.95       95      19.00    200.0     138.6     599.1     921.0   20.0
 0.99       99      99.00   1000.0     693.1    2995.7    4605.2  100.0
Little: lambda x R = 90/s x 0.100 s = 9.0 requests in the system
+10% traffic at rho=0.5: mean R 20.0 -> 22.2 ms (x1.11)
+10% traffic at rho=0.8: mean R 50.0 -> 83.3 ms (x1.67)
+10% traffic at rho=0.9: mean R 100.0 -> 1000.0 ms (x10.00)

এবার ধাপে ধাপে দেখুন, একই কাউন্টারে ব্যবহার বাড়লে সারির চেহারা কেমন বদলায়। প্রতিটি ধাপের সংখ্যা ওপরের সূত্র থেকে হিসাব করা (μ = ১০০/s, S = ১০ ms):

৫ · চার সম্পদের সংখ্যা পড়া — CPU, মেমরি, ডিস্ক আর নেটওয়ার্ক

CPU — user, system, iowait, steal

CPU-সময় কয়েকটি ভাগে দেখানো হয়। Linux এগুলো গোনে /proc/stat-এ, প্রতিটি CPU-র জন্য, “tick” এককে (সাধারণত সেকেন্ডে ১০০টি); দুটি মুহূর্তের পার্থক্য থেকে শতাংশ বানানো হয়।

iowait-এর ফাঁদ: নামের কারণে অনেকে ভাবেন CPU I/O-র জন্য “ব্যস্ত”। আসলে এটি অলস সময়, শুধু তখন কোথাও একটি I/O অপেক্ষায় ছিল। একটি CPU-ভারী কাজ চালু করলে iowait কমে যাবে, অথচ ডিস্কের অবস্থা একটুও বদলায়নি! Linux kernel-এর ডকুমেন্টেশনও বলে বহু-CPU যন্ত্রে সংখ্যাটি নির্ভরযোগ্য নয়। এটি একটি সংকেত মাত্র: “ডিস্কের দিকে তাকান।”

Steal-এর কথা: পর্ব ৫০-এ (virtual machine আর hypervisor) দেখেছেন, একটি ভৌত CPU কয়েকটি VM-এর vCPU ভাগ করে চালাতে পারে। KVM বা Xen-এর মতো hypervisor guest kernel-কে জানায় কতক্ষণ তার vCPU চলতে চেয়েও পায়নি — সেটিই st. নিয়মিত কয়েক শতাংশের বেশি steal মানে host-এ ভিড়, বা burst-ধরনের instance-এ CPU credit শেষ (প্রদানকারীভেদে আলাদা) — নিজের কোড না বদলালেও কেন ধীর, তার একটি লুকানো উত্তর।

CPU-র saturation — run queue আর load average

Utilization ১০০% হলে প্রশ্ন: কতজন লাইনে? vmstat 1-এর r কলাম দেখায় এই মুহূর্তে কতগুলো thread চলছে বা চলার অপেক্ষায় (run queue). r নিয়মিত CPU-সংখ্যার চেয়ে বেশি মানে CPU saturated. পর্ব ১১-এ (Shell, ps, top আর /proc) load average-এর বিস্তারিত দেখেছেন; এখানে শুধু মনে রাখুন, Linux-এ load average-এ ডিস্কের অপেক্ষায় আটকে থাকা (D-অবস্থার) thread-ও গোনা হয় — তাই উচ্চ load average মানেই CPU-র ভিড় নয়। সরাসরি মাপ PSI: /proc/pressure/cpu-এর some avg10=35.00 মানে গত ১০ সেকেন্ডের ৩৫% সময় অন্তত একটি কাজ CPU-র অপেক্ষায় ছিল।

Context switch: vmstat-এর cs কলাম সেকেন্ডে কতগুলো context switch. পর্ব ৯-এ (context switch আর dispatcher) এর খরচ দেখেছেন। এর কোনো সর্বজনীন “ভালো” মান নেই — baseline-এর সাথে তুলনা করুন। pidstat -w 1 দুই ভাগে দেখায়: cswch/s (নিজে থেমেছে — I/O, lock, sleep) আর nvcswch/s (জোর করে সরানো — CPU-র ভিড়)। অনেক voluntary switch আর কম CPU-ব্যবহার একসাথে প্রায়ই lock contention-এর ইঙ্গিত।

মেমরি — RSS-এর বৃদ্ধি, page fault, swap আর OOM

• Utilization: free -m-এর available কলাম (MemAvailable) — free নয়। Linux ফাঁকা RAM page cache-এ লাগিয়ে রাখে, তাই “free” কম দেখানো স্বাভাবিক। এই পার্থক্য পর্ব ৩৮-এ (Linux-এ মেমরি) বিস্তারিত আছে।
• প্রসেসের বৃদ্ধি: কাজ একই থাকলেও RSS ঘণ্টার পর ঘণ্টা বাড়লে তা memory leak বা সীমাহীন cache-এর লক্ষণ; pidstat -r 1 দিয়ে কয়েক মিনিট পরপর তুলনা করুন।
• Page fault: minor fault সস্তা, major fault দামি (ডিস্ক থেকে পড়া)। major fault-এর নিয়মিত স্রোত মানে কাজের মেমরি RAM-এ ধরছে না।
• Saturation: vmstat-এর si/so — সেকেন্ডে কত KiB swap-এ ঢুকছে-বেরোচ্ছে। পুরোনো page swap-এ পড়ে থাকা (swpd বড়) সমস্যা নয়; চলমান si/so সমস্যা। /proc/pressure/memory-এর ব্যবহার পর্ব ৩৭-এ (thrashing আর working set) দেখেছেন।
• Errors: OOM killer একটি প্রসেস মারলে dmesg-এ “Out of memory: Killed process …” লাইন আসে, আর /proc/vmstat-এর oom_kill বাড়ে (Linux 4.13 থেকে); container-এ cgroup-এর memory.events দেখুন।

ডিস্ক — IOPS, throughput, await আর %util-এর ফাঁদ

iostat -xz 1 প্রতিটি ডিস্কের এক লাইন দেয়। মূল কলামগুলো: r/s, w/s (IOPS), rkB/s, wkB/s (throughput), r_await, w_await (await — সারিতে অপেক্ষাসহ গড় সময়, ms), aqu-sz (গড় সারির দৈর্ঘ্য) আর %util. দুটি দ্রুত যাচাই কাজে লাগে: গড় I/O-র আকার = kB/s ÷ IOPS (৪ KiB মানে ছোট এলোমেলো I/O, প্রায়ই swap), আর Little's law = aqu-sz ≈ IOPS × await. পর্ব ৪০-এ (ডিস্ক আর SSD) HDD, SATA SSD আর NVMe-র IOPS-এর মাত্রা দেখেছেন।

নেটওয়ার্ক — সংক্ষেপে

sar -n DEV 1 প্রতিটি interface-এর rx/tx প্যাকেট আর kB/s দেখায়; লিংকের গতির সাথে তুলনা করে utilization (১ Gbit/s ≈ ১২৫,০০০ kB/s). sar -n TCP,ETCP 1-এ নতুন সংযোগের হার (active/s = এই যন্ত্র থেকে, passive/s = এই যন্ত্রে) আর retrans/s — TCP retransmission, অর্থাৎ পথে প্যাকেট হারানোর সংকেত; প্রতিটি retransmit একটি অনুরোধে শত ms যোগ করতে পারে। ip -s link বা sar -n EDEV 1-এ drop আর error. বিস্তারিত নেটওয়ার্ক-বিশ্লেষণ এই কোর্সের বিষয় নয়; USE-এর জন্য এটুকুই যথেষ্ট।

৬ · প্রথম ৬০ সেকেন্ড — দশটি কমান্ডের চেকলিস্ট

২০১৫ সালে Netflix-এর প্রকৌশল-ব্লগে Brendan Gregg আর Netflix-এর পারফরম্যান্স-দল একটি লেখা প্রকাশ করেন, যার মূল কথা: একটি ধীর Linux সার্ভারে লগইন করে প্রথম এক মিনিটে এই দশটি কমান্ড চালান। এগুলো প্রায় সব Linux-এ পাওয়া যায় (sysstat প্যাকেজ ইনস্টল থাকলে), আর মিলে USE-এর বেশিরভাগ ঘর ভরে দেয়:

এই পাতার রানারে sysstat নেই, root-ও নেই। কিন্তু প্রতিটি টুল যে কাঁচা সংখ্যা পড়ে, তা /proc-এ খোলা। নিচের স্ক্রিপ্ট সেখান থেকে একটি ছোট চেকলিস্ট বানায়: /proc/stat-এর দুটি নমুনা ১ সেকেন্ড ব্যবধানে নিয়ে CPU-র ভাগ (steal-সহ), /proc/vmstat-এর পার্থক্য থেকে প্রতি সেকেন্ডের page fault আর swap, /proc/meminfo থেকে মেমরি। সেকেন্ডটি যেন একেবারে অলস না থাকে, সেজন্য পেছনে একটি ছোট CPU-লুপ চলে:

# A mini "60-second checklist" built only from /proc (no sysstat tools needed)
snap() {
  read -r _ u n s i w q sq st _ < /proc/stat              # cpu  user nice system idle iowait irq softirq steal
  CPU="$u $n $s $i $w $q $sq $st"
  VM=$(awk '{v[$1] = $2} END {print v["pgfault"], v["pgmajfault"], v["pswpin"], v["pswpout"]}' /proc/vmstat)
  CS=$(awk '$1 == "ctxt" {print $2}' /proc/stat)
}
snap; c1=($CPU); v1=($VM); x1=$CS
timeout 1 sh -c 'while :; do :; done' &                    # some CPU work so the second is not idle
sleep 1; wait
snap; c2=($CPU); v2=($VM); x2=$CS
d=(); tot=0; for k in 0 1 2 3 4 5 6 7; do d[k]=$(( c2[k] - c1[k] )); tot=$(( tot + d[k] )); done
f=(); for k in 0 1 2 3; do f[k]=$(( v2[k] - v1[k] )); done
pct() { awk -v a="$1" -v t="$tot" 'BEGIN { printf "%.1f", (t ? 100 * a / t : 0) }'; }
read -r l1 l5 l15 runq _ < /proc/loadavg
echo "uptime : load $l1 $l5 $l15 (runnable/total threads $runq) on $(nproc) CPUs"
echo "cpu %  : user $(pct $(( d[0] + d[1] ))) sys $(pct $(( d[2] + d[5] + d[6] ))) iowait $(pct "${d[4]}") steal $(pct "${d[7]}") idle $(pct "${d[3]}")"
echo "sched  : $(( x2 - x1 )) context switches/s; procs_running $(awk '$1 == "procs_running" {print $2}' /proc/stat)"
mem=$(awk '{m[$1] = $2} END {printf "%d %d %.0f %d", m["MemTotal:"]/1024, m["MemAvailable:"]/1024,
  100 * (1 - m["MemAvailable:"] / m["MemTotal:"]), (m["SwapTotal:"] - m["SwapFree:"]) / 1024}' /proc/meminfo)
read -r mt ma mu sw <<< "$mem"
echo "memory : total $mt MiB, available $ma MiB, swap used $sw MiB"
echo "faults : ${f[0]} page faults/s (${f[1]} major), swap in/out ${f[2]}/${f[3]} pages/s"
echo "shell  : $(grep -E '^(VmRSS|voluntary_ctxt|nonvoluntary_ctxt)' /proc/$$/status | tr -s ' \t' ' ' | paste -sd ' ')"
echo "--- USE summary (whole machine, as /proc shows it) ---"
echo "CPU    : U=$(pct $(( tot - d[3] - d[4] )))%  S=runnable ${runq%/*} vs $(nproc) CPUs  E=see dmesg"
echo "Memory : U=${mu}%  S=major ${f[1]}/s, swap-out ${f[3]}/s  E=oom_kill $(awk '$1 == "oom_kill" {print $2}' /proc/vmstat) since boot"

uptime : load 2.60 2.66 2.42 (runnable/total threads 2/289) on 2 CPUs
cpu %  : user 80.3 sys 16.7 iowait 1.5 steal 0.0 idle 1.5
sched  : 4662 context switches/s; procs_running 2
memory : total 1961 MiB, available 1280 MiB, swap used 440 MiB
faults : 26713 page faults/s (4 major), swap in/out 0/0 pages/s
shell  : VmRSS: 3416 kB voluntary_ctxt_switches: 19 nonvoluntary_ctxt_switches: 24
--- USE summary (whole machine, as /proc shows it) ---
CPU    : U=97.0%  S=runnable 2 vs 2 CPUs  E=see dmesg
Memory : U=35%  S=major 4/s, swap-out 0/s  E=oom_kill 12 since boot

৭ · গভীরে খোঁড়া — strace, ltrace, perf আর hardware counter

চেকলিস্ট বলে কোন সম্পদ বা প্রসেস; এবার প্রশ্ন প্রসেসটির ভেতরে কী। এখানে টুলগুলো দুই ধরনের: tracing (প্রতিটি ঘটনা ধরে — সঠিক, কিন্তু দামি) আর sampling (নির্দিষ্ট হারে নমুনা — সস্তা, পরিসংখ্যানভিত্তিক)।

strace আর ltrace — কার্যকর, কিন্তু সাবধানে

পর্ব ৫-এ strace দেখেছেন। পারফরম্যান্সে এর দুটি কাজের রূপ: strace -c -p PID (কোন system call কতবার, কত সময় — সারাংশ) আর strace -T -e trace=openat,read -p PID (প্রতিটি কলের সময়)। ltrace একই কাজ করে library ফাংশনের (malloc, strlen) জন্য।

perf — Linux-এর নিজস্ব profiler

perf (kernel-এর perf_events ব্যবস্থার টুল, Linux 2.6.31 থেকে, ২০০৯ সালের দিকে) kernel source-এর সাথেই আসে। তিনটি কাজ সবচেয়ে বেশি লাগে:

# ১. গোনা: পুরো প্রোগ্রামে কত cycle, instruction, cache miss
perf stat -e cycles,instructions,cache-misses ./myapp

# ২. নমুনা: সব CPU-তে ৯৯ Hz-এ call stack-সহ ৩০ সেকেন্ড, তারপর রিপোর্ট
perf record -F 99 -a -g -- sleep 30
perf report --stdio

# ৩. সরাসরি: এই মুহূর্তে কোন ফাংশনে CPU যাচ্ছে (top-এর মতো)
perf top

Hardware counter আর IPC: আধুনিক CPU-র ভেতরে কয়েকটি বিশেষ register থাকে — performance counter — যা cycle, শেষ হওয়া instruction, cache miss, branch miss গোনে। এদের অনুপাত IPC (instructions per cycle) একটি অসাধারণ সংকেত: আধুনিক CPU আদর্শ অবস্থায় প্রতি cycle-এ কয়েকটি নির্দেশ শেষ করতে পারে, তাই IPC ১-এর অনেক নিচে মানে CPU বেশিরভাগ সময় থেমে আছে — সাধারণত মেমরির অপেক্ষায় (cache miss). top এই দুই অবস্থার পার্থক্য দেখায় না: দুটোতেই “১০০% CPU”.

এই পাতার রানারে perf নেই, আর এটি একটি VM-এর ভেতরের container — অনেক cloud VM hardware counter guest-কে দেয়ই না। তাই নিচের প্রোগ্রাম সৎভাবে যা মাপা যায় শুধু তা-ই মাপে: wall-clock time আর CPU time, আর “প্রতি কাজে কত ns” — IPC-র একটি মোটা বদলি। তিনটি অংশ: registers-এ থাকা একটি হিসাব, ৬৪ MiB-এর এলোমেলো একটি চক্রে pointer অনুসরণ (প্রতিটি load আগেরটির ফলের ওপর নির্ভর, তাই cache miss লুকানো যায় না), আর শুধু অপেক্ষা:

#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static double now(clockid_t c) { struct timespec t; clock_gettime(c, &t); return t.tv_sec + t.tv_nsec / 1e9; }
static double w0, c0;
static void start(void) { w0 = now(CLOCK_MONOTONIC); c0 = now(CLOCK_PROCESS_CPUTIME_ID); }
static void report(const char *name, long ops) {
    double w = now(CLOCK_MONOTONIC) - w0, c = now(CLOCK_PROCESS_CPUTIME_ID) - c0;
    printf("%-13s wall %.3f s  cpu %.3f s  cpu/wall %3.0f%%", name, w, c, 100 * c / w);
    if (ops > 0) printf("  %6.2f ns per op\n", 1e9 * w / ops); else printf("  (no work, only waiting)\n");
}
int main(void) {
    const long N = 1L << 23;                        /* 8M slots x 8 bytes = 64 MiB, far bigger than any cache */
    size_t *next = malloc(N * sizeof *next);
    if (!next) return 1;
    for (long i = 0; i < N; i++) next[i] = (size_t)i;
    unsigned long long s = 57;                      /* Sattolo shuffle: one random cycle through all slots */
    for (long i = N - 1; i > 0; i--) {
        s = s * 6364136223846793005ULL + 1442695040888963407ULL;
        long j = (long)((s >> 33) % (unsigned long long)i);
        size_t t = next[i]; next[i] = next[j]; next[j] = t;
    }
    unsigned long long x = 1; size_t p = 0; start(); /* 1. CPU-bound: the data lives in registers */
    for (long i = 0; i < 200000000; i++) x = x * 2862933555777941757ULL + 3037000493ULL;
    report("cpu-bound", 200000000);
    start();                                        /* 2. memory-bound: each load waits for the previous miss */
    for (long i = 0; i < 5000000; i++) p = next[p];
    report("pointer-chase", 5000000);
    start();                                        /* 3. off-CPU: waiting, not computing */
    nanosleep(&(struct timespec){0, 300000000}, NULL);
    report("sleep", 0);
    printf("checksums %llu %zu\n", x % 1000, p % 1000); free(next); return 0;
}

cpu-bound     wall 0.373 s  cpu 0.360 s  cpu/wall  96%    1.87 ns per op
pointer-chase wall 1.228 s  cpu 1.144 s  cpu/wall  93%  245.65 ns per op
sleep         wall 0.301 s  cpu 0.001 s  cpu/wall   0%  (no work, only waiting)
checksums 761 423

perf থাকা একটি সাধারণ যন্ত্রে perf stat সরাসরি এই পার্থক্য দেখাত। নিচের আউটপুট আনুমানিক উদাহরণ — ওপরের সময় আর ~৩ GHz ঘড়ি ধরে হিসাব করা, কোনো আসল রান নয়:

cpu-bound phase      1,050,000,000 cycles   2,000,000,000 instructions   #  1.90 insn per cycle
pointer-chase phase  3,210,000,000 cycles      45,000,000 instructions   #  0.01 insn per cycle
                                                4,900,000 cache-misses (about one per load)

দুটি অংশেই top একই “১০০% CPU” দেখাত। প্রথমটিতে CPU সত্যিই কাজ করছে; দ্বিতীয়টিতে প্রায় সব cycle মেমরির অপেক্ষায় নষ্ট। সমাধানও আলাদা: প্রথমটিতে কম নির্দেশ (ভালো অ্যালগরিদম), দ্বিতীয়টিতে ভালো locality (ডেটা পাশাপাশি রাখা, পর্ব ৪-এর memory hierarchy মনে করুন)।

৮ · Flame graph, eBPF আর অন্য OS-এর টুল

perf report-এর লেখা আউটপুট হাজার লাইনের হতে পারে — প্রতিটি আলাদা call stack আর তার শতাংশ। ২০১১ সালে Brendan Gregg (তখন Joyent-এ, একটি MySQL পারফরম্যান্স-সমস্যা খুঁজতে গিয়ে) এই স্তূপকে একটি ছবিতে আনার উপায় বানান: flame graph. একটি sampling profiler (যেমন perf record -g) প্রতিটি নমুনায় একটি পুরো call stack নেয়; একই stack-গুলো গুনে একসাথে করা হয়, তারপর আঁকা হয়। নিচে একটি কাল্পনিক API সার্ভারের CPU flame graph — মোট ১০০০টি নমুনা — ধাপে ধাপে পড়ুন:

বাস্তবে Gregg-এর FlameGraph স্ক্রিপ্ট (perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg) বা নতুন টুল ছবিটি বানায়; কিছু টুলে ছবি উল্টো (icicle, root ওপরে), পড়ার নিয়ম একই।

eBPF-ভিত্তিক টুল — production-এ নিরাপদ, কম-খরচের tracing

eBPF kernel-এর ভেতরে যাচাই-করা ছোট প্রোগ্রাম চালাতে দেয়; প্রোগ্রামটি kernel-এর ভেতরেই গুনে বা histogram বানিয়ে শুধু সারাংশ user space-এ পাঠায়, তাই strace-এর মতো প্রতি ঘটনায় থামার খরচ নেই। এর ভেতরের যন্ত্র — verifier, map, hook — পর্ব ৫৫-এ (Linux kernel-এর ভেতর) আলোচিত; এখানে শুধু ব্যবহারকারীর দিক। দুটি জনপ্রিয় সংগ্রহ: BCC-এর তৈরি টুল আর bpftrace-এর এক লাইনের প্রোগ্রাম। দুটোরই root (বা সমতুল্য capability) আর নতুন kernel লাগে:

# BCC tools (Ubuntu/Debian names often end in -bpfcc, e.g. biolatency-bpfcc)
execsnoop          # every new process (short-lived ones that top never shows)
opensnoop          # which process opens which file
biolatency 10 1    # disk I/O latency as a histogram, one 10-second interval
runqlat 10 1       # how long threads waited in the CPU run queue (histogram)
tcpretrans         # each TCP retransmission, with addresses
offcputime -p PID 10   # where a process blocked, with stacks (off-CPU analysis)

# bpftrace one-liners
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'   # syscalls per program
bpftrace -e 'profile:hz:99 { @[comm] = count(); }'                          # on-CPU samples per program

খেয়াল করুন, runqlat সরাসরি CPU-র saturation মাপে (thread কতক্ষণ লাইনে দাঁড়াল), আর biolatency ডিস্কের latency-কে histogram-এ দেখায় — অংশ ৩-এর “percentile বনাম histogram” শিক্ষার বাস্তব প্রয়োগ।

Windows আর macOS — একই প্রশ্ন, অন্য টুল

USE, RED আর queueing-এর অঙ্ক OS-নিরপেক্ষ; বদলায় টুল আর সংখ্যার সংজ্ঞা (Windows-এর “Processor Queue Length” আর Linux-এর load average এক জিনিস নয়)।

Get-Counter '\Processor(_Total)\% Processor Time','\System\Processor Queue Length','\Memory\Available MBytes' -SampleInterval 1 -MaxSamples 5
wpr -start CPU -start DiskIO
wpr -stop C:\traces\slow.etl      # then open the .etl file in WPA

৯ · কেস স্টাডি — ছাড়ের দিনে একটি e-commerce API ধীর হয়ে গেল

এবার সব একসাথে। নিচের গল্পটি কাল্পনিক — কোনো আসল প্রতিষ্ঠানের ঘটনা নয় — কিন্তু এ ধরনের ঘটনা বাস্তবে পরিচিত। একটি বাংলাদেশি অনলাইন দোকান, ধরা যাক “দোকানঘর”, একটি বড় ছাড়ের দিনে সকাল ১০টায় অফার চালু করল। তাদের product আর checkout API চলে একটি cloud VM-এ: ৪টি vCPU, ৮ GiB RAM, root ডিস্কে ৪ GiB-এর একটি swapfile, আর প্রদানকারীর দেওয়া ডিস্ক-সীমা ধরা যাক ৩,০০০ IOPS. অ্যাপটি Python-এ লেখা, gunicorn-এর কয়েকটি worker প্রসেসে চলে।

১০:৪০-এ অভিযোগ আসতে শুরু করল। অন-কল প্রকৌশলী তানজিলা আন্দাজে কিছু না বদলে USE-এর তালিকা ধরে এগোলেন। টুল-আউটপুটগুলো উদাহরণ — বানানো, কিন্তু সংখ্যাগুলো পরস্পরের সাথে মিলিয়ে হিসাব করা; কিছু কলাম ছাঁটা:

১০ · AI-এর যুগে পারফরম্যান্স-তদন্ত — দ্রুত, কিন্তু যাচাই করে

AI একটি vmstat আউটপুটের কলাম বুঝিয়ে দিতে বা bpftrace-এর একটি লাইন লিখে দিতে সত্যিই কাজে লাগে। কিন্তু তার ভুলগুলো চেনা দরকার, কারণ ভুল সমাধান production সার্ভারে সরাসরি ক্ষতি করে।

AI-এর পারফরম্যান্স-পরামর্শ মানার আগে — চেকলিস্ট

• লক্ষণ (rate, error, p50/p99) আর baseline লিখে নিয়েছি, যাতে পরিবর্তনের ফল মাপা যায়
• USE-এর চারটি সম্পদই দেখেছি — শুধু যেটিতে AI আঙুল তুলেছে সেটি নয়
• প্রতিটি কমান্ড আমার OS, distro আর টুলের সংস্করণে আছে কি না man পাতা বা --help-এ মিলিয়েছি
• queueing বা ক্ষমতার হিসাব সূত্র দিয়ে নিজে আবার করেছি
• production-এ ভারী tracing (strace, ltrace) চালানোর আগে খরচ ভেবেছি, বিকল্প দেখেছি
• একবারে একটি পরিবর্তন করে load test বা আসল ট্রাফিকে আগে-পরে মেপেছি, আর ফেরত যাওয়ার পথ রেখেছি