Node.js SSL服務器凍結，高CPU，沒有崩潰但沒有連接

Question

我希望有人能幫我解決這個問題。

在我們公司，我們正在建立一個連接到Java Push服務器的node.js服務器。

我正在使用https模塊而不是http和SLL證書。

節點和客戶端之間的連接由socket.io在服務器和客戶端中進行。

同時node.js服務器是java服務器的客戶端，這個連接是用常規套接字（net.connect）建立的。

這個想法是用戶連接到服務器，加入一些頻道，當一些數據從Java服務器到達時，這將被分派給相應的用戶。

一切似乎工作正常，但過了一段時間，像隨機一樣，有450到700個用戶，服務器的CPU達到100％，所有連接都被破壞，但服務器沒有崩潰。 問題是，如果你去瀏覽器中的https：// ...，你沒有得到404或類似的東西，但SSL連接錯誤，它真的很快。

我試圖在任何地方添加日志，但是沒有類似於模式的東西，它就像是隨機的。

如果有人有同樣的問題或者可以給我一個線索，或者提示調試更好，我會很感激。

非常感謝。

Answer 1

好的，問題解決了。 這是每個Linux服務器都會出現的問題。 因此，如果您正在使用其中一個，則需要閱讀此內容。

原因是Linux服務器每個進程的文件的默認限制。

似乎單個linux服務器都帶有每個進程打開的1024個文件的限制，您可以通過以下方式檢查您的限制：

# ulimit -n

增加這個數字

# ulimit -n 5000 (for example)

每個套接字創建一個新的虛擬文件。

由於某種原因，我的服務器沒有顯示任何錯誤，服務器剛剛凍結，停止日志，沒有信號或任何證據。 當我開始發送時，我在另一台機器上設置了服務器的副本

warn: error raised: Error: accept EMFILE
warn: error raised: Error: accept EMFILE
warn: error raised: Error: accept EMFILE
...

請注意，如果您不是root用戶，則只會為當前會話而不是永久更改此權限。

技巧：如果你想要節點文件的數量，在這種情況下，你的節點進程打開的文件數，請注意你的進程ID並調用此命令。

# ls -l /proc/XXXXX/fd | wc -l

其中XXXXX是進程ID。 這將幫助您了解這是否是您的問題，一旦啟動節點服務器，您可以使用此命令檢查它是否到達頂部，並在凍結后停止增長。 （默認為1024或“ulimit -n”）。

如果您只想檢查進程打開哪些文件：

# ls -l /proc/XXXXX/fd

希望這可以幫到你。 無論如何，如果你要設置一個節點js服務器，我很確定你想這樣做，以確保它不會融化。

最后，如果你需要在沒有日志未來的錯誤幫助，您可以嘗試strace荷蘭國際集團或dtruss閱讀過程

# strace -p <process-id>

應該做的工作。