From owner-freebsd-java@FreeBSD.ORG Thu Feb 28 08:53:58 2013 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E55BCCE5 for ; Thu, 28 Feb 2013 08:53:58 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 709101530 for ; Thu, 28 Feb 2013 08:53:58 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UAzFN-0001Zm-US; Thu, 28 Feb 2013 09:53:50 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAzFN-0007fH-EY; Thu, 28 Feb 2013 09:53:49 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Jurij Kovacic, OCPEA d.o.o." Subject: Re: Java threads on multiple processor cores References: <51283B84.5050709@ocpea.com> <512E3148.3000906@ocpea.com> Date: Thu, 28 Feb 2013 09:53:49 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <512E3148.3000906@ocpea.com> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 4cc6a862e0a753e674eb374334b394fd Cc: freebsd-java@freebsd.org X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:53:59 -0000 On Wed, 27 Feb 2013 17:16:08 +0100, Jurij Kovacic, OCPEA d.o.o. wrote: > Hello! > > On 02/24/2013 10:50 PM, Ronald Klop wrote: >> On Sat, 23 Feb 2013 04:46:12 +0100, Jurij Kovacic, OCPEA d.o.o. >> wrote: >> >>> Hi, >>> >>> I am running JBoss application server inside a jail on FreeBSD 8.3. >>> Since the server has a quad-core processor, it would be efficient if >>> the java process (and its threads) could utilize more than 1 CPU core >>> at a time, which is not currently the case. >>> >>> Is it possible to acomplish this (perhaps with the use of a proper >>> threading library) or am I barking up the wrong tree? >>> >>> Thank you for your reply, >>> Jurij >> >> I don't think there is a clear answer on this. It all depends on what >> is running in your JBoss application server. If that application does >> not use more than one thread, there is nothing going to use the other >> cores. If your application uses multiple threads and you are sure they >> should all be calculating very hard than you should debug the >> application for bottlenecks. And look if the bottleneck is in the >> application code, in the JDK or in FreeBSD. This is not possible >> without inside information of what your application is doing. > First of all, thank you very much for your reply. > > As it has turned out, I was not too precise in my earlier question - > after some testing I have found that after some intense page reloading, > full GC gets triggered. The thread running uses 100% of one core,while > all the other threads (presumably), have to wait for it to finish. Is > there any way to make full GC run in multiple threads? > > Kind regards, > Jurij I see in your other mail that you are familiar with choosing a GC on the command line. My experience is to just let the jvm choose the best settings unless you run a very special application and have a lot of knowledge about the internals of the GC. The guys (and girls) working on Java have done some pretty good work on this GCing. What sounds more troublesome (and yes I'm a bit guessing here, because I don't know your application) is that your application keeps doing GC for a long time. That sounds like your JVM runs with not enough memory or you have a memory leak somewhere. While your application is running you can see statistics of GC with this command. jstat -gc -t -h10 5s FGC increases with every new full gc run. Does OU (Old Usage) decrease after a FGC? If not the GC could not free any memory and it will keep GC'ing very hard. Ronald.