Làm cách nào để sửa lỗi rò rỉ bộ nhớ ws và socket.io?

Tôi đã đọc được rằng có sự cố rò rỉ bộ nhớ xảy ra trong cả hai mô-đun ổ cắm web node.js ws và socket.io. Nó đã tồn tại trong nhiều năm và đang tự hỏi làm thế nào để khắc phục nó.

Nó được đề cập sau đây, để đặt tên cho một số:

• https://github.com/socketio/socket.io/issues/2427 (đã đóng nhưng không có giải pháp)
• https://github.com/socketio/socket.io/issues/3477 (cài đặt perMessageDeflate: false rõ ràng có ích, nhưng nguyên nhân cốt lõi là do sự cố phân mảnh, nguyên nhân rõ ràng không phải do nút hoặc thư viện websocket gây ra mà do cách chúng chạy và có thể được khắc phục bằng cách tải trước jemalloc)
• https://github.com/nodejs/node/issues/8871#issuecomment-250915913 (cùng một giải pháp được cung cấp ở đây)
• https://github.com/websockets/ws/issues/804 (có vẻ như sự cố đã được giải quyết chỉ bằng cách đặt perMessageDeflate thành false - không có jemalloc)

Bây giờ là năm 2021, đặt khóa perMessageDeflate thành false và có lẽ tải trước jmalloc vẫn là giải pháp tốt nhất?

Sự hiểu biết sơ bộ của tôi về vấn đề này như sau (đừng trích dẫn tôi về nó):

• cả mô-đun ws node.js (tức là mô-đun websockets) và mô-đun socket.io node.js đều sử dụng một mô-đun khác có tên là zlib.Mô-đun này chịu trách nhiệm nén bất kỳ tin nhắn nào khi chúng được gửi qua websocket.
• mô-đun zlib trước đây đã gặp sự cố liên quan đến phân mảnh bộ nhớ, bắt chước rò rỉ bộ nhớ (tức là thực tế không phải rò rỉ bộ nhớ mà là phân mảnh bộ nhớ).
• tính năng nén thư bị tắt theo mặc định trên máy chủ nhưng được bật theo mặc định trên máy khách (ví dụ: trình duyệt). Nếu chúng tôi tắt nó, mô-đun zlib sẽ không được sử dụng, điều này sẽ loại bỏ vấn đề phân mảnh bộ nhớ.
• Để tắt tính năng nén trên máy khách (ví dụ: trình duyệt), chúng tôi cung cấp perMessageDeflate nhập mã máy chủ của bạn vào giá trị sai. Đó là:

const wss = new WebSocket.Server({ server:httpsServer, perMessageDeflate: false });

Rõ ràng đây không phải là giải pháp cho những người muốn nén tin nhắn của họ. Nhưng điều đáng nói là:

• vấn đề phân mảnh bộ nhớ với zlib dường như đã được khắc phục MỘT PHẦN với https://github.com/websockets/ws/pull/1204 nhưng nó dường như vẫn còn là một vấn đề; và
• lợi ích của việc nén các tin nhắn nhỏ, như các đoạn văn bản nhỏ, đã được tranh luận. Một số thậm chí còn tuyên bố rằng việc nén các tin nhắn nhỏ sẽ khiến mọi thứ chậm hơn. Nếu bạn đang làm việc với dữ liệu lớn hơn, chẳng hạn như hình ảnh hoặc video, bạn có thể đạt được thành công bằng cách tự nén dữ liệu đó (tức là không có ws/socket.io/zlib) trước khi gửi qua websocket.

Ngoài ra, một số người đã lưu ý rằng cài đặt perMessageDeflate: false chỉ làm giảm sự cố chứ không giải quyết được hoàn toàn sự cố. Tôi sẽ hướng sự chú ý của bạn đến cuộc thảo luận này, nơi người ta nói rằng MỘT SỐ bộ nhớ còn lại và không đổi (tức là không tăng) sử dụng từ việc mở và đóng các ổ cắm web là bình thường (nhân tiện, tôi không nhất thiết phải nói điều này là đúng): https://github.com/websockets/ws/issues/804#issuecomment-302612661

Đối với tải trước Jemalloc, có vẻ như điều này không khắc phục được sự cố. Mặc dù nếu đoạn mã trên không hoạt động, nó chắc chắn đáng để xem xét (hoặc thử).

cũng vậy preMessageDeflate: sai giải pháp tốt nhất lúc này? Từ sự hiểu biết của tôi, tôi sẽ nói có.

Nếu bất cứ ai có sửa chữa hoặc biết thêm thông tin về điều này xin vui lòng thêm.