Sehr langsam: Aufruf von ActiveRecord :: QueryCache #
Ich habe eine App auf Heroku, die auf Puma läuft:
%Vor%Es sieht so aus, als ob einige Anfragen in der Middleware hängen bleiben und die App sehr langsam wird (SEHR!). Ich habe andere Leute über dieses Problem gesehen, aber bisher keine Lösung.
Bitte lassen Sie mich wissen, wenn Sie einen Hinweis haben.
!
!
3 Antworten
Ich werde meine eigene Frage beantworten: Ich musste einfach alle Anfragen an meine Datenbank abfragen. 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üfe alle Anfragen an deine Datenbank, behebe die langsamsten (es könnte bedeuten, dass es in wenigen Schritten abgebrochen wird, es könnte bedeuten, dass es nachts läuft, wenn kein Verkehr ist, etc ...). Sobald diese Abfragen behoben sind, sollte alles wieder normal sein.
Ich arbeite für die Heroku-Unterstützung und Middleware/Rack/ActiveRecord::QueryCache#call wird häufig von New Relic als Problem gemeldet. Leider ist es in der Regel ein Ablenkungsmanöver, da die Quelle des Problems woanders liegt.
QueryCache ist der Ort, an dem Rails zuerst versucht, eine Verbindung für die Verwendung auszuchecken. Daher werden hier alle Probleme mit einer Verbindung angezeigt, wenn eine Anforderung "warten" wartet. Dies bedeutet nicht, dass der Datenbankserver nicht notwendigerweise über Verbindungen verfügt (wenn Sie Librato-Diagramme für Postgres haben, zeigen sie dies an). 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 gesetzt ist - wenn einige Verbindungen in einen schlechten Zustand geraten und die anderen geerntet werden, wird dies Probleme verursachen.
Einige Vorschläge auf hoher Ebene lauten wie folgt:
- Aktualisieren Sie Ruby & amp; Puma
- Wenn du das Juwel
rack-timeoutverwendest, rüste das auch auf auf
Diese Upgrades helfen oft. 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 zum Konfigurieren von gleichzeitigen Webservern für die Verwendung mit Postgres hier: Ссылка
Ich habe kürzlich einen Anstieg der Zeit in ActiveRecord :: QueryCache # Call gesehen. Nachdem ich die Quelle angeschaut hatte, entschied ich mich, den Cache mit ActiveRecord::Base.connection.clear_query_cache von einer Rails Console zu löschen, die an die Produktionsumgebung angeschlossen war. Der Fehler, den ich zurückbekommen habe, war PG::ConnectionBad: could not fork new process for connection: Cannot allocate memory , was mich zu dieser anderen SO-Frage führte, zumindest Heroku Rails konnte keinen neuen Prozess für die Verbindung abzweigen: Kann nicht Speicher reservieren
Tags und Links activerecord heroku ruby-on-rails-4 rack query-cache