OS ইন্টারভিউর প্রশ্ন — ধারণা থেকে বাস্তব সিস্টেম

সংক্ষিপ্ত উত্তর: Process হলো চলমান প্রোগ্রাম, যার নিজের address space, fd টেবিল আর অনুমতি আছে। Thread একটি process-এর ভেতরের কাজের ধারা — নিজের stack আর register, কিন্তু মেমরি ও fd ভাগ করা। Thread সস্তা আর দ্রুত ডেটা ভাগ করে; process বিচ্ছিন্নতা দেয় — একটি ভাঙলে অন্যটি টেকে।

গভীর উত্তর: Linux-এ দুটোই kernel-এর কাছে task (task_struct); পার্থক্য clone-এর flag-এ — thread-এ CLONE_VM, CLONE_FILES ইত্যাদি দিয়ে মেমরি আর fd ভাগ হয়। তাই ps -L বা /proc/<pid>/task-এ প্রতিটি thread আলাদা দেখা যায়। বেছে নেওয়ার যুক্তি: crash বা মেমরি-দুর্নীতি একে অন্যকে না ছোঁয়াতে, আলাদা অনুমতি (privilege separation) বা আলাদা ভাষার অংশে process (Chrome-এর প্রতিটি সাইটের renderer, PostgreSQL-এর প্রতিটি connection); প্রচুর ভাগ-করা ডেটা আর কম latency-তে thread (একটি Java বা Go সার্ভার)। Thread-এর দাম — data race আর lock-এর জটিলতা।

সম্ভাব্য ফলো-আপ: “একটি thread segfault করলে কী হয়?” → পুরো process মরে, কারণ signal-এর ডিফল্ট কাজ process-স্তরে। “Thread switch কেন সস্তা?” → প্রশ্ন ০২.

সংক্ষিপ্ত উত্তর: চলতি task-এর register, program counter, stack pointer আর FPU/SIMD অবস্থা kernel-এ সংরক্ষণ করে পরের task-এরটি ফিরিয়ে আনা হয়; process বদলালে page table-ও (x86-এ CR3). প্রত্যক্ষ খরচ সাধারণত কয়েক মাইক্রোসেকেন্ড; বড় খরচটি পরোক্ষ — cache আর TLB আবার গরম হতে সময় লাগে।

গভীর উত্তর: পর্ব ৯-এর মোটা দাগের হিসাব: একটি ছোট syscall-এর mode switch প্রায় ১০০ ns থেকে কয়েকশো ns, context switch-এর প্রত্যক্ষ খরচ প্রায় ১ µs থেকে কয়েক µs, আর পরোক্ষ ক্ষতি বড় working set-এ শত µs পর্যন্ত। Thread switch-এ address space একই থাকে, তাই TLB টেকে (PCID/ASID থাকলে process switch-এও অংশত টেকে)। মাপতে: perf bench sched pipe, আর একটি process-এর জন্য /proc/<pid>/status-এর voluntary_ctxt_switches (নিজে ঘুমিয়েছে — I/O বা lock) বনাম nonvoluntary_ctxt_switches (CPU-র জন্য কাড়াকাড়ি)। সার্ভারে সেকেন্ডে লাখো switch হলে thread কমানো, batch করা বা async মডেল ভাবতে হয়।

সম্ভাব্য ফলো-আপ: “Mode switch কি context switch?” → না, একই task user↔kernel যায়-আসে। “VM-এ খরচ বেশি কেন?” → virtualization আর নিরাপত্তা-প্রতিরোধের (যেমন KPTI) বাড়তি কাজ।

সংক্ষিপ্ত উত্তর: Kernel নতুন PID-সহ একটি child বানায়, যে parent-এর মেমরি, fd আর signal-সেটিংয়ের কপি পায়। মেমরি আসলে কপি হয় না — copy-on-write-এ দুজনের page table একই frame দেখায়, শুধু-পড়া হিসেবে; কেউ লিখলে তবেই সেই একটি page কপি হয়। fork ফেরে দুবার: child-এ 0, parent-এ child-এর PID.

গভীর উত্তর: কপি হয় page table আর kernel-এর হিসাবপত্র, তাই বিশাল process-এও fork মিলিসেকেন্ডের ঘরে হতে পারে, শূন্য নয়। fd টেবিল কপি হয়, কিন্তু দুজনের fd একই open file description দেখায় — offset ভাগ। Multithreaded process fork করলে child-এ শুধু যে thread fork ডেকেছে সেটি থাকে; অন্য thread কোনো mutex ধরে থাকলে child-এ সেটি চিরকাল ধরা থাকে — তাই fork-এর পর exec-এর আগে শুধু async-signal-safe ফাংশন ডাকা নিরাপদ। বাস্তব উদাহরণ: Redis snapshot (BGSAVE) নিতে fork করে; ভারী লেখার সময় COW-এ মেমরি প্রায় দ্বিগুণ হতে পারে।

সম্ভাব্য ফলো-আপ: “লুপে ৩ বার fork করলে কতটি process?” → ২^৩ = ৮টি, যার ৭টি নতুন। “stdout pipe-এ থাকলে printf-এর লেখা দুবার কেন আসে?” → fork-এর আগে না-ছাপা buffer দুজনেই কপি পায়; fork-এর আগে fflush.

সংক্ষিপ্ত উত্তর: exec নতুন process বানায় না, একই PID-এ প্রোগ্রাম বদলায়। দুই ধাপ আলাদা বলে মাঝখানে child নিজের পরিবেশ সাজাতে পারে — fd redirect (dup2), working directory বদল, অনুমতি কমানো, signal ঠিক করা — shell-এর > আর | ঠিক এভাবেই কাজ করে।

গভীর উত্তর: খরচের দিক: বড় process থেকে শুধু একটি ছোট কমান্ড চালাতে fork-এর page-table কপি অপচয়। তাই vfork (child exec বা _exit না করা পর্যন্ত parent থামে, মেমরি ভাগ) আর posix_spawn (glibc ভেতরে clone(CLONE_VM|CLONE_VFORK) ব্যবহার করে) — অনেক মেমরির সার্ভার থেকে subprocess চালাতে এগুলো ভালো। Windows-এর CreateProcess ঠিক এক ধাপের নকশা; সেখানে redirect আর পরিবেশ প্যারামিটার হিসেবে দিতে হয়।

সম্ভাব্য ফলো-আপ: “exec সফল হলে পরের লাইনটি চলে?” → না, কখনো ফেরে না; ফিরলে মানে ব্যর্থ। “exec-এর পর খোলা fd কী হয়?” → খোলাই থাকে, যদি না O_CLOEXEC দেওয়া থাকে — fd leak ঠেকাতে এটি ডিফল্ট অভ্যাস করুন।

সংক্ষিপ্ত উত্তর: Zombie: শেষ হয়ে গেছে, কিন্তু parent এখনো wait করে exit status নেয়নি — ps-এ STAT Z, <defunct>. Orphan: এখনো চলছে, কিন্তু parent আগে মরেছে — তাকে init (PID 1) বা কোনো subreaper দত্তক নেয়, যে পরে reap করে।

গভীর উত্তর: Zombie-কে kill -9 দিয়ে মারা যায় না — সে তো আগেই মৃত; মেমরিও নেয় না, কিন্তু PID আর process-টেবিলের জায়গা নেয়। হাজার হাজার জমলে PID ফুরিয়ে (বা cgroup-এর pids.max ছুঁয়ে) নতুন fork ব্যর্থ হয়। সমাধান parent-এ: SIGCHLD handler-এ waitpid(-1, &st, WNOHANG) লুপ, বা SIGCHLD-কে SIG_IGN করা (Linux-এ তখন child নিজে reap হয়)। parent ঠিক করা না গেলে parent-কে বন্ধ করলে zombie-রা init-এর কাছে গিয়ে reap হয়। Container-এ PID 1 যদি আপনার অ্যাপ হয় আর সে reap না করে, zombie জমে — তাই tini বা docker run --init (প্রশ্ন ৪৫)।

সম্ভাব্য ফলো-আপ: “নিজের হাতে একটি zombie বানিয়ে দেখাবেন?” → নিচের উদাহরণ। “Orphan কি খারাপ?” → না; daemon বানানোর পুরোনো কৌশলই ইচ্ছা করে orphan করা।

সংক্ষিপ্ত উত্তর: SIGTERM (১৫) ধরা যায় — প্রোগ্রাম নতুন অনুরোধ নেওয়া বন্ধ করে, চলতি কাজ শেষ করে, ফাইল flush করে বের হতে পারে। SIGKILL (৯) ধরা বা উপেক্ষা করা যায় না; kernel সঙ্গে সঙ্গে শেষ করে, কোনো cleanup হয় না। তাই আগে SIGTERM, অপেক্ষা, তারপর শেষ উপায় হিসেবে SIGKILL.

গভীর উত্তর: systemd, Docker আর Kubernetes ঠিক এই ক্রম মানে: docker stop SIGTERM পাঠিয়ে ডিফল্টে ১০ সেকেন্ড অপেক্ষা করে, তারপর SIGKILL; Kubernetes-এ terminationGracePeriodSeconds (ডিফল্ট ৩০)। Handler-এ ভারী কাজ নয় — একটি volatile sig_atomic_t flag বসিয়ে মূল লুপে বন্ধ করা, কারণ handler-এ শুধু async-signal-safe ফাংশন নিরাপদ (printf নয়)। SIGKILL-এও D-অবস্থায় আটকে থাকা process সঙ্গে সঙ্গে মরে না — I/O শেষ না হওয়া পর্যন্ত signal পৌঁছায় না।

সম্ভাব্য ফলো-আপ: “Ctrl+C কী পাঠায়?” → terminal foreground process group-কে SIGINT.

সংক্ষিপ্ত উত্তর: Thread-per-connection লেখা সহজ, কিন্তু প্রতিটি thread-এর stack মেমরি, scheduling আর context switch-এর খরচ আছে; বেশিরভাগ connection বেশিরভাগ সময় অলস থাকলে সেই খরচ অপচয়। Async মডেলে অল্প কয়েকটি thread epoll-এর মতো I/O multiplexing দিয়ে হাজার fd একসাথে দেখে — শুধু প্রস্তুতগুলো নিয়ে কাজ করে।

গভীর উত্তর: প্রতিটি Linux thread-এর stack ডিফল্টে প্রায়ই ৮ MiB virtual (ulimit -s), যদিও RAM-এ আসে শুধু ছোঁয়া অংশ; সমস্যা বেশি হয় scheduler-এর চাপ, cache দূষণ আর lock-প্রতিযোগিতায়। nginx, Redis আর Node.js event loop + epoll মডেলে; Go-র goroutine আর Java 21-এর virtual thread মাঝামাঝি পথ — কোড দেখতে blocking, কিন্তু runtime ভেতরে অল্প OS thread আর epoll চালায় (M:N). সিদ্ধান্তের মাপকাঠি: কাজ CPU-নির্ভর হলে core-সংখ্যার কাছাকাছি thread; I/O-নির্ভর আর অনেক অলস connection হলে async বা সস্তা thread.

সম্ভাব্য ফলো-আপ: “Async-এর অসুবিধা?” → callback/await-এর জটিলতা, একটি blocking call বা লম্বা হিসাব পুরো loop আটকায় (প্রশ্ন ০৮)। “C10K কী?” → প্রশ্ন ৩৯.

সংক্ষিপ্ত উত্তর: Event loop একটি লুপ: OS-কে জিজ্ঞেস করে কোন fd বা timer প্রস্তুত (Linux-এ epoll), তারপর সেগুলোর callback একে একে একই thread-এ চালায়। কোনো callback যদি CPU ধরে রাখে (বড় JSON parse, sync crypto, readFileSync), সেই সময় অন্য কোনো callback চলতে পারে না — সবার latency বাড়ে।

গভীর উত্তর: Node.js-এর libuv নেটওয়ার্কের জন্য epoll (macOS-এ kqueue, Windows-এ IOCP) ব্যবহার করে; কিন্তু সাধারণ ফাইলের I/O, DNS-এর getaddrinfo আর কিছু crypto চালায় একটি ছোট thread pool-এ (ডিফল্টে ৪টি thread), কারণ Linux-এ সাধারণ ফাইলকে epoll-এ যোগই করা যায় না (EPERM), আর select/poll তাকে সবসময় “প্রস্তুত” বলে। সমাধান: ভারী হিসাব worker thread বা আলাদা process-এ, sync API এড়ানো, আর event-loop lag মাপা (মেট্রিক হিসেবে)। একই নীতি Python-এর asyncio আর Rust-এর tokio-তেও।

সম্ভাব্য ফলো-আপ: “Readiness আর completion মডেলের পার্থক্য?” → epoll বলে “এখন পড়া যাবে”, io_uring/IOCP বলে “পড়া শেষ” (প্রশ্ন ৩৫)।

সংক্ষিপ্ত উত্তর: প্রচলিত CPython-এ GIL এক মুহূর্তে একটিই thread-কে Python bytecode চালাতে দেয়, তাই CPU-নির্ভর কাজে thread বাড়িয়ে গতি সাধারণত বাড়ে না; I/O-অপেক্ষায় thread তবু কাজে লাগে। Go-র goroutine runtime-এর M:N scheduler-এ চলে — হাজার goroutine কয়েকটি OS thread-এ, আর সত্যিই সব core ব্যবহার করে।

গভীর উত্তর: Python-এ CPU-কাজের জন্য multiprocessing বা ProcessPoolExecutor (প্রতিটি process-এর নিজের GIL), অথবা NumPy-র মতো C-লাইব্রেরি, যা হিসাবের সময় GIL ছেড়ে দেয়। Python 3.13 থেকে GIL-ছাড়া একটি পরীক্ষামূলক build পাওয়া যায়। Go-তে GOMAXPROCS ঠিক করে একসাথে কতটি OS thread Go কোড চালাবে; blocking syscall-এ runtime নতুন thread জোগায়, আর নেটওয়ার্কে নিজের netpoller (Linux-এ epoll). Container-এ CPU limit থাকলে GOMAXPROCS host-এর সব CPU ধরে নিলে throttling বাড়ে — প্রশ্ন ৪৪।

সম্ভাব্য ফলো-আপ: “তাহলে Python-এ thread একেবারে অকেজো?” → না; নেটওয়ার্ক বা ডিস্কের অপেক্ষায় GIL ছাড়া থাকে, তাই I/O-ভারী কাজে কাজে লাগে।

সংক্ষিপ্ত উত্তর: System call হলো user program-এর kernel-এর কাছে সেবা চাওয়ার নির্দিষ্ট দরজা: বিশেষ instruction (x86-64-এ syscall) CPU-কে kernel mode-এ নেয়, kernel argument যাচাই করে কাজ করে, তারপর ফেরে। Mode বদল, যাচাই আর নিরাপত্তা-প্রতিরোধের জন্য এটি function call-এর চেয়ে বহু গুণ দামি।

গভীর উত্তর: Syscall নম্বর register-এ (x86-64 Linux-এ rax), argument rdi, rsi, rdx, r10, r8, r9-এ; ব্যর্থ হলে libc wrapper errno বসিয়ে −1 ফেরত দেয়। vDSO হলো kernel-এর user space-এ map করা একটি ছোট লাইব্রেরি, যাতে clock_gettime-এর মতো কেবল-পড়ার কাজ mode বদল ছাড়াই হয় — সেকেন্ডে লাখো বার সময় পড়া সার্ভারে বড় সাশ্রয়। কোন syscall কতবার হচ্ছে দেখতে strace -c (production-এ সাবধানে, এটি প্রোগ্রামকে অনেক ধীর করে) বা perf trace.

সম্ভাব্য ফলো-আপ: “printf কি system call?” → না, library ফাংশন; শেষে write ডাকে। “Syscall কমাবেন কীভাবে?” → buffering, বড় ব্লকে পড়া, readv/writev, epoll-এ এক ঘুমে অনেক ঘটনা, io_uring.

সংক্ষিপ্ত উত্তর: না। Data race একটি নির্দিষ্ট সংজ্ঞা: দুই thread একই মেমরি-ঘর একসাথে ছোঁয়, অন্তত একজন লেখে, আর মাঝে কোনো synchronization নেই — C/C++-এ এটি undefined behavior. Race condition আরও বড় ধারণা: ফল ঘটনার সময়-ক্রমের ওপর নির্ভর করে — data race ছাড়াও হতে পারে।

গভীর উত্তর: উদাহরণ: প্রতিটি অংশ আলাদা lock-এ সুরক্ষিত, তবু “ব্যালান্স পড়া → যাচাই → টাকা কাটা” তিন ধাপের মাঝে অন্য thread ঢুকে পড়তে পারে — data race নেই, race condition আছে (check-then-act). ফাইলেও হয়: if (!exists(f)) create(f) — দুই process একসাথে; সমাধান open(O_CREAT|O_EXCL)-এর মতো অবিভাজ্য অপারেশন। Data race ধরতে ThreadSanitizer (-fsanitize=thread); race condition ধরতে নকশা পর্যালোচনা আর invariant ভাবা।

সম্ভাব্য ফলো-আপ: “দুই thread ১০ লাখ করে lock ছাড়া counter++ করলে ফল?” → ২ থেকে ২০ লাখের যেকোনো মান হতে পারে (load-add-store মিশে lost update); বাস্তবে সাধারণত ২০ লাখের অনেক কম।

সংক্ষিপ্ত উত্তর: Mutex একজনকে ঢুকতে দেয়, আর তার মালিক আছে — যে নিয়েছে সে-ই ছাড়ে; অপেক্ষাকারী ঘুমায়। Semaphore একটি গণনা — N জন একসাথে (যেমন ১০টি DB connection), মালিক নেই, তাই এক thread অন্য thread-কে সংকেত দিতে পারে। Spinlock-এ অপেক্ষাকারী ঘুমায় না, ঘুরতে থাকে — শুধু multicore-এ খুব ছোট critical section-এ, বা যেখানে ঘুমানো যায় না (interrupt handler).

গভীর উত্তর: মালিকানা থাকায় mutex-এ priority inheritance, recursive lock-এর নিয়ম আর “অন্যের lock ছাড়লে” ভুল ধরা সম্ভব। Linux-এর pthread mutex futex-এর ওপর: প্রতিযোগিতা না থাকলে একটি atomic instruction-এ user space-এই শেষ, system call শুধু ঘুমানো-জাগানোর সময়; অনেক বাস্তবায়ন ঘুমানোর আগে অল্প ঘোরে (adaptive). Uniprocessor-এ spinlock অর্থহীন — ঘোরার সময় holder চলতেই পারে না। User space-এ সাধারণত mutex-ই ঠিক; নিজের spinlock লেখা প্রায়ই ভুল সিদ্ধান্ত।

সম্ভাব্য ফলো-আপ: “Binary semaphore কি mutex?” → প্রায়, কিন্তু মালিক নেই। “Semaphore-এর মান ১০; ৬টি P, ৪টি V — এখন?” → ১০ − ৬ + ৪ = ৮.

সংক্ষিপ্ত উত্তর: সবচেয়ে কার্যকর নিয়ম lock ordering: সব জায়গায় lock একই global ক্রমে নেওয়া (যেমন account id বা ঠিকানার ছোট থেকে বড়) — তাহলে circular wait অসম্ভব। এর সাথে: lock ধরে বাইরের কোড বা I/O না ডাকা, একবারে কম lock, আর দরকারে timeout-সহ trylock.

গভীর উত্তর: ক্লাসিক ফাঁদ: transfer(a, b) আগে a-র lock, তারপর b-র; একই সময়ে transfer(b, a) উল্টো ক্রমে — deadlock. সমাধান: min(a,b) আগে। Linux kernel lockdep দিয়ে চলার সময় lock-ক্রমের নিয়মভঙ্গ ধরে; user space-এ ThreadSanitizer-ও lock-order-inversion জানায়। Production-এ আটকে গেলে: CPU প্রায় শূন্য, অনুরোধ জমছে; gdb -p PID বা pstack-এ thread apply all bt — দেখবেন দুই thread পরস্পরের ধরা lock-এ futex_wait-এ বসে আছে; Java-য় jstack সরাসরি “Found one Java-level deadlock” লেখে।

সম্ভাব্য ফলো-আপ: “Livelock কী?” → সবাই চলছে, বারবার পিছিয়ে যাচ্ছে, কেউ এগোচ্ছে না; সমাধান এলোমেলো backoff.

সংক্ষিপ্ত উত্তর: Lock-free মানে কোনো thread থেমে গেলেও (preempt বা ধীর) অন্তত কেউ না কেউ সবসময় এগোয়। মূল হাতিয়ার CAS: “মান এখনো X থাকলে তবেই Y লেখা হবে” — একটি অবিভাজ্য instruction; ব্যর্থ হলে আবার পড়ে চেষ্টা। CAS-stack-এর বিখ্যাত বাগ ABA.

গভীর উত্তর: ABA: thread 1 head = A পড়ে, next = B মনে রাখে, তারপর থেমে যায়। এর মধ্যে অন্যরা A আর B pop করে, A আবার push করে (হয়তো একই ঠিকানায় নতুন node). Thread 1-এর CAS দেখে head এখনো A — সফল, আর head বানায় B, যা আর তালিকায় নেই। সমাধান: version tag-সহ pointer (double-width CAS), hazard pointer, epoch-ভিত্তিক মুক্তি, বা GC-যুক্ত ভাষা। Lock-free সবসময় দ্রুত নয় — প্রতিযোগিতা বেশি হলে CAS বারবার ব্যর্থ হয় আর cache line টানাটানি করে; সঠিকতা প্রমাণও কঠিন। Linux kernel-এ পাঠক-প্রধান ডেটায় RCU জনপ্রিয়।

সম্ভাব্য ফলো-আপ: “Lock-free আর wait-free?” → wait-free-এ প্রত্যেকেই সসীম ধাপে শেষ করে — আরও কড়া নিশ্চয়তা। “x86 আর ARM-এ CAS?” → x86-এ lock cmpxchg, ARM-এ LL/SC জোড়া (ldxr/stxr) বা নতুন ARM-এ cas.

সংক্ষিপ্ত উত্তর: CPU cache-এ ডেটা আসে cache line ধরে (সাধারণত ৬৪ বাইট)। দুই thread দুই আলাদা ভ্যারিয়েবলে লিখছে, কিন্তু দুটো একই line-এ পড়েছে — তখন coherence protocol line-টি দুই core-এর মধ্যে বারবার টানাটানি করে। এটি false sharing: ফল ঠিক, কিন্তু গতি কয়েক গুণ কমতে পারে।

গভীর উত্তর: ক্লাসিক উদাহরণ: long counters[8], প্রতি thread একটি ঘরে লুপে লেখে — আটটি ঘর মিলে ৬৪ বাইট, একটিই line. সমাধান: প্রতিটি ঘর আলাদা line-এ (padding বা alignas(64); Java-য় @Contended), বা local ভ্যারিয়েবলে জমিয়ে শেষে একবার লেখা। ধরা পড়ে মাপলে: perf c2c cache-to-cache টানাটানির ঠিকানা দেখায়; টেস্টে ধরা পড়ে না, কারণ এটি সঠিকতার নয়, গতির সমস্যা।

সম্ভাব্য ফলো-আপ: “True sharing থেকে আলাদা কীভাবে?” → true sharing-এ সত্যিই একই ভ্যারিয়েবল ভাগ — তখন নকশা বদলাতে হয় (প্রতি-CPU counter, শেষে যোগ)।

সংক্ষিপ্ত উত্তর: দুই কারণে: spurious wakeup — কেউ signal না দিলেও wait ফিরতে পারে; আর জাগার পর mutex ফেরত পাওয়ার আগেই অন্য thread শর্তটি আবার বদলে দিতে পারে (Mesa semantics). তাই জেগে শর্তটি আবার দেখতে হয়: while (!ready) pthread_cond_wait(&cv, &m);

গভীর উত্তর: Condition variable-এর কোনো স্মৃতি নেই — কেউ অপেক্ষায় না থাকলে signal হারিয়ে যায়; শর্তটি থাকে mutex-রক্ষিত একটি ভ্যারিয়েবলে। wait অবিভাজ্যভাবে mutex ছেড়ে ঘুমায়, তাই “শর্ত দেখলাম মিথ্যা” আর “ঘুমালাম”-এর মাঝে signal হারানোর (lost wakeup) ফাঁক থাকে না। একাধিক ধরনের অপেক্ষাকারী একই CV-তে থাকলে broadcast নিরাপদ, তবে thundering herd-এর দাম আছে; ভালো নকশা প্রতিটি শর্তের আলাদা CV (যেমন bounded buffer-এ notFull আর notEmpty).

সম্ভাব্য ফলো-আপ: “Semaphore দিয়ে একই কাজ?” → semaphore গণনা মনে রাখে, তাই আগে দেওয়া V হারায় না।

সংক্ষিপ্ত উত্তর: উচ্চ-অগ্রাধিকারের task একটি lock-এর অপেক্ষায়, যা ধরে আছে নিম্ন-অগ্রাধিকারের task; মাঝারি-অগ্রাধিকারের task এসে নিম্নটিকে CPU থেকে সরিয়ে রাখে — ফলে উচ্চ task কার্যত মাঝারির চেয়েও পিছিয়ে যায়। প্রতিকার priority inheritance: lock-ধারী সাময়িকভাবে অপেক্ষমাণের অগ্রাধিকার পায়।

গভীর উত্তর: ১৯৯৭ সালের Mars Pathfinder-এর ঘটনা এর পরিচিত উদাহরণ: watchdog বারবার সিস্টেম রিসেট করত; VxWorks-এ mutex-এর priority inheritance চালু করে সমস্যা মেটানো হয়েছিল বলে জানা যায়। বিকল্প priority ceiling protocol. Linux-এ PTHREAD_PRIO_INHERIT দিয়ে mutex বানানো যায়, আর PREEMPT_RT kernel-এর rt-mutex এটি দেয়।

সম্ভাব্য ফলো-আপ: “Semaphore-এ inheritance কেন হয় না?” → মালিক নেই, তাই কাকে অগ্রাধিকার দেবে জানা যায় না।

সংক্ষিপ্ত উত্তর: না। volatile শুধু compiler-কে বলে প্রতিবার মেমরি থেকে পড়তে-লিখতে; এটি অবিভাজ্যতা দেয় না, আর অন্য ভ্যারিয়েবলের সাথে ক্রম (ordering) নিশ্চিত করে না — CPU আর compiler দুজনেই লেখা-পড়া আগে-পিছে করতে পারে। দরকার _Atomic/std::atomic (সঠিক memory ordering-সহ) বা lock.

গভীর উত্তর: ক্লাসিক ভুল: thread A ডেটা লিখে ready = 1; thread B ready দেখে ডেটা পড়ে। ARM-এর মতো দুর্বল-ক্রমের CPU-তে B নতুন ready কিন্তু পুরোনো ডেটা দেখতে পারে। সমাধান: লেখায় release, পড়ায় acquire (atomic_store_explicit(&ready, 1, memory_order_release)). x86-এর TSO তুলনামূলক কড়া, তবু store→load পুনর্বিন্যাস হয় (store buffer), তাই Peterson-এর মতো algorithm বাধা (fence) ছাড়া ভাঙে। “আমার x86 ল্যাপটপে চলে” প্রমাণ নয়। volatile-এর আসল জায়গা memory-mapped device register আর signal handler-এর sig_atomic_t.

সম্ভাব্য ফলো-আপ: “Java-র volatile?” → আলাদা: Java-য় volatile visibility আর ক্রমের নিশ্চয়তা দেয় (তবু count++ অবিভাজ্য নয়)।

সংক্ষিপ্ত উত্তর: কাজের ধরনের ওপর নির্ভর করে। CPU-নির্ভর কাজে প্রায় core-সংখ্যা (বা core + ১); বেশি দিলে শুধু context switch বাড়ে। I/O-নির্ভর কাজে বেশি: মোটামুটি N_core × (১ + অপেক্ষার সময় ÷ হিসাবের সময়)। তারপর মেপে ঠিক করা।

গভীর উত্তর: উদাহরণ: ৮ core, প্রতিটি অনুরোধে ১০ ms হিসাব আর ৯০ ms DB-অপেক্ষা — ৮ × (১ + ৯) = ৮০টি thread প্রায় সব core ব্যস্ত রাখে। কিন্তু DB-র connection pool যদি ২০টি হয়, ৮০ thread-এর ৬০টি শুধু pool-এর লাইনে দাঁড়াবে — নিচের সম্পদের সীমাই আসল সীমা। Container-এ “core-সংখ্যা” মানে CPU limit, host-এর nproc নয় (JVM ১০ সংস্করণ থেকে container-এর সীমা নিজে পড়ে)। Bounded queue আর backpressure রাখুন, নইলে অতিরিক্ত লোডে queue অসীম বাড়ে আর latency ফেটে যায় (Little's law: L = λW).

সম্ভাব্য ফলো-আপ: “Pool কেন, প্রতি অনুরোধে নতুন thread কেন নয়?” → তৈরির খরচ আর একসাথে চলা thread-এর সীমা — হঠাৎ লোডে সিস্টেম ডোবে না।

সংক্ষিপ্ত উত্তর: প্রতিটি process নিজের একটি বড়, একটানা ঠিকানা-জগৎ দেখে; MMU প্রতিটি ঠিকানা page table দিয়ে আসল RAM-এর frame-এ অনুবাদ করে। এতে তিনটি লাভ: বিচ্ছিন্নতা (একজন অন্যের মেমরি ছুঁতে পারে না), সুবিধা (প্রতিটি প্রোগ্রাম একই বিন্যাস পায়), আর RAM-এর চেয়ে বেশি মেমরির ভান — যা লাগে শুধু তা-ই RAM-এ।

গভীর উত্তর: Virtual memory-এর ওপর দাঁড়িয়ে আছে demand paging (প্রথম ছোঁয়ায় page আনা), copy-on-write fork, shared library (একই libc-এর page সব process-এ ভাগ), mmap দিয়ে ফাইল পড়া আর swap. খরচ: প্রতিটি ঠিকানা-অনুবাদ — x86-64-এ ৪ স্তরের page table, যা TLB cache করে; TLB miss হলে page walk. তাই TLB-বান্ধব (ঘনিষ্ঠ ঠিকানায়) কোড দ্রুত, আর huge page TLB-র নাগাল বাড়ায় (প্রশ্ন ২৭)।

সম্ভাব্য ফলো-আপ: “Virtual memory মানে কি swap?” → না, swap এর একটি ব্যবহার মাত্র; swap ছাড়াও virtual memory পুরোদমে কাজ করে।

সংক্ষিপ্ত উত্তর: তিন রকম। Minor: ডিস্ক ছাড়াই মেটে — প্রথম ছোঁয়ায় শূন্য page দেওয়া, COW কপি, বা page cache-এ আগে থেকে থাকা ফাইল-page জোড়া। Major: ডিস্ক বা swap থেকে পড়তে হয় — মিলিসেকেন্ডের খরচ। অবৈধ: map না করা বা অনুমতি-ভাঙা ঠিকানা — kernel SIGSEGV পাঠায় (segmentation fault).

গভীর উত্তর: সুস্থ সার্ভারে সেকেন্ডে হাজার হাজার minor fault স্বাভাবিক — প্রতিটি fork, exec, malloc-এর নতুন page-এ এগুলো হয়। সমস্যা হলো major fault-এর হার বাড়া, বিশেষ করে swap-in: তখন latency লাফ দেয়। দেখার জায়গা: /proc/<pid>/stat-এর minflt/majflt, ps -o min_flt,maj_flt, vmstat-এর si/so, আর perf stat -e page-faults,major-faults. লেখা-অনুমতিহীন page-এ লেখাও fault — COW-তে সেটি বৈধ (কপি হয়), শুধু-পড়ার code-এ সেটি SIGSEGV.

সম্ভাব্য ফলো-আপ: “Page fault-এ OS ধাপে ধাপে কী করে?” → trap, ঠিকানা যাচাই, frame জোগাড় (দরকারে replacement), দরকার হলে ডিস্ক থেকে পড়া (ততক্ষণ অন্য process চলে), page table হালনাগাদ, একই instruction আবার।

সংক্ষিপ্ত উত্তর: না। glibc-র malloc বড় অনুরোধ (mmap threshold, শুরুতে ১২৮ KiB, পরে নিজে বদলায়, তার সমান বা বড়) mmap দিয়ে নতুন anonymous এলাকা হিসেবে নেয়; ছোটগুলো brk-এ বাড়ানো heap থেকে। Kernel শুধু ঠিকানার এলাকা (VMA) লিখে রাখে — RAM আসে প্রতিটি page প্রথম ছোঁয়ার সময়, minor fault-এ। তাই VSZ সঙ্গে সঙ্গে বাড়ে, RSS বাড়ে ছোঁয়ার সাথে সাথে।

গভীর উত্তর: Linux ডিফল্টে overcommit করে (vm.overcommit_memory = 0, heuristic): ফাঁকা RAM-এর চেয়ে বেশি চাইলেও malloc সাধারণত সফল হয়, আর আসল ঘাটতি ধরা পড়ে পরে — ছোঁয়ার সময়, তখন OOM killer. তাই “malloc NULL দেয়নি, তবু প্রোগ্রাম মরল” Linux-এ সম্ভব। mmap-এ পাওয়া চাংক free করলে সঙ্গে সঙ্গে munmap হয়ে RAM ফেরত যায়; brk-heap-এর মাঝের ফাঁকা জায়গা সাধারণত process-এর ভেতরেই থাকে, পরের malloc-এ কাজে লাগে। নিচের উদাহরণে দেখুন।

সম্ভাব্য ফলো-আপ: “calloc কেন প্রায়ই malloc + memset-এর চেয়ে দ্রুত?” → mmap-এর নতুন page kernel এমনিতেই শূন্য দেয়, তাই calloc আবার শূন্য লেখা এড়াতে পারে।

সংক্ষিপ্ত উত্তর: সবসময় leak নয়। Allocator ছোট free-করা ব্লক OS-কে ফেরত না দিয়ে নিজের কাছে রাখে (পরে কাজে লাগবে), heap-এর মাঝে fragmentation হয়, আর multithreaded প্রোগ্রামে glibc প্রতি thread-দলের আলাদা arena রাখে। ফলে RSS একটি উঁচু “জোয়ারের দাগে” থেমে থাকে। Leak হলে কিন্তু একই লোডে RSS সময়ের সাথে থামে না।

গভীর উত্তর: পার্থক্য করার উপায়: একই লোড দিয়ে কয়েক ঘণ্টা RSS দেখা — সমতলে থামে, নাকি সরলরেখায় বাড়ে। glibc-তে malloc_trim(0) ডাকলে RSS কমলে সমস্যা allocator-এর ধারণক্ষমতা; MALLOC_ARENA_MAX কমানো বা jemalloc/tcmalloc ব্যবহারে অনেক সময় RSS কমে। মাপ ঠিকমতো নেওয়াও জরুরি: RSS-এ shared library-র ভাগ-করা page-ও গোনা; process-এর নিজের অংশ বুঝতে PSS/USS (/proc/<pid>/smaps_rollup).

সম্ভাব্য ফলো-আপ: “Java/Go-তে?” → GC-ভাষায় heap-এর আকার runtime ঠিক করে, তাই “ব্যবহৃত heap” আর RSS আলাদা মেট্রিক।

সংক্ষিপ্ত উত্তর: VSZ: process-এর সব map করা এলাকার মোট আকার — ছোঁয়া হোক বা না হোক। RSS: এই মুহূর্তে RAM-এ থাকা page, ভাগ-করা page-সহ। PSS: ভাগ-করা page তার অংশীদারের সংখ্যা দিয়ে ভাগ করে গোনা — সব process-এর PSS যোগ করলে মোট ব্যবহৃত RAM-এর কাছাকাছি আসে।

গভীর উত্তর: ২০টি PHP-FPM worker-এর প্রতিটির RSS ১০০ MB দেখালে মোট ২ GB ভাবা ভুল, যদি তার ৬০ MB সবার ভাগ-করা code আর library হয়। ঠিক প্রশ্নের ঠিক মেট্রিক: “এই process বন্ধ করলে কত RAM ফেরত পাব?” → USS (একান্ত নিজের); “মোট খরচে এর ভাগ?” → PSS; “ঠিকানা-জগৎ কত বড়?” → VSZ (Java বা Go-তে প্রায়ই বিশাল, চিন্তার কিছু নয়)। Kubernetes আর cgroup-এর OOM সিদ্ধান্ত হয় cgroup-এর memory.current দিয়ে, যাতে anonymous মেমরি, page cache আর kernel-এর কিছু অংশ থাকে।

সম্ভাব্য ফলো-আপ: “top-এর VIRT, RES, SHR?” → যথাক্রমে VSZ, RSS আর তার ভাগযোগ্য অংশ।

সংক্ষিপ্ত উত্তর: Reclaim (page cache ফেলা, swap) করেও মেমরি জোগানো না গেলে OOM killer চলে — পুরো সিস্টেমে, বা একটি cgroup তার memory.max ছুঁলে শুধু সেই দলের ভেতরে। সে সবচেয়ে বেশি “badness” পয়েন্টের process বাছে — মূলত RSS + swap + page table-এর আকার, যার সাথে oom_score_adj (−১০০০ থেকে +১০০০) যোগ হয় — আর তাকে SIGKILL পাঠায়।

গভীর উত্তর: প্রমাণ মেলে dmesg বা journalctl -k-এ “Out of memory: Killed process …”, আর cgroup-এ memory.events-এর oom_kill গণকে। রক্ষার উপায়: oom_score_adj = -1000 (কখনো বাছা হবে না — শুধু সত্যিই জরুরি daemon-এ, কারণ তখন অন্য কেউ মরবে), systemd-এ OOMScoreAdjust=; আর ভালো সমাধান প্রতিটি সার্ভিসের সীমা (memory.max) আর আগাম সতর্ক সংকেত (memory.high, PSI). systemd-oomd বা Android-এর lmkd-এর মতো user-space daemon kernel-এর আগেই চাপ দেখে ব্যবস্থা নেয়।

সম্ভাব্য ফলো-আপ: “OOM-এ মরা container-এর exit code?” → 137 (প্রশ্ন ৪৩)। “overcommit বন্ধ করলে?” → vm.overcommit_memory = 2-এ malloc আগেই ব্যর্থ হয়, কিন্তু fork-ভারী সিস্টেম কষ্ট পায়।

সংক্ষিপ্ত উত্তর: আগে প্রমাণ — একই লোডে RSS বা heap সময়ের সাথে সরলরেখায় বাড়ছে, GC বা restart ছাড়া কমছে না। তারপর কোন ধরনের মেমরি বাড়ছে (smaps: heap, anonymous mmap, নাকি থ্রেড-stack), তারপর কোন কোড-পথ বরাদ্দ করছে — heap profiler দিয়ে দুই সময়ের snapshot তুলনা।

গভীর উত্তর: C/C++: test পরিবেশে AddressSanitizer-এর LeakSanitizer বা Valgrind (অনেক ধীর); production-এ কম-খরচের heaptrack, jemalloc/tcmalloc-এর heap profiling, বা eBPF-ভিত্তিক memleak (bcc) — শেষেরটি root আর সতর্কতা চায়। Java-য় heap dump (jcmd GC.heap_dump) আর dominator tree; Go-তে pprof-এর heap profile; Node.js-এ heap snapshot. প্রচলিত কারণ: সীমাহীন cache বা map, বন্ধ না হওয়া listener বা callback, থ্রেড বা goroutine leak (প্রতিটি নিজের stack নিয়ে), fd leak (প্রশ্ন ৩৮)। সমাধানের পর একই লোডে আবার মেপে নিশ্চিত হন।

সম্ভাব্য ফলো-আপ: “রোজ restart করলেই তো হয়?” → উপসর্গ ঢাকা; leak-এর হার বাড়লে বিরতিও ছোট হবে, আর কারণ অজানা থাকবে।

সংক্ষিপ্ত উত্তর: x86-64-এ সাধারণ page ৪ KiB, huge page ২ MiB (বা ১ GiB). একটি TLB entry তখন ৫১২ গুণ বেশি মেমরি ঢাকে, আর page walk-এ একটি স্তর কম — বড় working set-এর অ্যাপে (ডেটাবেস, JVM, VM) TLB miss অনেক কমে। দাম: internal fragmentation আর একটানা ২ MiB ফাঁকা RAM জোগাড়ের খরচ।

গভীর উত্তর: দুই পথ: hugetlbfs (আগে থেকে সংরক্ষিত, অনুমানযোগ্য — Oracle আর PostgreSQL-এর huge_pages), আর THP (kernel নিজে, khugepaged দিয়ে পেছনে জোড়া লাগায়)। THP-র ঝুঁকি: page fault-এর সময় বা পেছনে compaction-এ হঠাৎ দেরি (tail latency), আর ছড়ানো ছোট লেখায় fork-এর পর COW-তে পুরো ২ MiB কপি হতে পারা। তাই Redis-এর মতো কিছু ডেটাবেস THP চালু থাকলে সতর্ক বার্তা দেয়। বহু distro এখন /sys/kernel/mm/transparent_hugepage/enabled-এ madvise রাখে — শুধু যে অ্যাপ চায় (madvise(MADV_HUGEPAGE)) সে পায়।

সম্ভাব্য ফলো-আপ: “লাভ হচ্ছে কি না কীভাবে মাপবেন?” → perf stat -e dTLB-load-misses আগে-পরে, আর p99 latency.

সংক্ষিপ্ত উত্তর: সাধারণত না। Linux ফাঁকা RAM ফেলে না রেখে page cache-এ ফাইলের ডেটা রাখে; দরকার হলে পরিষ্কার cache-page সঙ্গে সঙ্গে ফেলে দেওয়া যায়। আসল প্রশ্নের উত্তর “available” কলাম (MemAvailable) — swap ছাড়া নতুন কাজের জন্য আনুমানিক কত মেমরি পাওয়া যাবে।

গভীর উত্তর: উদ্বেগের সংকেত অন্যখানে: available ক্রমাগত কমা, vmstat-এ si/so (swap in/out) নিয়মিত শূন্যের বেশি, major fault বাড়া, PSI-র /proc/pressure/memory-এ “some/full” বাড়া, আর dmesg-এ OOM. echo 3 > /proc/sys/vm/drop_caches-কে “মেমরি খালি করার” সমাধান বলা একটি প্রচলিত ভুল পরামর্শ — cache হারিয়ে পরের পড়াগুলো ডিস্কে যায়, সিস্টেম আরও ধীর হয়।

সম্ভাব্য ফলো-আপ: “buff/cache-এর সবটাই কি ফেলা যায়?” → না; dirty page আগে লিখতে হয়, আর tmpfs/shmem-এর page cache-এ দেখালেও ফেলা যায় না।

সংক্ষিপ্ত উত্তর: Shell fork + exec করে cat চালায় (PATH-এ খুঁজে)। cat ডাকে openat — kernel path ধরে directory-র পর directory খুঁজে (dentry cache-এ, না থাকলে ডিস্কে) inode পায়, অনুমতি যাচাই করে, একটি fd ফেরত দেয়। তারপর read: ডেটা page cache-এ থাকলে সরাসরি কপি, না থাকলে file system ব্লক খুঁজে block layer আর driver-এর মাধ্যমে ডিস্ক থেকে আনে। শেষে write(1, …) দিয়ে terminal-এ, close, exit.

গভীর উত্তর: ডিস্কের পথ: VFS → ext4-এর মতো file system (logical block → ডিস্কের ব্লক, extent দিয়ে) → block layer-এর I/O scheduler → NVMe বা SATA driver → ডিভাইস DMA দিয়ে RAM-এ লেখে → interrupt → ঘুমন্ত cat জাগে। Kernel একসাথে read-ahead করে পরের ব্লকগুলোও আনে। Terminal-এর দিকে: fd 1 একটি pty — লেখা যায় tty line discipline হয়ে terminal emulator-এর কাছে, যে অক্ষর আঁকে। strace cat notes.txt দিয়ে ঠিক এই syscall-ক্রম দেখা যায়।

সম্ভাব্য ফলো-আপ: “দ্বিতীয়বার কেন দ্রুত?” → page cache (প্রশ্ন ৩০)। “ফাইলটি NFS-এ হলে?” → VFS-এর নিচে NFS client, ডিস্কের বদলে নেটওয়ার্ক।

সংক্ষিপ্ত উত্তর: Page cache হলো kernel-এর RAM-এ রাখা ফাইলের page — সব process-এর ভাগ। প্রথম পড়ায় ডিস্ক থেকে এনে রাখা হয়; পরের পড়া শুধু RAM থেকে কপি। লেখাও প্রথমে এখানেই যায় (dirty page), পরে পেছনে ডিস্কে (writeback).

গভীর উত্তর: mmap করা ফাইল আর read() দুজনেই একই page cache দেখে (unified cache). Kernel active/inactive তালিকা দিয়ে কোন page ফেলবে বাছে; তবু ভারী backup-এর মতো বড় একবারের স্ক্যান গরম ডেটা তাড়িয়ে অ্যাপ ধীর করতে পারে। ডেটাবেস প্রায়ই নিজের buffer pool রাখে, তাই কেউ কেউ O_DIRECT দিয়ে page cache এড়ায় (double caching বাঁচাতে)। নিচের উদাহরণে root ছাড়াই page cache-এর অবস্থা মাপা হয়েছে mincore দিয়ে।

সম্ভাব্য ফলো-আপ: “Benchmark-এ cache-এর প্রভাব কীভাবে বাদ দেবেন?” → test মেশিনে drop_caches (root), posix_fadvise(DONTNEED), বা O_DIRECT; আর cold ও warm দুটো আলাদা করে রিপোর্ট করা।

সংক্ষিপ্ত উত্তর: না, নিশ্চিত নয়। write সাধারণত শুধু page cache-এ কপি করে ফেরে; ডিস্কে যায় পরে, writeback-এ। টেকসই (durable) করতে fsync(fd) — যা ফেরে ডেটা আর metadata ডিস্কে পৌঁছানোর পর (ডিস্কের নিজের write cache-ও flush করিয়ে)। fdatasync শুধু দরকারি metadata লেখে, তাই একটু সস্তা।

গভীর উত্তর: নতুন ফাইল তৈরি বা rename-এর পর ফাইলের fsync যথেষ্ট নয় — directory entry-টিও টেকসই করতে directory-র fd-তে fsync লাগে। একটি কনফিগ ফাইল নিরাপদে বদলানোর প্রচলিত ধরন (atomic rename): temp ফাইলে লেখা → fsync(temp) → rename(temp, real) → fsync(directory). crash হলে পুরোনো বা নতুন পুরো ফাইল থাকে, আধা-লেখা নয়। ডেটাবেস ঠিক এভাবে WAL-এর commit-এ fsync করে; তাই commit-এর latency ডিস্কের flush-গতির ওপর নির্ভর করে, আর power-loss protection-ওয়ালা SSD সেখানে বড় পার্থক্য আনে। ২০১৮ সালে PostgreSQL দলের আলোচনায় (“fsyncgate”) সামনে আসে, fsync ব্যর্থ হলে Linux dirty page-কে পরিষ্কার চিহ্ন দিতে পারে — তাই ব্যর্থ fsync-এর পর আবার চেষ্টাকে সফলতা ধরা নিরাপদ নয়।

সম্ভাব্য ফলো-আপ: “ext4-এ data=ordered কী দেয়?” → নতুন বরাদ্দ ব্লকে আগে ডেটা, তারপর metadata commit — জঞ্জাল দেখা যায় না, কিন্তু fsync-এর বিকল্প নয়।

সংক্ষিপ্ত উত্তর: Inode হলো ফাইলের আসল রেকর্ড — আকার, মালিক, অনুমতি, সময়, link count আর ডেটা-ব্লকের ঠিকানা; ফাইলের নাম থাকে না। নাম থাকে directory entry-তে, যা নাম → inode নম্বর জোড়ে। Hard link একই inode-এর আরেকটি নাম (link count বাড়ে, একই file system-এ, directory-র জন্য নয়); symlink একটি আলাদা ছোট ফাইল, যার ভেতরে একটি path লেখা — অন্য file system বা directory-কেও দেখাতে পারে, লক্ষ্য মুছলে ঝুলে যায়।

গভীর উত্তর: rm আসলে unlink: একটি নাম মোছে আর link count কমায়। ডেটা মুক্ত হয় তখনই, যখন link count শূন্য এবং কোনো process ফাইলটি খোলা রাখেনি। তাই চলমান সার্ভিসের log মুছলে ডিস্কের জায়গা ফেরত আসে না (প্রশ্ন ৩৩)। Directory-র hard link নিষেধ, কারণ তাতে cycle তৈরি হতো — গাছ-ঘোরা অসীম হতো আর reference count দিয়ে জায়গা ফেরত আনা যেত না।

সম্ভাব্য ফলো-আপ: “mv একই file system-এ কেন তাৎক্ষণিক?” → শুধু directory entry বদলায়, ডেটা সরে না; অন্য file system-এ হলে কপি + মোছা।

সংক্ষিপ্ত উত্তর: প্রথম ক্ষেত্রে সম্ভবত inode ফুরিয়েছে — লাখো ছোট ফাইল (session, cache) — df -i দেখুন। দ্বিতীয় ক্ষেত্রে সাধারণত মুছে ফেলা কিন্তু এখনো খোলা ফাইল: du নাম ধরে গোনে, তাই নামহীন ফাইল দেখে না; df file system-এর আসল ব্যবহার দেখায়।

গভীর উত্তর: খোলা-মোছা ফাইল খুঁজতে: lsof +L1, বা ls -l /proc/*/fd 2>/dev/null | grep deleted. সমাধান: সেই process-কে log আবার খুলতে বলা (অনেক daemon SIGHUP-এ করে, logrotate-এর postrotate), বা restart; জরুরি অবস্থায় : > /proc/PID/fd/N দিয়ে ফাইলটি ছোট করা যায়। অন্য কারণ: ext4 root-এর জন্য ডিফল্টে প্রায় ৫% ব্লক সংরক্ষিত রাখে, কোটা, বা একটি directory-র ওপর অন্য file system mount হয়ে নিচের ফাইল ঢেকে গেছে।

সম্ভাব্য ফলো-আপ: “ভবিষ্যতে ঠেকাবেন কীভাবে?” → logrotate-এ copytruncate বা সংকেত দিয়ে আবার খোলা, ডিস্ক আর inode দুটোরই সতর্ক-সংকেত।

সংক্ষিপ্ত উত্তর: select আর poll প্রতিবার পুরো fd-তালিকা kernel-এ পাঠায়, kernel প্রতিটি দেখে — খরচ O(n), হাজার connection-এ ভারী (select-এ সাধারণত ১০২৪ fd-এর সীমাও আছে)। epoll-এ তালিকা kernel-এ একবার নিবন্ধন হয়, আর epoll_wait শুধু প্রস্তুত fd ফেরত দেয় — খরচ প্রস্তুত fd-এর সংখ্যার অনুপাতে।

গভীর উত্তর: Level-triggered (ডিফল্ট): যতক্ষণ পড়ার ডেটা আছে, প্রতিবার জানায় — ভুল কম হয়। Edge-triggered (EPOLLET): শুধু অবস্থা বদলের মুহূর্তে জানায়; অর্ধেক পড়ে থামলে নতুন ডেটা না আসা পর্যন্ত আর খবর নেই — তাই fd non-blocking রেখে EAGAIN না পাওয়া পর্যন্ত পড়তে হয়। অনেক thread একই fd-তে অপেক্ষা করলে thundering herd এড়াতে EPOLLEXCLUSIVE বা প্রতি-thread আলাদা listen socket (SO_REUSEPORT). BSD/macOS-এ সমতুল্য kqueue, Windows-এ completion-মডেলের IOCP. সাধারণ ফাইলে epoll কাজে আসে না — epoll_ctl EPERM দেয়, কারণ ডিস্কের ফাইল কখনো “অপ্রস্তুত” হয় না।

সম্ভাব্য ফলো-আপ: “epoll কবে এসেছে?” → Linux ২.৫/২.৬-এর সময়, ২০০২-এর আশেপাশে; nginx, Redis, libuv এর ওপর দাঁড়িয়ে।

সংক্ষিপ্ত উত্তর: io_uring (Linux ৫.১, ২০১৯) একটি completion-ভিত্তিক async I/O: অ্যাপ আর kernel-এর মধ্যে ভাগ-করা দুটি ring buffer — submission queue-তে অনুরোধ রাখা হয়, completion queue-তে ফল আসে। এক system call-এ অনেক অনুরোধ জমা দেওয়া যায়, আর সাধারণ ফাইলেও সত্যিকারের async I/O হয়, যা epoll পারে না।

গভীর উত্তর: IORING_SETUP_SQPOLL-এ একটি kernel thread submission ring poll করে, তাই কোনো system call-ই লাগে না; buffer আর fd আগে থেকে register করলে প্রতিবার page pin বা fd খোঁজার খরচ বাঁচে। দাম: kernel-এর বড় নতুন attack surface — এর বাগ নিয়ে বেশ কিছু নিরাপত্তা-সমস্যা প্রকাশ পেয়েছে, তাই কিছু পরিবেশ (যেমন কিছু container runtime-এর ডিফল্ট seccomp নীতি বা কিছু distro) এটি সীমিত বা বন্ধ রাখে। POSIX aio_* glibc-তে ভেতরে thread দিয়ে চলে, তাই আসল async নয়।

সম্ভাব্য ফলো-আপ: “Readiness বনাম completion?” → epoll: “এখন পড়া যাবে”, তারপর অ্যাপ নিজে read করে; io_uring/IOCP: “পড়া হয়ে গেছে, ফল তৈরি”।

সংক্ষিপ্ত উত্তর: File descriptor একটি ছোট পূর্ণসংখ্যা — process-এর fd টেবিলের একটি সূচক, যা kernel-এর একটি open file description দেখায় (offset, mode, flag), সেটি আবার inode দেখায়। fork আর dup-এর পর দুই fd একই description ভাগ করে, তাই offset-ও ভাগ — দুজনের লেখা পাশাপাশি জোড়ে, একে অন্যকে মুছে না।

গভীর উত্তর: একই ফাইল দুবার open করলে দুটি আলাদা description, আলাদা offset — দুজন একসাথে লিখলে একে অন্যের লেখা ঢেকে দিতে পারে; log-এর জন্য O_APPEND নিশ্চিত করে প্রতিটি write শেষে বসবে। নতুন fd সবসময় সবচেয়ে ছোট খালি নম্বর পায় — shell-এর redirect এই নিয়মের ওপর দাঁড়িয়ে। fd শুধু ফাইল নয়: socket, pipe, eventfd, timerfd, epoll — “সবকিছুই ফাইল” Unix-দর্শন। Windows-এ সমতুল্য handle, যা যেকোনো kernel object-এর জন্য।

সম্ভাব্য ফলো-আপ: “fd 0, 1, 2?” → stdin, stdout, stderr. “একটি process-এর খোলা fd কীভাবে দেখবেন?” → ls -l /proc/PID/fd বা lsof -p PID.

সংক্ষিপ্ত উত্তর: না। send/write সফল মানে শুধু ডেটা kernel-এর socket buffer-এ (send buffer) কপি হয়েছে; kernel-এর TCP stack পরে পাঠাবে, হারালে আবার পাঠাবে। অপর পক্ষের অ্যাপ পড়েছে কি না জানার একমাত্র উপায় application-স্তরের উত্তর (ack).

গভীর উত্তর: প্রতিটি TCP socket-এর একটি send আর একটি receive buffer; Linux এগুলোর আকার নিজে বদলায় (autotuning, net.ipv4.tcp_rmem/tcp_wmem-এর সীমার ভেতরে)। Send buffer ভরলে blocking socket-এ send থামে, non-blocking-এ EAGAIN — এটাই প্রাকৃতিক backpressure. Receive buffer ভরলে TCP window ছোট হয়ে প্রেরককে ধীর করে।ss -tm প্রতিটি socket-এর buffer আর queue দেখায়; Recv-Q বাড়তে থাকা মানে অ্যাপ যথেষ্ট দ্রুত পড়ছে না।

সম্ভাব্য ফলো-আপ: “close() করলে না-পাঠানো ডেটা?” → kernel পেছনে পাঠাতে থাকে (SO_LINGER না দিলে); receive buffer-এ না-পড়া ডেটা থাকলে কিন্তু RST যেতে পারে।

সংক্ষিপ্ত উত্তর: Process তার fd-সীমা (RLIMIT_NOFILE, ulimit -n) ছুঁয়েছে — প্রতিটি socket, ফাইল আর pipe একটি করে fd নেয়। আগে দেখুন সত্যিই এত connection লাগে, নাকি fd leak (বন্ধ না করা socket বা ফাইল): ls /proc/PID/fd | wc -l সময়ের সাথে বাড়ছে কি না।

গভীর উত্তর: সীমা দুটি: soft (চলতি, process নিজে hard পর্যন্ত বাড়াতে পারে) আর hard (শুধু বিশেষ অধিকারে বাড়ে)। অনেক distro-তে login shell-এ soft ডিফল্ট ১০২৪। systemd সার্ভিসে সীমা আসে unit-এর LimitNOFILE= থেকে, shell-এর ulimit বা /etc/security/limits.conf থেকে নয় — এটি একটি পরিচিত ফাঁদ। চলমান process-এর সীমা দেখতে cat /proc/PID/limits. পুরো সিস্টেমের সীমা আলাদা: fs.file-max (তখন ত্রুটি ENFILE). Leak হলে সীমা বাড়ানো শুধু দেরি করায়। নিচের উদাহরণে সীমা ১৬ করে ঠিক কোথায় EMFILE আসে, দেখুন।

সম্ভাব্য ফলো-আপ: “fd-সংখ্যা বাড়লে কোন kernel সম্পদ খরচ হয়?” → প্রতিটি open file বা socket-এর kernel struct আর socket buffer — তাই সীমা বাড়ানোর সাথে মেমরিও ভাবুন।

সংক্ষিপ্ত উত্তর: C10K — এক সার্ভারে একসাথে ১০,০০০ client সামলানো। Dan Kegel ১৯৯৯ সালে এই নামে একটি লেখায় প্রশ্নটি তোলেন। তখনকার প্রচলিত নকশা — প্রতি connection-এ একটি process বা thread আর select/poll — এত connection-এ মেমরি আর CPU-তে ডুবে যেত। সমাধান এসেছে OS আর নকশা মিলে: epoll/kqueue-এর মতো O(প্রস্তুত) multiplexing, non-blocking socket আর event-driven সার্ভার।

গভীর উত্তর: সাথে আরও কিছু kernel-উন্নতি: সস্তা thread (NPTL), sendfile-এর মতো zero-copy, accept-এর thundering herd কমানো, SO_REUSEPORT দিয়ে প্রতি core-এ আলাদা listen socket, আর NIC-এর একাধিক queue ও RSS. আজ লাখো connection সাধারণ, যেখানে সীমা হয় fd-সীমা, প্রতি socket-এর buffer-মেমরি, ephemeral port (একটি client থেকে একটি গন্তব্যে), আর conntrack টেবিল। চরম ক্ষেত্রে kernel-কে পাশ কাটানো (DPDK) বা XDP.

সম্ভাব্য ফলো-আপ: “অনেক TIME_WAIT socket দেখলে?” → যে পক্ষ আগে বন্ধ করে, সে-ই TIME_WAIT-এ থাকে (Linux-এ ৬০ সেকেন্ড); সাধারণত ক্ষতিকর নয়, তবে outgoing connection-ভারী client-এ port ফুরাতে পারে — connection reuse (keep-alive, pool) আসল সমাধান।

সংক্ষিপ্ত উত্তর: কীবোর্ডের interrupt থেকে ব্রাউজারের event loop; তারপর নাম থেকে IP (ব্রাউজারের cache, তারপর OS-এর resolver — /etc/hosts, তারপর DNS server-এ UDP); socket + connect — kernel-এর TCP stack handshake করে; TLS চলে user space-এর লাইব্রেরিতে; send/recv-এ ডেটা socket buffer, driver আর NIC-এর DMA পেরোয়; শেষে GPU আর compositor দিয়ে পাতা পর্দায়।

গভীর উত্তর: নিচের stepper ধাপে ধাপে দেখায়। শুরুতেই বলে নিন আপনি OS-এর দিকটি বলছেন (process, syscall, resolver, socket, buffer, interrupt, cache), আর জিজ্ঞেস করুন DNS বা TCP-র প্রোটোকল-খুঁটিনাটিতে যাবেন কি না — সেটি নেটওয়ার্ক কোর্সের বিষয়। OS-ভেদে resolver আলাদা: Linux-এ glibc-র getaddrinfo (/etc/nsswitch.conf মেনে), Windows-এ DNS Client সার্ভিস, macOS-এ mDNSResponder; কিছু ব্রাউজার নিজস্ব resolver বা DNS-over-HTTPS-ও ব্যবহার করে।

সম্ভাব্য ফলো-আপ: “getaddrinfo blocking — ব্রাউজার বা Node.js কী করে?” → আলাদা thread-এ চালায় (libuv-এর thread pool) বা নিজের async resolver.

সংক্ষিপ্ত উত্তর: VM-এ hypervisor নকল হার্ডওয়্যার দেয়, আর প্রতিটি VM নিজের পুরো kernel চালায়। Container হলো host-এর একই kernel-এ চলা সাধারণ process — namespace দিয়ে আলাদা দেখানো আর cgroup দিয়ে সীমিত। তাই container হালকা আর মুহূর্তে চালু হয়; VM-এর সীমানা শক্ত, আর ভিন্ন OS চালানো যায়।

গভীর উত্তর: Container-এর ভেতর থেকে uname -r host-এর kernel দেখায় — Linux container-এ Windows চলে না (Docker Desktop macOS আর Windows-এ ভেতরে একটি Linux VM চালায়)। একটি kernel বাগ সব container-কে ঝুঁকিতে ফেলে, তাই অবিশ্বস্ত বহু-গ্রাহকের কাজে microVM (Firecracker) বা gVisor-এর মতো মাঝামাঝি পথ। সিদ্ধান্ত: একই দলের অনেক সার্ভিস ঘন করে চালাতে container; কঠোর বিচ্ছিন্নতা, ভিন্ন kernel বা পুরো OS লাগলে VM; প্রায়ই দুটো একসাথে — cloud VM-এর ভেতরে container.

সম্ভাব্য ফলো-আপ: “Hypervisor type 1 আর type 2?” → type 1 সরাসরি হার্ডওয়্যারে (ESXi, Xen, Hyper-V), type 2 একটি host OS-এর অ্যাপ হিসেবে (VirtualBox); KVM দুই দলেই ফেলার যুক্তি আছে।

সংক্ষিপ্ত উত্তর: Namespace ঠিক করে process কী দেখে; cgroup ঠিক করে কতটা ব্যবহার করতে পারে আর তার হিসাব রাখে। Linux-এ namespace আটটি: PID, mount, network, UTS (hostname), IPC, user, cgroup আর time.

গভীর উত্তর: PID namespace-এ container-এর প্রথম process নিজেকে PID 1 দেখে; network namespace-এ নিজের interface, route আর port (host-এর সাথে veth জোড়া দিয়ে যুক্ত); user namespace-এ ভেতরের UID 0 বাইরের একজন সাধারণ user-এ map হতে পারে (rootless). cgroup v2-এ এক গাছ, প্রতিটি দলে controller-এর ফাইল: cpu.max, cpu.weight, memory.max, memory.high, pids.max, io.max. একটি সতর্কতা: /proc/meminfo, /proc/stat আর nproc-এর অনেক সংখ্যা namespace মানে না, পুরো host-এর ছবি দেখায় — container-এর আসল সীমা cgroup ফাইলে (নিচের উদাহরণ)। tool হিসেবে unshare, nsenter, lsns.

সম্ভাব্য ফলো-আপ: “chroot কি container?” → না; শুধু path-এর মূল বদলায়, PID, নেটওয়ার্ক, UID বা সম্পদ আলাদা করে না।

সংক্ষিপ্ত উত্তর: 137 = ১২৮ + ৯ — process-টি SIGKILL-এ মরেছে। সবচেয়ে সাধারণ কারণ মেমরি-সীমা: cgroup-এর memory.max ছুঁয়ে OOM kill (Kubernetes-এ OOMKilled). দ্বিতীয় সাধারণ কারণ: graceful সময় শেষে runtime-এর SIGKILL (docker stop-এর ১০ সেকেন্ড, বা liveness probe ব্যর্থ হয়ে restart).

গভীর উত্তর: প্রমাণ খুঁজুন: kubectl describe pod-এ “Last State: Terminated, Reason: OOMKilled”; docker inspect-এ State.OOMKilled; node-এ dmesg-এ “Memory cgroup out of memory”; cgroup-এর memory.events-এ oom_kill বাড়া। তারপর কেন: আসল চাহিদা কি limit-এর বেশি (লোডে মাপুন), leak (প্রশ্ন ২৬), নাকি runtime limit জানে না — যেমন পুরোনো JVM-এর heap limit-এর কাছাকাছি বা বেশি, যার ওপর thread stack, metaspace আর native মেমরি যোগ হয়। এককের ভুলও হয়: 512M (১০^৬) আর 512Mi (২^২০) আলাদা।

সম্ভাব্য ফলো-আপ: “OOMKilled না দেখালেও 137?” → node-এর মেমরি-চাপে kubelet-এর eviction, বা কেউ হাতে kill -9 — event আর node-এর log দেখুন।

সংক্ষিপ্ত উত্তর: CPU limit হয় CFS bandwidth control-এর কোটা: প্রতি period-এ (ডিফল্ট ১০০ ms) মোট এত CPU-সময়। limits.cpu: 500m মানে cpu.max = "50000 100000" — প্রতি ১০০ ms-এ ৫০ ms. কোটা period-এর শুরুতেই শেষ হলে বাকি সময় পুরো দল থেমে থাকে — throttling. গড় কম হলেও ছোট ছোট বিস্ফোরণে latency লাফ দেয়।

গভীর উত্তর: হিসাব: ৫০ ms কোটা, ৪টি thread একসাথে পুরো CPU-নির্ভর কাজ শুরু করল ৪টি ফাঁকা core-এ — ৫০ ÷ ৪ = ১২.৫ ms-এ কোটা শেষ, তারপর period-এর বাকি ১০০ − ১২.৫ = ৮৭.৫ ms চারটিই throttled. সেই ফাঁকে আসা অনুরোধ ৮৭.৫ ms পর্যন্ত অপেক্ষা করে। অথচ এমন বিস্ফোরণ প্রতি চারটি period-এ একবার হলে গড় ব্যবহার ৫০ ÷ ৪০০ = ০.১২৫ CPU — limit-এর মাত্র ২৫%. প্রমাণ: cgroup-এর cpu.stat-এ nr_throttled আর throttled_usec বাড়ছে। প্রতিকার: thread-সংখ্যা limit-এর সাথে মেলানো (GOMAXPROCS, JVM-এর CPU-গণনা, worker-সংখ্যা — নতুন Go আর JVM container-এর সীমা নিজে পড়ে), limit বাড়ানো বা latency-সংবেদনশীল সার্ভিসে CPU limit না দিয়ে শুধু request (cpu.weight) রাখা — এ নিয়ে দলভেদে মত আলাদা।

সম্ভাব্য ফলো-আপ: “Request আর limit-এর পার্থক্য?” → request দিয়ে scheduler node বাছে আর CPU-র ভাগ (weight) ঠিক হয়; limit cgroup-এ কড়া সীমা — CPU-তে throttling, মেমরিতে OOM kill.

সংক্ষিপ্ত উত্তর: Container-এর ভেতরে আপনার অ্যাপ PID 1. Linux-এ PID namespace-এর init-কে kernel আলাদা চোখে দেখে: যে signal-এর handler সে বসায়নি, তার ডিফল্ট কাজ (মরে যাওয়া) প্রয়োগ হয় না — SIGTERM চুপচাপ উপেক্ষিত। Docker ১০ সেকেন্ড অপেক্ষা করে SIGKILL পাঠায় — exit 137.

গভীর উত্তর: আরেকটি সাধারণ কারণ shell-রূপের CMD node app.js — তখন PID 1 হয় /bin/sh -c, যে signal child-কে পাঠায় না। সমাধান: exec-রূপ CMD ["node", "app.js"], অ্যাপে SIGTERM handler, অথবা একটি ছোট init — tini বা docker run --init — যে signal সামনে পাঠায় আর orphan-দের reap করে (zombie জমা ঠেকায়, প্রশ্ন ০৫)। PID 1 মরলে namespace-এর বাকি সবাই SIGKILL পায়।

সম্ভাব্য ফলো-আপ: “Kubernetes-এ graceful shutdown?” → preStop hook, readiness ব্যর্থ করে ট্রাফিক সরানো, তারপর SIGTERM; সময় terminationGracePeriodSeconds.

সংক্ষিপ্ত উত্তর: আংশিক। সব container একই kernel ভাগ করে, তাই kernel-এর একটি বাগ বা ভুল কনফিগ (privileged container, host-এর Docker socket mount) পুরো host-কে ঝুঁকিতে ফেলে। VM-এর সীমানা তুলনায় শক্ত। Container-কে শক্ত করা হয় স্তরে স্তরে: root নয় এমন user, কম capability, seccomp, MAC আর read-only file system.

গভীর উত্তর: ব্যবহারিক তালিকা: ভেতরে non-root user (বা rootless runtime, যেখানে ভেতরের root বাইরে সাধারণ user); --cap-drop=ALL আর শুধু দরকারিগুলো ফেরত; ডিফল্ট seccomp profile চালু রাখা; AppArmor বা SELinux; --read-only root আর no-new-privileges; --privileged আর /var/run/docker.sock mount এড়ানো; সম্পদ-সীমা (pids.max fork-বোমা ঠেকায়)। অবিশ্বস্ত কোডে gVisor (user-space kernel) বা Kata/Firecracker (microVM).

সম্ভাব্য ফলো-আপ: “Docker socket mount কেন বিপজ্জনক?” → সেটি দিয়ে নতুন privileged container চালানো যায় — কার্যত host-এর root.

সংক্ষিপ্ত উত্তর: Linux-এ load average চলমান আর চলতে-চাওয়া task-এর সাথে D-অবস্থার (uninterruptible sleep) task-ও গোনে। তাই অনেক task ডিস্ক, NFS বা অন্য ধীর I/O-তে আটকে থাকলে CPU অলস থেকেও load বিশাল হয়। পরের ধাপ: vmstat-এর b কলাম, ps-এ D-অবস্থার task আর iostat.

গভীর উত্তর: এটি Linux-এর নিজস্ব সিদ্ধান্ত — অন্য অনেক Unix শুধু CPU-র চাহিদা গোনে। Load একটি exponentially-damped চলমান গড় (১, ৫, ১৫ মিনিট), CPU-সংখ্যার সাথে তুলনা করে পড়তে হয়। কারণের তালিকা: saturated ডিস্ক, সাড়া না দেওয়া NFS server (hard mount-এ task অনির্দিষ্টকাল D-তে), ব্যর্থ-হতে-থাকা ডিস্ক (dmesg-এ I/O error), বা kernel-এর lock-এ আটকে থাকা। PSI (/proc/pressure/{cpu,memory,io}) সরাসরি বলে কোন সম্পদের জন্য task-রা সময় হারাচ্ছে — load-এর চেয়ে স্পষ্ট সংকেত।

সম্ভাব্য ফলো-আপ: “D-অবস্থার task মারা যায় না কেন?” → kernel I/O-র মাঝখানে তাকে signal-এ জাগাতে পারে না; নতুন kernel-এ কিছু অপেক্ষা TASK_KILLABLE — শুধু মারাত্মক signal-এ জাগে।

সংক্ষিপ্ত উত্তর: আগে কোন process আর কোন thread (top -H, pidstat -t 1), আর user না kernel সময় (us বনাম sy). তারপর sampling profiler: perf top -p PID সরাসরি, বা perf record -F 99 -g -p PID -- sleep 30 নিয়ে flame graph — সবচেয়ে চওড়া চ্যাপ্টা মাথাটি আসল খরচ।

গভীর উত্তর: perf নির্দিষ্ট হারে stack-এর নমুনা নেয়, তাই খরচ কম আর production-এ সাবধানে চলে। stack ঠিকমতো পেতে frame pointer বা debug symbol লাগে; JIT-ভাষায় (Java, Node.js) symbol map লাগে (যেমন Node-এ --perf-basic-prof). sy বেশি হলে syscall-ঝড় বা lock-প্রতিযোগিতা — perf trace -s বা strace -c -p (strace ভারী, অল্প সময়ের জন্য)। “CPU ১০০%” মানেই হিসাব নয় — মেমরির অপেক্ষাও CPU-সময়; perf stat-এ IPC (instructions per cycle) কম হলে cache miss দায়ী। Spinlock বা ব্যস্ত লুপে থাকা thread-ও ১০০% দেখায়।

সম্ভাব্য ফলো-আপ: “Flame graph-এর x-অক্ষ সময়?” → না; নমুনার অনুপাত, ফ্রেমগুলো সাধারণত বর্ণানুক্রমে। “অপেক্ষার সময় কোথায় যায়?” → off-CPU analysis.

সংক্ষিপ্ত উত্তর: iostat -xz 1-এ প্রতি ডিভাইসে: r/s আর w/s (IOPS), rkB/s আর wkB/s (throughput), r_await আর w_await (গড় অপেক্ষা + সেবার সময়, ms), aqu-sz (গড় সারির দৈর্ঘ্য) আর %util. await-এর স্বাভাবিক মানের সাথে তুলনা আর সারি বাড়ছে কি না — এ দুটিই মূল সংকেত।

গভীর উত্তর: %util শুধু বলে সময়ের কত অংশে অন্তত একটি অনুরোধ চলছিল; একসাথে বহু অনুরোধ সামলানো NVMe বা RAID-এ ১০০% মানেই ভরপুর নয়। Cloud volume-এ প্রায়ই IOPS বা throughput-এর কোটা থাকে — কোটায় পৌঁছালে await লাফ দেয়, যদিও ডিভাইস নিজে দ্রুত। কে I/O করছে: pidstat -d 1 বা iotop; latency-র বণ্টন দেখতে eBPF-এর biolatency. ডিস্কের নিজের সমস্যা: dmesg-এ I/O error, smartctl. অ্যাপের দিকে: ছোট ছোট sync লেখা (প্রতিটিতে fsync) ডিস্ককে IOPS-এ আটকে দেয় — batch বা group commit সাহায্য করে।

সম্ভাব্য ফলো-আপ: “HDD-তে random বনাম sequential?” → random I/O-তে seek আর rotation প্রায় পুরো সময় নেয় (7200 RPM-এ গড় rotation প্রায় ৪.১৭ ms), তাই IOPS শ’খানেকের ঘরে।

সংক্ষিপ্ত উত্তর: প্রথমে লক্ষণ পরিষ্কার করা (কী ধীর, কার জন্য, কতটা, কবে থেকে, কী বদলেছে), তারপর baseline-এর সাথে তুলনা, তারপর USE method — CPU, মেমরি, ডিস্ক আর নেটওয়ার্কের প্রতিটিতে utilization, saturation, error — ৬০ সেকেন্ডের চেকলিস্টে, তারপর সন্দেহের দিকে গভীর টুল, একবারে একটি পরিবর্তন আর আবার মাপা।

গভীর উত্তর: কমান্ডের ক্রম, প্রতিটির সাথে কী খুঁজছেন বলে বলে: uptime (load আর প্রবণতা) → dmesg -T | tail (OOM, I/O error, throttling) → vmstat 1 (r, b, si/so, us/sy/wa/st) → mpstat -P ALL 1 (একটি CPU কি একাই ভরা — একটি thread বা interrupt) → pidstat 1 → iostat -xz 1 → free -m → sar -n DEV,TCP,ETCP 1 (নেটওয়ার্ক, retransmit) → top. VM-এ steal বেশি হলে প্রতিবেশীর ভিড়; container-এ cgroup-এর throttling আর memory events. উপরের stepper এর একটি পূর্ণ উদাহরণ। শেষে বলুন কীভাবে আবার না ঘটে — alert, capacity, postmortem.

সম্ভাব্য ফলো-আপ: “সব সংখ্যা স্বাভাবিক, তবু ধীর?” → সমস্যা নিচের নির্ভরতায় (DB, DNS, বাইরের API) বা অ্যাপের ভেতরে lock — distributed trace আর off-CPU analysis.

সংক্ষিপ্ত উত্তর: ps -o stat,wchan:32 -p PID — S (কিছুর অপেক্ষায়), D (I/O-তে), T (থামানো)? তারপর user-space-এর stack: gdb -p PID → thread apply all bt (বা eu-stack, Java-য় jstack), আর কোন syscall-এ আটকে: strace -p PID (অল্প সময়ের জন্য)। root থাকলে kernel-এর দিকের stack /proc/PID/stack-এ।

গভীর উত্তর: সাধারণ ছবি: সব thread futex_wait-এ — lock-এর deadlock বা হারানো signal (প্রশ্ন ১৩, ১৬); read-এ একটি socket-এ — অপর পক্ষ উত্তর দিচ্ছে না, আর timeout নেই; epoll_wait-এ — event loop স্বাভাবিক অলস, সমস্যা অন্যখানে; pipe-এর write-এ — পাঠক পড়ছে না, buffer ভরা; D-তে nfs_* — NFS server. ls -l /proc/PID/fd দিয়ে দেখুন ওই fd কোন ফাইল বা socket. তদন্তের সময় core dump (gcore) রেখে দিন, তারপর restart — প্রমাণ হারায় না।

সম্ভাব্য ফলো-আপ: “strace বা gdb attach করতে অনুমতি না পেলে?” → kernel.yama.ptrace_scope আর CAP_SYS_PTRACE — নিরাপত্তার জন্যই সীমিত।

সংক্ষিপ্ত উত্তর: Setuid bit-ওয়ালা প্রোগ্রাম exec হলে process-এর effective UID হয় ফাইলের মালিক — সাধারণ user-ও সাময়িকভাবে মালিকের অধিকার পায়। উদাহরণ passwd: root-এর /etc/shadow বদলাতে হয়, আর real UID দিয়ে বোঝে কার পাসওয়ার্ড বদলাচ্ছে। ঝুঁকি: এমন প্রোগ্রামের একটি বাগ মানে সরাসরি root-এর অধিকার।

গভীর উত্তর: তাই setuid প্রোগ্রাম যত কম তত ভালো, আর যেগুলো আছে সেগুলো কাজ শেষে দ্রুত অধিকার ছাড়ে, environment বিশ্বাস করে না। Linux script-এর (#!) setuid bit মানে না — race-এর ঝুঁকি বেশি বলে। যাচাই: find / -perm -4000 -type f 2>/dev/null দিয়ে তালিকা নিয়ে অপ্রত্যাশিত কিছু আছে কি না দেখা; ব্যবহারকারীর লেখা যায় এমন file system nosuid দিয়ে mount. আধুনিক বিকল্প: পুরো root-এর বদলে নির্দিষ্ট capability (যেমন ping-এ শুধু CAP_NET_RAW, বা unprivileged ICMP socket), বা একটি ছোট privileged সার্ভিস।

সম্ভাব্য ফলো-আপ: “Directory-তে setgid আর sticky bit?” → setgid: নতুন ফাইল directory-র group পায় (দলের ভাগ-করা ফোল্ডার); sticky (/tmp-এর 1777): শুধু মালিক নিজের ফাইল মুছতে পারেন।

সংক্ষিপ্ত উত্তর: Least privilege: প্রতিটি অংশ শুধু নিজের কাজের ন্যূনতম অধিকার পাবে। সার্ভিস নিজের আলাদা অ-root user-এ চলবে, শুধু নিজের ফাইলে লিখতে পারবে, দরকারি port আর নেটওয়ার্ক-পথ ছাড়া কিছু পাবে না, আর secret পাবে শুধু যেগুলো তার দরকার।

গভীর উত্তর: systemd unit-এ কয়েক লাইনেই অনেকটা: User=, NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, PrivateTmp=yes, CapabilityBoundingSet=, SystemCallFilter=@system-service, ReadWritePaths=; systemd-analyze security একটি unit কতটা খোলা তার মূল্যায়ন দেখায়। ৮০ বা ৪৪৩ port-এ বসতে root নয় — শুধু CAP_NET_BIND_SERVICE, বা সামনে একটি reverse proxy. ডেটাবেস-user-কেও শুধু দরকারি টেবিলের অধিকার। ফাইলের অনুমতি: সাধারণ ফাইল 644 বা 640, secret 600, directory 755/750 — কখনো 777 নয়।

সম্ভাব্য ফলো-আপ: “chmod 777 দিলে ‘Permission denied’ চলে যায় — সমস্যা কী?” → যে কেউ ফাইল বদলাতে বা বদলে দিয়ে কোড চালাতে পারে; ঠিক সমাধান হলো সঠিক মালিক বা group আর ন্যূনতম bit.

সংক্ষিপ্ত উত্তর: NX (W^X): ডেটার page (stack, heap) থেকে কোড চালানো আটকায়। ASLR: stack, heap, library আর (PIE হলে) প্রোগ্রামের ঠিকানা প্রতিবার এলোমেলো — আক্রমণকারী কোন ঠিকানায় লাফাবে আগে জানে না। Stack canary: ফেরার ঠিকানার আগে একটি গোপন মান; একটানা উপচে পড়া লেখা সেটি বদলালে ফেরার আগেই প্রোগ্রাম থামে।

গভীর উত্তর: এগুলো স্তরে স্তরে কাজ করে, কোনোটিই একা যথেষ্ট নয় — যেমন একটি ঠিকানা ফাঁস হলে ASLR দুর্বল হয়, তাই CFI আর shadow stack-এর মতো নতুন প্রতিরক্ষা। যাচাই: cat /proc/sys/kernel/randomize_va_space (2 = পূর্ণ), একই প্রোগ্রাম দুবার চালিয়ে /proc/self/maps-এর ঠিকানা তুলনা; binary-র সুরক্ষা দেখতে checksec বা readelf; compile-এ -fstack-protector-strong, -D_FORTIFY_SOURCE, -fPIE -pie, linker-এ RELRO. Kernel নিজের জন্য KASLR, SMEP আর SMAP ব্যবহার করে। মূল সমাধান অবশ্য memory-safe কোড — Rust, bounds-checking, sanitizer দিয়ে টেস্ট।

সম্ভাব্য ফলো-আপ: “Debug করার সময় ASLR বিরক্ত করে?” → gdb ডিফল্টে নিজের চালানো প্রোগ্রামে এটি বন্ধ রাখে; production-এ বন্ধ করা উচিত নয়।

সংক্ষিপ্ত উত্তর: ঐতিহ্যগত Unix-এ UID 0 সব পারে। Linux সেই সর্বশক্তিকে কয়েক ডজন capability-তে ভাগ করেছে — CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, CAP_NET_ADMIN ইত্যাদি — তাই একটি process-কে পুরো root-এর বদলে শুধু দরকারি টুকরো দেওয়া যায়। seccomp আরেক স্তর: process কোন system call ডাকতে পারবে, তার তালিকা — বাকিগুলো ব্যর্থ বা process মরে।

গভীর উত্তর: Capability দেওয়া যায় ফাইলে (setcap cap_net_bind_service=+ep ./server, দেখতে getcap) বা systemd/Docker-এর কনফিগে; চলমান process-এর অবস্থা /proc/PID/status-এর CapEff লাইনে (capsh --decode). CAP_SYS_ADMIN এত কিছু খোলে যে একে প্রায় “নতুন root” বলা হয় — এড়িয়ে চলুন। seccomp-bpf-এ প্রতিটি syscall-এ একটি BPF ফিল্টার রায় দেয় (ALLOW, ERRNO, KILL…); Docker-এর ডিফল্ট profile ঝুঁকিপূর্ণ কিছু syscall আটকায়, Chrome-এর renderer আর systemd-এর SystemCallFilter এটি ব্যবহার করে। no_new_privs নিশ্চিত করে exec করে setuid দিয়ে অধিকার বাড়ানো যাবে না।

সম্ভাব্য ফলো-আপ: “DAC আর MAC?” → DAC-এ মালিক অনুমতি ঠিক করেন (rwx); MAC-এ কেন্দ্রীয় নীতি (SELinux, AppArmor), root-ও এড়াতে পারে না।