| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| mqsicreateaclentry is sloooowwwww |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Nov 26, 2008 10:54 am Post subject: mqsicreateaclentry is sloooowwwww |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
WMB 6.1.0.2
MQ 6.0.2.5
RHEL 5 on x86-64
12GB of memory
4 cores of CPU
Nothing else running on the server, its dedicated to being a Configuration manager.
mqsicreateaclentry takes about a minute to return.
mqsilistaclentry takes 2-3 minutes to return.
For each command, I notice the SYSTEM.BROKER.CONFIG.QUEUE rise to a depth of 24 and slowly drain.
I have a script that sets about 50 different IDs for one Broker with about 15 Execution Groups. The script takes over an hour to run! And a couple of the commands time out with:
| Quote: |
BIP1047E: The operation timed out waiting for a response from the Configuration Manager.
The utility did not receive an expected message from the Configuration Manager within a reasonable amount of time. The cause is described as: 'hasBeenUpdatedByConfigManager timed out'
Ensure that the Configuration Manager is running and that the correct connection parameters have been supplied to the utility. Use the -w flag to increase the amount of time to wait for responses.
BIP8071I: Successful command completion.
|
(I'm using the default timeout)
The commands are slow whether I script them or manually run them. I know I can up the wait time so none fail, but 90 minutes to run a script to run about 60 mqsicreateaclentry commands and a finishing mqsilistaclentry?
Something is wrong, correct? Especially with all the horsepower this Config Manager has. There are no deploys happening its a brand new server not live yet.
PMR has been opened, but hasn't been looked at yet.
Anything I can check or tweak to increase performance?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Nov 26, 2008 11:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
A couple of examples of the commands being issued:
| Code: |
mqsicreateaclentry $CMNAME -u peter -a -x F -p
mqsicreateaclentry CMNAME -u developer1 -a -x D -b BRKRNAME -e EG1 |
They are slow the first time I run them or subsequent times.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 28, 2008 12:13 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I noticed the bipconfig process was taking 100% of the CPU anytime I ran an ACL command. After restarting the Config Manager things are much faster. The script takes a couple of minutes to complete instead of > 1 hour. PMR still open, maybe they'll find something in the traces.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Nov 29, 2008 6:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Fix Pack 6.1.0.3 was released today, and I see the following as one of the fixes. I did just create a bunch of Execution Groups.
http://www-01.ibm.com/support/docview.wss?rs=849&context=SSKM8N&context=SS3GH2&context=SSKMAB&q1=IC57886&uid=swg1IC57886&loc=en_US&cs=utf-8&lang=en
| Quote: |
IC57886: CONFIGURATION MANAGER HAS HIGH CPU USAGE FOLLOWING A DEPLOY
APAR status
Closed as program error.
Error description
This has been recently found during FixPack 3 testing, and a fix
has been identified through internal defect 52038. The fix is
targetted for FixPack 3, but we feel it will be beneficial to
make the fix available to the customer early as a Test Fix. The
problem found was that following a deploy to a new execution
group, and also a "Remove deployed children" deploy which
effectively removes all flows and recreates an empty EG, the
Configuration Manager was re-subscribing to the internal status
publications with each EG in the broker, and re-synchronising.
This results in unnecessary processing by both the Broker and
Configuration Manager, but the Configuration Manager in
particular can become busy and unresponsive whilst it processes
the information returned by the broker.
Local fix
Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Message Broker V6.1. *
****************************************************************
* PROBLEM DESCRIPTION: After a bar file deployment to a new *
* execution group from the Broker *
* Toolkit, or using the mqsideploy *
* command with the -m parameter, the *
* CPU usage of the Configuration *
* Manager is high for a prolonged period. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The Configuration Manager is initiating a resynchronisation
with the broker after the creation of every new execution
group following a bar file deployment. This includes the use
of the mqsideploy command with the -m parameter which removes
all currently deployed message flows and message sets from the
execution group as part of the deployment by effectively
deleting and recreating the execution group.
The resynchronisation process causes the Broker to report on
all of its runtime properties back to the Configuration
Manager. With large Broker configurations, this can cause the
Configuration Manager to become busy whilst processing the
responses.
Problem conclusion
The Configuration Manager no longer resynchronises with the
Broker for every new execution group created.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
