Linux-এ মেমরি — malloc, mmap, slab, huge page আর OOM killer

১ · একটি process মেমরিকে কীভাবে দেখে — VMA, maps আর smaps

পর্ব ৩০ থেকে ৩৭-এ আপনি তত্ত্ব দেখেছেন: address binding (পর্ব ৩০), buddy system (পর্ব ৩১), paging (পর্ব ৩২), TLB (পর্ব ৩৩), segmentation (পর্ব ৩৪), virtual memory, demand paging আর copy-on-write (পর্ব ৩৫), page replacement (পর্ব ৩৬), thrashing (পর্ব ৩৭)। এই পর্বে সেই টুকরোগুলো জোড়া লাগবে একটি আসল Linux যন্ত্রে — তত্ত্ব আবার শেখানো হবে না, আগের পর্বের নম্বর বলা থাকবে।

VMA আর mm_struct — kernel-এর খাতা

Linux kernel প্রতিটি process-এর address space একটি mm_struct-এ রাখে (একই process-এর সব thread একটিই ভাগ করে)। এর ভেতরে থাকে page table-এর শিকড় (x86-এ CR3-এ যা বসে, পর্ব ০৯), heap আর stack-এর সীমা, আর VMA-র তালিকা. একটি VMA (struct vm_area_struct) হলো address space-এর একটানা একটি টুকরো, যার অনুমতি আর উৎস এক — যেমন “libc-এর কোড, পড়া আর চালানো যায়” বা “heap, পড়া আর লেখা যায়”.

struct vm_area_struct {
    unsigned long vm_start, vm_end;   /* [start, end) — page-এর সীমায় */
    struct mm_struct *vm_mm;          /* কোন address space-এর অংশ */
    pgprot_t vm_page_prot;            /* page-এর অনুমতি */
    unsigned long vm_flags;           /* VM_READ, VM_WRITE, VM_EXEC, VM_SHARED ... */
    struct file *vm_file;             /* ফাইল-map হলে ফাইল, anonymous হলে NULL */
    unsigned long vm_pgoff;           /* ফাইলের কোন page থেকে শুরু */
};

struct mm_struct {
    struct maple_tree mm_mt;          /* সব VMA (৬.১ থেকে maple tree; আগে rbtree + list) */
    pgd_t *pgd;                       /* সবার ওপরের page table */
    unsigned long start_brk, brk;     /* heap-এর শুরু আর বর্তমান শেষ */
    unsigned long start_stack;
    /* RSS-এর হিসাব: ফাইল, anonymous, swap আর shared-memory page-এর কাউন্টার */
};

একটি VMA থাকা মানে RAM পাওয়া নয়। VMA শুধু বলে “এই ঠিকানাগুলো বৈধ”. প্রথমবার ছুঁলে page fault হয়, kernel VMA দেখে বোঝে ছোঁয়াটি বৈধ, তারপর একটি frame জোগাড় করে page table-এ বসায় (পর্ব ৩৫)। VMA-র বাইরে ছুঁলে আসে SIGSEGV (পর্ব ১৩)।

/proc/PID/maps — VMA-র তালিকা পড়া

পর্ব ১১-এ দেখা /proc-এ প্রতিটি process-এর maps ফাইল তার VMA-গুলো ছাপে। একটি ছোট C প্রোগ্রামের সাধারণ চেহারা (উদাহরণ; ঠিকানা প্রতি রানে ASLR-এর কারণে বদলায়):

55d0c3a00000-55d0c3a01000 r--p 00000000 08:01 393228   /home/user/a.out
55d0c3a01000-55d0c3a02000 r-xp 00001000 08:01 393228   /home/user/a.out
55d0c3a03000-55d0c3a04000 rw-p 00002000 08:01 393228   /home/user/a.out
55d0c4e5f000-55d0c4e80000 rw-p 00000000 00:00 0        [heap]
7f3a1c000000-7f3a1c021000 rw-p 00000000 00:00 0
7f3a1c400000-7f3a1c428000 r--p 00000000 08:01 1835106  /usr/lib/x86_64-linux-gnu/libc.so.6
7f3a1c428000-7f3a1c5bd000 r-xp 00028000 08:01 1835106  /usr/lib/x86_64-linux-gnu/libc.so.6
7ffd5e8c0000-7ffd5e8e1000 rw-p 00000000 00:00 0        [stack]
7ffd5e9f8000-7ffd5e9fa000 r-xp 00000000 00:00 0        [vdso]

কলামগুলো: ঠিকানার পরিসর; অনুমতি (r/w/x, আর শেষে p = private copy-on-write বা s = shared); ফাইলের offset; device; inode; আর নাম। নামহীন লাইন (পঞ্চম লাইন) হলো anonymous memory — বড় malloc বা thread-এর stack সাধারণত এমন দেখায়। লক্ষ করুন [heap]-এর আকার 0x55d0c4e80000 − 0x55d0c4e5f000 = 0x21000 = ১৩২ KiB — glibc প্রথম malloc-এ সাধারণত heap এতটাই বাড়ায় (অংশ ২)। কোড অংশ r-xp, লেখা যায় না; ডেটা অংশ rw-p, চালানো যায় না — পর্ব ৪৮-এর W^X সুরক্ষার ভিত্তি এটিই।

smaps — প্রতিটি VMA-র RAM-এর হিসাব

/proc/PID/smaps একই VMA-গুলোর প্রত্যেকটির জন্য বিস্তারিত হিসাব দেয়। উপরের libc-এর প্রথম VMA-র একটি নমুনা (উদাহরণ):

7f3a1c400000-7f3a1c428000 r--p 00000000 08:01 1835106  /usr/lib/x86_64-linux-gnu/libc.so.6
Size:                160 kB
Rss:                 160 kB
Pss:                   5 kB
Shared_Clean:        160 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Anonymous:             0 kB
Swap:                  0 kB

• Size — VMA-র মাপ (এখানে 160 kB). Rss — এর মধ্যে কতটা এখন RAM-এ।
• Pss — প্রতিটি page-কে যতজন ভাগ করে, ততভাগে ভাগ করে যোগ। 160 kB-কে মোটামুটি ৩২টি process ভাগ করছে, তাই এই process-এর ভাগে ৫ kB.
• Shared/Private × Clean/Dirty — page অন্য কেউ ব্যবহার করছে কি না, আর ডিস্কের কপি থেকে বদলেছে কি না। Clean page ফেলে দিয়ে পরে ফাইল থেকে আবার পড়া যায়; Private_Dirty anonymous page ফেলতে হলে swap-এ লিখতে হয়।
• Swap — এই VMA-র কতটা এখন swap-এ। পুরো process-এর যোগফল একবারে চাইলে /proc/PID/smaps_rollup (Linux ৪.১৪ থেকে)।

VSZ, RSS, PSS আর USS — চারটি মাপ, চারটি প্রশ্ন

২ · malloc কোথা থেকে মেমরি আনে — brk না mmap

malloc একটি system call নয় — এটি C library-র (Linux-এ সাধারণত glibc) একটি ফাংশন, যা user space-এ নিজের হিসাব রাখে। প্রতিটি ১৬ বাইটের অনুরোধে kernel-এ যাওয়া খুব ধীর হতো (পর্ব ০৫-এ system call-এর দাম দেখেছেন), তাই malloc kernel-এর কাছ থেকে বড় টুকরো আনে আর নিজে কেটে কেটে দেয়। বড় টুকরো আনার দুটি পথ:

সীমারেখা M_MMAP_THRESHOLD: 64-bit glibc-এ শুরুর মান 128 KiB; অনুরোধ (হিসাবের কয়েক বাইটসহ) এর সমান বা বড় হলে mmap. কিন্তু আধুনিক glibc-এ (বহু বছর ধরে) এই সীমা dynamic: mmap করা একটি ব্লক free হলে glibc ধরে নেয় এই আকারের ব্লক বারবার আসবে, তাই threshold বাড়িয়ে সেই ব্লকের আকারে নেয় (সর্বোচ্চ 64-bit-এ 32 MiB পর্যন্ত), আর heap ছাঁটার সীমা (M_TRIM_THRESHOLD) করে তার দ্বিগুণ। mallopt() বা MALLOC_MMAP_THRESHOLD_ environment variable দিয়ে মান স্থির করলে এই স্বয়ংক্রিয় বদল বন্ধ হয়। (সঠিক খুঁটিনাটি glibc সংস্করণভেদে বদলাতে পারে — man mallopt দেখুন।)

নিচের stepper একটি ছোট প্রোগ্রামের ছয়টি ধাপ দেখায়, glibc-এর ডিফল্ট মানে (heap-এর আকারগুলো glibc-এর হিসাবের নিয়মে, বাস্তবে অন্য বরাদ্দ থাকলে একটু বদলাবে):

এবার আসল glibc-কে পরীক্ষা: প্রোগ্রামটি বিভিন্ন আকারের malloc করে /proc/self/maps-এ খোঁজে ঠিকানাটি কোন VMA-তে — ঠিকানা নয়, শুধু শ্রেণি ছাপে, তাই আউটপুট নিশ্চিত।

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static const char *region(const void *p) {
    static char res[32];
    char line[512], path[256];
    unsigned long lo, hi, a = (unsigned long)p;
    FILE *f = fopen("/proc/self/maps", "r");
    strcpy(res, "not found");
    while (f && fgets(line, sizeof line, f)) {
        path[0] = '\0';
        if (sscanf(line, "%lx-%lx %*s %*s %*s %*s %255s", &lo, &hi, path) >= 2 && a >= lo && a < hi) {
            strcpy(res, strcmp(path, "[heap]") == 0 ? "[heap]  (brk)" : path[0] ? path : "anonymous mmap");
            break;
        }
    }
    if (f) fclose(f);
    return res;
}

int main(void) {
    size_t kib[] = { 1, 64, 127, 129, 1024 };
    for (int i = 0; i < 5; i++) {
        char *p = malloc(kib[i] * 1024);
        printf("malloc(%5zu KiB) -> %s\n", kib[i], region(p));
        free(p);
    }
    char *q = malloc(129 * 1024);               /* the same 129 KiB request again */
    printf("again (  129 KiB) -> %s\n", region(q));
    free(q);
    return 0;
}

malloc(    1 KiB) -> [heap]  (brk)
malloc(   64 KiB) -> [heap]  (brk)
malloc(  127 KiB) -> [heap]  (brk)
malloc(  129 KiB) -> anonymous mmap
malloc( 1024 KiB) -> anonymous mmap
again (  129 KiB) -> [heap]  (brk)

৩ · VSZ বনাম RSS, arena, আর free() কেন RAM ফেরত দেয় না

প্রতিশ্রুতি বনাম আসল RAM — demand paging চোখের সামনে

malloc যখন mmap করে, kernel শুধু একটি VMA বানায় — কোনো frame দেয় না। প্রথম লেখায় প্রতিটি page-এ একটি page fault, আর kernel একটি শূন্য করা frame বসায় (পর্ব ৩৫-এর demand paging). নিচের প্রোগ্রাম 32 MiB নেয়, প্রথমে অর্ধেক, পরে পুরোটা ছোঁয়, তারপর free করে — প্রতিবার /proc/self/status থেকে VmSize (VSZ) আর VmRSS-এর বদল ছাপে (পরম মান container-ভেদে বদলায়, বদল নয়)।

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static long status_kb(const char *key) {
    char line[256]; long kb = -1;
    size_t n = strlen(key);
    FILE *f = fopen("/proc/self/status", "r");
    while (f && fgets(line, sizeof line, f))
        if (strncmp(line, key, n) == 0) { sscanf(line + n, "%ld", &kb); break; }
    if (f) fclose(f);
    return kb;
}
static long vsz0, rss0;
static void show(const char *step) {
    long vsz = status_kb("VmSize:"), rss = status_kb("VmRSS:");
    printf("%-22s VSZ %+4ld MiB   RSS %+4ld MiB\n", step,
           (vsz - vsz0 + 512) / 1024, (rss - rss0 + 512) / 1024);
}

int main(void) {
    const size_t SZ = 32u << 20;                 /* 32 MiB */
    vsz0 = status_kb("VmSize:"); rss0 = status_kb("VmRSS:");
    printf("start: RSS > 0 kB? %s\n", rss0 > 0 ? "yes" : "no");
    char *p = malloc(SZ);
    if (!p) return 1;
    show("after malloc(32 MiB)");
    memset(p, 1, SZ / 2);                        /* touch the first half */
    show("after touching 16 MiB");
    memset(p, 1, SZ);                            /* touch all of it */
    show("after touching 32 MiB");
    free(p);
    show("after free()");
    return 0;
}

start: RSS > 0 kB? yes
after malloc(32 MiB)   VSZ  +32 MiB   RSS   +0 MiB
after touching 16 MiB  VSZ  +32 MiB   RSS  +16 MiB
after touching 32 MiB  VSZ  +32 MiB   RSS  +32 MiB
after free()           VSZ   +0 MiB   RSS   +0 MiB

Arena — বহু thread-এর জন্য বহু খাতা

একটিমাত্র heap আর একটি lock হলে ১৬টি thread একসাথে malloc করলে সবাই lock-এর জন্য লাইনে দাঁড়াত (পর্ব ২৪)। তাই glibc একাধিক arena রাখে: প্রধান arena brk-এর heap ব্যবহার করে, বাকিগুলো mmap দিয়ে আনা ৬৪ MiB-এর “heap” এলাকা (64-bit-এ)। নতুন thread একটি arena পায়; arena-র সংখ্যার সর্বোচ্চ সীমা ডিফল্টভাবে 64-bit-এ CPU-সংখ্যার ৮ গুণ। তার ওপরে glibc ২.২৬ (২০১৭) থেকে প্রতিটি thread-এর নিজস্ব tcache — ছোট ব্লকের lock-ছাড়া তালিকা।

free() কেন RAM ফেরত দেয় না — আর malloc_trim

heap একটানা, আর brk শুধু মাথা থেকে ছাঁটতে পারে। লাখো ছোট ব্লকের মাঝে শেষ ব্লকটি ব্যবহৃত থাকলে নিচের সব ফাঁকা জায়গা malloc-এর ভেতরে আটকে থাকে — প্রোগ্রামের চোখে “free”, OS-এর চোখে RSS. এটি user space-এর external fragmentation. glibc ২.৮ থেকে malloc_trim মাঝের পুরো ফাঁকা page-গুলোও madvise(MADV_DONTNEED) দিয়ে kernel-কে ফেরত দেয় — ঠিকানা থাকে, frame যায়।

#include <malloc.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static long rss_kb(void) {
    char line[256]; long kb = -1;
    FILE *f = fopen("/proc/self/status", "r");
    while (f && fgets(line, sizeof line, f))
        if (strncmp(line, "VmRSS:", 6) == 0) { sscanf(line + 6, "%ld", &kb); break; }
    if (f) fclose(f);
    return kb;
}

enum { N = 40000, SZ = 1000 };                  /* 40000 small blocks, about 40 MB */
static char *blk[N];

int main(void) {
    long base = rss_kb();
    for (int i = 0; i < N; i++) { blk[i] = malloc(SZ); if (!blk[i]) return 1; memset(blk[i], 7, SZ); }
    long full = rss_kb();
    for (int i = 0; i < N - 1; i++) free(blk[i]);   /* keep only the LAST block */
    long freed = rss_kb();
    struct mallinfo2 mi = mallinfo2();
    malloc_trim(0);
    long trimmed = rss_kb();
    printf("RSS growth after 40000 x malloc(1000): %4ld MiB\n", (full - base) / 1024);
    printf("after freeing all but the last block : %4ld MiB\n", (freed - base) / 1024);
    printf("  free bytes kept inside malloc      : %4zu MiB\n", mi.fordblks >> 20);
    printf("after malloc_trim(0)                 : %4ld MiB\n", (trimmed - base) / 1024);
    free(blk[N - 1]);
    return 0;
}

RSS growth after 40000 x malloc(1000):   39 MiB
after freeing all but the last block :   39 MiB
  free bytes kept inside malloc      :   38 MiB
after malloc_trim(0)                 :    0 MiB

৪ · Kernel-এর দিক — zone আর buddy allocator

malloc যখন brk বা mmap চায়, আর পরে page fault-এ frame লাগে, তখন kernel-কে physical মেমরি থেকে page বের করতে হয়। এই কাজের নিচতলা দুটি ধারণায় দাঁড়িয়ে: zone আর buddy allocator.

Zone — ঠিকানার পরিসর অনুযায়ী ভাগ

সব physical মেমরি সব কাজে সমান নয়। কিছু পুরোনো ডিভাইস DMA (পর্ব ০৪) দিয়ে শুধু প্রথম 16 MiB ছুঁতে পারত, আর শুধু 32-bit ঠিকানা বোঝে এমন ডিভাইস শুধু প্রথম 4 GiB. তাই Linux প্রতিটি NUMA node-এর মেমরিকে zone-এ ভাগ করে। x86-64-এ সাধারণত:

32-bit x86-এ আরও একটি ZONE_HIGHMEM ছিল, 64-bit-এ নেই। প্রতিটি zone-এর তিনটি জলসীমা (watermark: min, low, high) — ফাঁকা page low-এর নিচে নামলে kswapd জেগে পেছনে page ফেরত আনে, min-এর নিচে নামলে allocation করা thread নিজেই reclaim করে (direct reclaim — latency বাড়ায়)। কোন page ফেরত আসবে, তা ঠিক করে active/inactive তালিকা বা Linux ৬.১-এর MGLRU (পর্ব ৩৬)।

Buddy allocator — Linux-এর page allocator

পর্ব ৩১-এ buddy system-এর তত্ত্ব দেখেছেন। Linux-এ প্রতিটি zone-এর free_area[]-এ প্রতিটি order-এর জন্য একটি ফাঁকা-তালিকা: order n মানে ২ⁿটি একটানা page. সাধারণ kernel-এ order ০ থেকে ১০ — 4 KiB থেকে 4 MiB. (Kernel-এর ধ্রুবকটি আগে ছিল MAX_ORDER = 11, অর্থাৎ “সর্বোচ্চ order-এর এক বেশি”; ৬.৪-এ অর্থ বদলে MAX_ORDER = 10 হয়, আর ৬.৮-এ নাম হয় MAX_PAGE_ORDER; ফল একই — ১১টি তালিকা।) একটি ব্লকের buddy খুঁজতে শুধু একটি XOR: page frame number (pfn) ⊕ ২^order.

নিচে একটি ছোট zone, ১৬টি page (pfn ০–১৫), order ০ থেকে ৪. A চায় ৩টি page, B চায় ১টি; তারপর দুজনেই ফেরত দেয়।

আসল যন্ত্রে এই তালিকাগুলোর গণনা /proc/buddyinfo-এ (অংশ ৬-এর bash ব্লকে চালানো হবে): প্রতিটি সারি একটি node আর zone, ১১টি সংখ্যা order ০ থেকে ১০-এর ফাঁকা ব্লক। ডানের সংখ্যা যত কম, fragmentation তত বেশি — huge page (order 9 = 2 MiB) তখন সহজে মেলে না, আর kernel compaction চালিয়ে সরানো যায় এমন page সরিয়ে ফাঁকা জায়গা একত্র করে। Fragmentation কমাতে Linux “movable” আর “unmovable” page আলাদা page-block-এ রাখারও চেষ্টা করে।

৫ · Slab আর SLUB — kernel-এর ছোট বস্তুর জন্য

Buddy-র সবচেয়ে ছোট একক 4 KiB. কিন্তু kernel-এর বেশিরভাগ বস্তু ছোট: একটি struct file কয়েকশো বাইট, একটি dentry ২০০-র কাছাকাছি, একটি task_struct কয়েক KiB. প্রতিটির জন্য পুরো page দিলে বিপুল অপচয়, আর প্রতিবার শুরু থেকে বস্তু সাজাতেও সময় যায়। সমাধান slab allocator: প্রতিটি বস্তু-ধরনের জন্য একটি cache; cache buddy থেকে কয়েকটি page (একটি “slab”) নেয়, সেটিকে সমান মাপের ঘরে কাটে, আর ফাঁকা ঘরের তালিকা রাখে।

সব slab cache-এর হিসাব /proc/slabinfo-এ, যা সাধারণত শুধু root পড়তে পারে; সাজানো চেহারায় দেখায় slabtop:

$ sudo slabtop -o -s c | head -9
 Active / Total Objects (% used)    : 2147310 / 2210468 (97.1%)
 Active / Total Slabs (% used)      : 61204 / 61204 (100.0%)
 Active / Total Caches (% used)     : 128 / 182 (70.3%)
 Active / Total Size (% used)       : 512340.18K / 528911.50K (96.9%)

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 399126 398870  99%    0.19K  19006       21     76024K dentry
 181440 180912  99%    0.57K   6480       28    103680K radix_tree_node
 118290 117801  99%    1.06K   3943       30    126176K ext4_inode_cache

এখানে dentry (পর্ব ৪২) আর inode cache-ই বড়; মেমরির চাপে kernel এগুলোর বড় অংশ ফেরত আনতে পারে। /proc/meminfo-র SReclaimable আর SUnreclaim এই দুই ভাগ দেখায়। SUnreclaim যদি দিনের পর দিন বাড়তেই থাকে, তা kernel বা driver-এর leak-এর লক্ষণ হতে পারে।

kmalloc বনাম vmalloc

kvmalloc() আগে kmalloc চেষ্টা করে, না পেলে vmalloc. Windows kernel-এর সমতুল্য paged আর non-paged pool.

৬ · Page cache, “free” বনাম “available”, আর swap

Linux-এর একটি বিখ্যাত ভুল-বোঝাবুঝি: “আমার ১৬ GiB RAM-এর মাত্র ৫০০ MiB ফাঁকা — মেমরি শেষ!” প্রায় সব ক্ষেত্রে উত্তর: না। Kernel ফাঁকা RAM ফেলে রাখে না; ডিস্ক থেকে পড়া ফাইলের ডেটা page cache-এ রেখে দেয়, যাতে আবার পড়লে ডিস্কে যেতে না হয় (পর্ব ০৪-এর memory hierarchy মনে করুন)। দরকার হলে পরিষ্কার cache-page সাথে সাথে ফেলে দেওয়া যায়।

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       5.1Gi       512Mi       820Mi       9.8Gi        9.6Gi
Swap:          4.0Gi       128Mi       3.9Gi

free মাত্র ৫১২ MiB, কিন্তু available ৯.৬ GiB — নতুন কাজকে swap ছাড়াই মোটামুটি এতটা দেওয়া যাবে। মানটি আসে /proc/meminfo-র MemAvailable থেকে, যা Linux ৩.১৪ (২০১৪)-এ যোগ হয়: ফাঁকা RAM (জলসীমা বাদে) + ফেলে দেওয়া যায় এমন page cache-এর অংশ + ফেরতযোগ্য slab-এর অংশ — একটি অনুমান, নিখুঁত সংখ্যা নয়। মনিটরিংয়ে “MemFree কম” নয়, “MemAvailable কম আর কমছে”, swap-এর কার্যকলাপ আর PSI-এর মেমরি চাপ (পর্ব ৩৭) দেখুন।

Dirty page আর writeback

ফাইলে write() সাধারণত সরাসরি ডিস্কে যায় না — page cache-এর page বদলে dirty চিহ্ন পায়, আর পরে kernel-এর flusher thread দলবেঁধে লেখে (writeback). কতটা dirty জমতে দেওয়া হবে, তা vm.dirty_background_ratio আর vm.dirty_ratio ঠিক করে — দ্বিতীয়টি ছাড়ালে লিখতে থাকা process-কেই থামানো হয়। তাই USB drive-এ কপি “শেষ” দেখানোর পরেও নিরাপদে সরাতে sync/eject দরকার; ডেটাবেস নিশ্চয়তার জন্য fsync() ডাকে (পর্ব ৪৪)।

drop_caches — বুঝুন, কিন্তু অভ্যাস করবেন না

echo 3 > /proc/sys/vm/drop_caches (root) পরিষ্কার page cache আর ফেরতযোগ্য slab বস্তু (dentry, inode) ফেলে দেয়; ১ শুধু page cache, ২ শুধু slab. Dirty page ফেলে না, তাই আগে sync. এর সৎ ব্যবহার একটিই: benchmark-এ “ঠান্ডা cache” তৈরি। চলমান সার্ভারে নিয়মিত চালালে সব ফাইল আবার ডিস্ক থেকে পড়তে হয়, গতি কমে, আর আসল সমস্যা ঢাকা পড়ে।

Swap, swappiness, zswap আর zram

RAM-এর চাপে kernel দুই ধরনের page ফেরত আনতে পারে: ফাইল-page (পরিষ্কার হলে ফেলে দেওয়া, পরে আবার পড়া) আর anonymous page (swap-এ লেখা ছাড়া উপায় নেই)। কোনটির দিকে কতটা ঝুঁকবে, তা vm.swappiness দিয়ে বলা যায় — Linux ৫.৮ থেকে ০–২০০, বেশিরভাগ distro-তে ডিফল্ট সাধারণত ৬০. ০ মানে “swap একেবারে বন্ধ” নয়, শুধু anonymous page-কে অনেক কম পছন্দ; ১০০ মানে দুই ধরনকে সমান দাম; ১০০-র ওপরে swap-কে বেশি পছন্দ — দ্রুত zram-এর জন্য অর্থবহ। কোন মান ভালো, তা workload আর storage-এর গতির ওপর নির্ভর করে; অন্ধ নিয়ম নেই।

• zswap (Linux ৩.১১ থেকে): swap-এ লেখার আগে page সংকুচিত করে RAM-এর একটি ছোট pool-এ রাখে; pool ভরলে তবেই আসল swap ডিভাইসে। ডিস্কে লেখা অনেক কমে।
• zram: RAM-এর ভেতরেই একটি সংকুচিত block device, যাকে swap হিসেবে ব্যবহার করা হয় — ডিস্ক নেই। Android আর ChromeOS-এ বহুল ব্যবহৃত, আর Fedora ৩৩ থেকে ডিফল্ট swap হিসেবে zram ব্যবহার করে।

এবার এই অনলাইন রানারের যন্ত্রটি (একটি container) নিজেই দেখি — meminfo, buddyinfo, THP-র নীতি, overcommit, আর এই shell-এর OOM হিসাব। কোনো ফাইল না থাকলে script থামে না, শুধু জানায়:

echo "== /proc/meminfo (selected) =="
grep -E '^(MemTotal|MemFree|MemAvailable|Cached|Dirty|SwapTotal|SwapFree|HugePages_Total|HugePages_Free|Hugepagesize|AnonHugePages|CommitLimit|Committed_AS):' /proc/meminfo
echo "== /proc/buddyinfo (free blocks of order 0..10) =="
if [ -r /proc/buddyinfo ]; then cat /proc/buddyinfo; else echo "not readable here"; fi
echo "== THP =="
for f in enabled defrag; do
  p=/sys/kernel/mm/transparent_hugepage/$f
  if [ -r "$p" ]; then echo "$f: $(cat "$p")"; else echo "$f: not available"; fi
done
echo "== overcommit / swappiness =="
for f in overcommit_memory overcommit_ratio swappiness; do
  p=/proc/sys/vm/$f
  if [ -r "$p" ]; then echo "vm.$f = $(cat "$p")"; else echo "vm.$f: not readable"; fi
done
echo "== this shell =="
echo "oom_score=$(cat /proc/$$/oom_score) oom_score_adj=$(cat /proc/$$/oom_score_adj)"
for f in memory.max memory.high memory.current; do
  p=/sys/fs/cgroup/$f
  if [ -r "$p" ]; then echo "cgroup $f = $(cat "$p")"; else echo "cgroup $f: not readable"; fi
done

== /proc/meminfo (selected) ==
MemTotal:        2008912 kB
MemFree:          161868 kB
MemAvailable:    1280060 kB
Cached:           835768 kB
SwapTotal:       6041596 kB
SwapFree:        5627256 kB
Dirty:              3232 kB
CommitLimit:     7046052 kB
Committed_AS:    1651516 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
Hugepagesize:       2048 kB
== /proc/buddyinfo (free blocks of order 0..10) ==
Node 0, zone      DMA     90     64     43     31     24     13      3      3      2      1      0
Node 0, zone    DMA32   4665   2834   1016   1363    488    103     16      0      0      0      0
== THP ==
enabled: always [madvise] never
defrag: always defer defer+madvise [madvise] never
== overcommit / swappiness ==
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.swappiness = 60
== this shell ==
oom_score=666 oom_score_adj=0
cgroup memory.max = max
cgroup memory.high = max
cgroup memory.current = 1277952

৭ · Huge page, THP আর NUMA

কেন বড় page — TLB-র নাগাল

পর্ব ৩৩-এ দেখেছেন, প্রতিটি ঠিকানা অনুবাদের জন্য TLB দরকার; miss হলে চার স্তরের page table হাঁটতে হয়। TLB-র entry সীমিত, তাই প্রশ্ন: সব entry মিলিয়ে কতটা মেমরি ঢাকা যায় — একে বলে TLB reach.

দুই পথ: HugeTLBfs আর THP

THP-র দামও আছে। (১) Latency-র ঝাঁকুনি: 2 MiB ব্লক না থাকলে page fault-এর মধ্যেই compaction চলতে পারে (defrag নীতি তা ঠিক করে)। (২) মেমরি ফুলে ওঠা: প্রোগ্রাম 2 MiB এলাকার মাত্র কয়েক KiB ছুঁলেও পুরো 2 MiB RSS-এ আসতে পারে। (৩) fork-এর পর copy-on-write-এ বড় page কপি। তাই অনেক distro madvise নীতি নেয় — শুধু যে প্রোগ্রাম madvise(MADV_HUGEPAGE) চায়, সে পায়; কিছু distro always. ডেটাবেস নির্মাতাদের পরামর্শও এক নয় আর সময়ের সাথে বদলেছে: Redis শুরুতেই সতর্কবার্তা দেয় THP always থাকলে, Oracle আর অনেক ডেটাবেস ঐতিহ্যগতভাবে THP বন্ধ রেখে HugeTLBfs-এর পরামর্শ দিয়েছে, আবার কোনো কোনো নির্মাতা নতুন সংস্করণে THP চালু রাখতে বলছে। নিজের সংস্করণের ডকুমেন্টেশন দেখে, মেপে সিদ্ধান্ত নিন। Linux ৬.৮-এর “multi-size THP” (যেমন 64 KiB) ছবিটি আরও নমনীয় করছে।

NUMA — কাছের মেমরি, দূরের মেমরি

বড় সার্ভারে প্রতিটি CPU socket-এর নিজস্ব মেমরি থাকে (NUMA, পর্ব ২০); দূরের node-এর মেমরি ছুঁতে বেশি সময় লাগে। Linux-এর ডিফল্ট first-touch নীতি: একটি page যে CPU প্রথম ছোঁয়, তার node থেকে frame আসে। তাই একটি thread পুরো বড় array শূন্য করে দিলে সব মেমরি এক node-এ জমে, আর অন্য node-এর thread-গুলো দূরের মেমরিতে ধীরে চলে। সমাধান: প্রতিটি thread নিজের অংশ নিজে প্রথম ছোঁয়, অথবা numactl:

$ numactl --hardware | head -4
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 64215 MB
node 0 free: 1022 MB
$ numactl --cpunodebind=0 --membind=0 ./db-server   # এক node-এ বাঁধা
$ numactl --interleave=all ./big-cache             # সব node-এ পালা করে page
$ numastat -p db-server                            # কোন node-এ কত মেমরি

লক্ষ করুন, node 0-এ মাত্র ১ GB ফাঁকা — অন্য node-এ জায়গা থাকলেও একটি node-এ চাপ পড়লে reclaim শুরু হতে পারে। Linux পেছনে “automatic NUMA balancing” দিয়ে page আর task-কে কাছাকাছি আনার চেষ্টাও করে।

৮ · Overcommit, OOM killer আর cgroup — container কেন হঠাৎ মরে

Overcommit — ব্যাংকের মতো প্রতিশ্রুতি

অংশ ৩-এ দেখেছেন, malloc শুধু ঠিকানা দেয়, RAM আসে ছোঁয়ার সময়। fork-এর পর copy-on-write (পর্ব ১০, ৩৫)-এ parent আর child-এর পুরো মেমরি “প্রতিশ্রুত”, অথচ বেশিরভাগ কখনো কপি হয় না। তাই Linux ডিফল্টভাবে overcommit করে — RAM আর swap মিলিয়ে যত আছে, তার চেয়ে বেশি প্রতিশ্রুতি (Committed_AS CommitLimit ছাড়াতে পারে)। vm.overcommit_memory-এর তিনটি মান:

• ০ — heuristic (ডিফল্ট): স্পষ্টতই অসম্ভব অনুরোধ (যেমন একবারে মোট RAM + swap-এর চেয়ে বড়) প্রত্যাখ্যান, বাকি সব হ্যাঁ।
• ১ — সবসময় হ্যাঁ: বড় sparse array-র কোড বা fork-ভিত্তিক snapshot নেওয়া Redis-এর মতো প্রোগ্রামের জন্য।
• ২ — কড়া হিসাব: মোট প্রতিশ্রুতি CommitLimit = swap + RAM × overcommit_ratio% ছাড়ালে malloc/mmap ব্যর্থ (ENOMEM).

OOM killer — যখন প্রতিশ্রুতি রাখা যায় না

সবাই একসাথে মেমরি ছুঁলে, আর kswapd ও direct reclaim মিলেও কিছু ফেরত আনতে না পারলে, page fault মেটানোর মতো frame থাকে না। তখন kernel-এর OOM killer একটি process বেছে SIGKILL দেয়। বাছাইয়ের মূল ফাংশন oom_badness(), যার যুক্তি বর্তমান kernel-এ মোটামুটি এই (সংস্করণভেদে খুঁটিনাটি বদলেছে — যেমন পুরোনো kernel-এ root process-এর জন্য ছাড় ছিল, এখন নেই):

long oom_badness(struct task_struct *p, unsigned long totalpages)
{
    long points, adj = p->signal->oom_score_adj;

    if (adj == OOM_SCORE_ADJ_MIN || oom_unkillable_task(p))   /* -1000 */
        return LONG_MIN;                       /* কখনো বাছা হবে না */

    points = get_mm_rss(p->mm)                 /* RAM-এ থাকা page */
           + get_mm_counter(p->mm, MM_SWAPENTS) /* swap-এ থাকা page */
           + mm_pgtables_bytes(p->mm) / PAGE_SIZE;   /* page table-এর page */

    adj *= totalpages / 1000;                  /* adj-এর এক একক = মোট-এর ০.১% */
    return points + adj;                       /* সবচেয়ে বড় points-এর process মরবে */
}
/* totalpages = RAM + swap (cgroup-এর ভেতরে OOM হলে সেই cgroup-এর সীমা) */

oom_score_adj −১০০০ থেকে +১০০০; প্রতিটি একক মোট মেমরির ০.১%-এর সমান points যোগ বা বিয়োগ করে। −১০০০ মানে কখনো বাছা হবে না। এবার একটি numerical, ধাপে ধাপে: ৩ GiB RAM + ১ GiB swap = ৪ GiB = ১০,৪৮,৫৭৬টি 4 KiB page, তাই adj-এর এক একক = ১০,৪৮,৫৭৬ ÷ ১০০০ → পূর্ণসংখ্যায় ১০৪৮ page. (১ MiB = ২৫৬ page.)

নিজের যন্ত্রে মান দেখা আর বদলানো (সাধারণ user নিজের process-এর adj বাড়াতে পারেন, কমাতে CAP_SYS_RESOURCE লাগে):

$ echo 500 > /proc/self/oom_score_adj        # এই shell আর তার child-রা আগে মরবে
$ choom -p 4100                               # util-linux: score আর adj দেখা
pid 4100's current OOM score: 878
pid 4100's current OOM score adjustment value: 0
$ systemctl show sshd -p OOMScoreAdjust       # systemd ইউনিটে স্থায়ীভাবে
OOMScoreAdjust=-1000
$ journalctl -k | grep -i "killed process"    # অতীতের OOM kill খোঁজা

cgroup v2 — দলের সীমা আর container-এর OOM

cgroup v2-এর memory controller একটি দলের মেমরি (anonymous, page cache, kernel-এর কিছু অংশ সহ) গোনে আর সীমা বসায় (container-এর পুরো গল্প পর্ব ৫১-এ):

• memory.high — নরম সীমা। পেরোলে kernel দলটির page জোর করে reclaim করে আর দলকে ধীর করে, কিন্তু মারে না। ধীরে ধীরে চাপ দেওয়ার উপায়।
• memory.max — কড়া সীমা। Reclaim করেও নিচে না নামলে দলের ভেতরেই OOM killer চলে, totalpages তখন দলের সীমা। memory.events-এর oom_kill গণনা বাড়ে। memory.oom.group = 1 দিলে পুরো দল একসাথে মরে (আধা-মরা সার্ভিসের চেয়ে ভালো)।
• memory.low/memory.min উল্টো কাজ করে — দলের একটি অংশকে reclaim থেকে রক্ষা।

Docker-এ --memory=512m বা Kubernetes-এ limits.memory সরাসরি memory.max লেখে। সীমা পেরোলে container-এর প্রধান process SIGKILL পায়, আর exit status হয় ১২৮ + ৯ = ১৩৭ (exit code 137, পর্ব ১৩-এর signal-এর নিয়ম)। Kubernetes কারণ লেখে OOMKilled, Docker-এর docker inspect-এ "OOMKilled": true. তবে ১৩৭ মানেই OOM নয় — কেউ kill -9 দিলেও একই কোড, তাই কারণ মিলিয়ে নিন।

$ docker run --memory=256m --name hog myapp
$ echo $?
137
$ docker inspect -f '{{.State.OOMKilled}} {{.State.ExitCode}}' hog
true 137
$ cat /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.events
low 0
high 0
max 1843
oom 1
oom_kill 1

Kernel-এর OOM killer শেষ মুহূর্তের অস্ত্র — তার আগে যন্ত্র প্রায়ই thrashing-এ (পর্ব ৩৭) আটকে থাকে। তাই systemd-oomd PSI-এর মেমরি-চাপ দেখে আগেভাগে পুরো cgroup মারে, আর Android-এর lmkd পেছনের অ্যাপ বন্ধ করে।

৯ · Memory leak খোঁজা, আর Windows ও macOS কী করে

Memory leak মানে প্রোগ্রাম মেমরি নেয় কিন্তু আর কখনো ফেরত দেয় না, অথচ সেটি আর কাজেও লাগে না। ছোট টুলে leak প্রায় অদৃশ্য (process শেষে kernel সব ফেরত নেয়), কিন্তু সপ্তাহ ধরে চলা সার্ভারে RSS বাড়তে বাড়তে OOM kill. আবার RSS বাড়া মানেই leak নয় (অংশ ৩) — প্রমাণে টুল লাগে।

$ gcc -g -O0 leaky.c -o leaky
$ valgrind --leak-check=full ./leaky
==3127== HEAP SUMMARY:
==3127==     in use at exit: 4,000 bytes in 40 blocks
==3127== 4,000 bytes in 40 blocks are definitely lost in loss record 1 of 1
==3127==    at 0x48447A8: malloc (vg_replace_malloc.c:446)
==3127==    by 0x109176: read_record (leaky.c:12)
==3127==    by 0x1091B5: main (leaky.c:21)

$ gcc -g -fsanitize=address leaky.c -o leaky_asan && ./leaky_asan
==3140==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4000 byte(s) in 40 object(s) allocated from:
    #0 0x7f1c2b4b9a37 in malloc
    #1 0x55a1c0a001a9 in read_record leaky.c:12

$ heaptrack ./server            # চলার সময় প্রতিটি malloc-এর call stack লেখে
$ heaptrack_print heaptrack.server.12345.zst | head   # বা heaptrack_gui

চলমান সার্ভারে প্রথম ধাপ সহজ: কয়েক ঘণ্টা smaps_rollup-এর Pss_Anon লিখে রাখুন; সমান load-এ টানা বাড়লে তবেই টুল। GC-ভাষাতেও leak হয়, যদি কোথাও রেফারেন্স রয়ে যায়।

Windows আর macOS — একই সমস্যা, ভিন্ন নীতি

দর্শনের পার্থক্য: Windows প্রতিশ্রুতির সময়েই “না” বলে, Linux “হ্যাঁ” বলে পরে হিসাব মেলায় — বেশি দক্ষ, কিন্তু ব্যর্থতা আসে হঠাৎ। Windows-এর খুঁটিনাটি পর্ব ৫৬-এ।

১০ · AI-এর যুগে মেমরির প্রশ্ন — উত্তর যাচাই

“আমার Linux সার্ভারে RAM ভরে যাচ্ছে, কী করব?” — AI প্রায়ই প্রথমেই বলবে echo 3 > /proc/sys/vm/drop_caches cron-এ বসাতে, বা swapoff -a, বা vm.swappiness=0 “সবসময় ভালো”. অথচ অংশ ৬-এর মতো “free কম” হয়তো কোনো সমস্যাই নয়। AI-এর মেমরি-সংক্রান্ত সাধারণ ভুল:

AI-এর দেওয়া মেমরি-পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• সমস্যাটি আসল কি না মেপেছি — MemAvailable, swap-এর si/so, PSI, OOM-এর log — শুধু “free কম” দেখে নয়
• পরামর্শটি আমার kernel, distro আর cgroup সংস্করণের (v1 না v2) জন্য, আর উল্লেখ করা ফাইল সত্যিই আছে — ls করে দেখেছি
• RSS, PSS বা oom_score-এর যেকোনো হিসাব হাতে বা ছোট প্রোগ্রামে মিলিয়েছি
• drop_caches, swapoff, overcommit বা oom_score_adj বদলানোর আগে ভেবেছি — চলমান সার্ভারে কী ক্ষতি হতে পারে; পরিবর্তন প্রথমে পরীক্ষার যন্ত্রে
• “leak” দাবি টুল (ASan, valgrind, heaptrack) দিয়ে প্রমাণ করেছি; fragmentation বা cache আলাদা করেছি
• পরিবর্তনের আগে-পরে আসল load-এ (load test) latency আর মেমরি দুটোই মেপেছি