Ich habe eine App auf Heroku, auf Puma läuft:Sehr langsam: Active :: Querycache # call
workers 2
threads_count 3
pool 5
Es sieht aus wie einige Anfragen in der Middleware stecken, und es macht die App sehr langsam (SEHR !). Ich habe andere Leute Themen zu diesem Problem gesehen, aber keine Lösung bisher.
Bitte lassen Sie mich wissen, wenn Sie einen Hinweis haben.
!
!
Ich werde meine eigene Frage beantworten: Ich musste einfach alle Anfragen an meine DB zu überprüfen. Eine davon dauerte SEHR lange, und selbst wenn es nicht oft gewünscht wurde, verlangsamte es den ganzen Server für einige Zeit danach (sogar nachdem der Prozess fertig war, gab es eine Art "Stau" auf der Server). Lösung: Überprüfen Sie alle Abfragen zu Ihrer Datenbank, beheben Sie die langsamsten (es könnte einfach bedeuten, es in wenigen Schritten zu brechen, könnte es bedeuten, dass es in der Nacht laufen, wenn kein Verkehr, etc ...). Sobald diese Abfragen behoben sind, sollte alles wieder normal werden.
Ich habe kürzlich einen Anstieg der Zeit in ActiveRecord :: QueryCache # Anruf gesehen. Nachdem ich die Quelle angeschaut hatte, entschied ich mich, den Cache zu löschen, indem ich ActiveRecord::Base.connection.clear_query_cache von einer Rails Console verwendete, die an die Produktionsumgebung angeschlossen war. Der Fehler, den ich bekam, war zurück PG::ConnectionBad: could not fork new process for connection: Cannot allocate memory die mich so auf diese anderen führen mindestens Heroku Rails could not fork new process for connection: Cannot allocate memory
Wie beantwortet das die Frage? –
Nachdem ich die gleiche Erfahrung gemacht hatte wie das OP und mehr Nachforschungen gemacht hatte, teilte ich das, was ich gefunden hatte, anstatt die Frage völlig unbeantwortet zu lassen, in der Hoffnung, dass es jemandem helfen könnte. – rjspotter
Frage Ich arbeite für Heroku Unterstützung und Middleware/Rack/ActiveRecord::QueryCache#call ist ein häufig als Problem von New Relic berichtet. Leider ist es in der Regel ein Ablenkungsmanöver, da die Quelle des Problems woanders liegt.
QueryCache ist, wo Rails zuerst versucht, eine Verbindung für die Verwendung auschecken, so dass alle Probleme mit einer Verbindung hier als eine Anforderung angezeigt wird "warten" warten. Dies bedeutet nicht, dass der Datenbankserver nicht notwendigerweise über Verbindungen verfügt (wenn Sie Librarotabellen für Postgres haben, zeigen sie dies). Es bedeutet wahrscheinlich, dass etwas dazu führt, dass bestimmte Datenbankverbindungen in einen fehlerhaften Zustand geraten und neue Anforderungen für eine Verbindung warten. Dies kann in älteren Versionen von Puma auftreten, wo mehrere Threads verwendet werden und reaping_frequency eingestellt ist - wenn einige Verbindungen in einen schlechten Zustand geraten und die anderen geerntet werden, führt dies zu Problemen.
Einige hochrangige Vorschläge sind wie folgt:
rack-timeout gem Wenn verwenden, aktualisieren Sie das auchDiese Upgrades oft helfen. Wenn nicht, gibt es andere Möglichkeiten, wie zum Beispiel den Wechsel von Threads zu Worker-basierten Prozessen oder die Verwendung eines Postgres-Verbindungspools wie PgBouncer. Wir haben weitere Vorschläge zur Konfiguration von gleichzeitigen Webservern für die Verwendung mit Postgres hier: https://devcenter.heroku.com/articles/concurrency-and-database-connections
Antwort auf mich selbst: Überprüfen Sie nur die langsamste Datenbankabfragen, auch wenn sie selten angefordert werden, ihre Auswirkungen auf die restlichen Abfragen ist riesig. – user3029400
Welchen Cache-Speicher verwenden Sie?Das erste, was zu debuggen wäre, warum der Speicher so lange braucht, um zu antworten, oder (wenn der Cache-Speicher archiviert ist), dauert die Deserialisierung der Daten im Cache-Speicher zu lange? – jbielick