Redis xử lý lần lượt từng lệnh một, nên một lệnh chậm sẽ chặn mọi yêu cầu phía sau.
Vì sao Trong giờ vận hành, dùng KEYS để quét toàn bộ, đọc hoặc xóa trọn một bảng xếp hạng hay danh sách có hàng triệu phần tử → Dẫn đến Mọi yêu cầu khác phải chờ cho đến khi lệnh đó xong (từ vài chục ms đến vài giây) → Trên màn hình Các tính năng dùng session, bảng xếp hạng, cache cùng lúc bị khựng, đăng nhập chậm
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng DB (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Dùng SCAN thay cho KEYS, chia nhỏ key lớn, xóa bằng UNLINK (xóa ở chế độ chạy nền), rải các thời điểm hết hạn đang dồn vào cùng một giây.
Việc cần làm (Đội hạ tầng)
Theo dõi log lệnh chậm (SLOWLOG), chặn các lệnh nguy hiểm như KEYS trên server vận hành, kiểm tra key lớn định kỳ, tắt THP và chừa dư bộ nhớ cho fork, lưu RDB và AOF trên bản sao.
Con số tham khảo
Lệnh thông thường mất dưới 1 ms. Xử lý hàng triệu phần tử một lượt có thể mất từ vài trăm ms tới vài giây.
Trên đồ thị
Thỉnh thoảng vọt lên bất chợt · Độ trễ phản hồi của Redis, số lệnh chậm
Chỗ cần xem
Dùng SLOWLOG GET xem các lệnh vượt slowlog-log-slower-than; bật latency monitor (mặc định tắt) bằng CONFIG SET latency-monitor-threshold, rồi xem độ trễ theo từng sự kiện như fork, expire-cycle bằng LATENCY LATEST, LATENCY DOCTOR. Kiểm tra cả thời gian fork và key lớn bằng latest_fork_usec trong INFO và redis-cli --bigkeys
Đúng nếu
vào lúc dừng, SLOWLOG có KEYS hoặc lệnh xử lý trọn một key lớn, hoặc LATENCY ghi nhận sự kiện fork, expire-cycle cùng thời điểm, kéo dài từ vài chục ms trở lên
Loại trừ nếu
SLOWLOG và LATENCY đều trống mà chỉ phía server game thấy chậm → mạng hoặc việc chờ bên trong server game (SLOWLOG chỉ đo thời gian thực thi lệnh, không tính thời gian trao đổi với client)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Redis cũng dừng đúng lúc nhân bản tiến trình (fork) để tạo file lưu (snapshot RDB) hoặc ghi lại AOF. Trên server ngày nay, fork mất khoảng 10 ms cho mỗi 1 GB bộ nhớ, nên 30 GB là khoảng 300 ms. Nếu bật huge page (THP), sau fork mỗi lần ghi phải sao chép nguyên cả huge page (copy-on-write), làm thời gian dừng và mức dùng bộ nhớ tăng mạnh, nên thường tắt THP và chừa dư nhiều bộ nhớ. Khi có rất nhiều key hết hạn trong cùng một giây, Redis cũng dừng một chút để xóa chúng.
Nguồn
Diagnosing latency issuesRedis Một thread xử lý lần lượt các yêu cầu nên lệnh chậm chặn mọi thứ phía sau; dùng SCAN thay cho KEYS; fork đo thực tế trên server vật lý và VM đời mới mất khoảng 9–13 ms mỗi 1 GB; THP làm độ trễ và bộ nhớ tăng vọt do sao chép sau fork; nhiều key hết hạn trong cùng một giây thì Redis dừng
KEYSRedis Phải cực kỳ thận trọng khi dùng trong môi trường vận hành, có thể phá hỏng hiệu năng trên DB lớn (1 triệu key mất 40 ms trên laptop phổ thông)
UNLINKRedis Xóa bất đồng bộ: gỡ key ra ngay, còn việc thu hồi bộ nhớ do thread khác làm
SLOWLOGRedis Log lệnh chậm ghi các lệnh vượt slowlog-log-slower-than; thời gian thực thi không tính I/O trao đổi với client
Redis latency monitoringRedis latency-monitor-threshold mặc định 0 (tắt), LATENCY LATEST, LATENCY DOCTOR, ghi độ trễ theo từng sự kiện như fork, expire-cycle
INFORedis latest_fork_usec: thời gian của lần fork gần nhất (micro giây)
Redis CLIRedis --bigkeys: quét keyspace để tìm key lớn