|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Tandem MQQSSVR memory |
« View previous topic :: View next topic » |
Author |
Message
|
AndyMQ |
Posted: Wed May 10, 2006 8:54 am Post subject: Tandem MQQSSVR memory |
|
|
Apprentice
Joined: 22 Apr 2004 Posts: 33 Location: Scotland
|
Concerned at the amount of memory being used in our queue managers, specifically the queue service servers. We have created multiple MQQSSVR processes spread across all available CPUs, but the primary processes use anything up to 150MB memory with the backup processes using double that. We are using persistent messages, so turning off the qsoptions C setting shouldn't buy us anything. Don't set either of the other qsoptions so are at a bit of a loss to understand why that memory is being consumed, and more specifically why it isn't being released when the qmgr is in test and isn't being accessed for days on end.
Anyone know of any other memory tuning options available on 5.1 MQ (CSD03)? |
|
Back to top |
|
 |
Tibor |
Posted: Fri May 12, 2006 6:53 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
Our production qmgr on Tandem comsumes more less memory however the average of daily traffic is more than 900MB (mainly persistent messages). There are 5 MQQSSVR process for faster parallel working, but the sizes are smaller: 20, 5, 4, 4 and 3 MB.
Had you installed any fix since upgrading CSD03? |
|
Back to top |
|
 |
AndyMQ |
Posted: Fri May 12, 2006 7:06 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004 Posts: 33 Location: Scotland
|
We went with efix 3 as we had to apply the PATHSEC changes (an audit point). We're still only testing with this configuration, but we have around 8 or 9 MQQSVR processes running per node. Invariably the primary QSVR process has been 100 and 150MB memory allocated. The backup process however, has anything up to 300MB memory, which scarily is almost twice the memory used by the busiest disk process on the same CPU.
We shut all qmgrs down at the weekend as part of a contingency/site switch exercise. They've started up with between 40 and 90MB memory for both pri and bkp. Both are creeping up, but now in parallel, i.e. no memory mismatches between pri and bkp.
Have played about with all the qsoptions and things. Even considered playing with the "tuning parameters" in the QMINI, although the manual recommends against touching these.
Are there memory options that you're aware of with other efixes?
Thanks for the response! |
|
Back to top |
|
 |
Tibor |
Posted: Fri May 12, 2006 8:16 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
We are on efix2 as far as I remember correctly (perhaps efix3?). We use the MQ on Tandem since 1999 but it was no need the tuning those parameters, that's why I can't help you
Of course I am wondering when any interesting thing will emerge  |
|
Back to top |
|
 |
Tibor |
Posted: Fri May 12, 2006 8:21 am Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
It is the qmini file of our prod qmgr, maybe helps:
Code: |
#*******************************************************************#
#* Module Name: QMINI *#
#* Type : MQSeries queue manager configuration file *#
# Function : Define the configuration of a single queue manager *#
#* *#
#*******************************************************************#
#* Notes : *#
#* 1) This file defines the configuration of the queue manager *#
#* *#
#*******************************************************************#
Configuration:
PathmonProcName=$MQSP
DefaultQueueServerName=$MQSS
DefaultStatusServerName=$MQST
ServerClassName=MQS-ECBOSS
EMSCollectorName=$0
HomeTerminalName=$VHS2
ShutdownFileName=SHUTDOWN
TraceOptionsFileName=TRACEOPT
RuntimeFileName=RUNTIME
StatableFileName=STATABLE
ChannelDefFileName=CHDEFS
DefaultCCSID=819
DefaultTraceOptions=0
MaxIdleAgents=10
MinIdleMCALU62Responders=0
MinIdleMCATCPResponders=0
MinIdleMCACallers=0
MinIdleLQMAgents=1
MaxIdleAgentReuse=10
DefaultProcess:
ExeFileName=DEFAULT
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=256000
IniPoolSize=256000
Priority=175
ECBoss:
ExeFileName=MQECBOSS
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
ExpectedNumECs=16
EC:
ExeFileName=MQEC
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=256000
IniPoolSize=256000
Priority=175
LQMAgentExe=MQLQMAG
MCACallerExe=MQMCACAL
MCATCPResponderExe=MQTCPRES
MCALU62ResponderExe=MQLU6RES
MCAAgentPriority=165
LQMAgentPriority=165
StopProcessTimer=3000
IdleProcessTimer=3000
MCACaller:
ExeFileName=MQMCACAL
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
MCATCPResponder:
ExeFileName=MQTCPRES
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
MCALU62Responder:
ExeFileName=MQLU6RES
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
MQIServer:
ExeFileName=MQMQISER
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
LQMAgent:
ExeFileName=MQLQMAG
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=50
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=120000
IniPoolSize=200000
Priority=175
ChannelInitiator:
ExeFileName=RUNMQCHI
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=256000
IniPoolSize=256000
Priority=175
TCPListener:
ExeFileName=RUNMQLSR
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=256000
IniPoolSize=256000
Priority=175
Queue Manager Server:
ExeFileName=MQMGRSVR
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=300000
IniPoolSize=256000
Priority=175
Repository Server:
ExeFileName=MQREPSVR
TraceVolSubvol=$SQLCAT.OSSPL
TracePrefix=TR
ErrorVolSubvol=$SQLCAT.OSSPL
ErrorPrefix=ER
DebugMode=0
IPCCTimeOut=10000
IPCCMemSetSize=32000
MemSetSize=16000
ExtPoolSize=256000
IniPoolSize=256000
Priority=175
Authority:
MQAUTH=On
Service:
Service=AuthorizationService
EntryPoints=9
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.TANDEM.auth.service
Module=MQOAM
ComponentDataSize=0
ComponentID=0
TuningParameters:
KernelMemSetSize=32000
ObjCatMemSetSize=32000
QueueMemSetSize=16000
MQGETActiveQPoll=50
MQGETInactiveQPoll=1000
Channels:
RetryAll=1
MaxChannels=40
MaxActiveChannels=40
MaxTries=3
MaxTriesInterval=10
ChanInitDiscInterval=10
AdoptNewMCA=NO
AdoptNewMCATimeout=60
AdoptNewMCACheck=NAME,ADDRESS,QM
TCPConfig:
TCPPort=1414
TCPNumListenerPorts=1
TCPListenerPort=1414
TCPKeepAlive=1
|
|
|
Back to top |
|
 |
AndyMQ |
Posted: Fri May 12, 2006 8:40 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004 Posts: 33 Location: Scotland
|
Thanks Tibor, thats useful as it gives me something to do comparisons with. In general, our backup processes were consuming around doubles the memory of our primary processes. I can understand that happening if we're using non persistent messages as we have qsoptions C set to checkpoint. However, all our messages SHOULD be persistent, tho' I won't have access to the mqm.manager id until this weekend as it's controlled. If they are persistent, then no checkpointing should be done as TMF should handle that.
We are expecting a huge increase in MQ traffic over the coming months, so it should be interesting to see how the system copes, particularly as regards memory.
We're monitoring it and will post any update here. |
|
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
|
|
|
|