Process-এর শরীর — task_struct থেকে address space পর্যন্ত

সুবিধা — disk আর load time দুটোতেই।

একটা প্রোগ্রামে যদি ১০০ MB-র একটা বড় uninitialised array থাকে (static char buffer[100*1024*1024];), সেটা .data-তে গেলে ELF ফাইল নিজেই ১০০ MB বড় হতো, আর প্রতিবার load করার সময় সেই ১০০ MB disk থেকে পড়তে হতো।

.bss-তে গেলে ELF ফাইলে শুধু “এখানে ১০০ MB শূন্য রাখো” — কয়েক byte-এর একটা metadata। Loader শুধু একটা zero-filled anonymous mapping বানায় (mmap(MAP_ANONYMOUS) ঘরানার), যা kernel demand-paging দিয়ে lazily allocate করে (লেসন ১০-১৩)।

নির্ধারণের নিয়ম — compiler/linker করে, স্বয়ংক্রিয়ভাবে:

int a;              /* .bss — initial value নেই */
int b = 0;           /* .bss — শূন্যেই initialised, তাই একই কথা */
int c = 5;            /* .data — non-zero initial value */
const char *d = "x";   /* pointer .data-তে, string literal .rodata-তে */
static int e;          /* .bss */

Compiler প্রতিটা global/static variable-এর initial value দেখে সিদ্ধান্ত নেয়। = 0 লেখা আর কিছু না লেখা — দুটোই .bss-এ যায়, কারণ ফলাফল একই (linker/loader optimization)।

gcc -c test.c -o test.o
size test.o

size কমান্ড প্রতিটা section-এর আকার আলাদা করে দেখায় — নিজে যাচাই করুন।

ব্যবহারিক পরিণতি: এই কারণেই একটা বিশাল static array থাকা প্রোগ্রামের binary ফাইল ছোট থাকে, কিন্তু চালানোর সময় memory-তে বড় জায়গা নেয় — ls -l আর ps-এর RSS সংখ্যা মিলবে না, আর এটা bug নয়।

ps-এর STAT column-এ প্রথম অক্ষরটাই মূল state (R/S/D/T/Z), তারপরের অক্ষরগুলো modifier:

Ss — sleeping (S) এবং session leader (s)। এটা প্রায় নিশ্চিতভাবে একটা shell বা daemon যেটা নিজে একটা নতুন session শুরু করেছে (setsid() ডেকে) — যেমন আপনার login shell, বা sshd-এর একটা child।

R+ — running/runnable (R) এবং foreground group-এ (+)। এটা এমন একটা প্রোগ্রাম যা এই মুহূর্তে আপনার terminal-এ চলছে আর active — যেমন আপনি যদি এই মুহূর্তে ps কমান্ডটাই দেখতে পারতেন, সেটা নিজেই R+ হতো।

যাচাই করুন:

sleep 100 &
ps -eo pid,ppid,stat,comm | grep sleep

sleep 100 & ব্যাকগ্রাউন্ডে গেছে, তাই foreground নয় — STAT-এ + থাকবে না, শুধু S।

sleep 100

(এবার & ছাড়া, অন্য terminal থেকে দেখুন) — এবার S+, কারণ এটা foreground-এ ঘুমাচ্ছে।

গুরুত্ব: + না থাকা মানে সেই process Ctrl-C দিয়ে থামানো যাবে না (কারণ terminal driver SIGINT শুধু foreground group-কে পাঠায়) — এটাই লেসন ২৩ ও ২৫-এর signal আলোচনায় গুরুত্বপূর্ণ হয়ে ফিরবে।

ধাপ ১ — নিশ্চিত করুন এটা সত্যিই D state, আর কতক্ষণ ধরে।

ps -eo pid,stat,etime,comm | grep " D"

etime দেখায় process কতক্ষণ চলছে — কিন্তু D state-এ কতক্ষণ আটকে সেটা আলাদা করে জানতে:

watch -n1 'ps -eo pid,stat,comm | grep " D"'

কয়েক সেকেন্ডের বেশি স্থায়ী D state সন্দেহজনক — সাধারণ disk read কয়েক মিলিসেকেন্ডে শেষ হয়।

ধাপ ২ — কোন kernel function-এ আটকে তা দেখুন।

cat /proc/<pid>/wchan; echo
cat /proc/<pid>/stack     # root লাগবে, kernel debug symbol দরকার

wchan একটা function নাম দেবে — যেমন wait_on_page_bit (disk page-এর জন্য অপেক্ষা), nfs_wait_bit_killable (NFS), __wait_rcu_gp। নামটাই root cause-এর দিকনির্দেশ করে।

ধাপ ৩ — কী resource-এ আটকে তা দেখুন।

sudo cat /proc/<pid>/syscall     # কোন syscall-এ আটকে
sudo ls -la /proc/<pid>/fd/      # কোন file/socket খোলা
iostat -x 1                       # disk latency অস্বাভাবিক কি না

wchan-এ NFS-সংক্রান্ত নাম থাকলে সেই NFS server-এর অবস্থা দেখুন। Local disk হলে iostat-এ %util আর await দেখুন — disk নিজে ধীর বা মৃত কি না।

ধাপ ৪ — dmesg-এ hardware error খুঁজুন।

dmesg -T | grep -iE "error|timeout|reset" | tail -50

Disk controller error, SCSI timeout, বা storage array-এর পাশ থেকে network সমস্যা — এগুলো প্রায়ই D state-এর প্রকৃত কারণ, প্রোগ্রামের কোড নয়।

যা করবেন না: এই অবস্থায় kill -9 বারবার চেষ্টা করা — এটা কাজ করবে না (D state signal উপেক্ষা করে), আর সময় নষ্ট করবে। D state-এ আটকে থাকা process-এর জন্য একমাত্র বাস্তব সমাধান হয় underlying I/O সমস্যা সমাধান, নয়তো পুরো মেশিন reboot।

দীর্ঘমেয়াদী প্রতিরোধ: NFS mount-এ soft,intr,timeo= option ব্যবহার করুন (hard mount-এর বদলে) যাতে timeout-এ অন্তত signal-এ সাড়া দেয়। Application-স্তরে I/O timeout সেট করুন যাতে একটা ধীর disk পুরো worker pool আটকে না দেয়।

এই diagnostic flow-টাই লেসন ৩০-এ (/proc ও observability) আমরা আরো সাধারণ toolkit হিসেবে ফিরে দেখব।

প্রথমটা — {0} — যাবে .bss-তে।

C-এর নিয়মে {0}-দিয়ে initialise করা array-র সব element শূন্য হয় — আর সব-শূন্য মানে .bss-এর সংজ্ঞার সাথে হুবহু মিলে যায়। Compiler এটা চেনে আর optimize করে .bss-এ পাঠায়, .data-তে ৪ MB (১০ লক্ষ × ৪ byte) real zero byte সংরক্ষণ করে না।

cat > t1.c <<'EOF'
int arr[1000000] = {0};
int main(void) { return arr[0]; }
EOF
gcc -c t1.c -o t1.o && size t1.o

   text    data     bss     dec     hex filename
    ...       ...  4000000   ...     ... t1.o

data column প্রায় শূন্য, bss column ৪,০০০,০০০ — নিশ্চিত।

দ্বিতীয়টা — {1} — যাবে .data-তে, পুরোটাই।

C-তে {1} মানে প্রথম element 1, বাকি সব automatically শূন্যে initialised (এটা C standard-এর নিয়ম — partial initializer list-এর বাকিটা শূন্য হয়)। কিন্তু array-টা এখন আর “সব শূন্য” নয় — একটা non-zero byte আছে।

এখানে compiler-এর দুইটা বৈধ পথ আছে:

1. সরল পথ: পুরো ৪ MB .data-তে রাখা (একটা non-zero element-এর জন্য পুরোটাই real byte সংরক্ষণ)
2. চতুর পথ: সবচেয়ে ছোট continuous non-zero অংশটুকু .data-তে, বাকি .bss-তে (কিছু compiler/linker এটা করে, .data আর .bss-এর মাঝে বিভাজন করে)

cat > t2.c <<'EOF'
int arr[1000000] = {1};
int main(void) { return arr[0]; }
EOF
gcc -c t2.c -o t2.o && size t2.o

আপনার compiler কোন পথ নিয়েছে সেটা size-এর আউটপুট দেখেই বোঝা যাবে — data column বড় হলে প্রথম পথ, ছোট হয়ে bss বড় হলে দ্বিতীয় পথ।

সাধারণ শিক্ষা: compiler-এর decision কোনো রহস্য নয় — size, readelf -S, আর objdump -h দিয়ে সরাসরি যাচাই করা যায়। যখনই “compiler নিশ্চয়ই এটা করে” ভাবছেন, চালিয়ে দেখাই সবচেয়ে নির্ভরযোগ্য উত্তর।

না, প্রায় বদলাবে না।

docker stats cgroup-এর memory accounting থেকে সংখ্যা নেয়, আর cgroup memory controller physical page usage (RSS-এর কাছাকাছি একটা মেট্রিক) মাপে, virtual address space নয়।

mmap() দিয়ে address space reserve করা মানে শুধু page table-এ একটা entry আর task_struct-এর mm-এ একটা VMA (Virtual Memory Area) যোগ হওয়া — কোনো physical page এখনো বরাদ্দ হয়নি। এই লেসনে দেখেছি address space একটা illusion; সেই illusion-এর একটা অংশ দাবি করা মানে বাস্তব সম্পদ খরচ হওয়া নয়, যতক্ষণ না touch করা হয় (লেসন ১০-১৩-এ demand paging বিস্তারিত)।

পার্থক্যটা যাচাই করা যায়:

void *p = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE,
              MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
/* এখানে docker stats: প্রায় অপরিবর্তিত */

memset(p, 1, 1UL << 30);   /* প্রতিটা byte touch */
/* এখানে docker stats: ~1 GB বেড়ে যাবে — যদি limit-এ না ঠেকে */

memset চালালে প্রতিটা page-এ page fault হবে, kernel সেগুলো physical frame দিয়ে ভরবে (লেসন ১৩), আর তখনই RSS বাড়বে — আর তখনই cgroup limit-এ ঠেকলে OOM killer container-টাকে মেরে ফেলবে।

ব্যবহারিক পরিণতি: এই কারণেই “আমার প্রোগ্রাম শুধু malloc করেছে, এখনো লেখেনি, তবু OOM হলো” — এটা স্ববিরোধী শোনায় কিন্তু আসলে ঠিক এই আচরণেরই একটা রূপ। যদি allocator বড় একটা chunk mmap করে আর zero-out করার জন্য touch করে (কিছু allocator security বা predictability-র জন্য করে), তখনই সমস্যা।

Overcommit-এর সাথে সংযোগ: /proc/sys/vm/overcommit_memory সেটিং নির্ধারণ করে kernel কি mmap()-এর সময়েই প্রত্যাখ্যান করবে (যদি মোট virtual demand physical+swap-এর চেয়ে বেশি হয়), নাকি allow করে দিয়ে পরে touch করার সময় OOM killer-এর উপর ছেড়ে দেবে। এটাই লেসন ১০-এর কেন্দ্রীয় বিষয়।

Level 12-এ আমরা এই cgroup accounting বিস্তারিত দেখব, আর docker stats-এর সংখ্যা ঠিক কোন /sys/fs/cgroup/ ফাইল থেকে আসে তা খুঁজে বের করব।