Thoát Khỏi Vòng Lặp Vô Hạn

Trong hệ thống Skynet, module monitor đóng vai trò như “người canh gác” để phát hiện các dịch vụ có nguy cơ mắc kẹt trong vòng lặp vô hạn. Cơ chế hoạt động của nó như sau: mỗi lần xử lý một tin nhắn cho một dịch vụ, hệ thống sẽ tự động tăng giá trị một biến toàn cục liên quan đến dịch vụ đó lên 1 đơn vị. Trong khi đó, luồng monitor chạy độc lập, định kỳ kiểm tra (khoảng 5 giây) toàn bộ các luồng làm việc để phát hiện các luồng không có sự thay đổi trên biến đếm này. Nếu phát hiện một luồng “im lặng” đáng ngờ, hệ thống sẽ nghi ngờ rằng dịch vụ tương ứng đang bị treo trong vòng lặp vô hạn.

Khi phát hiện trường hợp bất thường, Skynet chỉ có thể ghi lại một dòng log cảnh báo. Hệ thống không thể can thiệp từ bên ngoài để ngắt quá trình xử lý tin nhắn, điều này khiến dịch vụ bị treo sẽ chiếm dụng vĩnh viễn một nhân CPU, gây giảm hiệu năng toàn hệ thống. Thậm chí, lệnh kill thông thường cũng không thể loại bỏ được các dịch vụ rơi vào trạng thái này.

Giải pháp đặc biệt cho Lua

Trong trường hợp dịch vụ được viết bằng Lua, chúng ta có thêm một công cụ mạnh mẽ hơn: debug hook. Với các coroutine đang chạy, chúng ta có thể gắn một hàm hook để kiểm tra xem có tín hiệu yêu cầu ngắt xử lý từ bên ngoài hay không. Vì mọi dịch vụ Lua trong Skynet đều được quản lý thông qua cơ chế coroutine, nên việc thêm debug hook cho mỗi yêu cầu là hoàn toàn khả thi.

Tuy nhiên, debug hook trong Lua có chi phí hiệu năng không nhỏ, đặc biệt là khi so sánh với phiên bản hook được viết bằng C thông qua API hệ thống. Dù vậy, tính năng này lại cực kỳ hữu ích trong việc phân tích và sửa lỗi trực tiếp trên hệ thống đang chạy. Nếu có thể giảm thiểu tác động đến hiệu năng, việc đánh đổi giữa hiệu năng và khả năng debug là hoàn toàn xứng đáng.

Để giải quyết vấn đề, tôi đã chỉnh sửa trực tiếp máy ảo Lua (Lua VM). Trước đây tôi đã từng sửa đổi VM để giải quyết bài toán chia sẻ bytecode giữa nhiều máy ảo, lần này lại tiếp tục điều chỉnh thêm. Mấu chốt là vẫn đảm bảo phiên bản VM chưa sửa đổi cũng hoạt động bình thường trong Skynet, để những ai không thích tính năng mới có thể dễ dàng thay thế.

Giải pháp kỹ thuật

Giải pháp tôi áp dụng là can thiệp vào một số opcode quan trọng trong quá trình VM thực thi: JMP, CALL, TAILCALL, và FORLOOP. Tại mỗi điểm này, VM sẽ kiểm tra một biến toàn cục. Nếu biến này chứa con trỏ trùng với lua_state hiện tại, hệ thống sẽ lập tức ném ra một exception để ngắt luồng xử lý.

Kết quả thử nghiệm cho thấy với một vòng lặp trống 100 triệu lần, việc thêm cơ chế kiểm tra biến toàn cục này chỉ làm giảm hiệu năng khoảng 3% – mức độ chấp nhận được.

Mở rộng giao tiếp tín hiệu

Phía Skynet cũng cần thêm giao diện gửi tín hiệu (signal) cho các dịch vụ. Hiện tại, sau khi khởi tạo, mỗi dịch vụ chỉ có duy nhất một giao diện callback được gọi khi có tin nhắn đến, và đảm bảo tính thread-safe (không bị gọi đồng thời từ nhiều luồng).

Tôi đã bổ sung thêm giao diện tùy chọn signal, cho phép gọi bất kỳ lúc nào. Việc gửi tín hiệu được tích hợp vào hệ thống command của Skynet, giúp bất kỳ dịch vụ nào cũng có thể gửi tín hiệu đến các dịch vụ khác trong cùng tiến trình. Tín hiệu được biểu diễn dưới dạng số nguyên để phân biệt loại. Hiện tại, chỉ module snlua hỗ trợ giao diện này, nhưng chưa phân biệt rõ ràng các loại tín hiệu cụ thể.

Trong hàm snlua_signal, hệ thống đơn giản chỉ cần thiết lập giá trị cho biến toàn cục trong Lua VM. Nếu VM sử dụng là phiên bản gốc, thao tác này sẽ không có hiệu ứng gì.

Hiệu quả thực tế

Như vậy, với chi phí tối thiểu, chúng ta đã nâng cao khả năng quản lý các dịch vụ bất thường. Khi log xuất hiện dòng “maybe in an endless loop”, kỹ sư có thể dùng debug console để gửi tín hiệu đến địa chỉ dịch vụ nghi ngờ. Nếu đây là dịch vụ snlua, hệ thống sẽ ném ra một lỗi, từ đó hiển thị stack trace của đoạn code Lua đang bị treo. Đồng thời, nếu trước đó đã thử lệnh kill, dịch vụ sẽ tự thoát khi quá trình xử lý lỗi kết thúc.

Bản vá đầy đủ có thể xem tại đây. Code chi tiết sẽ giúp bạn hiểu rõ hơn về từng bước thực hiện.