You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2013/10/26 21:39:30 UTC

[jira] [Comment Edited] (LOG4J2-437) Log4J2 Performs poorly with 500 concurrent users with Jboss 5.1.GA and JDK 6

    [ https://issues.apache.org/jira/browse/LOG4J2-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806159#comment-13806159 ] 

Ralph Goers edited comment on LOG4J2-437 at 10/26/13 7:37 PM:
--------------------------------------------------------------

If you have a log4j 1.2 jar in the parent class loader then there is no way to prevent CXF from using it unless you put log4j 2 in the parent class loader along with log4j-1.2-api.jar from Log4j 2 and completely remove the log4j 1.2 jar.

Although I believe Remko has performance test that show that the RandomAccessFileAppender is faster than the RollingFileAppender, you still might want to try using that to determine if the locking Remko mentions is causing any problems for you. However, if you are seeing lots of I/O waits that is more a sign of I/O contention, not lock contention. Still, since you are probably writing to an NFS mount the differences in how these Appenders work might be impacted differently.

You might also try adjusting the buffer size on the RandomAccessFileAppender. The default buffer size is 256K. RollingFileAppender uses a buffer size of 8K (which is currently not configurable - interestingly it is in a normal FileAppender).

As for swapping and system memory usage, you would need to look at the output from top to determine what processes are using the memory. If you have processes that in total are being given more memory than the server physically has then you should expect to see swapping based on what each application is doing.


was (Author: ralph.goers@dslextreme.com):
If you have a log4j 1.2 jar in the parent class loader then there is no way to prevent CXF from using it unless you put log4j 2 in the parent class loader along with log4j-1.2-api.jar from Log4j 2 and completely remove the log4j 1.2 jar.

Although I believe Remko has performance test that show that the RandomAccessFileAppender is faster than the RollingFileAppender, you still might want to try using that to determine if the locking Remko mentions is causing any problems for you. However, if you are seeing lots of I/O waits that is more a sign of I/O contention, not lock contention. Still, since you are probably writing to an NFS mount the differences in how these Appenders work might be impacted differently.

You might also try adjusting the buffer size on the RandomAccessFileAppender. The default buffer size is 256K. RollingFileAppender uses a buffer size of 8K (which is currently not configurable - interestingly it is in a normal FileAppender).

As for swapping and system memory usage, you would need to look at the output from top to determine what processes are using the memory. If you have processes that in total are being given more memory than the server physically has then you should expect to see swapping based on what each server is doing.

> Log4J2 Performs poorly with 500 concurrent users with Jboss 5.1.GA and JDK 6
> ----------------------------------------------------------------------------
>
>                 Key: LOG4J2-437
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-437
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 2.0-beta9
>         Environment: JDK                : 1.6.0_18
> APP Server    :  Jboss 5.1.0_GA
> Task               : Migrate from Log4J_1.2 to Log4J2
> OS                 : Linux 5 (Virtual Machine)
>            Reporter: Giri Kosuru
>            Priority: Critical
>              Labels: Performance
>
> Environment Details
> ================
> JDK                : 1.6.0_18
> APP Server    :  Jboss 5.1.0_GA
> Task               : Migrate from Log4J_1.2 to Log4J2
> OS                 : Linux 5 (Virtual Machine)
> We are trying to upgrade from Log4J 1.2 to Log4J2 due to performance reasons. In log4j1.2, we saw thread BLOCKING and decided to go to LOG4J2. Before migration, we tested to evaluate and we found performance improvement with LOG4J2. 
> After full migration, when application moved to performance testing environment, we started seeing trouble with Log4j2. We saw at least 40 TPS down, with increased response times; in performance. When diagnosed, found that there is increased SWAPPING  on linux and with increased IO waits (Some times 15 %). 
> For the same given environment and load test; application with LOG4J_1.2 code , does not have  any SWAPPING and IO waits. In addition we have BAD performance with LOG4J2.
> Can anyone give us pointers on what we are doing wrong ? Or there are some performance issues with LOG4J2 ?? We are stuck in between releases and if there is no help coming, we may just abandon LOG4J2. So Please I request you to look seriously and give us some pointers.
> Following is the configuration for log4j2.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration status="trace" verbose="true">
>         <appenders>
>                 <RollingRandomAccessFile name=“APP_1066_LOG" fileName=“/path/to/log/file-1066.log" filePattern=“/path/to/log/file-1066.log.%i" append="true" immediateFlush="false">
>                         <PatternLayout>
>                                 <pattern>%d{ISO8601} %-5p [%t]: [%c{1}] %m%n - %X{ElapsedTime}-%X{ByteSize}- %X{uniqueID}-%X{HttpMethod}-%X{Host}-%X{URL}-%X{ClientIP}-%X{NodeID}-%X{NodeUserID}-%X{HttpCode}-%X{ApplicationCode}</pattern>
>                         </PatternLayout>
>                         <Policies>
>                                 <SizeBasedTriggeringPolicy size="250 MB"/>
>                         </Policies>
>                         <DefaultRolloverStrategy max="10"/>
>                 </RollingRandomAccessFile>
>                 <RollingRandomAccessFile name="hibernateAppender" fileName=“/path/to/log/anotherfile-1066.log" filePattern=“/path/to/log/anotherfile-1066.log.%i" append="true" immediateFlush="false">
>                         <PatternLayout>
>                                 <pattern>%d{ISO8601} %-5p [%t]: [%c{1}] %m%n - %X{ElapsedTime}-%X{ByteSize}- %X{uniqueID}-%X{HttpMethod}-%X{Host}-%X{URL}-%X{ClientIP}-%X{NodeID}-%X{NodeUserID}-%X{HttpCode}-%X{ApplicationCode}</pattern>
>                         </PatternLayout>
>                         <Policies>
>                                 <SizeBasedTriggeringPolicy size="250 MB"/>
>                         </Policies>
>                         <DefaultRolloverStrategy max="10"/>
>                 </RollingRandomAccessFile>
>                 <Async name="ASYNC">
>                         <appender-ref ref="hibernateAppender"/>
>                         <appender-ref ref=“APP_1066_LOG"/>
>                 </Async>
>         </appenders>
>         <loggers>
>                 <root level="INFO">
>                         <appender-ref ref="ASYNC"/>
>                 </root>
>         <!-- ============================== -->
>         <!-- Various loggers -->
>         <!-- ============================== -->
>         <logger name="org.hibernate" additivity="false" level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         <logger name="org.springframework.orm.hibernate3" additivity="false" level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         <logger name="org.hibernate.SQL" level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         </loggers>
> </configuration>
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org