Giải thích về quản lý bộ nhớ Linux: swap, OOM killer và cgroups

Linux xử lý bộ nhớ khác với hầu hết các hệ điều hành. Việc sử dụng RAM cao không phải lúc nào cũng là vấn đề — nhân hệ điều hành chủ động sử dụng bộ nhớ trống để lưu trữ tạm thời nhằm tăng tốc độ đọc đĩa. Nhưng khi áp lực bộ nhớ thực sự gia tăng, ba cơ chế sẽ phát huy tác dụng: swap, OOM killer và cgroups. Hiểu cách thức hoạt động của từng cơ chế và cách cấu hình chúng là yếu tố quyết định sự khác biệt giữa một máy chủ hoạt động ổn định khi chịu tải và một máy chủ bị sập mà không có cảnh báo.

Cách Linux quản lý các trang bộ nhớ

Mỗi quá trình chạy trong không gian địa chỉ ảo riêng của mình, lên đến 128 TB trên các hệ thống 64-bit. Hạt nhân ánh xạ các địa chỉ ảo này sang RAM vật lý thông qua các bảng trang, với bộ đệm TLB (Translation Lookaside Buffer) lưu trữ các truy vấn gần đây. Một lần trúng TLB mất khoảng 1 nano giây; một lần trượt tốn 20–100 nano giây, điều này tích lũy trong các tác vụ đòi hỏi nhiều bộ nhớ như cơ sở dữ liệu.

Bộ nhớ vật lý được chia thành các trang 4 KB, và nhân hệ điều hành chia chúng thành hai loại:

• Các trang được hỗ trợ bởi tệp — gắn liền với các tệp trên đĩa. Hệ điều hành có thể loại bỏ các trang sạch hoặc xóa các trang bẩn mà không cần đến bộ nhớ ảo.
• Các trang ẩn danh — bộ nhớ heap và stack không có tệp hỗ trợ. Các trang này phải được ghi vào vùng hoán đổi trước khi nhân hệ điều hành có thể giải phóng chúng.

Trên các máy chủ có nhu cầu bộ nhớ cao, tỷ lệ lớn các trang ẩn danh có nghĩa là bộ nhớ ảo sẽ được sử dụng sớm. Hãy theo dõi si (swap in) và so (swap out) trong vmstat 1 — các giá trị không bằng 0 liên tục là cảnh báo đầu tiên cho thấy hệ thống đang chịu áp lực.

Để giám sát, hãy sử dụng công cụ phù hợp cho công việc:

Một sai lầm phổ biến: theo dõi free cột free -h và hoảng loạn. Cột available cột mới là điều quan trọng. Nó bao gồm bộ nhớ mà kernel có thể thu hồi từ bộ đệm theo yêu cầu. Một máy chủ chỉ hiển thị 512 MB trống nhưng có 5 GB khả dụng thì không gặp vấn đề gì.

Khi bộ nhớ giảm xuống dưới ngưỡng, kswapd bắt đầu thu hồi các trang bộ nhớ ở chế độ nền. Nếu điều đó không đủ, nhân hệ thống sẽ chuyển sang chế độ thu hồi trực tiếp, chặn các tiến trình cho đến khi các trang bộ nhớ được giải phóng. Đây chính là nguyên nhân gây ra các đỉnh độ trễ. Hãy thiết lập cảnh báo khi MemAvailable giảm xuống dưới 10–15% tổng dung lượng RAM để bạn có thời gian phản ứng.

Cấu hình swap

Swap là một vùng đĩa — có thể là một phân vùng hoặc một tệp — nơi nhân hệ điều hành di chuyển các trang bộ nhớ không hoạt động khi RAM đầy. Sự chênh lệch về tốc độ là đáng kể: RAM DDR4 có độ trễ khoảng 100 ns, trong khi SSD NVMe khoảng 100.000 ns và SSD SATA gần 500.000 ns. Swap là một vùng đệm an toàn, không phải là RAM bổ sung. Một máy chủ liên tục phụ thuộc vào swap có vấn đề về bộ nhớ mà việc tăng swap sẽ không giải quyết được.

Sử dụng tệp swap thay vì phân vùng. Tệp dễ dàng thay đổi kích thước hơn và không cần phân vùng lại.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Thêm tệp vào /etc/fstab để duy trì dữ liệu qua các lần khởi động lại. chmod 600 bước này là bắt buộc — bất kỳ dữ liệu nào được chuyển ra khỏi RAM đều có thể đọc được từ swap, do đó tệp không được cho phép đọc bởi người dùng khác.

Sau khi tạo swap, hãy điều chỉnh vm.swappiness. Giá trị mặc định là 60 khá cao. Đối với hầu hết các tác vụ lưu trữ, bạn muốn kernel ưu tiên RAM và chỉ sử dụng tệp hoán đổi như phương án cuối cùng:

Đối với kích thước vùng swap: 1–2 GB là đủ cho một VPS 2 GB xử lý các đợt tăng đột biến lưu lượng thỉnh thoảng. Trên các hệ thống có 8 GB RAM trở lên, vùng swap cố định 2–4 GB thường là đủ. Mục tiêu là cung cấp cho kernel một "van xả áp" cho các trang bộ nhớ không hoạt động, chứ không phải để mở rộng bộ nhớ địa chỉ tổng thể.

Trên các máy chủ bị giới hạn RAM nhưng có CPU dồi dào, zram tạo ra một vùng swap nén trong bộ nhớ, tránh hoàn toàn I/O đĩa. Điều này đáng được xem xét trên các máy chủ VPS đa người thuê, nơi NVMe được chia sẻ giữa các người thuê. Hãy chú ý đến sự tranh chấp I/O nếu vùng swap nằm trên cùng một thiết bị với các tệp cơ sở dữ liệu — việc trao đổi dữ liệu nặng và ghi đĩa thông lượng cao không thể cùng tồn tại tốt.

OOM killer

Khi kernel cạn kiệt RAM và swap và không thể thu hồi đủ bộ nhớ bằng các phương pháp khác, OOM killer sẽ can thiệp. Nó chấm điểm các tiến trình bằng cách sử dụng oom_badness() hàm:

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

Quá trình có điểm số cao nhất sẽ bị giết. Công thức này ưu tiên các quá trình tiêu thụ nhiều bộ nhớ, và nhân hệ điều hành tránh giết nhiều quá trình liên tiếp bằng cách kiểm tra xem một quá trình đã bị kết thúc trong 5 giây qua hay chưa.

Hai loại sự kiện OOM xuất hiện trong nhật ký:

• Global OOM — toàn bộ hệ thống đã hết RAM và vùng swap. Nhật ký có tiền tố Out of memory:
• Cgroup OOM — một container hoặc dịch vụ đã đạt đến memory.max giới hạn. Nhật ký có tiền tố Memory cgroup out of memory:

Để xem lại các sự kiện OOM trong quá khứ:

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

Hãy chú ý đến trường order trong nhật ký OOM. Giá trị lớn hơn 0 cho thấy tình trạng phân mảnh bộ nhớ chứ không phải cạn kiệt hoàn toàn — nhân hệ thống không thể tìm thấy đủ các trang liên tục ngay cả khi có bộ nhớ trống sẵn có.

Bạn có thể điều chỉnh các quy trình mà OOM killer nhắm đến bằng cách điều chỉnh /proc/<pid>/oom_score_adj. Phạm vi là từ -1000 (không bao giờ giết) đến +1000 (giết trước). Đối với các dịch vụ được quản lý bởi systemd, hãy thiết lập giá trị này vĩnh viễn trong tệp đơn vị:

[Service]
OOMScoreAdjust=-1000

Các tham số sysctl bổ sung để điều chỉnh hành vi OOM:

Để giám sát chủ động, hãy kiểm tra /proc/pressure/memory (Thông tin về Tình trạng Ứng lực, có sẵn từ kernel 4.20). Theo dõi some avg10 giá trị: dưới 5% là bình thường, duy trì trên 20% có nghĩa là sự kiện OOM có khả năng sắp xảy ra. Một allocstall đếm trong /proc/vmstat là một tín hiệu sớm khác — nó đếm các lần dừng thu hồi trực tiếp, thường xảy ra trước khi OOM giết tiến trình. Các công cụ như systemd-oomd hoặc earlyoom có thể thực hiện hành động dựa trên các ngưỡng PSI trước khi trình OOM killer của kernel kích hoạt.

Cgroups và giới hạn bộ nhớ

Các nhóm kiểm soát (cgroups) cho phép bạn tổ chức các quy trình thành các nhóm và áp dụng các giới hạn tài nguyên cứng. Được giới thiệu trong Linux 2.6.24, chúng là nền tảng của các runtime container bao gồm Docker, Podman, Kubernetes và LXC. Hệ điều hành theo dõi việc sử dụng bộ nhớ theo từng cgroup, bao gồm bộ nhớ ẩn danh, trang bộ nhớ dựa trên tệp và các đối tượng hệ điều hành. Nếu một cgroup đạt đến giới hạn của mình, hệ điều hành sẽ thu hồi bộ nhớ trong nhóm đó hoặc kích hoạt lệnh OOM kill trong phạm vi cgroup.

Cgroup v1 và v2 khác nhau chủ yếu ở cách cấu trúc. V1 gắn riêng từng bộ điều khiển (bộ nhớ, CPU, I/O) dưới /sys/fs/cgroup/<controller>/, dẫn đến việc theo dõi tài nguyên không nhất quán. V2 sử dụng một hệ thống phân cấp thống nhất tại /sys/fs/cgroup/. Kubernetes đã chuyển sang v2 làm mặc định từ phiên bản 1.25 và ngừng hỗ trợ v1 từ phiên bản 1.31.

Để kiểm tra hệ thống của bạn đang sử dụng phiên bản nào:

stat -fc %T /sys/fs/cgroup/

cgroup2fs có nghĩa là v2; tmpfs thường có nghĩa là v1.

Các điều khiển bộ nhớ chính trong cgroup v2:

Một quy tắc thực tế: đặt memory.high khoảng 10–20% dưới memory.max để tạo không gian cho kernel thu hồi trước khi đạt đến giới hạn cứng. Khi xác định kích thước memory.max, hãy thêm 20–30% so với mức sử dụng cao nhất của ứng dụng để tính đến bộ đệm trang, vốn được tính vào tổng bộ nhớ của cgroup.

Quản lý cgroups thông qua systemd thay vì ghi trực tiếp vào hệ thống tệp cgroup. Sử dụng các chỉ thị tệp đơn vị như MemoryMax=, MemoryHigh=và MemoryMin= để thiết lập giới hạn cố định. Để kiểm tra nhanh:

systemd-run --scope -p MemoryMax=512M <command>

Đối với các nhóm công nhân máy chủ web, việc thiết lập memory.oom.group=1 đảm bảo việc ngắt kết nối sạch sẽ nếu một công nhân vượt quá giới hạn của nó — không để lại các tiến trình mồ côi. Đối với các hệ thống cơ sở dữ liệu, memory.min bảo vệ vùng đệm khỏi bị thu hồi khi hệ thống gặp áp lực toàn hệ thống.

Cấu hình bộ nhớ theo vai trò máy chủ

Cài đặt bộ nhớ phù hợp phụ thuộc vào chức năng của máy chủ. Áp dụng cùng một cấu hình cho cơ sở dữ liệu và máy chủ web PHP sẽ gây ảnh hưởng xấu đến một trong hai.

Đối với MySQL và PostgreSQL, hãy phân bổ 50–70% RAM khả dụng cho innodb_buffer_pool_size, vô hiệu hóa Transparent Huge Pages để giảm các đợt tăng đột biến độ trễ, và bảo vệ quá trình bằng OOMScoreAdjust=-900 trong tệp đơn vị systemd.

Đối với PHP-FPM, xác định kích thước nhóm worker dựa trên mức sử dụng bộ nhớ thực tế. Mỗi worker thường sử dụng 30–100 MB. Chia RAM đã phân bổ cho kích thước trung bình của worker để có được một pm.max_children . Sử dụng memory.max trong cgroups để giới hạn nhóm.

Đối với các tác vụ có nhiều thao tác ghi, hãy đặt vm.dirty_ratio khoảng 10% và vm.dirty_background_ratio là 3%. Điều này giúp xóa các trang bẩn thường xuyên hơn, tránh tình trạng I/O bị đình trệ nghiêm trọng.

Làm cho việc điều chỉnh kernel trở nên bền vững bằng cách lưu các tham số vào /etc/sysctl.d/90-memory.conf. Các thiết lập được áp dụng trong thời gian chạy sẽ bị mất khi khởi động lại.

Để xem tóm tắt các giá trị được khuyến nghị theo vai trò:

Nếu bạn đang chạy các khối lượng công việc mật độ cao và cần một máy chủ có dung lượng dự phòng để áp dụng các chính sách này một cách thích hợp, các máy chủ chuyên dụng của FDC là lựa chọn đáng xem xét.