Giới hạn tài nguyên hosting CPU, RAM: đặt bao nhiêu cho đúng?

Giới hạn tài nguyên hosting là mức trần CPU, RAM, số tiến trình, tốc độ đọc ghi đĩa, dung lượng và số file mà mỗi tài khoản hosting được dùng. Trên Linux, CPU, RAM, tiến trình và I/O được kernel áp dụng qua cgroups, còn dung lượng và inode qua disk quota. Mục đích không phải là bóp khách hàng, mà là để một website bị bot đánh, một plugin lỗi hay một mã độc đào coin chỉ làm chậm tài khoản của chính nó, thay vì kéo sập cả server.

Bài viết giải thích từng loại giới hạn, cách Linux thực thi chúng, cách tính để các gói hosting không "hứa" nhiều hơn RAM thật, và cách thiết lập trên ZoPanel lẫn thủ công.

Vì sao server hosting cần giới hạn tài nguyên cho từng tài khoản?

Trên một server chung, mọi website dùng chung một CPU, một khối RAM và một ổ đĩa. Không có giới hạn, chỉ cần một tài khoản gặp sự cố là cả trăm website khác chậm theo. Những tình huống chúng tôi thấy thường xuyên nhất:

• Bot và crawler gọi liên tục các URL không cache được (tìm kiếm, bộ lọc sản phẩm), mỗi request là một lần chạy PHP và truy vấn database.
• Plugin lỗi chạy vòng lặp vô hạn hoặc truy vấn nặng trên mọi trang.
• Website bị hack chạy mã đào coin, gửi spam hàng loạt hay mở hàng trăm tiến trình.
• Một khách hàng thật sự đông khách, ví dụ cửa hàng đang chạy quảng cáo: chuyện tốt, nhưng khách đó nên dùng gói lớn hơn.

Giới hạn biến những sự cố này thành vấn đề của một tài khoản, và cũng là cơ sở để bán gói theo tầng: gói lớn được nhiều CPU, RAM và PHP worker hơn.

Có những loại giới hạn tài nguyên hosting nào?

Giới hạn	Đo cái gì	Khi vượt thì sao
CPU	Phần trăm của một nhân (100% = một nhân, 200% = hai nhân)	Tiến trình bị điều tiết, website chậm lại nhưng không lỗi
RAM	Bộ nhớ của mọi tiến trình trong tài khoản cộng lại	Kernel dừng tiến trình trong tài khoản đó, thường là một PHP worker
Số tiến trình	Tổng tiến trình và luồng	Không tạo được tiến trình mới, request mới có thể lỗi
Tốc độ đĩa (I/O)	MB/s đọc ghi	Thao tác đĩa bị chậm lại
Dung lượng đĩa	MB	Ghi file thất bại cho riêng tài khoản đó
Số file (inode)	Số file và thư mục	Không tạo được file mới
Kết nối database	Số kết nối đồng thời của một user database	Kết nối mới bị từ chối
Email mỗi giờ	Số người nhận gửi đi	Thư vượt mức bị từ chối
PHP worker	Số request PHP chạy cùng lúc	Request xếp hàng chờ

Hai giới hạn hay bị hiểu nhầm nhất là CPU và RAM. CPU là tài nguyên "co giãn": vượt mức chỉ làm chậm. RAM thì không co giãn: khi một tài khoản chạm trần, kernel phải dừng một tiến trình của tài khoản đó. Vì vậy đặt RAM quá thấp sẽ thấy lỗi 502 hoặc 503 ngắt quãng, còn đặt CPU quá thấp chỉ thấy website chậm.

Linux áp dụng giới hạn như thế nào?

cgroups và systemd

Ubuntu từ 21.10 và Debian từ 11 mặc định dùng cgroups v2. systemd quản lý cgroups qua các "slice": đặt mọi tiến trình của một tài khoản vào một slice, rồi gắn giới hạn lên slice đó. Các thuộc tính chính, theo tài liệu systemd.resource-control:

• CPUQuota= tính theo phần trăm của một CPU, có thể vượt 100% khi cho phép nhiều nhân.
• MemoryHigh= điều tiết và đòi lại bộ nhớ khi vượt; MemoryMax= là trần cứng, vượt thì kernel dừng tiến trình.
• TasksMax= giới hạn số tiến trình và luồng.
• IOReadBandwidthMax= và IOWriteBandwidthMax= giới hạn tốc độ đọc ghi trên một thiết bị.

Bạn có thể thử với slice của một user đã đăng nhập:

# Giới hạn user có UID 1001: một nhân CPU, 1 GB RAM, 200 tiến trình
sudo systemctl set-property user-1001.slice CPUQuota=100% MemoryMax=1G TasksMax=200

# Xem slice nào đang dùng nhiều tài nguyên
sudo systemd-cgtop

Điểm khó khi làm thủ công: PHP-FPM mặc định chạy mọi pool dưới một tiến trình master trong php8.3-fpm.service. Khi đó PHP của mọi khách nằm trong cùng một cgroup, nên giới hạn theo slice của user không áp dụng cho PHP, vốn là thứ tốn tài nguyên nhất. Muốn giới hạn thật sự theo tài khoản, mỗi tài khoản cần PHP-FPM master riêng chạy trong slice riêng, kèm cron và tiến trình SSH của tài khoản đó. Đây là phần việc mà control panel nên làm thay bạn.

Disk quota

Dung lượng và inode được giới hạn bằng quota của filesystem. Phân vùng chứa /home phải mount với tuỳ chọn usrquota (ext4) hoặc uquota (XFS), sau đó bật quota và đặt mức cho từng user. Kiểm tra nhanh:

sudo repquota -a        # dung lượng và inode đang dùng của mọi user

Không có quota, dung lượng chỉ được "đo" chứ không bị chặn, và một tài khoản có thể ghi đầy cả ổ đĩa, làm database và mail của mọi người ngừng theo.

Database và email

MariaDB giới hạn kết nối theo user:

ALTER USER 'alice_shop'@'localhost' WITH MAX_USER_CONNECTIONS 30;

Giới hạn email mỗi giờ nằm ở mail server. Đây là lớp bảo vệ quan trọng: một website bị hack gửi spam có thể khiến IP server bị đưa vào blocklist, và lúc đó email của mọi khách đều vào spam.

Còn CloudLinux thì sao?

Trên server cPanel, DirectAdmin hay Plesk, cách phổ biến là CloudLinux OS, một bản phân phối thương mại. Công nghệ LVE của nó giới hạn CPU (SPEED), RAM vật lý (PMEM), I/O, IOPS, số tiến trình (NPROC) và số "entry process" (EP, số request đồng thời vào tài khoản), theo tài liệu của CloudLinux. Khi vượt EP, khách thấy lỗi 508. Ý tưởng tương tự cgroups, nhưng cần license CloudLinux riêng, ngoài license của panel. Hãy kiểm tra giá hiện tại trên trang của CloudLinux.

Đặt giới hạn bao nhiêu là hợp lý?

Không có con số chung cho mọi server, nhưng có cách tính để không tự bắn vào chân mình.

Bắt đầu từ RAM của PHP

Mỗi PHP worker của WordPress khi đang chạy thường chiếm vài chục MB, plugin nặng có thể hơn. Giới hạn RAM của gói phải chứa được số PHP worker cho phép:

RAM gói ≥ số PHP worker × RAM mỗi worker + phần cho cron, app, SSH

Ví dụ gói cho 10 PHP worker, mỗi worker khoảng 60 MB, cần ít nhất 600 MB cho PHP, nên 1 GB RAM là hợp lý. Nếu đặt 20 worker trong gói 512 MB, kernel sẽ dừng worker liên tục mỗi khi website đông khách.

Hiểu đúng chuyện "overselling"

Giới hạn RAM là trần, không phải phần giữ chỗ. Một server 8 GB có thể có 50 tài khoản, mỗi tài khoản trần 1 GB, vì phần lớn website vắng khách phần lớn thời gian. Đó là bán vượt có kiểm soát, cách mọi công ty shared hosting đang làm. Rủi ro nằm ở chỗ nhiều tài khoản cùng chạm trần một lúc. Vì vậy cần thêm một lớp bảo vệ ở cấp server: dành riêng một phần RAM cho MariaDB, mail, web server và chính control panel, để khách có tăng tải đến đâu thì bạn vẫn SSH vào được.

Dung lượng đĩa nên bán thận trọng hơn: đĩa đầy thì database và backup đều có thể thất bại.

Gợi ý điểm khởi đầu

Bảng dưới là điểm khởi đầu để bạn điều chỉnh theo khách thật, không phải con số đo được:

Gói	CPU	RAM	PHP worker	Tiến trình
Website giới thiệu	50–100%	512 MB–1 GB	5–10	100
Doanh nghiệp, blog đông khách	100–200%	1–2 GB	10–20	200
Cửa hàng WooCommerce	200% trở lên	2 GB trở lên	20 trở lên	300

Sau một hai tuần, hãy nhìn lịch sử tài nguyên thật. Tài khoản nào liên tục chạm trần là ứng viên để bán gói lớn hơn; tài khoản chưa bao giờ dùng quá 10% cho thấy server của bạn còn chỗ.

Những lỗi hay gặp

1. Không bật disk quota. Giới hạn dung lượng trên giao diện không có tác dụng nếu kernel không thực thi.
2. RAM gói nhỏ hơn số PHP worker cần. Website báo lỗi ngắt quãng, khách tưởng do code.
3. Đặt memory_limit của PHP lớn hơn RAM của cả gói. Một script nặng sẽ bị kernel dừng thay vì nhận lỗi PHP rõ ràng.
4. Không giới hạn email. Một website bị hack là đủ để IP server vào blocklist.

Thiết lập giới hạn tài nguyên trên ZoPanel

ZoPanel gom mọi giới hạn vào gói hosting. Vào Gói hosting, bấm Tạo gói hoặc sửa gói có sẵn. Chi tiết từng mục có trong tài liệu Gói hosting và giới hạn. Những điểm chính:

• CPU, RAM, số tiến trình và tốc độ đĩa được áp dụng bằng systemd cgroups lên mọi thứ tài khoản chạy: PHP, app, cron và shell. Mỗi tài khoản có slice riêng và pool PHP-FPM riêng, nên giới hạn áp dụng cả cho PHP. Tiến trình vượt RAM bị kernel dừng trong đúng tài khoản đó.
• Ổ đĩa và số file (inode) là quota của kernel. Hãy kiểm tra quota đang ở trạng thái đang áp dụng tại Cài đặt → Hệ thống → Hạn mức ổ đĩa (quota).
• Tốc độ đĩa để trống sẽ tự tính khoảng 40 MB/s cho mỗi GB RAM của gói, trong khoảng 30 đến 300 MB/s.
• Kết nối database để trống sẽ là 3 lần số PHP worker, tối thiểu 30.
• Email mỗi giờ đếm người nhận gửi qua PHP mail() và SMTP; thư vượt mức bị từ chối.
• PHP luôn chạy cho gói cao cấp: PHP không ngủ khi rảnh, đổi lại mỗi website giữ khoảng 20–60 MB RAM.

Gói Business do bộ cài tạo sẵn là một điểm khởi đầu hợp lý: 5 website, 10 database, 100% CPU, 1 GB RAM, 200 tiến trình, PHP memory_limit 256 MB và 10 PHP worker. Sửa gói thì giới hạn mới áp dụng ngay cho mọi tài khoản đang dùng.

Ngoài giới hạn từng tài khoản, ZoPanel chia RAM server thành phần dự trữ cho hệ thống (MariaDB, mail, nginx, panel) và phần cho toàn bộ khách, như mô tả trong Hiệu năng và sức chứa. Khi nhiều website cùng tăng tải, tiến trình của khách bị điều tiết trước, còn SSH, panel và database vẫn giữ được bộ nhớ.

Để chỉnh gói theo dữ liệu thật:

• Trang Tối ưu cảnh báo khi tổng số PHP worker mà các gói cho phép không vừa RAM.
• Lịch sử tài nguyên ghi CPU và RAM của từng tài khoản mỗi 5 phút, xem theo 24 giờ, 7 ngày, 30 ngày hoặc 1 năm. Quản trị viên mở từ menu của tài khoản trong Tài khoản; khách xem ở trang Tài nguyên (xem Vận hành và giám sát).
• Đại lý (cần gói Pro) tạo gói cho khách của mình, nhưng không thể vượt gói của chính đại lý.

Giới hạn tài khoản là một lớp trong mô hình cách ly rộng hơn; bài vì sao control panel không nên chạy bằng root giải thích các lớp còn lại. Còn nếu bạn đang lên kế hoạch mật độ, bài VPS 4 GB chạy được bao nhiêu website WordPress có số liệu đo thực tế.

Kết luận

Giới hạn tài nguyên hosting không làm website nhanh hơn, nhưng là thứ quyết định một sự cố nhỏ có trở thành sự cố cả server hay không. Hãy đặt RAM đủ cho số PHP worker, bật disk quota, giới hạn email, dành phần dự trữ cho hệ thống, rồi chỉnh gói theo lịch sử dùng thật thay vì đoán.

Bạn có thể thử toàn bộ hệ thống gói và giới hạn trên gói Free của ZoPanel (3 tài khoản hosting, 10 website, 10 database, không giới hạn thời gian), cài bằng curl -fsSL https://get.zopanel.net | sudo bash. Khi cần nhiều website hơn, xem bảng giá.

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

Website báo lỗi 503 có phải do giới hạn tài nguyên không?

Có thể. Khi tài khoản chạm trần RAM, kernel dừng một PHP worker và request đang chạy bị lỗi; khi mọi PHP worker đều bận, request mới phải xếp hàng. Hãy xem lịch sử CPU và RAM của tài khoản vào đúng thời điểm lỗi trước khi nghi ngờ code.

Nên giới hạn CPU hay RAM chặt hơn?

RAM cần đặt cẩn thận hơn vì vượt RAM là tiến trình bị dừng, còn vượt CPU chỉ làm chậm. Đặt RAM đủ cho số PHP worker của gói, còn CPU có thể đặt thoáng hơn vì phần lớn website không dùng CPU liên tục.

Tổng giới hạn RAM của các gói có được lớn hơn RAM server không?

Được, và đó là cách shared hosting vận hành, vì giới hạn là trần chứ không phải phần giữ chỗ. Điều kiện là server phải có phần RAM dự trữ cho hệ thống và cơ chế xử lý khi nhiều tài khoản chạm trần cùng lúc.

Có cần CloudLinux để giới hạn tài nguyên không?

Không bắt buộc. Kernel Linux hiện đại có sẵn cgroups v2 và disk quota để giới hạn CPU, RAM, tiến trình, I/O, dung lượng và inode. CloudLinux là một sản phẩm thương mại thêm công cụ quản lý quanh cơ chế này; một số panel, như ZoPanel, dùng trực tiếp cgroups qua systemd.

Giới hạn inode là gì và vì sao quan trọng?

Inode là số file và thư mục một tài khoản được tạo. Cache dạng file, session hay thư viện không dọn dẹp có thể sinh hàng triệu file nhỏ, làm backup chậm và có thể dùng hết inode của filesystem dù ổ còn trống. Giới hạn inode giữ vấn đề đó trong một tài khoản.