Tối ưu VPS cho automation: swap, ulimit và tmpfs

Chạy các tác vụ automation bằng trình duyệt (headless Chrome, Playwright, Puppeteer) trên VPS sau một thời gian, bạn sẽ thấy VPS bắt đầu ì ạch, job treo hoặc crash với lỗi "cannot open shared object file" hay "too many open files". Vấn đề thường không nằm ở phần mềm chính, mà ở ba tham số cấp thấp của hệ điều hành: swap, ulimit, và tmpfs. Ba thứ này nếu cấu hình tùy chỉnh cho riêng Workload automation sẽ giúp VPS của bạn giảm ngốn RAM, ít crash, và ổn định hơn hẳn.

Tóm tắt nhanh

• Swap: công tắc cứu hộ RAM, nên đặt 50-rất cao RAM khả dụng, ưu tiên swapfile trên NVMe.
• Ulimit: giới hạn số file một process có thể mở, tăng lên 262144 cho service automation.
• Tmpfs: thư mục tạm chạy trên RAM, dùng cho Chrome sandbox và cache để giảm I/O SSD, tăng tốc.

Yêu cầu trước khi bắt đầu

• VPS cài Ubuntu 24.04 LTS (hướng dẫn này dùng Ubuntu, các lệnh đã kiểm trên bản này).
• Quyền root hoặc sudo không mật khẩu.
• Đã cài các công cụ automation (headless Chrome, Playwright, Puppeteer, OpenClaw).
• Ít nhất 2 GB RAM và ổ NVMe, đúng với dòng VPS NVMe phổ biến hiện nay.

Vì sao ba tham số này quan trọng với automation

Không giống web server hay database, automation dùng trình duyệt có đặc thù rất riêng: mỗi instance Chrome có thể ngốn 200-600 MB RAM, đồng thời mở hàng trăm file (shared libraries, cache, profiles). Nếu RAM đầy và không có swap, OOM Killer sẽ tóm gọn tiến trình Chrome, khiến job thất bại. Nếu ulimit quá thấp, Chrome không thể mở đủ file để load page, crash với lỗi EMFILE. Và nếu thư mục tạm nằm trên ổ cứng (dù là NVMe), I/O vẫn có thể gây chậm khi có nhiều screenshot hay PDF được sinh ra.

Chỉnh ba giá trị này là việc đầu tiên mình làm khi setup bất kỳ VPS automation nào. Công sức bỏ ra khoảng 15 phút, nhưng giảm được 70-80% lỗi crash ngẫu nhiên.

Bước 1, Cấu hình swap hợp lý cho VPS automation

Swap là vùng trên ổ cứng được dùng làm RAM dự phòng. Với automation, swap nên có nhưng không nên quá lớn (nếu quá lớn, kernel sẽ ỷ lại và đẩy process ra swap thay vì giữ trong RAM).

Công thức mình hay dùng: Swap = 50-rất cao RAM khả dụng. Với VPS 4 GB RAM, swap 2-4 GB là vừa. Với 2 GB RAM, đặt 2 GB. Trên NVMe, tốc độ swap rất nhanh (700+ MB/s đọc/ghi), đỡ giật so với ổ HDD.

Kiểm tra swap hiện tại:

swapon --show
free -h

Nếu chưa có swap hoặc muốn thay đổi, dùng swapfile trên phân vùng gốc (recommended trên VPS):

# Tắt swap cũ (nếu có)
swapoff -a

# Tạo swapfile 4 GB (nhân 1024*1024*4 = 4194304 blocks)
dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Thêm vào fstab để tự động mount sau reboot
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

Kiểm tra lại:

swapon --show
free -h

Output mong đợi: thấy swapfile 4G, "Swap total" trong free -h tăng tương ứng.

Cảnh báo: Không tạo swap lớn hơn RAM nếu bạn chạy nhiều job song song, kernel sẽ swap nhiều thay vì giữ tiến trình trong RAM, gây chậm toàn hệ thống. Swappiness (vm.swappiness) nên để 10 (mặc định 60) để ưu tiên RAM:

sysctl vm.swappiness=10
echo 'vm.swappiness=10' | tee -a /etc/sysctl.conf

Bước 2, Tăng ulimit cho process của automation

Mỗi tiến trình (process) trên Linux có giới hạn số file descriptors (FD) có thể mở cùng lúc. Mặc định thường là 1024, quá thấp cho headless Chrome khi render trang web có nhiều tài nguyên (ảnh, CSS, JS, font). Lỗi "too many open files" là dấu hiệu kinh điển.

Kiểm tra giới hạn hiện tại của user đang chạy automation:

ulimit -n

Nếu ra 1024 hoặc 4096, cần nâng lên.

Cách làm đúng: thay đổi qua systemd service hoặc file /etc/security/limits.conf. Vì bạn đang chạy automation dưới dạng service (vd OpenClaw, n8n dùng Docker, script systemd), cách clean nhất là thêm vào service unit.

Ví dụ với service openclaw.service:

[Service]
LimitNOFILE=262144

Nếu bạn chạy bằng tay từ shell, sửa file limits.conf:

echo '* soft nofile 262144' | tee -a /etc/security/limits.conf
echo '* hard nofile 262144' | tee -a /etc/security/limits.conf

Sau đó logout/login lại hoặc restart service. Kiểm tra:

ulimit -n

Output mong đợi: 262144.

Lưu ý: Với Docker, cần thêm --ulimit nofile=262144:262144 vào docker run hoặc trong docker-compose.yml:

ulimits:
  nofile:
    soft: 262144
    hard: 262144

Mức 262144 là con số an toàn cho hầu hết VPS 2-8 GB RAM. Với VPS 16 GB chạy 50+ instance Chrome, có thể nâng lên 524288.

Bước 3, Dùng tmpfs cho thư mục tạm của Chrome

Chrome sử dụng thư mục /tmp để lưu cache, session, sandbox. Nếu để trên ổ NVMe, mỗi lần chụp ảnh, xuất PDF, hay render trang là có I/O ghi vào ổ đĩa. Không nguy hiểm, nhưng không tối ưu. Tmpfs là một vùng filesystem trên RAM, cực nhanh (tốc độ bằng RAM, ~40-60 GB/s), và tự động xóa khi reboot, rất phù hợp cho dữ liệu tạm của automation.

Các thư mục thường dùng trong automation:

• /tmp, mặc định nhiều bản Ubuntu đã là tmpfs rồi (kiểm tra bằng df -h /tmp nếu thấy tmpfs là tốt).
• /dev/shm, default tmpfs, Chrome dùng cho shared memory.

Nếu bạn muốn tạo thêm thư mục tmpfs riêng cho cache/screenshot:

# Tạo thư mục
mkdir -p /mnt/chrome-cache

# Mount tmpfs 1 GB
mount -t tmpfs -o size=1G tmpfs /mnt/chrome-cache

# Thêm vào fstab để mount lại khi reboot
echo 'tmpfs /mnt/chrome-cache tmpfs defaults,noatime,size=1G 0 0' | tee -a /etc/fstab

Sau đó cấu hình Chrome flag --disk-cache-dir=/mnt/chrome-cache trong script/command launch trình duyệt. Headless Chrome không cần cache lâu dài, tmpfs 1 GB là đủ cho vài giờ chạy.

Kiểm tra mount:

df -h /mnt/chrome-cache
mount | grep tmpfs

Output mong đợi: filesystem tmpfs, size 1G, usage thấp (0-100 MB).

Mẹo: Trên VPS 4 GB RAM, mình thường dành tối đa 1 GB cho tmpfs. Nếu RAM eo hẹp (2 GB), hãy để default, không tạo thêm, vì Chrome đã dùng /dev/shm sẵn rồi.

Bước 4, Đo lại sau khi chỉnh

Chạy một kịch bản test automation cơ bản để xem sự khác biệt.

Đo trước khi chỉnh (lưu lại làm baseline):

# Số file descriptors đang mở của process
lsof -p $(pgrep -x chrome) 2>/dev/null | wc -l

# RAM usage
ps -e --format pid,cmd,%mem,%cpu | grep chrome

# Disk I/O trên /tmp (nếu đang dùng)
iostat -x 1 5

Chạy test automation trong 5-10 phút, rồi làm lại các lệnh trên. Bạn sẽ thấy:

• RAM vẫn ở mức hợp lý, không bị OOM.
• Swap usage thấp (dưới 10% swap dùng).
• Lỗi "too many open files" biến mất.
• I/O trên /tmp về gần 0 nhờ tmpfs.

Câu lệnh kiểm tra nhanh tình trạng swap:

free -h | grep Swap

Output mong đợi: "Swap total" bằng swapfile đã tạo, "used" dưới 500 MB khi không chạy nhiều.

Xử lý lỗi thường gặp

Lỗi 1: Swapfile không được mount sau reboot

Kiểm tra /etc/fstab có dòng swapfile chưa. Lệnh blkid /swapfile không ra UUID là bình thường, swapfile không có UUID. Chỉ cần đúng path và sw là được. Nếu vẫn không được, chạy systemctl daemon-reload hoặc chỉnh fstab thành /swapfile none swap sw 0 0.

Lỗi 2: ulimit không áp dụng cho service systemd

Nếu bạn sửa /etc/security/limits.conf nhưng service chạy vẫn bị giới hạn 1024, nguyên nhân là systemd không đọc limits.conf cho service, nó dùng giá trị trong unit file. Cần thêm LimitNOFILE=262144 trực tiếp vào /etc/systemd/system/your-service.service, chạy systemctl daemon-reload rồi systemctl restart your-service.

Lỗi 3: Tmpfs không đủ dung lượng

Khi chạy nhiều instance Chrome song song, tmpfs 1 GB có thể đầy nhanh. Kiểm tra df -h xem usage. Nếu đầy, tăng size lên, nhưng nhớ dành RAM cho process chính. Trên VPS chạy OpenClaw với headless Chrome, mình dùng 1.5 GB tmpfs cho 10 job đồng thời và vẫn ổn.

Câu hỏi thường gặp

Bài viết liên quan

• Headless Chrome ngốn RAM, cách đo và giới hạn
• Vì sao automation trình duyệt cần IP riêng
• Chọn RAM cho n8n theo số workflow chạy song song
• Lập lịch job automation đại hội bằng systemd timer