Using AsyncAppender will cause logging messages to buffer into memory that goes straight to heap (iirc) and will eventually cause memory pressure issues (i.e. long GCs). Which is very problematic to overall cluster performance and stability.
Elasticsearch logging at INFO level is very quiet and should not be the cause of any I/O bottleneck.
Hi! I posted the issue from 19 days ago. I believe we actually do need asynchronous appending:
We have a setup with Elasticsearch logging to a Redis queue. Suppose the ES loglevel would temporarily be changed to DEBUG (or maybe even TRACE) and there would also be network issues in between ES and Redis. If a synchronous appender would be used, then in this setup the logging would actually render the cluster to be very slow/unresponsive because it would have to wait for all logs to be processed, before getting to continue its normal operations.
Or is there something I'm missing/does ES solve this in a different way?
@tvlieg I understand what you mean and indeed enabling TRACE and DEBUG with synchronous may impose some performance impact but I don't think it pays off the performance issues you would have if async is used and heap gets flooded with logging messages because disk can not keep up with it.
Anyway, I have yet to see a situation that enabling DEBUG and TRACE in production with sync logging would severely impact cluster performance. When you enable that logging level it is generally because you have bigger issues going on.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.