[logback-user] Logback becomes excruciatingly slow during rollover

[Ceki Gulcu]

Hello Vesuvius,

Enabling logback's internal status messages [1] is an investigative step 
of *first* resort. I would start there.

Any computing system can be brought to its knees if sufficiently 
stressed. From what I could gather from your previous messages, the 
application in question generates massive amounts of logs. If so, my 
suggestion would be to reduce logging output by setting the root logger 
level to WARN for example.

As a side note, I would suggest using SizeAndTimeBasedRollingPolicy [2] 
which provides a much nicer archiving policy than the 
FixedWindowRollingPolicy+SizeBasedTriggeringPolicy combination.

--
Ceki

[1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting

[2] 
http://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy


On 5/11/2016 12:02, Vesuvius Prime wrote:

> Hi,

> Thank you for the suggestion. This was the first thing I had
> suggested to the customer during the live session with them but then
> they said they didn't want to be a "testbed" for us, so they didn't do
> it. Now I asked our support guys to ask the customer again to do this
> and this time the customer agreed. After waiting a while for the logs
> to roll over, here's the feedback:
>
> "Hello, Customer just provided an update.  Log file is not rolling
> over, however it has grown to over 90mb, but the [product] has not
> slowed down."
>
> So, there's an improvement -- at least now we're not becoming
> unusable due to excessive slowness. However, the log grows without a
> limit. The bottom line is that this is an improvement, but not a
> solution.
>
> I would still love somebody with deep knowledge of Logback
> (presumably its authors) to provide some feedback here. For example,
> if this is a known problem and it has been solved in some version of
> Logback, we may go ahead an modify the Virgo server to use that
> version. Alternatively, if Logback is unreliable, we may have to
> switch to some other logging framework. I've been seeing various
> reports about rollover problems, even in this mail list. We can't
> afford to lose customers due to logging. Besides, this creates a
> really bad image to Logback itself.
>
>  Thank you for reading this.
>