Phát hiện chặn Event Loop trong Node.js Production mà không cần chạm vào mã nguồn

Bạn đang trực ca (on-call). Đột nhiên, hệ thống cảnh báo (alerts) liên tục báo động. Dịch vụ Node.js của bạn đang phản hồi rất chậm, hoặc thậm chí không phản hồi gì cả. Bạn nghi ngờ có sự cố chặn Event Loop (Event Loop blocking), nhưng ứng dụng đang chạy trên môi trường Production thực tế. Bạn không thể triển khai lại (redeploy) với cờ --inspect. Bạn không thể thêm require('blocked-at') vào mã nguồn. Và chắc chắn bạn không thể khởi động lại dịch vụ.

Bạn sẽ làm gì?

Đây chính là vấn đề đã thúc đẩy tôi xây dựng node-loop-detective — một công cụ chẩn đoán có thể gắn vào một tiến trình Node.js đang chạy, phát hiện sự cố chặn Event Loop và độ trễ (lag), cũng như chỉ cho bạn chính xác hàm nào trong tệp nào đang gây ra vấn đề. Hoàn toàn không cần thay đổi mã nguồn. Không cần khởi động lại.

Trong bài viết này, tôi sẽ đi sâu vào vấn đề, cách tiếp cận và cách hoạt động bên trong của công cụ này.

Vấn đề về Event Loop

Node.js chạy JavaScript trên một luồng duy nhất (single thread). Event Loop đóng vai trò là bộ lập lịch — nó nhận các callback, bộ hẹn giờ (timers), hoàn tác I/O và chạy chúng từng cái một. Khi một trong những callback đó mất quá nhiều thời gian, mọi thứ khác phải chờ đợi.

Đây là những gì chúng ta gọi là "chặn Event Loop" (Event Loop blocking), và nó là một trong những thủ phạm phổ biến nhất làm giảm hiệu năng ứng dụng Node.js. Các nguyên nhân thường gặp bao gồm:

• Thực hiện JSON.parse() trên một payload dung lượng lớn (ví dụ 50MB).
• Sử dụng biểu thức chính quy (regex) gây ra hiện tượng backtracking thảm họa.
• Một lệnh readFileSync() bị bỏ quên trong trình xử lý yêu cầu.
• Vòng lặp bận (tight loop) thực hiện tính toán tốn nhiều CPU.
• Quá trình thu gom rác (Garbage Collection) quá mức do cấp phát đối tượng nhanh chóng.

Điểm khó khăn nhất là các vấn đề này thường chỉ xuất hiện dưới áp lực tải cao của môi trường Production. Môi trường staging với 10 yêu cầu mỗi giây có thể hoạt động tốt, nhưng Production với 10.000 yêu cầu thì không.

Các công cụ hiện tại và hạn chế của chúng

Có những công cụ tuyệt vời để chẩn đoán các vấn đề về Event Loop:

• clinic.js — tạo ra biểu đồ ngọn lửa (flame graphs), biểu đồ độ trễ Event Loop, v.v.
• 0x — tạo ra các biểu đồ ngọn lửa đẹp mắt từ hồ sơ CPU.
• blocked-at — phát hiện sự chặn và báo cáo stack trace.

Tuy nhiên, điểm yếu chung? Chúng đều yêu cầu bạn khởi động ứng dụng thông qua chúng, hoặc thêm mã vào ứng dụng của bạn. Trong môi trường Production, điều này đồng nghĩa với việc phải triển khai lại hoặc khởi động lại. Nếu vấn đề chỉ diễn ra thoáng qua, nó có thể biến mất ngay khi bạn khởi động lại.

Những gì chúng ta cần là một công cụ có thể gắn vào một tiến trình đang chạy.

Ý tưởng then chốt: SIGUSR1 + V8 Inspector

Node.js có một "lối thoát" tích hợp mà hầu hết các nhà phát triển không biết đến. Nếu bạn gửi tín hiệu SIGUSR1 đến một tiến trình Node.js đang chạy trên Linux hoặc macOS:

kill -SIGUSR1 <pid>

Node.js sẽ kích hoạt V8 Inspector trên cổng 9229. Không cần khởi động lại. Không cần thay đổi mã. Tiến trình tiếp tục chạy bình thường, nhưng giờ đây nó chấp nhận các kết nối thông qua Giao thức Chrome DevTools (CDP).

Đây chính là nền tảng của node-loop-detective.

Cách node-loop-detective hoạt động

Công cụ này hoạt động qua 5 giai đoạn:

Giai đoạn 1: Kích hoạt Inspector

Đầu tiên, chúng ta gửi tín hiệu SIGUSR1 để kích hoạt trình kiểm tra:

// Send SIGUSR1 to activate the inspector
process.kill(targetPid, 'SIGUSR1');

Sau một khoảng nghỉ ngắn, tiến trình đích sẽ mở một điểm cuối WebSocket Inspector. Chúng tôi phát hiện URL này qua điểm cuối HTTP tiêu chuẩn /json/list.

Giai đoạn 2: Kết nối thông qua CDP

Chúng tôi thiết lập kết nối WebSocket và giao tiếp bằng Chrome DevTools Protocol. Điều này cấp quyền truy cập vào các miền gỡ lỗi V8 như Runtime, Profiler — những gì mà Chrome DevTools sử dụng.

Giai đoạn 3: Tiêm trình phát hiện độ trễ (Lag Detector)

Đây là phần thú vị. Chúng tôi sử dụng Runtime.evaluate để tiêm một đoạn mã nhỏ vào tiến trình đích:

const timer = setInterval(() => {
  const now = Date.now();
  const lag = now - lastTime - interval;
  if (lag > threshold) {
    // Record the lag event with a stack trace
    lags.push({ lag, timestamp: now, stack: captureStack() });
  }
  lastTime = now;
}, interval);

timer.unref(); // Don't prevent process exit

Nguyên tắc rất đơn giản: setInterval nên kích hoạt mỗi interval mili-giây. Nếu khoảng thời gian thực tế lớn hơn nhiều, điều đó có nghĩa là Event Loop đã bị chặn trong khoảng thời gian đó. Sự chênh lệch chính là độ trễ (lag).

Điểm bổ sung quan trọng: khi phát hiện độ trễ, chúng tôi chụp lại stack trace JavaScript hiện tại. Điều này đảm bảo mỗi sự kiện độ trễ đều đi kèm với vị trí mã chính xác đang thực thi khi Event Loop bị chặn.

Giai đoạn 4: Profiling CPU

Đồng thời, chúng tôi sử dụng V8 Profiler thông qua CDP để chụp hồ sơ CPU:

await cdp.send('Profiler.enable');
await cdp.send('Profiler.setSamplingInterval', { interval: 100 });
await cdp.send('Profiler.start');

// Wait for the profiling duration...

const { profile } = await cdp.send('Profiler.stop');

Hồ sơ CPU của V8 là một bộ lấy mẫu thống kê. Mỗi ~100 micro-giây, nó ghi lại hàm nào đang thực thi. Qu hàng nghìn mẫu, nó xây dựng bức tranh chính xác về nơi thời gian CPU đang được tiêu tốn.

Giai đoạn 5: Phân tích

Đây là nơi dữ liệu thô trở thành thông tin chẩn đoán hữu ích. Trình phân tích xử lý hồ sơ CPU để:

1. Tính toán thời gian tự (self time) cho mỗi hàm.
2. Xếp hạng các hàm tốn tài nguyên để tìm ra những "kẻ ăn" CPU lớn nhất.
3. Xây dựng stack trace để truy ngược lại chuỗi gọi hàm.
4. Phát hiện mẫu: Trình phân tích so khớp với 6 mẫu chặn phổ biến như cpu-hog (hàm chiếm >50% CPU), json-heavy (thao tác JSON chiếm >10%), sync-io (I/O đồng bộ), v.v.

Ví dụ về kết quả đầu ra

✔ Connected to Node.js process
  Profiling for 10s with 50ms lag threshold...

⚠ Event loop lag: 312ms at 2025-01-15T10:23:45.123Z
    → heavyComputation /app/server.js:42:1
    → handleRequest /app/routes.js:15:5

────────────────────────────────────────────────────────────
  Event Loop Detective Report
────────────────────────────────────────────────────────────
  Diagnosis
────────────────────────────────────────────────────────────
   HIGH  cpu-hog
         Function "heavyComputation" consumed 62.3% of CPU time (6245ms)
         at /app/server.js:42
         → Consider breaking this into smaller async chunks
           or moving to a worker thread

  Top CPU-Heavy Functions
────────────────────────────────────────────────────────────
   1. heavyComputation
      ██████████████░░░░░░ 6245ms (62.3%)
      /app/server.js:42:1

Chỉ từ một đầu ra duy nhất, bạn biết: Event Loop bị chặn 3 lần, hàm heavyComputation tại /app/server.js:42 là thủ phạm, và giải pháp được đề xuất là chia nhỏ nó hoặc sử dụng Worker Threads.

Các mô hình thực tế tôi đã gặp

JSON.parse bị ẩn

Một API REST đang phân tích thân yêu cầu thủ công thay vì dùng trình phân tích luồng (streaming parser). Với payload nhỏ thì ổn, nhưng khi client gửi mảng JSON 10MB, Event Loop bị chặn 800ms mỗi yêu cầu.

"Bom hẹn giờ" Regex

Một regex xác thực URL hoạt động tốt trong nhiều năm — cho đến khi ai đó gửi một URL kích hoạt catastrophic backtracking. Engine regex dành 2 giây cho một lệnh gọi test() duy nhất.

Lệnh readFileSync bị quên

Một hàm tải lại cấu hình sử dụng readFileSync. Nó được gọi một lần khi khởi động — không sao. Nhưng sau đó ai đó thêm tính năng tải lại cấu hình trên mỗi yêu cầu, dẫn đến chặn toàn bộ hệ thống.

Hạn chế

• Windows: Tín hiệu SIGUSR1 không khả dụng. Tiến trình đích phải được khởi tạo với --inspect.
• Chặn dưới mili-giây: Bộ lấy mẫu V8 có thể bỏ sót các sự kiện chặn rất ngắn.
• Nút thắt I/O: Nếu sự chậm là do truy vấn cơ sở dữ liệu chậm hoặc mạng I/O (không phải CPU), công cụ này tập trung vào sự chặn liên quan đến CPU.

Bắt đầu như thế nào

npm install -g node-loop-detective

# Profile một tiến trình đang chạy trong 10 giây
loop-detective <pid>

# Giám sát liên tục
loop-detective <pid> --watch

Mã nguồn có sẵn trên GitHub: github.com/iwtxokhtd83/node-loop-detective

Kết luận

Bằng cách tận dụng giao thức Inspector tích hợp và tín hiệu SIGUSR1 của Node.js, chúng ta có thể gắn vào một tiến trình đang chạy, phân tích hiệu năng và nhận được thông tin chẩn đoá chi tiết mà không gây gián đoạn. Sự kết hợp giữa phát hiện độ trễ theo thời gian thực và phân tích hồ sơ CPU sẽ cung cấp cho bạn cả triệu chứng và nguyên nhân gốc rễ.

Lần tới khi dịch vụ Node.js của bạn gặp sự cố và bạn cần câu trả lời nhanh, hãy thử:

loop-detective $(pgrep -f "node app.js")

Bạn có thể sẽ ngạc nhiên vì tìm ra thủ phạm nhanh đến mức nào.