Unsere Rails 4.0-Anwendung (Ruby 2.1.2) läuft auf Nginx mit Puma 2.9.0.
Ich habe kürzlich festgestellt, dass alle Anfragen an unsere Anwendung nach einiger Zeit (normalerweise 1 oder 2 Tage) hängen bleiben.
Beim Überprüfen des Protokolls, das auf debug mode eingestellt ist, habe ich den folgenden Protokollstack bemerkt:
Es bedeutet, dass Anfragen tatsächlich auf die Rails-App treffen, aber irgendwie wird es nicht ausgeführt, während es normalerweise so wäre:
%Vor%Meine Puma-Konfiguration ist die folgende:
%Vor%Unsere Anwendung ist nur für den internen Gebrauch wie jetzt, also ist die RPM sehr niedrig und keine der Anfragen dauert länger als 2s.
Was sind / sind die Gründe, die zu diesem Problem führen könnten? (Puma-Konfiguration, Datenbankverbindung usw.)
Vielen Dank im Voraus.
Aktualisierung: Nach dem Installieren des gem rack_timers, um die Zeit aufzuzeichnen, die für jede Middleware aufgewendet wurde, stellte ich fest, dass unsere Anfragen bei dem ActiveRecord :: QueryCache hängen blieben, als der Hang auftrat und viel Zeit darauf war:
%Vor%Ich habe diese Middleware vorerst entfernt und sie scheint wieder normal zu sein. Ich verstehe jedoch, dass der Zweck dieser Middleware darin besteht, die Leistung zu erhöhen, so dass es nur eine vorübergehende Lösung ist. Bitte helfen Sie mir, die mögliche Ursache für dieses Problem herauszufinden.
FYI, wir benutzen mysql (5.1.67) mit dem Adapter mysql2 (0.3.13)
Es könnte ein Symptom für RAM-Mangel sein, weil der Abfrage-Cache zu groß wird. Wir haben das in einer unserer Apps auf Heroku gesehen. Der Standardabfragecache ist auf 1000 gesetzt. Das Senken des Limits hat die RAM-Nutzung für uns ohne merkliche Leistungseinbuße erleichtert:
Bei der Suche nach "activecord querycache slow" werden jedoch andere Ursachen zurückgegeben, z. B. möglicherweise veraltete Versionen von Ruby oder Puma oder Rack-Timeout: Ссылка
Oder vielleicht ein zu großer Wert für read_timeout: Ссылка
Tags und Links nginx mysql ruby-on-rails puma