Đọc thế nào. Nhịp toàn hệ chặn TỔNG số phòng mở mỗi phút — đo được ngưỡng sạch là ≤20 phòng/phút; vượt lên 40+ thì lỗi 91116 bùng (đo 9h/2.502 phòng ngày 30/08). Nhịp thực lệch khỏi thiết kế khi pool thiếu key hoặc job nhỏ hơn nhịp — lệch là dấu hiệu, không phải lỗi.
Số cần canh là “Swap còn”. RAM còn thấp là bình thường khi đã có swapfile; hết SWAP mới là lúc OOM-kill nổ, và phòng bị giết giữa trận = acc mất trắng và AOV trừ 5% thưởng vĩnh viễn.
Swappiness là nút quyết định “bao giờ mới dùng swap”: 60 (mặc định Linux) đẩy trang ra swap ngay cả khi RAM còn nhiều — đó là lý do 702 MB nằm trong swap lúc còn 30 GB RAM trống; 10 (đang đặt) chỉ đẩy khi bắt đầu thiếu thật. Linux không có công tắc bật/tắt swap theo ngưỡng: swapoff phải kéo mọi trang đã swap trở về RAM, nên gọi nó lúc RAM đang cạn là tự gây OOM. Đổi bằng /etc/sysctl.d/99-hmod-swap.conf (sống qua reboot).
Bão hoà dự kiến = số phòng máy sẽ DỪNG Ở khi chạy đủ lâu, và nó bị kẹp bởi hai trần chứ không phải một: nhịp (20 phòng/phút × 1235s/phòng = 411 phòng) và trần luồng TOÀN HỆ admin đặt tay (÷ 5 acc = số phòng). Số nhỏ hơn thắng — ô này hiện số THẮNG, và ghi thêm “nhịp cho …” khi trần admin là bên kẹp. % là so với trần RAM+swap. Đặt trần luồng toàn hệ = 0 (tự đo) thì nhịp thành trần duy nhất và con số nhảy lên 411 — lúc đó mới thật là vượt ngân sách.
Bảng máy hiện từng VPS, vì tổng che mất máy đang sát mép: cột Trần trống là đúng con số bộ chọn máy cân khi tạo job (job mới về máy có số này lớn nhất), Nhịp phải bằng 3,0s × số máy ở MỌI máy — web tự đẩy lại trong ~5s nên lệch quá một lượt poll là dấu hiệu máy đó không nhận /dat_nhip. Dòng tổng so trần trống với bão hoà toàn hệ: thêm máy mua được chỗ chứa chứ không mua được nhịp (lỗi 91116 bám TỔNG phòng/phút toàn hệ, không bám IP), nên khi tổng trần trống đã vượt bão hoà thì VPS tiếp theo không thêm được gì cho tới khi đo lại được dải nhịp cao hơn. Cập nhật —.

Ba ô đầu là ba cửa khác nhau: ô 1 chặn một user, ô 2 chặn tổng cả hệ, ô 3 chặn kích cỡ một job. Sức chứa THẬT của máy nằm ở card ngay trên — đặt vượt nó thì acc không mất, chỉ nằm hàng chờ lâu hơn.

Đánh giá CHUẨN HOÁ theo mục tiêu: lv5 ~25s, lv8 ~110s là bình thường (đường xanh đứt = mốc chuẩn). Xanh ≤ chuẩn & lỗi<5% · Vàng chậm hơn chuẩn hoặc lỗi 5–15% · Đỏ chậm >~1.8× chuẩn, lỗi>15% hoặc kẹt hàng.
“Phiên” ở đây không phải “luồng”. Một phòng 5v5 (5 acc) đếm là 1 phiên, một acc chạy lẻ cũng 1, một lượt /jwt cũng 1 — nên số này KHÔNG so được với ba ô trần ở trên. Trước bản (103) ô này hiện 0 / 1000, trong đó 1000 là số chỗ của pool job trong động cơ (mặc định HMOD_HMOD_LUONG, mỗi chỗ chạy MỘT JOB) — khác đơn vị hoàn toàn, nên mẫu số đó đã bỏ. Cập nhật —.

Chỉ tính job còn acc chờ hoặc đang chạy — job đã xong bị loại ngay, dù Tong còn giữ lại 2h để khôi phục callback. "Luồng" là luồng thực: min(max_luong, số acc còn lại), nên job cấu hình 10 luồng mà còn 3 acc chỉ tính 3. Job còn running quá 3h được cron đóng thành het_han, dòng cũ hơn 2 ngày bị xoá.

Chỉ đếm lệnh completed, theo thời điểm xác nhận — lệnh tạo hôm qua mà xác nhận hôm nay vẫn tính vào hôm nay. Tuần bắt đầu từ Thứ Hai.

Trần luồng tính trên tất cả job của đại lý cộng lại — cấp 100 thì họ chạy 1 hay 50 job cũng chỉ 100 luồng cùng lúc. Không giới hạn token: trừ trực tiếp từ túi của key đó.