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 13:03:40 GMT
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