Sehen Sie sich das beigefügte Bild des Fusionsreaktors an, das Seiten zeigt, die einfach weiterlaufen. Die Zeiten sind in die Millionen gegangen und ich habe sie stehen lassen, um zu sehen, ob sie fertig werden, aber das war, als es nur 2 oder 3 waren.
Jetzt bekomme ich Dutzende von Seiten, die einfach nie fertig werden. Und es sind unterschiedliche Abfragen, ich kann kein großes Muster erkennen, außer dass es nur auf 3 meiner 7 Datenbanken zuzutreffen scheint.
topzeigt anKaltfusionDie CPU-Auslastung liegt bei etwa 70–120 %, und bei genauerem Hinsehen auf den Detailseiten des Fusion Reactors wird deutlich, dass die gesamte Zeit ausschließlich für MySQL-Abfragen aufgewendet wird.
show processlistgibt nichts Ungewöhnliches zurück, außer 10 - 20 Verbindungen inschlafenZustand.
Während dieser Zeit werden viele Seiten fertig gestellt, aber da die Zahl der hängenden Seiten zunimmt und sie scheinbar nie fertig werden, gibt der Server schließlich nur weiße Seiten zurück.
Die einzige kurzfristige Lösung scheint ein Neustart von Coldfusion zu sein, was jedoch alles andere als ideal ist.
Kürzlich wurde ein Node.js-Skript hinzugefügt, das alle 5 Minuten ausgeführt wird und nach zu verarbeitenden Batch-CSV-Dateien sucht. Ich habe mich gefragt, ob dies ein Problem beim Stehlen aller MySQL-Verbindungen verursacht, also habe ich es deaktiviert (das Skript enthält keine Methode connection.end()), aber das ist nur eine schnelle Vermutung.
Keine Ahnung, wo Sie anfangen sollen, kann jemand helfen?
Das Schlimmste ist, dass es bei den Seiten NIE zu einer Zeitüberschreitung kommt. Wenn das der Fall wäre, wäre es nicht so schlimm. Nach einer Weile wird jedoch nichts mehr bereitgestellt.
Ich verwende einen CentOS LAMP-Stack mit Coldfusion und NodeJS als meinen primären Skriptsprachen
AKTUALISIEREN SIE VOR DEM TATSÄCHLICHEN POSTEN
Während ich diesen Beitrag verfasste, nachdem ich das Node-Skript deaktiviert und Coldfusion neu gestartet hatte, schien das Problem behoben zu sein.
Aber ich hätte trotzdem gerne Hilfe bei der genauen Identifizierung, warum die Seiten nicht ablaufen, und bei der Bestätigung, dass das Node-Skript so etwas braucht wieconnection.end()
Außerdem kann es sein, dass es nur unter Last auftritt, also bin ich nicht 100% sicher, dass es weg ist
AKTUALISIEREN
Ich habe immer noch Probleme. Ich habe gerade eine der Abfragen kopiert, die derzeit bis zu 70 Sekunden in Fusion Reactor dauert, und sie manuell in der Datenbank ausgeführt. Sie war in wenigen Millisekunden abgeschlossen. Die Abfragen selbst scheinen kein Problem zu sein.
EIN WEITERES UPDATE
Der Stacktrace einer der Seiten ist noch aktiv. Der Server hat schon seit einiger Zeit nicht aufgehört, Seiten bereitzustellen, alle Node-Skripte sind derzeit deaktiviert.
WEITERE UPDATES
Ich hatte heute noch ein paar davon – sie sind tatsächlich fertig geworden und ich habe diesen Fehler in FusionReactor entdeckt:
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.
NOCH MEHR UPDATES
Beim Durchstöbern des Codes habe ich nach „2 h“, „120“ und „7200“ gesucht, da mir das Timeout von 7200000 ms zu sehr nach einem Zufall aussah.
Ich habe diesen Code gefunden:
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
Die 4 Seiten, die auf diese Codezeilen verweisen, werden sehr selten ausgeführt, sind nie mit den Zeitüberschreitungen von über 2 Stunden in den Protokollen aufgetaucht und befinden sich in einem passwortgeschützten Bereich, sodass sie nicht gescrapt werden können (sie dienten zum Hochladen von Dateien und zur CSV-Verarbeitung und wurden jetzt zu node.js verschoben).
Ist es möglich, dass diese Einstellungen irgendwie von einer Seite festgelegt werden, aber auf dem Server vorhanden sind und andere Anforderungen beeinflussen?
Antwort1
1) Posten Sie einen Stacktrace.
Ich garantiere, dass sie an Socket.read() (oder ähnlichem) hängen bleiben.
Was passiert, ist, dass die Hälfte der TCP-Verbindung zur Datenbank geschlossen wird, sodass CF auf eine Antwort wartet, die es nie erhalten wird.
Es gibt Netzwerkprobleme zwischen der CF-Box und der Datenbank.
Java-DB-Treiber sind im Allgemeinen schlecht im Umgang mit diesem
Danke für den Stacktrace
Dies bestätigt meine Annahme, dass die Hälfte der TCP-Verbindung geschlossen wird.
Ich vermute einen der folgenden Gründe: 1) MySQL läuft unter Linux und hat einen Fehler im TCP-Stack, Sie müssen also Linux auf dieser Box aktualisieren – ja, das habe ich schon einmal gesehen. 2) ColdFusion läuft unter Linux … gemäß 1) 3) Auf oder zwischen einer der Boxen befindet sich ein fehlerhaftes Kabel/eine fehlerhafte Hardware. 4) Wenn Sie Windows verwenden, DEAKTIVIEREN SIE TCP-OFFLOAD!!!
Nummer 3) ist die schwierigste. Sie müssten Wireshark auf beiden Boxen ausführen und Paketverluste nachweisen. Die einfachere Lösung wäre, die Rackspace-VMs auf andere physische Hosts zu verschieben und zu sehen, ob das Problem verschwindet. (Es besteht eine geringe Chance, dass Ihr Code sehr, sehr schlecht ist und Sie das Netzwerk zwischen der CF-Box und der MySQL-Box überlasten, aber ich bin nicht sicher, ob es möglich ist, so schlechten Code zu schreiben.)
Antwort2
Ich habe etwas mehr Zeit darauf verwendet, dies zu untersuchen, und kann nun einige weitere Einzelheiten über die spezifische Ursache der Netzwerkprobleme und einen Workaround hinzufügen, den ich mit etwas Hilfe von Charlie Arehart gefunden habe.
Zunächst wurde die Netzwerkverbindung durch ein automatisiertes Skript unterbrochen iptables restart. Dadurch wurde eine Liste von IP-Adressen aktualisiert, die auf den Server zugreifen konnten, aber auch alle Verbindungen zwischen der Anwendung und dem DB-Server wurden unterbrochen.
Dies passierte eher auf langsameren Seiten oder solchen, die häufiger ausgeführt wurden, aber alles, was mit dem iptables restartCode zusammenhing, wurde abgeschnitten.
Rackspace hat dies für mich gefunden und vorgeschlagen, den Code wie folgt zu ändern:
/sbin/service iptables restart
Zu
/sbin/iptables-restore < /etc/sysconfig/iptables
Dies verhindert einen Neustart des Dienstes und gilt nur für neue Verbindungen.
Dies war die Grundursache des Problems, das wirkliche Problem besteht jedoch darin, dass Coldfusion bzw. das zugrunde liegende JDBC nicht aufhörte, auf die Antwort vom DB-Server zu warten.
Ich bin nicht sicher, woher das 2-Stunden-Timeout kommt (ich nehme an, es ist ein Standard), aber Charlie hat eine Möglichkeit gezeigt, in der CFIDE-Verbindungszeichenfolge ein kürzeres Timeout festzulegen – dies weist CF an, eine maximale Zeit zu warten, bevor die Datenbank aufgegeben wird.
Unsere Verbindungszeichenfolge lautet also:
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
Ich kann mich bei diesen beiden nicht an die Einzelheiten erinnern, aber sie legen eine Zeit in Millisekunden fest, die gewartet und dann die Datenbankverbindung aufgegeben wird:
- VerbindungsTimeout=600000;
- SocketTimeout = 600000;
Dies ist einfach die Bezeichnung der Datenquelle in Fusion Reactor. Wenn Sie es haben, ist es sehr nützlich, um Probleme in Ihren CF-Anwendungen zu finden. Wenn Sie Fusion Reactor nicht haben, lassen Sie diesen Teil weg.
- __fusionreactor_name=dsnapi;
Sie müssen dies auf JEDE Datenquelle in Ihrem CFIDE anwenden
