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

Question

我希望任何人都可以幫助我解決這個問題。

在我們公司，我們正在建立一個連接到Java Push服務器的nod​​e.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 
... 

要小心，因爲如果你不是根用戶，你只能改變這個當前會話，而不是永久。技巧：如果您想要發佈文件的數量，在這種情況下，您的節點進程打開的文件的數量，請注意您的進程ID並調用此命令。

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

其中XXXXX是進程ID。這會幫助你知道這是否是你的問題，一旦你啓動了你的節點服務器，你可以使用這個命令來檢查它是否到達頂端，並在它被凍結後停止增長。（默認爲1024或「ulimit -n」）。

如果你只是想檢查哪些文件是通過開放的過程：

# ls -l /proc/XXXXX/fd 

希望這可以幫助你。任何方式，如果你正在建立一個節點js服務器我敢肯定你想這樣做，以確保它不會融化。

最後，如果你需要在今後的錯誤的幫助沒有日誌，你可以嘗試strace ING或dtruss閱讀過程

# strace -p <process-id> 

應該做的工作。