Schreiben in einen log4net FileAppender mit mehreren Thread-Leistungsproblemen

Question

TickZoom ist eine sehr leistungsfähige App, die eine eigene Parallelisierungsbibliothek und mehrere O/S-Threads für die reibungslose Nutzung von Multicore-Computern verwendet.

Die App löst einen Engpass, bei dem Benutzer Informationen aus separaten O/S-Threads in einen LogAppender schreiben müssen.

Der FileAppender verwendet die MinimalLock-Funktion, so dass jeder Thread sperren und in die Datei schreiben kann und sie dann für den nächsten zu schreibenden Thread freigeben kann.

Wenn MinimalLock deaktiviert wird, meldet log4net Fehler über die Datei, die bereits von einem anderen Prozess (Thread) gesperrt ist.

Ein besserer Weg für log4net, dies zu tun wäre, einen einzigen Thread zu haben, der sich um das Schreiben in den FileAppender kümmert, und alle anderen Threads fügen einfach ihre Nachrichten zu einer Warteschlange hinzu.

Auf diese Weise konnte MinimalLock deaktiviert werden, um die Leistung der Protokollierung erheblich zu verbessern.

Darüber hinaus führt die Anwendung eine Menge CPU-intensive Arbeit durch, so dass sie auch die Leistung verbessert, einen separaten Thread zum Schreiben in die Datei zu verwenden, so dass die CPU niemals auf die I/O wartet.

Die Frage ist also, bietet log4net diese Funktion bereits? Wenn ja, wie wird das Thread-Schreiben in eine Datei aktiviert? Gibt es vielleicht noch einen anderen, fortgeschritteneren Appender?

Wenn nicht, dann ist log4net bereits in der Plattform eingebunden, wodurch es möglich ist, einen separaten Thread und eine Warteschlange für diesen Zweck im TickZoom-Code zu implementieren.

Mit freundlichen Grüßen, Wayne

EDIT:

Dank es die Antworten auf irgendeine Weise log4net verweisen auf die Entwicklung unserer eigenen Lösung, wie vielleicht eine Erweiterung scheint. Und sie zeigen deutlich, dass log4net solche Dinge nicht macht.

Darüber hinaus haben wir gerade festgestellt, dass wir das Logging-System "missbrauchen" könnten, das hauptsächlich für lesbare Nachrichten gedacht ist, um wichtige Ereignisse oder Debugging-Informationen zu melden. Dieser spezielle Teil der Softwareausgabe wird nur für automatisierte Tools verwendet, die die Genauigkeit des Systems überprüfen.

Natürlich verwenden wir log4net auch auf "normale" Weise für Debugging, Warnungen und so.

Aber diese sind eher "Transaktionsprotokolle" als Debug oder Benutzer Benachrichtigungsprotokolle. Genauer gesagt ist es nicht notwendig, dass diese Protokolle direkt für Menschen lesbar sind. Bei Bedarf kann ein "Betrachter" den Inhalt in ASCII-Form anzeigen.

Also werden wir planen, diese Transaktion-Typ-Protokoll zu einem Hochgeschwindigkeits-Binärspeicher geschrieben werden.

Danke, es scheint, dass beide der Antworten unten große Anstöße waren, unsere eigene Lösung zu entwickeln.

Answer 1

Log4net unterstützt nicht das genaue Szenario, das Sie beschreiben. Es bietet jedoch andere Appender, die nicht sperren, wie der Datenbank-Appender oder der UDP-Appender.Hier sind ein paar Ideen:

1. Melden Sie Ihre Nachrichten an eine Nachricht Warteschlange, und dann einen Leser (oder mehrere Leser) lesen Nachrichten aus die Warteschlange und schreibt sie in einem Protokoll. Dies bietet einen zuverlässigen Mechanismus zum Senden/Schreiben von Nachrichten. Um ehrlich zu sein Ich weiß nicht, ob es schon einen MSMQ Appender gibt, aber es selbst schreiben wäre nicht zu schwer.

2. Verwenden Sie den UDP appender Nachrichten zu senden und dann Ihren eigenen Service schreiben, die auf diese Nachrichten hören und sie in eine Datei schreibt.

Ich glaube, Sie hier ein Thema erkennen kann ... im Grunde eine der nicht blockierende Appender (oder schreiben Sie Ihre eigenen) und Ihre eigenen Dienst implementieren, die die Nachrichten von den Appen empfängt und schreibt sie in eine Datei .

Answer 2

Es ist sehr wünschenswert, keine I/O zu Ihren Targets-Threads hinzuzufügen, daher ist es ratsam, eine Nachricht an den Logging-Collector-Thread zu senden. Manchmal benutze ich auch System :: Diagnostics :: Debug :: WriteLine aus dem Zielthread, um seine Ausgabe auszugeben, aber da drinnen muss es sowieso eine kleine Sperre geben.

Natürlich wird jede zusätzliche Protokollierung zu "Heisenberg" -Effekten führen, also müssen Sie irgendwie wissen, wann diese Effekte vernachlässigbar sind und wann nicht, um eine brauchbare Protokollierung Ihrer Hochleistungs-Threads zu erhalten.

Wenn Sie ein wenig schicker werden wollen, können Sie jeden Thread seine eigene Nachrichtenliste speichern lassen und sie dann nach so vielen Iterationen irgendwo ausgeben lassen. Die Daten würden also nur in der Zeit nützlich sein, bevor ein Thread seine Logging-E/A durchführt, aber vielleicht könnten Sie genug Informationen für Ihr Debugging erfassen. Außerdem haben Sie die lustige Aufgabe, die einzelnen Thread-Logs zur Analyse in einem einzigen Log zusammenzufassen.

Answer 3

Auschecken Die Object Guy Logger für eine hohe Leistung, Multi-Thread-Safe-Logger mit der Fähigkeit für asynchrone Protokollierung sowie viele andere Funktionen - ganz nett denke ich - http://www.theobjectguy.com/DotNetLog/. Sehen Sie sich das Multithread-Video auf dieser Seite an.