简体   繁体   English

log4net性能问题:修复了消息之间的延迟

[英]log4net performance issue: fixed delay between messages

I have quite complex application which consist of 2 web sites and 3 windows services. 我有一个非常复杂的应用程序,其中包括2个网站和3个Windows服务。 All use same log4net configuration, just write into different files: 它们都使用相同的log4net配置,只是写入不同的文件中:

<log4net>
  <logger name="Default">
    <appender-ref ref="VerboseLogFileAppendder" />
  </logger>
  <appender name="VerboseLogFileAppendder" type="log4net.Appender.RollingFileAppender">
    <threshold value="DEBUG" />
    <file value="Logs\MyProductName" />
    <appendToFile value="true" />
    <rollingStyle value="Date" />
    <maximumFileSize value="100MB" />
    <datePattern value="'.'yyyy-MM-dd'.log'" />
    <staticLogFileName value="false" />
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%-3thread] %-5level - %message%newline" />
    </layout>
  </appender>
</log4net>

But one site has huge performance issues with writing logs - every two adjacent messages has more or less fixed delay between them . 但是, 一个站点编写日志时会遇到巨大的性能问题 - 每两条相邻的消息之间或多或少都有固定的延迟 For example, here is part of my log file: 例如,这是我的日志文件的一部分:

2014-03-21 21:48:19,163 [24 ] INFO  -       Begin SiteColourTheme
2014-03-21 21:48:19,489 [24 ] INFO  -         IsChanged = False
2014-03-21 21:48:19,808 [24 ] INFO  -         GridHeaderColour.BackgroundColour = #373F71
2014-03-21 21:48:20,133 [24 ] INFO  -         GridHeaderColour.IsBackgroundColourChanged = False
2014-03-21 21:48:20,464 [24 ] INFO  -         GridHeaderColour.FontColour = #E0E0E0
2014-03-21 21:48:20,800 [24 ] INFO  -         GridHeaderColour.IsFontColourChanged = False
2014-03-21 21:48:21,134 [24 ] INFO  -         GridHeaderColour.IsColourThemeChanged = False
2014-03-21 21:48:21,475 [24 ] INFO  -         DialogHeaderColour.BackgroundColour = #373F71
2014-03-21 21:48:21,810 [24 ] INFO  -         DialogHeaderColour.IsBackgroundColourChanged = False
2014-03-21 21:48:22,139 [24 ] INFO  -         DialogHeaderColour.FontColour = #FFFFFF
2014-03-21 21:48:22,462 [24 ] INFO  -         DialogHeaderColour.IsFontColourChanged = False
2014-03-21 21:48:22,781 [24 ] INFO  -         DialogHeaderColour.IsColourThemeChanged = False
2014-03-21 21:48:23,122 [24 ] INFO  -         AccordionPaneColour.BackgroundColour = #F8F8F8
2014-03-21 21:48:23,481 [24 ] INFO  -         AccordionPaneColour.IsBackgroundColourChanged = False
2014-03-21 21:48:23,862 [24 ] INFO  -         AccordionPaneColour.FontColour = #2B2B2B
2014-03-21 21:48:24,202 [24 ] INFO  -         AccordionPaneColour.IsFontColourChanged = False
2014-03-21 21:48:24,522 [24 ] INFO  -         AccordionPaneColour.IsColourThemeChanged = False
2014-03-21 21:48:24,862 [24 ] INFO  -         PageTabColour.BackgroundColour = #DCDBDB
2014-03-21 21:48:25,208 [24 ] INFO  -         PageTabColour.IsBackgroundColourChanged = False
2014-03-21 21:48:25,527 [24 ] INFO  -         PageTabColour.FontColour = #000000
2014-03-21 21:48:25,855 [24 ] INFO  -         PageTabColour.IsFontColourChanged = False

As you can see, the delay is more than 300ms even for just logging properties of an object (there is no complex logic to retrieve them). 如您所见,即使仅记录对象的属性,延迟也超过300毫秒(没有复杂的逻辑可检索它们)。 What I've discovered that this delay is proportional to the log size: if it is 1 MB, the delay is about 100ms, 2 MB - 200ms, 3 MB - 300ms . 我发现此延迟与日志大小成正比:如果为1 MB,则延迟约为100ms,2 MB-200ms,3 MB-300ms I wonder what could cause such problems. 我想知道是什么原因导致这种问题的。 Any ideas would be highly apreciated. 任何想法都会引起高度重视。

INVESTIGATION DETAILS: 调查详细信息:

Since we are not using log4net directly, but created a wrapper, I first thought there is a bug in wrapper, but it is quite simple and I have no idea how it could cause so strange issues only in one site. 因为我们不是直接使用log4net,而是创建了一个包装器,所以我首先认为包装器中有一个bug,但这很简单,我不知道它怎么可能仅在一个站点上引起如此奇怪的问题。

VS 2013 performance analyzer surprisingly didn't say that logger methods took the most samples (I used sampling analyze). VS 2013性能分析器出乎意料的是没有说记录器方法采样最多(我使用了采样分析)。 I think it proves that issue is not in logic, but in access to external resources, while application thread is suspended. 我认为这证明问题不在逻辑上,而是在应用程序线程被挂起时访问外部资源。

I didn't find any difference between two sites that should cause this issue in one and work find in other. 没有发现两个站点之间的任何差异,一个站点应该导致此问题,而其他站点则可以找到工作。 The sites are very different of course, but no suspicious environment or IIS configuration differences. 这些站点当然有很大的不同,但是没有可疑的环境或IIS配置差异。

I had an idea that log file is opened and closed on each write , but I don't know how to check that for sure. 我有一个想法,每次写操作都会打开和关闭日志文件 ,但是我不知道如何确定。 I can open log in the notepad, edit and save it while application is running. 我可以在记事本中打开日志,在应用程序运行时进行编辑并保存。 Probably that may be a proof. 可能是一个证明。 But shouldn't the delay be almost fixed (not proportional) to file size in this case? 但是在这种情况下,延迟是否不应该几乎与文件大小固定(不成比例)? All that system needs is seeking to the end of a file which is defined by file size (maybe few seeks if file is partitioned, but that's not important). 系统所需的全部工作是查找由文件大小定义的文件的末尾(也许很少有人寻找文件是否已分区,但这并不重要)。 If this is the problem, how can I fix it? 如果这是问题,我该如何解决? I tried using buffered log appender, but same result. 我尝试使用缓冲的日志附加程序,但结果相同。

Other idea was that antivirus checks file on each write , but disabling it didn't solve the problem. 另一个想法是,防病毒软件会在每次写入时检查文件 ,但是禁用它并不能解决问题。

UPDATE: 更新:

Changing logs folder from local relative path to other directory "D:\\Logs..." solved the problem on my development environment, but didn't work on test machine. 将日志文件夹从本地相对路径更改为其他目录“ D:\\ Logs ...”解决了我的开发环境中的问题,但在测试机上不起作用。

UPDATE 2 更新2

The issue is reproducing not stabilly. 问题正在重现,没有停滞不前。 One day I may have the described performance issue and neither restarts, or changing log configuration helps; 有一天,我可能遇到了所描述的性能问题,并且没有重启或更改日志配置都没有帮助。 but then someday the problem goes away and I thought I found a solution. 但是后来有一天问题消失了,我以为我找到了解决方案。 But now it is again reproducing and I don't know why this is happening. 但是现在它又在再现了,我不知道为什么会这样。

It's really hard to diagnose these kind of issues since many factors may be in play to explain the difference. 诊断此类问题确实很困难,因为可能有许多因素在解释这种差异。 However you mentioned that you had many logging actors. 但是,您提到您有许多日志记录参与者。 Are they all on the same machine? 它们都在同一台机器上吗? Is the configuration file you posted the one for the site with the problem? 您为存在问题的站点发布了一个配置文件吗?

It's not a direct answer to your question but you could also investigate the BufferingForwardAppender ( example ), which accumulates messages until a configured limit. 这不是您问题的直接答案,但是您也可以研究BufferingForwardAppender示例 ),该方法会累积消息直到配置了限制。 This will not solve the problem directly but will compound the "writing tax" on your log file, and it has some interesting properties (lossy logging for example, but that's not the subject :) ) 这不会直接解决问题,但是会在日志文件中增加“写作税”,并且具有一些有趣的属性(例如,有损日志记录,但这不是主题:))

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM