How big is your estate?

I was sent a question from someone who had read my blog, and this reminded me of a conversation I had with a fellow traveler whilst on holiday.

The lady spoke about her housing problem. At first I thought she meant, the roof leaked, or there were 10 people per room, but no, it was totally different. She had the house in Wimbledon, London; the flat in Marble Arch, London; the Manor house in the Cotswolds (the Cotswolds is a very pretty part of England, with old stone houses, and where many people ride horses for pleasure); and her husband had recently been made responsible for the shooting lodge and estate in Scotland. The housing problem was that she had been asked to look into the holiday cottages and see what could be done with them. She said that after a brief visit, she had found 9 out of the 10 properties, some were very old, some were very small. They paid tax on the houses even if they were empty. Should they knock down the worst houses and improve the remainder – for example put in better insulation and make them more energy efficient, or make two small cottages into one larger cottage.

The emailed question I had was something similar, she had been promoted and moved to a different part of the company and was now in change of MQ. She found there were no good records about the number of queue managers and what they were used for. The question was – how do you tell the size of the MQ estate – and if there was “old iron” which should be disposed of?

I heard that in California, the state said your data centre could use no more power than it uses today. So if you wanted to add a new server – you had to take out an old one, or take out an old server, and add two energy efficient servers.

What questions do you need to ask?

• How many queue managers do you have
• How much work are they doing?
• Are they current?
• Do you have licenses for them?
• Can I get rid of any?

How many queue managers do I have?

Most enterprise customers have each machine set up with an agent which reports what software is installed on the machine, and stores the information in a central database.

This only reports on machines it knows about; if you have old machines in the dusty basement which no one knows about – they may not be in the database.

If you do not have this enterprise software running an agent, you can logon to the machine and issue

• dspmqver to tell you level of software and the license type
• dspmq to tell you which queue managers are configured, and if they are running

How much work are they doing

For the high level view you can use information provided by MQ

Messages on the SYSTEM.ADMIN.STATISTICS.QUEUE report information at the queue manager level such as number of puts, gets, bytes put etc. Your enterprise software may already be consuming these and may (or may not) be storing the information in a central repository. If so, you cannot get these messages.

In MQ V9 there are also statistics produced a pub/sub model which allow multiple programs to get statistics and accounting data. You subscribe to what you want – and they get published to your queue. This allows you to run in parallel with the enterprise tools.

Good metrics are

• Number of puts per day. This includes MQPUT, MQPUT1 to a queue and publishes and puts using a topic Later on when you are looking at consolidating queue managers, you may want plots of messages put per hour. The number of gets may not be so useful, as you usually have gets which return no messages, and get with browse, both of which increase the overall number of gets.
• Amount of data put per day.  This is useful to get a measure of message size.

Are they current?

The enterprise tools running an agent on your machines should be able to tell you the versions of software running on the machine.

As described above, you can use dspmqver

You can also issue the Display ChannelStatus command, and this will report the level of MQ at the remote end of the channel, then try to find the remote end!

Do you have licenses for them?

Your enterprise tools running the agents on your machine should collect the information, or you can use the dspmqver command.

You need to check you are running the right license, for example not using a development license in production.

Can I get rid of any?

As Shakespeare’s Hamlet says “Ay, there’s the rub”, meaning this is a difficult problem.

Some things you need to think about

• A server may be little used during most of the year – but very heavily used at year end – be it Christmas, or financial year. You may need to monitor for a year before deciding to decommission it
• You may want consolidate several little used queue managers on old iron onto one newer server, to reduce the number of servers, and to use newer, energy efficient hardware.
• Migrate old releases to newer releases of software.
• The cost of the license depends on the size of the machine. If MQ is on a large machine and doing no work, consider moving it to a smaller machine, or reduce the capacity of the virtualised server.
• If you plan to merge servers you need to ensure the new server has enough capacity, CPU, RAM, disk bandwidth and network bandwidth, and the disk and network have acceptable response times. Assume that all workloads will peak at the same time, to ensure you have enough peak capacity.