qtforum.de

Hallo,
Mal wieder ein Problem aus dem Dunstkreis Threads.

Neben meiner Anwendung läuft ein Thread, der Debugmeldungen in eine SQLite-Datenbank-schreibt. Diese Meldungen werden vom Hauptprogramm mittels Signal an diesen Thread übergeben.
Soweit so gut - es funktioniert solange ganz gut, wie sich die Belastung in Grenzen hält. Aber einer gewissen Belastung jedoch scheint die Queue einfach überzulaufen. Offensichtlich kommt der Thread nicht mehr dazu, die ganzen Einträge wegzuschreiben (möglicherweise könnte man natürlich auch über die Priorität der einzelnen Threads ein wenig gegensteuern). Jedenfalls steigt auf einmal der Speicherverbrauch steil an und wenn man das separat geschriebene Logfile (qDebug umgeleitet) betrachtet, sieht man, das nachdem der Hauptthread ein wenig zur Ruhe gekommen ist, der DebugThread die aufgelaufenen Signale abarbeitet.

Meine Frage:
Gibt es eine Möglichkeit, die Anzahl der sich stauenden Signale zu ermitteln - so das man in einem solchen Fall die Anzahl der neu hinzukommenden Signale zumindest drosseln könnte? Das ganze natürlich mit Qt-Bordmitteln, also ohne jetzt einen Zähler einzubauen, der dann ja wieder von beiden Threads angesteuert werden müsste, was dann die anzahl der Probleme wohl eher erhöhen würde


Gruss
Tilman Räger

Spontaner Gedanke: Hast Du schon mal mit den ConnectionTypes von QObject::connect() "gespielt"?

ich würde sagen, "works as expected".
Die Events werden vom QAbstractEventDispatcher behandelt, und der liefert nur ob es pending events hat. Daher kriegst Du vermutlich nicht die Anzahl events.
Evt via einem NativeEventListener und selber zählen...
Evt kannst Du nach dem senden des Log-Events via QApplication::processEvents... Aber ob das gut geht?
Eine rdbms für Debug-Log empfinde ich nicht als das "Beste". -> verwende besser ein Log-File, das Du später in die db einliest.

Da es mich auch "etwas" interessiert, würde es helfen die QThread::Priority für den Thread, der für das Logging der Debug-Meldungen zuständig ist, zu erhöhen?

Das Logging ist demnach zu langsam - also sollte man dort optimieren...

Hallo,

nach einer Woche Schweiz (leider kein Urlaub - sondern Testtermin komme ich mal wieder dazu hier zu antworten.

Das Problem ist definitiv, das sich ab einer gewissen Belastung die Logmeldungen stauen - was letzten Endes bis zum Absturz des Programms führt. Wir haben jetzt das ganze ein wenig beschleunigt, indem wir die Meldungen nicht mehr auf Platte schreiben sondern in einer sqlite-Datenbank im Speicher halten (das Logging ist nicht dazu gedacht, Fehler im laufenden Betrieb zu protokollieren, sondern dient dazu, in der Einrichtungsphase fehlerhafte Anfragen zu finden.) Trotzdem besteht das Problem weiter, das falls ein Anwender das Logging im vollen Betrieb aufdreht ihm das Programm irgendwann um die Ohren fliegt.

Da ich befürchte, das auch Optimieren des Loggings nicht unbedingt zielführend sein wird (es erweitert lediglich den Flaschenhals) trotz der folgenden Bemerkung

Christian81 hat geschrieben:Das Logging ist demnach zu langsam - also sollte man dort optimieren...

also noch einmal mein Gedankengang.
Ab einem gewissen Stau an Log-Meldungen sollen weitere einfach abgeblockt werden. Möglich wäre das ganze natürlich über eine Queue, in die ich die Logmeldungen einschreibe und die bei einem gewissen Füllstand erst einmal abblockt. Hätte natürlich den ungemeinen Vorteil, das man auch in diesem Zustand noch filtern kann und Logeinträge mit niedriger Priorität zuerst filtern kann. Allerdings handle ich mir dazu natürlich noch einmal eine Kontrollstruktur ein und muss dazu eigentlich auch noch einen separaten Thread einrichten, der das schreiben in die Queue erledigt. In diesem Fall natürlich dann noch mit Zugriffsschutz etc. etc. Also ein elender Rattenschwanz
Eleganter wäre natürlich, wenn man direkt die Anzahl der aufgelaufenen Signale abfragen und ggf. blocken könnte. Gibt es eine solche Möglichkeit?

Gruss
Tilman (Räger)