請參閱 Fusion Reactor 的附圖，其中顯示了繼續運行的頁面。時間已經增加到了數百萬，我讓他們看看是否能完成，但當時只有兩三個。
現在我收到了幾十頁，但永遠讀不完。這是不同的查詢，我看不到任何巨大的模式，除了它似乎只適用於我的 7 個資料庫中的 3 個。
top節目冷聚變CPU 使用率約 70-120%，深入研究 Fusion Reactor 詳細資訊頁面顯示所有建置時間都只花費在 Mysql 查詢上。
show processlist返回沒有任何異常，除了 10 - 20 個連接睡覺狀態。
在此期間，許多頁面確實完成了，但隨著掛起的頁面數量不斷增加，它們似乎永遠不會完成，伺服器最終只會返回白色頁面。
唯一的短期解決方案似乎是重新啟動 Coldfusion，但這遠非理想。
最近新增了一個Node.js 腳本，該腳本每5 分鐘運行一次並檢查要處理的批次csv 文件，我想知道這是否會導致竊取所有MySQL 連接的問題，因此我禁用了該腳本（該腳本沒有連結）。
不知道從哪裡開始，有人可以幫忙嗎？
最糟糕的部分是頁面永遠不會超時，如果超時的話也不會那麼糟糕，但過了一段時間就沒有任何服務了。
我正在運行 CentOS LAMP 堆疊，並使用 Coldfusion 和 NodeJS 作為我的主要腳本語言
在實際發布之前更新
在我禁用 Node 腳本並重新啟動 Coldfusion 後開始撰寫這篇文章期間，問題似乎已經消失了。
但我仍然需要一些幫助來確定頁面超時的確切原因，並確認節點腳本需要類似的東西connection.end()
而且它可能只在負載下發生，所以我不能 100% 確定它已經消失
更新
仍有問題，我剛剛複製了 Fusion Reactor 中當前長達 70 秒的查詢之一，並在資料庫中手動運行它，並在幾毫秒內完成。查詢本身似乎不是問題。
另一個更新
其中一頁仍在運行的堆疊追蹤。伺服器有一段時間沒有停止提供頁面服務，所有節點腳本目前已停用
更多更新
今天我又做了一些——它們實際上完成了，我在 FusionReactor 中發現了這個錯誤：
Error Executing Database Query. The last packet successfully received from the server was 7,200,045 milliseconds ago. The last packet sent successfully to the server was 7,200,041 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
更多更新
深入研究代碼，我嘗試查找“2 h”、“120”和“7200”，因為我覺得 7200000 毫秒超時太巧合了。
我找到了這段程式碼：
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
引用這些程式碼行的 4 個頁面很少運行，從未在日誌中顯示過 2 小時以上的超時，並且位於密碼保護區中，因此無法被抓取（它們用於文件上傳和 CSV 處理，現在轉移到nodejs）。
這些設定是否有可能以某種方式由一個頁面設定但存在於伺服器中，並影響其他請求？
答案1
1）發布堆疊追蹤。
我保證它們將掛在 Socket.read() （或類似的）上
發生的情況是 1/2 到 db 的 tcp 連線關閉，讓 cf 等待它永遠不會得到的回應。
cf 盒和資料庫之間有網路問題。
Java 資料庫驅動程式通常不擅長處理這個問題
感謝您的堆疊追蹤
這證實了我的假設，即 1/2 tcp 連線關閉。
我懷疑以下情況之一：1）mysql在linux上，並且TCP堆疊中存在錯誤，因此您需要升級該機器上的linux - 是的，我以前見過這個2）coldfusion在linux上..按照1 ) 3) 兩個盒子上或之間的電纜/硬體故障4) 如果您運行的是Windows，請停用TCP 卸載！
第3）是最難的。您需要在兩個盒子上運行wireshark並證明資料包遺失。更簡單的解決方案是將 Rackspace 虛擬機器移至不同的實體主機並查看它是否消失。 （極有可能你的程式碼非常非常糟糕，而且你正在使 CF 盒和 MySQL 盒之間的網路飽和，但我不確定是否有可能編寫那麼糟糕的程式碼）
答案2
我花了更多時間研究這個問題，並添加了一些有關網路問題的具體原因的更多詳細信息，以及在 Charlie Arehart 的幫助下找到的解決方法。
首先，網路連線會被自動腳本觸發中斷iptables restart。這會更新可以存取伺服器的 IP 位址列表，但也會中斷應用程式和資料庫伺服器之間的任何連線。
它更有可能發生在速度較慢的頁面或運行頻率較高的頁面上，但與iptables restart程式碼一致的任何內容都會被切斷。
Rackspace 為我找到了這個並建議更改程式碼：
/sbin/service iptables restart
到
/sbin/iptables-restore < /etc/sysconfig/iptables
這會停止重新啟動服務並僅適用於新連線。
這是問題的根本原因，但真正的問題是 Coldfusion，或者實際上是底層的 JDBC，不會停止等待資料庫伺服器的回應。
我不確定 2 小時超時是從哪裡來的（假設它是預設值），但 Charlie 展示了一種在 CFIDE 連接字串中設定較低逾時的方法 - 這告訴 CF 在放棄 DB 之前等待最長時間。
所以我們的連接字串是：
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
我不記得這兩個的具體細節，但他們設定了一個以毫秒為單位的等待時間，然後放棄資料庫連線：
- 連線逾時=600000；
- 套接字超時=600000；
這只是在 Fusion Reactor 中標記資料來源 - 如果您有它，它對於查找 CF 應用程式中的問題非常有用。如果你沒有聚變反應堆，那麼請忽略這一點。
- __fusionreactor_name=dsnapi;
您必須將其應用於 CFIDE 中的每個資料來源
