Funktionierte heute. Ich habe ein track hochgeladen.
Heute wieder diese Fehlermeldung im Portal.openbikesensor.org –
„QueuePool limit of size 30 overflow 60 reached, connection timed out, timeout 30.00 (Background on this error at: Error Messages — SQLAlchemy 1.4 Documentation)“
Ich bin auch bis morgen Abend ohne PC unterwegs. Ich starte es neu, sobald ich wieder zurück bin
Obiger Fehler tritt heute wieder auf. Ich wollte einen API-Key für meinen neuen OBS generieren, kann mich aber nicht einloggen.
@opatut kannst Du mal dagegentreten?
Ich nutze beim darmstädter Portal einen lokalen Failsafe, falls den noch jemand verwenden möchte. Der Portal container bekommt ein zusätzliches Label „AUTOHEAL=true“, einen healthcheck und es wird ein autoheal-dienst angefahren der bei problemen das Portal neu startet:
portal:
[...]
labels:
[...]
- AUTOHEAL=true
healthcheck:
test: ["CMD", "curl", "--fail", "http://localhost:3000/api/mapdetails/road?longitude=0.0&latitude=0.0&radius=100"]
interval: 20s
retries: 2
start_period: 30s
timeout: 10s
autoheal:
restart: always
image: willfarrell/autoheal
environment:
- AUTOHEAL_CONTAINER_LABEL=AUTOHEAL
volumes:
- /var/run/docker.sock:/var/run/docker.sock
Ich habe das Portal gerade einmal neugestartet.
Danke @gluap. Das werde ich die Tage dann auch in unserem Portal konfigurieren!
Moin.
Aktuell versuche ich das Portal seit mehreren Tagen zu erreichen. Im Firefox kommt eine Fehlermeldung (Timeout), in Opera kommt zwar die Startseite, aber es werden keine statistischen Daten angezeigt. :-\
Beste Grüße
Daniel
Ich habe es neugestartet. Es ist wieder online.
Das Portal meldet schon wieder einen TimeOut. Könnt Ihr nochmal nachsehen?
Vielen Dank!
Eine Root-Cause Analyse wäre vielleicht auch interessant. Was genau bleibt denn hängen und warum?
@HortusNanum die Analyse läuft hier QueuePool limit · Issue #192 · openbikesensor/portal · GitHub
weitere Infos finden sich beim ersten - nicht 100% erfolgreichen - reparaturversuch: https://github.com/openbikesensor/portal/pull/196
Gist ist: Beim Herumscrollen auf der Karte schickt der Browser reichlich request aborts ans backend, die mehr oder weniger direkt an die sqlalchemy datenbankverbindung weitergeben werden. Das endet damit, dass im pool mutmaßlich kaputte Verbindungen zurückbleiben. Das Problem ist auch upstream beschrieben worden. Das Problem wird durch langsame Serverhardware verschlimmert, kann aber der Sache nach auch auf schnelleren Servern auftreten.
Sind da eventuell zwei DB Pooler im Spiel? Ich kenne ein ähnliches Verhalten aus dem Zusammenspiel von Hikari (Java Pooler) und dem PGbouncer Postgres HA Pooler. Hier steigt auch die Connectionanzahl binnen Minuten weil Hikari als erste Instanz die offenen Connections nicht sieht und neue aufmacht.
Den Autorestart haben wir gestern eingebaut. Sollte das Portal nicht verfügbar sein, einfach einen Moment warten und nochmal versuchen.
Und die Ursache ist egal?
Die Ursache ist auf jeden Fall nichts, das „HA“ im Namen trägt, denn sowas nutzen wir ja nicht, der Einfachheit halber.
Ich denke die Ursache ist entweder ein Fehler in der Nutzung von Transaktionen oder asyncio in der Anwendung oder ein Bug im Pooling von sqlalchemy’s async engine.
Die technische Analyse findet wie @gluap schrieb im Github Issue zu dem Thema statt. Falls du das analysieren möchtest um die root cause zu finden, nur zu! Der Autoheal ist dort auch als „Ugly workaround“ beschrieben, es ist allen klar dass das keine langfristige Lösung ist
Ich kann heute (5.3.23) das Portal portal.openbikesensor.org nicht aufrufen (page not found). Wurde es abgeschaltet? Sind alle Daten aus der Vergangenheit verloren?
Ich gehe davon aus dass es bald wieder auftaucht.
Edit: Schon wieder da!