archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: Archiva 1.4 M3/M4 on Raspberry PI
Date Sun, 12 May 2013 23:06:42 GMT
2013/5/13 Patrice Ringot <okulea@free.fr>:
> That's it !
>
> Even the Raspberry is happy ... (including 1.4.M4 startup time which is now
> comparable with what I obtained with the 1.4M3 version). Back in the game !
>
> The property to set was :
>
> -DAsyncLoggerConfig.WaitStrategy=Block
>
> (see http://logging.apache.org/log4j/2.x/manual/async.html)
>
> Please, if you can, leave this choice open to the user, maybe adding the
> following lines in the wrapper.conf files:
>
> wrapper.java.additional.7=-DAsyncLoggerConfig.WaitStrategy=Block
> #wrapper.java.additional.7=-DAsyncLoggerConfig.WaitStrategy=Sleep
Sounds good, I will try to change that except if you beat me sending a patch :-)
>
> Thanks for your help !
>
> Patrice
>
> PS: the Raspberry is your friend for performance issues because when it is
> hurt, this is visible (a kind of stress test ...)
LOL :-)
>
> Le 12/05/2013 15:03, Olivier Lamy a écrit :
>
>> Thanks for this analysis !
>> In last version I moved to use new asyncLogger from log4j2 (see
>> http://logging.apache.org/log4j/2.x/manual/async.html) which use
>> disruptor library.
>> I don't know yet if it's a good idea or not :-) but your value (on a
>> "classic" env) doesn't look to be an excessive.
>> Can you try the same analysis with the system property
>> -DAsyncLogger.WaitStrategy=Block ? (see the possible values in the
>> log4j2 documentation page).
>>
>>
>>
>> 2013/5/12 Patrice Ringot <okulea@free.fr>:
>>>
>>> Hello,
>>>
>>> Just an update about performance. After more work with the 1.4M4-SNAPSHOT
>>> (as of 5/11/2013) on the Raspberry, I noticed using htop that this
>>> version
>>> consumes more CPU comparing to the 1.4M3 version in the same context
>>> (don't
>>> be afraid by startup time of M3 on the PI, remember: it is indeed a slow
>>> machine ...).
>>>
>>>     1) initial startup time (fresh install, time to go to the alpacas
>>> banner):
>>>
>>>          - 5mn 47s with 1.4M3
>>>          - 14mn 23s with 1.4M4-SNAPSHOT
>>>
>>>     2) when Archiva is not used, htop shows that :
>>>
>>>          - the 1.4M3 version consumes no CPU
>>>          - the 1.4M4 snapshot version has a thread consuming roughly 88%
>>> of
>>> the ARM V6 CPU
>>>
>>> So I made the same test on a OpenSuse 12.2 vmware-ized on a i7 + SSD
>>> (using
>>> OpenJDK 7 1.7.0_21, 64 bits) and I obtained the following results:
>>>
>>>     1) initial startup time (fresh install, time to go to the alpacas
>>> banner):
>>>
>>>          - 20s with 1.4M3,
>>>          - 20s with 1.4M4-SNAPSHOT
>>>
>>>     2) when Archiva is not used, htop shows that :
>>>
>>>          - the 1.4M3 version consumes no CPU (just like the 1.3.6
>>> version)
>>>          - the 1.4M4 snapshot version has a thread consuming roughly 10%
>>> of
>>> the i7 CPU
>>>
>>> Archiva on the Raspberry and its preview JDK8 is definitely not a common
>>> use
>>> case for Archiva (maybe it will be in one or two years with 2x or 4x more
>>> powerful boards ?).
>>>
>>> But still, the difference exists between the M3 and M4 version on a more
>>> conventional Archiva target.
>>>
>>> Is it something new or did I do something wrong ?
>>>
>>> Regards
>>>
>>> Patrice
>>>
>>> PS: using jstack and the thread pid(dec)/nid(hex) identifier, it seems
>>> that
>>> the thread involved is the same in both cases:
>>>
>>> Raspbian/Oracle JDK8:
>>> "pool-2-thread-1" #28 prio=5 os_prio=0 tid=0x00ec62c0 nid=0x1434 runnable
>>> [0x9e644000]
>>>     java.lang.Thread.State: TIMED_WAITING (parking)
>>>          at sun.misc.Unsafe.park(Native Method)
>>>          at
>>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>>>          at
>>>
>>> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66)
>>>          at
>>>
>>> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39)
>>>          at
>>>
>>> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55)
>>>          at
>>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>>>          at
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>          at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>          at java.lang.Thread.run(Thread.java:722)
>>>
>>> OpenSuse/OpenJDK7:
>>> "pool-2-thread-1" prio=10 tid=0x00007faa28c6c000 nid=0x6082 runnable
>>> [0x00007faa76bcb000]
>>>     java.lang.Thread.State: TIMED_WAITING (parking)
>>>          at sun.misc.Unsafe.park(Native Method)
>>>          at
>>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>>>          at
>>>
>>> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66)
>>>          at
>>>
>>> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39)
>>>          at
>>>
>>> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55)
>>>          at
>>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>>>          at
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>          at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>          at java.lang.Thread.run(Thread.java:722)
>>>
>>>
>>> Le 12/05/2013 09:21, Olivier Lamy a écrit :
>>>
>>>> 2013/5/12 Patrice Ringot <okulea@free.fr>:
>>>>>
>>>>> Hello
>>>>>
>>>>> Just for information: the latest snapshot of 1.4-M4 I have downloaded
>>>>> today
>>>>> is able to run decently on a Raspberry PI model B (512MB) under
>>>>> Raspbian
>>>>> Wheezy and
>>>>> the Nov 12 preview of the Oracle JDK 8 for ARM processors. The UI is
>>>>> responsive, and the utilization of Maven is very acceptable for a home
>>>>> network (I have just modified the
>>>>> -Xmx parameter to 256M instead of the 512MB default).
>>>>>
>>>> Good to know thanks for sharing !
>>>>
>>>>> The only thing that do not work out of the box is the Tanuki wrapper
as
>>>>> it
>>>>> is packaged in the current distribution; it is too old to contain the
>>>>> required ARM files
>>>>> (the latest one from SourceForge is OK).
>>>>
>>>> Due to license reasons we cannot upgrade.
>>>> License has changed to GPL see
>>>> http://wrapper.tanukisoftware.com/doc/english/licenseOverview.html
>>>>
>>>>> Another thing I have  noted (unrelated to the Raspberry or this
>>>>> particular
>>>>> version of Archiva) concerns the content of the wrapper.conf file: it
>>>>> contains the version of each jar in the classpath. As I initially used
>>>>> it
>>>>> as
>>>>> a template in my Archiva puppet module, I had a problem when I made the
>>>>> 1.4-M3 -> 1.4-M4 update "in place" (class not found since the jars
>>>>> filenames
>>>>> have naturally changed between these two versions).
>>>>>
>>>>> Extract from wrapper.conf:
>>>>>
>>>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>>>> #  needed starting from 1
>>>>> wrapper.java.classpath.1=lib/wrapper.jar
>>>>> wrapper.java.classpath.2=%REPO_DIR%/archiva-jetty-1.4-M4-SNAPSHOT.pom
>>>>> wrapper.java.classpath.3=%REPO_DIR%/jetty-server-8.1.9.v20130131.jar
>>>>>
>>>>> wrapper.java.classpath.4=%REPO_DIR%/javax.servlet-3.0.0.v201112011016.jar
>>>>>
>>>>>
>>>>> wrapper.java.classpath.5=%REPO_DIR%/jetty-continuation-8.1.9.v20130131.jar
>>>>> ...
>>>>>
>>>>> So I have changed my way of dealing with this file, but I remembered
>>>>> that
>>>>> I
>>>>> did not encountered this problem with the
>>>>> ElasticSearch service wrapper; actually they manage the classpath
>>>>> differently:
>>>>>
>>>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>>>> #  needed starting from 1
>>>>> wrapper.java.classpath.1=%ES_HOME%/bin/service/lib/wrapper.jar
>>>>> wrapper.java.classpath.2=%ES_HOME%/lib/elasticsearch*.jar
>>>>> wrapper.java.classpath.3=%ES_HOME%/lib/*.jar
>>>>> wrapper.java.classpath.4=%ES_HOME%/lib/sigar/*.jar
>>>>>
>>>>> Using the * wildcard makes  wrapper.conf and Archiva versions much more
>>>>> independant of each other.
>>>>
>>>> Good idea that's something to test.
>>>> Maybe only one line with
>>>> wrapper.java.classpath.2=%REPO_DIR%/*.jar
>>>> Any time to propose a patch ?
>>>>
>>>>> Regards
>>>>>
>>>>> Patrice
>>>>>
>>>>> PS: I have also tested artifacts deletion in the snapshot repository
>>>>> and
>>>>> it
>>>>> was OK for me. This is very convenient.
>>>>>
>>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Ecetera: http://ecetera.com.au
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>>
>>
>>
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Mime
View raw message