Operating-System

Chương tổng kết: mỗi hệ thống lớn là một tập lựa chọn trên các trade-off đã học. Đọc mỗi mục và tự kiểm tra: bạn có chỉ ra được chương nào của tài liệu đứng sau từng quyết định không? 17.1. PostgreSQL — đặt cược vào Page Cache của kernel Kiến trúc trên OS: process-per-connection (fork — chương 04; lý do connection đắt và PgBouncer gần như bắt buộc ở connection count cao); shared_buffers là shared memory giữa các process; double buffering có chủ đích: dữ liệu nằm cả ở shared_buffers và Page Cache (Postgres đọc ghi qua buffered IO — tin kernel làm cache tầng hai, khác Oracle/MySQL-InnoDB dùng O_DIRECT tự quản 100%). ...

Tiếp nối khung phân tích của chương 15. Case 10 — File Descriptor Exhausted Triệu chứng: accept: too many open files / EMFILE; connection mới bị từ chối trong khi connection cũ vẫn chạy; có thể lan cả máy (ENFILE — trần toàn hệ thống). Bên trong kernel: mỗi process có bảng FD (chương 04, files_struct) giới hạn bởi RLIMIT_NOFILE (mặc định soft 1024 lịch sử — quá thấp cho server!); toàn máy bởi fs.file-max. FD không chỉ là file: socket, pipe, epoll, timerfd, eventfd — mọi thứ là FD. Cạn FD thường là leak: quên close socket khi lỗi giữa chừng, response body không đóng (Go resp.Body.Close() — bug số một của HTTP client Go), connection pool cấu hình vô hạn. ...

Mỗi case theo khung: Triệu chứng → Root cause phổ biến → Bên trong kernel → Metric & Dashboard → Điều tra từng bước → Khắc phục → Phòng tránh. Các lệnh mặc định chạy được trên mọi máy Linux; công cụ eBPF (bcc-tools) khi có càng tốt. Kiến thức nền: chương tương ứng ghi trong ngoặc. Case 1 — CPU 100% Triệu chứng: %CPU chạm trần; latency tăng; có thể kèm autoscale bùng nổ chi phí. ...

1. Problem Statement Mô hình Unix nguyên thủy chỉ có hai hạng người: root (uid 0) — làm được tất cả, và còn lại — bị giới hạn bởi quyền file. Hai vấn đề chết người: (1) nhiều tác vụ chỉ cần một mẩu quyền root (bind port 80, đổi giờ) nhưng phải trao cả root — ping từng phải setuid-root chỉ để mở raw socket; (2) quyền file không nói gì về hành vi: một process bị khai thác (RCE trong thư viện parse ảnh) được làm mọi thứ user đó làm được — đọc DB credential, mở kết nối ra ngoài, fork shell. ...

1. Problem Statement Bài toán kinh doanh: đóng gói app + dependency thành một đơn vị chạy được ở mọi nơi, khởi động trong milli-giây, nhét hàng chục cái vào một máy, cô lập vừa đủ để không giẫm chân nhau. VM giải được cô lập nhưng trả giá: mỗi VM một kernel + OS riêng (GB memory, khởi động chục giây, density thấp). Câu trả lời của Linux: không cần máy ảo — chỉ cần nói dối process một cách có hệ thống. Container = process bình thường + ba lớp cơ chế kernel: namespace (thấy gì), cgroup (dùng bao nhiêu), capability/seccomp/LSM (làm được gì — chương 14). Không có “Container Kernel Object” nào cả — docker chỉ là trình lắp ráp các cơ chế này. ...

1. Problem Statement Production chậm. Bạn có 30 phút và một máy 64 core đang chạy 200 process. Câu hỏi không phải “gõ lệnh gì” mà là: mỗi công cụ nhìn hệ thống qua cửa sổ nào, trả giá bao nhiêu để nhìn, và nói dối ở đâu. Không hiểu cơ chế thì: dùng strace làm sập production (overhead 100x), đọc %util của NVMe như HDD (sai), tin flame graph thiếu frame (vì thiếu frame pointer), hay đo latency bằng trung bình (che mất tail). ...

1. Problem Statement NIC là phần cứng nhận/gửi frame Ethernet thô. Ứng dụng muốn một thứ hoàn toàn khác: “một kết nối đáng tin cậy tới host X, gửi byte theo thứ tự, đừng làm mất, đừng làm nghẽn mạng”. Khoảng cách giữa hai thế giới đó — checksum, định tuyến, phân mảnh, retransmit, congestion control, ghép kênh theo port — chính là network stack trong kernel. Đây là mã đường-nóng lớn nhất và được tối ưu khốc liệt nhất của Linux: mọi request tới backend của bạn đi qua nó hai lần (vào và ra). ...

1. Problem Statement Server có 10.000 connection. Tại mỗi thời điểm chỉ vài trăm connection có dữ liệu; còn lại im lặng. Câu hỏi định hình cả một thế hệ kiến trúc backend: làm sao biết connection nào sẵn sàng mà không tốn một thread cho mỗi connection và không đốt CPU quay vòng hỏi? Đây là “bài toán C10K” (1999) — và mỗi IO model là một câu trả lời ở một thời kỳ. ...

1. Problem Statement Disk (NVMe/SSD/HDD) là một mảng block 512B/4KB đánh số từ 0 đến N. Không tên file, không thư mục, không quyền, không đảm bảo gì khi mất điện giữa chừng. Filesystem phải dựng trên đó: không gian tên phân cấp, quyền sở hữu, cấp phát không phân mảnh, và quan trọng nhất — tính toàn vẹn khi crash (crash consistency). Cộng thêm yêu cầu hiệu năng: disk chậm hơn RAM 100-1000 lần → phải cache quyết liệt — và cache chính là nơi sinh ra khoảng cách giữa “đã ghi” và “đã bền vững”, khoảng cách gây ra nhiều sự cố mất dữ liệu nhất trong nghề backend. ...

1. Problem Statement Hai thread cùng chạy counter++. Lệnh này thực chất là ba bước: load → add → store. Xen kẽ giữa hai thread → mất update. Đây là data race — nguồn bug khó tái hiện bậc nhất, và với CPU hiện đại còn tệ hơn trực giác: compiler đảo lệnh, CPU thực thi out-of-order, mỗi core có store buffer riêng — không có “thứ tự toàn cục” tự nhiên nào giữa các core cả. Muốn có, phải trả tiền để mua nó, bằng các primitive của chương này. ...

1. Problem Statement RAM là một mảng byte vật lý hữu hạn, phẳng, ai cũng thấy như nhau. Ta cần: (1) mỗi process một không gian địa chỉ riêng, cô lập; (2) tổng memory các process tưởng mình có được phép vượt RAM thật; (3) cấp phát/thu hồi linh hoạt không phân mảnh chết; (4) tận dụng RAM thừa làm cache cho disk. Virtual memory giải cả bốn — với cái giá là mọi truy cập memory đều phải qua một tầng dịch địa chỉ. ...

1. Problem Statement Máy có 32 core; tại một thời điểm có 80 task muốn chạy (runnable). Ai chạy? Chạy bao lâu? Trên core nào? Sai câu trả lời nào cũng có hậu quả: task quan trọng chờ lâu (latency), CPU nhảy task liên tục (mất throughput vì context switch + cache nguội), task nào đó đói vĩnh viễn (starvation), core này 100% core kia rảnh (mất tiền). Nếu không có scheduler: quay lại chương 01 — while(1) chiếm CPU mãi mãi. Scheduler + timer interrupt là bộ đôi biến “một CPU” thành “ảo ảnh nhiều CPU”. ...

1. Problem Statement Process cô lập tốt nhưng trả giá: hai process muốn chia sẻ dữ liệu phải đi đường vòng (pipe, socket, shared memory — đều qua kernel hoặc setup phức tạp), và tạo/chuyển process tương đối đắt. Nhiều bài toán cần điều ngược lại: nhiều dòng thực thi đồng thời trên cùng một khối dữ liệu — web server xử lý 10.000 connection, database xử lý nhiều query cùng chạm một buffer pool. ...

1. Problem Statement CPU chỉ có một dòng lệnh; RAM là một khối phẳng. Nhưng ta muốn chạy 500 chương trình “đồng thời”, mỗi cái tưởng mình sở hữu cả máy. Process là câu trả lời: một gói đóng kín gồm (code + data + trạng thái CPU + tài nguyên) mà kernel có thể đóng băng, hồi sinh, cô lập, và thu hồi. Nếu không có process: không chạy được nhiều chương trình; không giết được chương trình treo; một chương trình lỗi kéo sập tất cả; không có khái niệm “quyền của ai”. ...

1. Problem Statement Chương 01 kết luận: cần một trọng tài không thể bị qua mặt. Chương 02 cho thấy phần cứng cung cấp nguyên liệu: privilege ring, trap, interrupt. Chương này trả lời: kernel dựng ranh giới bảo vệ bằng nguyên liệu đó như thế nào, và một chương trình “xin” kernel làm việc qua cơ chế gì. Nếu không có ranh giới user/kernel: mọi process đều đọc được memory của nhau và của kernel (mật khẩu, key, dữ liệu khách hàng); mọi process đều ra lệnh trực tiếp cho disk/NIC (phá nát filesystem, giả mạo packet); không thể có multi-tenant, không thể có cloud. Nếu không có syscall: có ranh giới nhưng không có cửa — chương trình không làm được gì hữu ích. ...

1. Problem Statement Kernel không chạy trong chân không — nó chạy trên CPU thật, RAM thật, với những giới hạn vật lý thật. Mọi quyết định thiết kế lớn của Linux đều là phản ứng trước một giới hạn phần cứng cụ thể. Không hiểu phần cứng thì mọi giải thích về kernel đều thành học thuộc lòng. Nếu bỏ qua chương này: bạn sẽ không hiểu vì sao context switch đắt (cache pollution), vì sao lock contention giết throughput (cache line bouncing), vì sao cùng một đoạn code chạy chậm gấp 3 trên máy 2 socket (NUMA), vì sao kernel có thể giật CPU từ một vòng lặp vô hạn (timer interrupt). ...

1. Problem Statement Bạn có một dịch vụ backend: nhận HTTP request, đọc database, trả JSON. Bài toán kinh doanh rất đơn giản: phục vụ nhiều người dùng nhất có thể, nhanh nhất có thể, trên phần cứng rẻ nhất có thể, và không được sập. Bây giờ hãy thử làm điều đó không có hệ điều hành. Bài tập tư duy này là nền của toàn bộ tài liệu: mỗi lần bạn gặp một cơ chế kernel phức tạp (page table, futex, epoll…), hãy quay lại đây và hỏi — nếu không có nó, mình phải tự làm gì? ...

Bộ tài liệu chuyên sâu về hệ điều hành, tập trung vào Linux, viết cho Backend Engineer, Senior Backend Engineer, Tech Lead và Architect. Mục tiêu không phải là học lệnh Linux — mà là hiểu tại sao hệ thống hoạt động như vậy, điều gì xảy ra bên trong kernel khi backend của bạn chạy trong production, và trade-off đằng sau mỗi quyết định thiết kế. Cách đọc bộ tài liệu này Mỗi chương đi theo một template thống nhất: ...