Author |
Message
|
gilc |
Posted: Sun Aug 19, 2012 6:59 am Post subject: high cpu usage in toolkit after upgrade to 8.0.0.1 |
|
|
Apprentice
Joined: 17 Mar 2011 Posts: 32
|
Hey,
We've applied the new update 8.0.0.1 on the toolkit and since then we're having serious performance issuses.
The eclipse is "stuck" and prevents us from working for a few minutes. The task manager \ process explorer shows a high cpu usage of javaw.exe process.
These amazing and fun phenomena are happening in the following cases:
- opening a bar file
- building a bar file
of course this behavior is not acceptable (although staring at the wall for 5 minutes everytime i want to make a change gives you a lot of time to ponder on the important things in life) and so i turn to you with advices - anyone experinced such a thing?
all our pcs are running with windows xp sp3 with 3gb ram.
thanks in advance,
~Gil |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Aug 19, 2012 8:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Does it do the same thing with a new, empty, workspace? |
|
Back to top |
|
 |
smdavies99 |
Posted: Sun Aug 19, 2012 10:25 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
I've just updated my Laptop to 8001 and I'm not experiencing these issues. Ok, it is not a normal spec'd laptop I7 Quad Core, Windows 7 Ultimate, 24Gb Ram and 1.5Tb disk but it is running 3 6Gb VM's and I don't see this CPU Hogging at all when I startup the toolkit. If anything, it is faster than the Broker 7 TK to startup. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
McueMart |
Posted: Sun Aug 19, 2012 2:10 pm Post subject: |
|
|
 Chevalier
Joined: 29 Nov 2011 Posts: 490 Location: UK...somewhere
|
I saw a similar thing when I had a large jar file in my project folder (it was a 20mb WAS JMS client jar...). My bar file took ~10 minutes to build (seeing hight cpu as per the OP). I noticed after the bar file had finally built that all files which are in your project/application are packaged into the bar (I didnt know this).
My initial thought was that Broker was introspecting all the class files in the included jar. I might be way off in this guess though! Removing the large jar files from my project fixed the slow bar building though..... |
|
Back to top |
|
 |
goffinf |
Posted: Sun Aug 19, 2012 2:24 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
I see this pretty frequently even with v6.1 particularly when building BAR files. I try as much as possible to close any projects in my workspace which I'm not currently using, and every month or so I create a new workspace. It's a bit of a PITA though.
Sometimes when building a BAR, JARs that are completely unrelated to the project are included, which also adds time to the build and then more time to remove (javaws.exe at around 50% CPU). I've raised this one before and also with IBM. The only solution offered was to create a new workspace, no-one could come up with any reason for the behaviour although there must be one. I've learned to live with it (but hey, problem shared, is ...)
Fraser |
|
Back to top |
|
 |
gilc |
Posted: Mon Aug 20, 2012 11:09 pm Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011 Posts: 32
|
thanks everyone for your replies.
mqjeff - it doesn't happen with an empty workspace (mainly because there are no bar files in that case)
moreover, as goffinf and McueMart suggested it happens when there are jar files in the project (even if the are in a referenced library). when there are no jar files, it runs fast as normal.
so we're thinking on moving these jar files to shared-classes although it's not ideally the right thing to do.
but the question is - why does it happen only when upgrading a toolkit version? in v8.0.0.0 there were no problems with any of the projects...
~ Gil |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Aug 21, 2012 1:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
There's no reason to use shared-classes when you can use a JavaClassloader configurable service instead. |
|
Back to top |
|
 |
gilc |
Posted: Tue Aug 21, 2012 3:08 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011 Posts: 32
|
thanks mqjeff, I'll check it out and will come back with answers (hopfully positive ones)
~ Gil |
|
Back to top |
|
 |
gilc |
Posted: Wed Aug 22, 2012 1:17 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011 Posts: 32
|
In the end we didn't use shared-classes nor JavaClassloader.
We seperated the java files to a differnet library and all the esql functions calling these external java functions are in another library (2 libs at total). Then we have 2 bar files - one which includes the jar with the java files and the other (which we change a lot) with the other resources (flows, esqls etc.)
Works fine. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Aug 22, 2012 5:03 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
The common mistake with relying on BARs to deploy Jars to an EG is that often after a few years, some Jars get duplicated because people are not paying attention, so you have multiple Jars with different versions and you don't know what Jar is actually getting called by your code.
Its better to use Configurable service and create a home for all Jars some place on the file system. That way you know for sure which Jar is actually being used. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
|