[ https://issues.apache.org/jira/browse/HBASE-18517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131111#comment-16131111 ]
Hudson commented on HBASE-18517: -------------------------------- FAILURE: Integrated in Jenkins build HBASE-14070.HLC #233 (See [https://builds.apache.org/job/HBASE-14070.HLC/233/]) HBASE-18517 limit max log message width in log4j (stack: rev b653d1bf054737ea841a9298f4eb58fb1a00f1be) * (edit) conf/log4j.properties > limit max log message width in log4j > ------------------------------------ > > Key: HBASE-18517 > URL: https://issues.apache.org/jira/browse/HBASE-18517 > Project: HBase > Issue Type: Bug > Affects Versions: 1.5.0, 2.0.0-alpha-2 > Reporter: Vikas Vishwakarma > Assignee: Vikas Vishwakarma > Fix For: 1.5.0, 2.0.0-alpha-2 > > Attachments: HBASE-18517.branch-1.001.patch, > HBASE-18517.master.001.patch > > > We had two cases now in our prod / pilot setups which is leading to humongous > log lines in RegionServer logs. > In first case, one of the phoenix user had constructed a query with a really > large list of Id filters (61 MB) that translated into HBase scan that was > running slow which lead to responseTooSlow messages in the logs with the > entire filter list being printed in the logs, example > ipc.RpcServer - (responseTooSlow): > {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1501457864417,"responsesize":11,"method":"Scan","param":"region > { type: REGION_NAME value: ..... > org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter\\022\351\\200\\036\\n(org.apache.phoenix.filter.SkipScanFilter > ... <a really long filter list leading to single log lines of size 61MB> ... > There was another case where a use case had created a table with really large > key/region names. This was causing humongous log lines for flush and > compaction on these regions filling up the RS logs > These large logs usually cause issues with disk I/O load, loading the splunk > servers, even machine perf degradations. With 61 MB log lines basic log > processing commands like vim, scrolling the logs, wc -l , etc were getting > stuck. High GC activity was also noted on this cluster although not 100% sure > if it was related to above issue. > We should consider limiting the message size in logs which can be easily done > by adding a maximum width format modifier on the message conversion character > in log4j.properties > log4j.appender.console.layout.ConversionPattern=...: %m%n > to > log4j.appender.console.layout.ConversionPattern=...: %.10000m%n -- This message was sent by Atlassian JIRA (v6.4.14#64029)