| Author |
Message
|
| goffinf |
 Posted: Fri Mar 14, 2008 6:07 am Post subject: Toolkit Performance |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
WBIMB version 6
Toolkit 6.0.2 + ifx011 (Dec 2007)
Windows XP
2GB RAM
1GB virtual memory
Running under VMWare
I know this has come up before, but searching the archives I couldn't find any answer which worked for me, so here goes ...
Running up the toolkit and opening a flow and its associated eSQL. Make amendments to the eSQL, save, deploy, execute, maybe debug, .. all appears OK.
Soon though the experience starts to degrade. The memory usage for javaw.exe climbs often to over 400MB and editing eSQL becomes almost impossible. For example, even clicking the scroll bars causes 100% CPU usage for a few seconds and the disk to thrash. If I selct a bunch of eSQL using the mouse it might take 10 seconds before the text is highlighted (CPU 100% again - and its all javaw.exe). Pasting in the selected text, same problem. Adding a breakpoint, after the right-click on the mouse it may take 10-15 seconds before the dialogue box comes up offering the relevant choices, and another 10 seconds when one is selected.
Closing the toolkit and restarting brings back some normality for a short time, but not for long.
I have tinkered around with arguments on the shortcut and am currently using these (I have had them much higher and not at all and it appears not to make much difference) :-
"C:\Program Files\IBM\MessageBrokersToolkit\6.0\wmbt.exe" -vmargs -Xms128M -Xmx512M
I have fairly recently defragged the hard disk.
Can anyone think of anywhere else I can look or anything else to try ?
Thanks
Fraser. |
|
| Back to top |
|
 |
| francoisvdm |
| Posted: Mon Mar 17, 2008 12:17 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
I'm seeing this same behavior, a massive pain. My thoughts was that it has to do with the size of the .ESQL file, because I only see this in bigger .ESQL files. Will it help to split the .ESQL file?
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| goffinf |
| Posted: Mon Mar 17, 2008 9:46 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| francoisvdm wrote: |
| I'm seeing this same behavior, a massive pain. My thoughts was that it has to do with the size of the .ESQL file, because I only see this in bigger .ESQL files. Will it help to split the .ESQL file? |
Hi Francois,
thanks for your observation (and a problem shared), you may be on to something here ?
I noted that the eSQL for this particular flow is about 60KB (not especially large perhaps ?), but that there were a lot of comments. I have removed ALL of the comments and the eSQL file is now around 34KB. Eclipse DOES appear to be more responsive.
This of course leaves me with the dilemna of not having comments which, whilst I accept may have been a bit more than necessary in this case, are generally useful to the guys that have to support these flows.
How do you split your eSQL files ?
Fraser. |
|
| Back to top |
|
|
| mrgate |
| Posted: Mon Mar 17, 2008 12:13 pm Post subject: |
|
|
Centurion
Joined: 28 Feb 2007
Posts: 141
Location: India
|
Hello goffinf,
I too faced the same problem with the same configuration. But when I have changed the current workspace then the problem was solved.............
_________________
MQSeries terrorist |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Mar 18, 2008 3:28 am Post subject: Re: Toolkit Performance |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| goffinf wrote: |
| Running under VMWare |
Personally, I would never run a development environment under vmware. Yes, I know it's easier to manage, but some things just need to run native. |
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Mar 18, 2008 7:30 am Post subject: Re: Toolkit Performance |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| JLRowe wrote: |
| goffinf wrote: |
| Running under VMWare |
Personally, I would never run a development environment under vmware. Yes, I know it's easier to manage, but some things just need to run native. |
Yes I can understand that, but in our case the benefits are pretty significant (and its irritating hearing '... it works OK on my machine' all the time  .
We have been thinking about a hybrid install, but I'm not sure its worth it ?
Anyway, my comment above about reducing the size of the eSQL having a positive effect, was made a bit too soon, it has regressed back to where it was before. I guess I'll try creating a new workspace as was suggested above and see if that helps ?
Thanks for you comment anyhoo
Fraser. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 18, 2008 7:37 am Post subject: Re: Toolkit Performance |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| goffinf wrote: |
| Yes I can understand that, but in our case the benefits are pretty significant |
Slightly off topic, but what significant benefits do you obtain from using VMWare?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Mar 19, 2008 1:29 am Post subject: Re: Toolkit Performance |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Vitor wrote: |
| goffinf wrote: |
| Yes I can understand that, but in our case the benefits are pretty significant |
Slightly off topic, but what significant benefits do you obtain from using VMWare? |
The most obvious ones relate to having a consistent development environment. We operate a number of disparate development teams in the UK and abroad, and staff often move between them. When *issues* occur it is very quick and easy to recover a complete working environment. It gives us a standardised toolset (over and above just MB tooling) that means that everyone benefits from having the right tools for the job and helps us keep control of licencing issues. We remove many of the *local* idiosyncracies of installing a fairly complex list of software onto individual PCs and the time it often takes to get this right, ... and so on ....
Fraser. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 19, 2008 1:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Thank you. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Wed Mar 19, 2008 2:00 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Well, I would try and get some more physical memory and tune up:
Stick in 4gb of physical ram, set the windows /3gb switch and then you will have 3.25gb available.
Carefully tune your vmware and guest OS. Make sure the guest OS is not swapping, make sure the guest OS is not allocated too much host memory as this will cause host swapping.
Try the 6.1 tooling, the 1.5 java vm is faster and more efficient. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 19, 2008 3:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| JLRowe wrote: |
| Try the 6.1 tooling, the 1.5 java vm is faster and more efficient. |
You should only use the 6.1 toolkit for stuff you are deploying to 6.1 runtime.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqpaul |
| Posted: Wed Mar 19, 2008 8:23 am Post subject: Looks liike paging activity - what else is using memory? |
|
|
Acolyte
Joined: 14 Jan 2008
Posts: 66
Location: Hursley, UK
|
Disk thrashing and 100% CPU often (but not always) indicates paging activity. You have two possible levels of paging - the VMware virtual machine with 1 Gb, and the real machine with 2Gb.
What follows here is what I remember, but it's several years since I've used VMware or Windows in anger, so it may be misremembered or out of date. caveat emptor
1) Paging within VMware. You look to have have enough memory, but you say that there's a correlation with WMBT memory climbing over 400 Mb and lousy performance, so I wonder if there are other things consuming VMware memory. If so, you get very expensive paging to the virtual disk system. You can sometimes gain by defragmenting the VMware virtual disks (both in virtual Windows and with the VMware disk tools), but you'd do better to reduce paging - add more virtual memory, or decrease the JVM size further, below 400 Mb at least!
2) Paging of VMware in Windows. Likely to be equally contact admin, as the virtual operating system gets paged out. Add more hardware, or stop other memory-intensive applications. I doubt reducing the VMware size below 1 Gb would help.
In both cases, I believe it's best to have pre-allocated paging space ("swap space" according to Microsoft AFAIR). IMHO you should have 4 Gb swap space in real Windows, and 2 Gb in VMware Windows. The default automatic allocation tends to be a lot smaller.
_________________
Paul |
|
| Back to top |
|
|
|
|
