| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Pageset Usage For a particular page |
« View previous topic :: View next topic » |
| Author |
Message
|
| itsmaveric |
 Posted: Thu Dec 02, 2010 9:51 pm Post subject: Pageset Usage For a particular page |
 |
|
Novice
Joined: 24 May 2007
Posts: 18
Location: Singapore
|
Hi All ,
I am a MQ7 user on z/OS . There is a requirement where we need to gather the usage of page sets of a particular Queue Manager (v7) for a particular day .
Issuing DIS USAGE for every minute or for every 30 secs for an entire day is looking impossible .
The monitoring tool what we are currently using to monitor MQ is Tivoli . I tried to get the Page set Usage History by logging in into the TEPS server . But couldn't6 achieve what I am looking for .
Please suggest a way to achieve this .
Regards,
Tom |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Thu Dec 02, 2010 11:04 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
sounds like a very strange requirement to me.
IMHO there is nothing built-in in MQ that helps you to get a pageset usage statistic (MQ statistics and SMF records dont cover this i think)
I cant help you with Tivoli, but if i had to do that i'd go for the "DISPLAY USAGE" command
Maybe its possible to compute that indirectly if you have queue statistics. if you know the number of messages at a specific point in time in the queues, you can compute the space they took on the pagesets (okay, there are buffers too and messages may physically not be on the pageset, but logically they are, i dont take that into account at the moment).
just curious ... if you have this statistic ... what does it help you for?
why dont you go the other way round? if you know how may messages you must be able to store at a specific time, you know what pagesetsize you need.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| itsmaveric |
| Posted: Fri Dec 03, 2010 4:56 am Post subject: |
|
|
Novice
Joined: 24 May 2007
Posts: 18
Location: Singapore
|
Thanks Butcher . Thanks for the quick reply .
The requirment come into picture when we have migrated MQ v6 to v7 . The 2k msg now need a whole page to get stored as per the MQ v7 design .
So now to satisfy this requirment of MQ v7 we need to increase the size of the pageset . That's the reason we want to gather a sttistic of pageset usage of a whole day or may a whole week , and figure out which pagesets are mostly used and highly used . so that we can go ahead and increase the size of the pagesets which are being highly used .
The pagsets which are not that busy still can accomodate the new design on MQ v7 .
As you have suggested that you can guide us how to gather the data through Tivoli . That would be great as well . I tried the Historical Data gather of PageSet Usage in TEPS . But couldn't get the Data which I am looking for .
Please Sugest .
Regards ,
Tom |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Dec 03, 2010 5:36 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
hello,,
no, i can not help you with Tivoli, sorry. You could of course write some rexx issueing the command for you from a batch job and interpreting the answer.
however, another thing comes into my mind.
if you monitor your system a day then you only see the usage of the pagesets when everything is working. how about distributed systems? do you send and receive messages?
what if one of your application fails and messages are piling up in the application inbound queue? what if there is a networking issue or a remote system is failing and messages you want to send out are piling up in the xmitq?
thats the situation where you will encoutner how much space you need. not during a "normal day run" without problems.
you could use the queue statistics. msgs in/out by queue. (reset qstats command). this showes you how many messages are passing thourgh MQ by queue, e.g. on a single day (depending on when you issue that command).
now, think of an 1 day outage for that system, application or connection. then compute how many storage you need to store these messages until they can be processed or send or whatever.
we do not store messages here. what comes in, gets processed immediately. same when sending out. i dont need much pageset storage for that. if i am lucky, no message will ever hit a pageset due to pageset buffers. but if a customer fails, i must be able to store xxx.000 messages until the customer is back online again. then i need space.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 03, 2010 5:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The requirment come into picture when we have migrated MQ v6 to v7 . The 2k msg now need a whole page to get stored as per the MQ v7 design . |
Are you saying that v7 has doubled the pageset space requirement?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| itsmaveric |
| Posted: Fri Dec 03, 2010 8:55 am Post subject: |
|
|
Novice
Joined: 24 May 2007
Posts: 18
Location: Singapore
|
Thanks Bruce for the reply .
Prior to version 7.0.1, small messages were stored such that multiple messages could
co-exist on the same page. This meant that the scavenger could not run once a
message was deleted as there were potentially other messages still on the page.
Instead, the small message scavenger would run periodically – up to every 5 seconds .
This means that a workload using small messages could see a build up of dead pages
that were waiting to be scavenged. With ever faster processors, the time taken to fill
the bufferpool with dead pages becomes significantly reduced. In turn, this meant that
the messages would overflow onto the pageset and potentially the queue manager
could be spending time performing I/O – causing slower MQGETs and MQPUTs.
To allow the scavenger to work more efficiently with small messages, each message
is now stored in a separate page. In addition a separate index page is used to hold data
for approximately 72 messages. Once the message is deleted, the page holding the
message data can be re-used immediately but the index page can only be scavenged
once all messages referenced are deleted.
The above message I have gathered from the MP1G support pack . The new scavenger process needs the
pagesets size to be expanded . to meet this requirment we are trying to figure out which of our pagestes
are mostly used during a bussiness day , so that we can increase the pagesets before we migrate the prod
Queue Managers to v7 .
Regards,
Tom |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 03, 2010 10:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Usually, an application puts a message (to a queue), AND the consuming application gets the message from the queue within microseconds or seconds. On WMQ for z/OS, it is unlikely that the message will be written to a pageset in this scenario. If your DIS USAGE is reporting little pageset usage, then why are you concerned?
So, how many messages at your shop are put to queues, and sit in queues for an extended period - like for midnight batch processing?
Do your apps put/get millions of messages per second? Thousands of messages per second?
WMQ for z/OS allows pagesets to expand automatically - by a percentage you specify, if you want.
How did you size (calculate) your pagesets for v6? If v7 is going to double the space requirement, double the size of your pagesets. Or enable automatic expansion.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| itsmaveric |
| Posted: Mon Dec 06, 2010 6:54 pm Post subject: |
|
|
Novice
Joined: 24 May 2007
Posts: 18
Location: Singapore
|
Thanks Bruce ,
Actually we are not looking for large messages , but we are concern about the large number of messages in the smaller sizes where we significantly impact PAGESET capacity .
As now in V7 the short messages are going to be stored in a single page this creates little concern for us . As we have many application running and sometimes multiple apps are on a single pageset where we have both short and long messages . So to be in safe hand we are increasing the size of the pagesets which are mostlty used .
Regards,
Tom |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 06, 2010 8:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| As now in V7 the short messages are going to be stored in a single page this creates little concern for us . |
So far, so good. This follows the IBM-recommended design guidelines, namely: don't mix big/small messages in the same pageset; and don't mix short- and long-lived messages in the same pageset.
What type of DASD (disk drives)? If you are using Sharks. DS8k or similar devices, the issue of contention is not so much an issue (as compared to real 3390s). Most of the newer disk devices have lots of front-end cache, improving i/o throughput. Do you emulate 3390 mod9's, mod27's, mod54's? Disk space is fairly cheap.
Again I ask: why the concern?
Do you understand the behavior of your applications?
Do most of your messages stay in queue(s) for extended periods? Or are most put and get sub-second? If sub-second, it is highly unlikely that messages actually get written to pagesets.
Are your apps creating millions of messages that don't get consumed in real-time?
RMF reports will tell you (or your sysprogs) the current of your pagesets. Is there an issue (real or perceived)?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Dec 07, 2010 1:24 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
|
| 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
|
|
|
|
