계속 실행되는 페이지를 보여주는 Fusion Reactor의 첨부된 그림을 참조하세요. 시간이 수백만 개로 늘어났고 완료되었는지 확인하기 위해 남겨두었지만 그때는 2~3개밖에 없었습니다.
이제 결코 끝나지 않는 수십 페이지가 나옵니다. 그리고 그것은 다른 쿼리이므로 7개의 데이터베이스 중 3개에만 적용되는 것 외에는 큰 패턴을 볼 수 없습니다.
top쇼저온융합CPU 사용량은 약 70-120%이며 Fusion Reactor 세부 정보 페이지를 자세히 살펴보면 구축 시간이 MySQL 쿼리에만 소요되는 것을 알 수 있습니다.
show processlist10 - 20개의 연결을 제외하고 특별한 결과를 반환하지 않습니다.잠상태.
이 시간 동안 많은 페이지가 완료되지만 페이지 수가 늘어나고 완료되지 않는 것처럼 보이면 결국 서버는 흰색 페이지만 반환합니다.
유일한 단기 해결책은 Coldfusion을 다시 시작하는 것 같지만 이는 이상적이지 않습니다.
5분마다 실행되고 처리할 배치 csv 파일을 확인하는 Node.js 스크립트가 최근 추가되었습니다. 이것이 모든 MySQL 연결을 도용하는 데 문제를 일으키는지 궁금해서 이를 비활성화했습니다(스크립트에 연결이 없습니다.end). () 메서드가 포함되어 있음) 하지만 이는 단지 빠른 추측일 뿐입니다.
어디서부터 시작해야 할지 모르겠습니다. 누구든지 도와주실 수 있나요?
최악의 부분은 페이지가 절대로 시간 초과되지 않는다는 것입니다. 만약 그렇게 했다면 그렇게 나쁘지는 않을 것입니다. 그러나 잠시 후에는 아무것도 제공되지 않습니다.
Coldfusion 및 NodeJS를 기본 스크립트 언어로 사용하여 CentOS LAMP 스택을 실행하고 있습니다.
실제로 게시하기 전에 업데이트
Node 스크립트를 비활성화하고 Coldfusion을 다시 시작한 후 이 게시물을 작성하는 동안 문제가 사라진 것 같습니다.
하지만 페이지가 시간 초과되지 않는 이유를 정확히 식별하고 Node 스크립트에 다음과 같은 것이 필요한지 확인하는 데 도움이 필요합니다.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.
더 많은 업데이트
코드를 뒤져보면서 7200000ms 시간 제한이 너무 우연의 일치라고 느꼈기 때문에 "2h", "120" 및 "7200"을 찾아보았습니다.
이 코드를 찾았습니다.
// 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()(또는 유사한 것)에 매달릴 것이라고 보장합니다.
문제는 DB에 대한 TCP 연결의 1/2이 닫혀서 cf가 결코 얻지 못할 응답을 기다리고 있다는 것입니다.
cf 박스와 db 사이에 네트워크 문제가 있습니다.
일반적으로 Java db 드라이버는 이 문제를 제대로 처리하지 못합니다.
스택 추적에 감사드립니다.
이것은 TCP 연결이 닫히는 것의 1/2이라는 가정을 확인시켜줍니다.
다음 중 하나가 의심됩니다. 1) mysql이 Linux에 있고 TCP 스택에 버그가 있으므로 해당 상자에서 Linux를 업그레이드해야 합니다. 예, 이전에 본 적이 있습니다. 2) coldfusion이 Linux에 있습니다.. .1에 따라 ) 3) 상자 중 하나에 또는 상자 사이에 결함이 있는 케이블/하드웨어가 있습니다. 4) Windows를 실행하는 경우 TCP OFFLOAD를 비활성화하세요!!!
3) 어려운 문제입니다. 두 상자 모두에서 Wireshark를 실행하고 패킷 손실을 입증해야 합니다. 더 간단한 해결책은 Rackspace VM을 다른 물리적 호스트로 이동하고 그것이 사라지는지 확인하는 것입니다. (귀하의 코드가 매우 나쁘고 CF 상자와 MySQL 상자 사이의 네트워크가 포화 상태일 가능성은 거의 없지만 그렇게 나쁜 코드를 작성하는 것이 가능한지 확신할 수 없습니다.)
답변2
나는 이 문제를 조사하는 데 좀 더 많은 시간을 보냈고 네트워크 문제의 구체적인 원인과 Charlie Arehart의 도움을 받아 찾은 해결 방법에 대해 추가할 세부 정보가 있습니다.
첫째, iptables restart. 이는 서버에 접속할 수 있는 IP 주소 목록을 업데이트하는 동시에 애플리케이션과 DB 서버 간의 연결을 끊는 작업이었습니다.
이는 느린 페이지나 더 자주 실행되는 페이지에서 발생할 가능성이 더 높았지만 코드와 일치하는 모든 항목은 iptables restart잘립니다.
Rackspace는 이를 발견하고 다음과 같이 코드를 변경할 것을 제안했습니다.
/sbin/service iptables restart
에게
/sbin/iptables-restore < /etc/sysconfig/iptables
이렇게 하면 서비스 다시 시작이 중지되고 새 연결에만 적용됩니다.
이것이 문제의 근본 원인이었지만 실제 문제는 Coldfusion 또는 실제로 아래에 있는 JDBC가 DB 서버의 응답을 기다리는 것을 멈추지 않는다는 사실입니다.
2시간 제한 시간이 어디서 발생했는지는 잘 모르겠지만(기본값이라고 가정) Charlie는 CFIDE 연결 문자열에서 더 낮은 시간 제한을 설정하는 방법을 보여주었습니다. 이는 CF가 DB를 포기하기 전에 최대 시간을 기다리도록 지시합니다.
따라서 연결 문자열은 다음과 같습니다.
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
이 2개의 세부 사항은 기억나지 않지만 DB 연결을 기다린 다음 포기할 시간을 밀리초 단위로 설정하고 있습니다.
- 연결타임아웃=600000;
- 소켓타임아웃=600000;
이것은 단순히 Fusion Reactor에서 데이터 소스에 레이블을 지정하는 것입니다. 가지고 있는 경우 CF 애플리케이션에서 문제를 찾는 데 매우 유용합니다. Fusion Reactor가 없으면 이 부분을 그대로 두십시오.
- __fusionreactor_name=dsnapi;
이를 CFIDE의 각 데이터 소스에 적용해야 합니다.
