Запись в log4net FileAppender с проблемами производительности нескольких потоков

Question

TickZoom - очень высокопроизводительное приложение, которое использует собственную библиотеку распараллеливания и несколько потоков O / S для плавного использования многоядерных компьютеров.

Приложение попадает в узкое место, когда пользователям необходимо записывать информацию в LogAppender из отдельных потоков O / S.

FileAppender использует функцию MinimalLock, так что каждый поток может заблокировать и записать в файл, а затем освободить его для записи следующего потока.

Если MinimalLock отключен, log4net сообщает об ошибках, когда файл уже заблокирован другим процессом (потоком).

Лучшим способом сделать это для log4net было бы создание одного потока, который позаботится о записи в FileAppender, а любые другие потоки просто добавят свои сообщения в очередь.

Таким образом, MinimalLock можно отключить, чтобы значительно повысить производительность ведения журнала.

Кроме того, приложение выполняет большую нагрузку на ЦП, поэтому оно также повысит производительность, используя отдельный поток для записи в файл, чтобы ЦП не ожидал завершения ввода-вывода.

Итак, вопрос в том, предлагает ли log4net эту функцию? Если да, как включить потоковую запись в файл? Может быть, есть другой, более продвинутый аппендиат?

Если нет, то, поскольку log4net уже обернут в платформу, это позволяет реализовать отдельный поток и очередь для этой цели в коде TickZoom.

С уважением, Wayne

EDIT:

Спасибо, кажется, ответы указывают на то, что мы можем разработать наше собственное решение как расширение log4net. И они ясно показывают, что log4net не делает подобные вещи.

Кроме того, мы только что поняли, что можем «злоупотреблять» системой журналирования, которая в основном предназначена для удобочитаемых сообщений для уведомления о важных событиях или отладочной информации. Эта конкретная часть программного вывода действительно используется только для автоматизированных инструментов, которые проверяют точность системы.

Конечно, мы также используем log4net «обычными» способами для отладки, предупреждений и тому подобного.

Но это больше похоже на «журналы транзакций», чем журналы отладки или уведомлений пользователей. В частности, нет необходимости, чтобы эти журналы были непосредственно читаемыми человеком. При необходимости какой-либо «просмотрщик» может показать содержимое в форме ASCII.

Таким образом, мы планируем записать этот журнал транзакций в высокоскоростное двоичное хранилище.

Спасибо, что оба ответа ниже были большим толчком к разработке нашего собственного решения.

Answer 1

Log4net не поддерживает точный сценарий, который вы описываете. Тем не менее, он предлагает и другие блокирующие устройства, такие как приложение базы данных или приложение UDP. Вот пара идей:

1. Журнал ваших сообщений на сообщение очереди, а затем есть читатель (или несколько читателей) читать сообщения очереди и запишите их в журнал. Это обеспечивает надежный механизм отправлять / писать сообщения. Если честно Я не знаю, есть ли уже MSMQ appender, но пишу это ты не будешь слишком трудным.

2. Используйте приложение UDP для отправки сообщения, а затем написать свой сервис, который слушает эти сообщения и записывает их в файл.

Я думаю, что вы можете обнаружить тему здесь ... в основном используйте один из неблокирующих приложений (или напишите свой собственный) и реализуйте свой собственный сервис, который получает сообщения от приложений и записывает их в файл.

Answer 2

Проверьте регистратор Object Guy для высокопроизводительного, многопоточного безопасного регистратора с возможностью асинхронного ведения журнала, а также многих других функций - я думаю, это очень приятно - http://www.theobjectguy.com/DotNetLog/. Смотрите многопоточное видео на этом стр.

Answer 3

Весьма желательно избегать добавления ввода-вывода в потоки целевых объектов, поэтому отправка сообщения в поток сборщика журналов - хорошая идея. Я также иногда использую System :: Diagnostics :: Debug :: WriteLine из целевого потока, чтобы вывести его выходные данные, но там все равно будет небольшая блокировка.

Конечно, добавление любой дополнительной регистрации приведет к эффектам "Гейзенберга", поэтому вы должны каким-то образом знать, когда эти эффекты незначительны, а когда нет, чтобы иметь полезную запись ваших высокопроизводительных потоков. 1003 *

Если вы хотите немного повеселиться, вы можете попросить каждый поток сохранить свой собственный список сообщений, а затем вывести его куда-нибудь после стольких итераций. Таким образом, данные будут полезны только в течение периода времени, прежде чем какой-либо поток выполнит свои операции ввода-вывода, но, возможно, вы сможете собрать достаточно информации для отладки. Кроме того, вы получаете забавную задачу объединения журналов отдельных потоков в один журнал для анализа.