這次我們碰到了一個問題，疑似port泄露而導致了beam崩潰。
我們用erlang:length(erlang:ports()).在服務器控制檯執行查看了當前佔用端口數：32000+
然後自然想到了上限的設置，查看了啓動配置：
POLL=true
SMP=auto
ERL_MAX_PORTS=32000
ERL_PROCESSES=500000
ERL_MAX_ETS_TABLES=1400
export ERL_MAX_PORTS
export ERL_MAX_ETS_TABLES
在配置中上面設置的最大上限是32000.....悲劇了，當天我們的服務器就沒法再新開端口了，不停地大量報錯，到晚上的時候服務器還離奇地宕機了
然後查找了erlang相關文章，慶亮大神的一篇博客也就提到了，導致的原因應該是一樣的，就是客戶端在壓縮了數據包傳給服務器端後，服務器端在調用zlib:uncompress(Data)解壓縮數據時，傳入的Data參數不對，導致系統異常，port未正常關閉從而使port發生大量溢出，從而導致beam崩潰，服務器宕機
原文如下：
erlang zlib引起的系統崩潰記錄
在這篇文章中針對這個問題已經分析得相當透徹，並且慶亮也對於erlang的細節提出了針對性的意見：
“erlang在遇到port返回錯誤時直接error了，典型的非防禦性編程。但是個人認爲這個接口應該在拋出錯誤之前關閉掉打開的port。”
然後我又去找了erlang的版本更新介紹。針對上面提出的非防禦性編程引發的可能漏洞，erlang R15B01已經做了相關修復，請查看15B01的更新說明文件：
Bug fix release : otp_src_R15B01Build date : 2012-04-02
上面有一段話說到了：
OTP-9981 Fix port leak in zlib when passing invalid data to compress,uncompress,zip,unzip,gzip,gunzip.
（修復向函數compress,uncompress,zip,unzip,gzip,gunzip這幾個函數當傳入非法數據時會導致端口泄露的bug）
說明其在15B01中就已經修復了這個問題，在找不到具體是哪個地方調用傳參錯誤情況下，升級系統至R15B01是最好的解決辦法