lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error
Date Fri, 07 Sep 2018 18:37:00 GMT


Erick Erickson commented on SOLR-12753:

[~ab] Can you give this a whirl, I've found a pattern layout that limits the length of the
message. Notes:
 * I've arbitrarily limited the length of the messages to 10240. This is a straw-man number,
 * I've assumed that the truncation is done before the message is put in the buffer. I have
no proof of that but it seems logical
 * Truncated messages will have elipses at the end. Interestingly when I made the length extremely
short (10) there were no elipses.

Let me know if this fixes the problem you saw and anyone who wants to chime in on the default
message length please do. Having a default there _does_ allow us to predict the max memory

> Async logging ring buffer and OOM error
> ---------------------------------------
>                 Key: SOLR-12753
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: logging
>    Affects Versions: 7.5
>            Reporter: Andrzej Bialecki 
>            Assignee: Erick Erickson
>            Priority: Major
>         Attachments: SOLR-12753.patch
> I’m using a simulated environment for autoscaling tests, which may create some pretty
degenerate cases (like collections with 50,000 replicas and Policy calculations over these,
times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM error,
and the heap dump showed that the biggest objects were a bunch of extremely large strings
in the async logger’s ring buffer. These strings were admittedly extremely large (million
chars or so) but the previously used sync logging didn’t have any issue with them, because
they were consumed one by one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I also feel
like the framework could perhaps help here by enforcing large but sane limits on maximum size
of log messages.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message