| Author |
Message
|
| scott9 |
 Posted: Tue Oct 30, 2007 9:37 am Post subject: What functions of MQ consume file descriptors? |
 |
|
Acolyte
Joined: 11 Jul 2002
Posts: 62
Location: Sacramento,CA
|
I was engaged in a heated technical discussion with my peers regarding MQ cleanup and a thought crossed my mind.
The question: What mechanisms inside MQ (AIX in my case) consume file descriptors?
I know that processes and channels consume files, but what about internal MQ stuff?
For instance, would duplicate qmgr entries in a large cluster consume additional files (i.e. multiple qmids for a single qmgr, caused by rebuilding qmgr w/out removing from cluster first)?
Would old messages that are never processed (say, 80,000) consume additional files? Because, we all know MQ is a database, right?
Would executing runmqsc to query channel connections and check qdepth every 15 mins consume files?
Would old FDC files and saved logs in MQ directories consume files?
I was trying to make an argument for cleaning up our qmgrs, but I met with heavy resistance. Am I just causing busy work or is there some merit to having clean qmgr environments? Thoughts? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 30, 2007 9:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Messages on a queue are stored in one file - the q file. Regardless of how many messages are in the queue, they're all in one file. That is, one file for each queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 30, 2007 10:30 am Post subject: |
|
|
Guest
|
| ... and MQ is not a database. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Oct 30, 2007 1:21 pm Post subject: Re: What functions of MQ consume file descriptors? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| scott9 wrote: |
| I was trying to make an argument for cleaning up our qmgrs |
May I ask : what resource shortage is there that leads to a concern on this system? |
|
| Back to top |
|
|
| scott9 |
| Posted: Tue Oct 30, 2007 2:28 pm Post subject: |
|
|
Acolyte
Joined: 11 Jul 2002
Posts: 62
Location: Sacramento,CA
|
| We suspect that we reached a soft file limitation in MQ v5.3. We have nofiles=2000. The AIX quick beginnings document doesn't have recommendations for the nofiles attribute in /etc/security/limits with MQ v5.3. They don't address it until MQ v6...which is where we should be anyway, but that is a different story... |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Oct 30, 2007 10:10 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
nofiles=2000 seems like a lot to me. If you run out WMQ will soon tell you that the OS has refused to allocate any more, probably with a resource shortage FFST with EMFILE or ENFILE mentioned somewhere.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Oct 31, 2007 12:43 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| scott9 wrote: |
| We suspect that we reached a soft file limitation in MQ v5.3. |
OK this is progress. Please can you share
- why it was identified that this limit was being breached, and
- why MQ is receiving focus for this issue? |
|
| Back to top |
|
|
| scott9 |
| Posted: Wed Oct 31, 2007 10:43 am Post subject: |
|
|
Acolyte
Joined: 11 Jul 2002
Posts: 62
Location: Sacramento,CA
|
Aha! I get it now...you're helping me with my problem. Sorry, I'm slow. ..and thanks for the effort. In this particular case, I'm not looking for help to solve my problem. Rather, I am looking for feedback from other MQ savvy people on the topic of maintaining a clean MQ environment. I wanted to understand better the impact a "dirty" environment has on MQ. I specifically addressed the nofiles topic, because that sparked my discussion with peers.
I suggested to my team that we remove duplicate qmids from the repository cache and push our customer to remove the old messages from the backout queue, because I agree MQ is NOT a database!  Anyway, the question I posed in this forum was "Am I just causing busy work or is there some merit to having clean qmgr environments?"
BTW: Jefflowrey's response about messages on a queue consuming 1 file descriptor was interesting. Expanding on that idea, would anybody expect 80,000 persistent messages sitting in a queue for 1 year in a circular logging qmgr to cause any negative effect on a qmgr? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 31, 2007 10:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That many messages sitting on a queue - in a committed state - will only cause an issue if someone tries to get a message from there. And even then, if they're only trying to get the first message, then it's fine. It's if they try and select from that queue, by correlID or anything else, that they'll run into issues.
Remind your co-workers that a clean qmgr is like a clean house... It's A Good Thing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Oct 31, 2007 2:44 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| scott9 wrote: |
| I wanted to understand better the impact a "dirty" environment has on MQ. I specifically addressed the nofiles topic, because that sparked my discussion with peers. |
Understandable concern. I guess I was putting the question of whether there is a demonstrable problem already. Because, if there's a problem, it needs solving. If there's not... then maybe there never will be.
| Quote: |
| I suggested to my team that we remove duplicate qmids from the repository cache and push our customer to remove the old messages from the backout queue, because I agree MQ is NOT a database! |
You'll go far if you repeat that last bit at least once per day 
| Quote: |
| Anyway, the question I posed in this forum was "Am I just causing busy work or is there some merit to having clean qmgr environments?" |
Well, as long as you define carefully what is meant by "clean". Already you've mentioned cleaning the repository cache and dead messages from queues (don't these need to be replayed into the system by the way?) IMHO it will be difficult for any software engineer to argue against preventing buildup of deadwood in the system. Whether the deadwood actually causes any noticeable ill effects is really a moot point though. Hence my question about any ill effects you may already be aware of.
A deep queue takes time to load off of disk (note that only message metadata is loaded ahead of time, not all message contents!). But I expect it'll take one file descriptor per agent (amqzlaa0) process that accesses the queue, no more.
| Quote: |
| BTW: Jefflowrey's response about messages on a queue consuming 1 file descriptor was interesting. |
I didn't notice jeff say that exactly.
A file descriptor is needed by a process in order to access a file on disk. Run "find /var/mqm/qmgrs/QMNAME -type f | wc -l" to count the number of files that are potentially opened by the various queue manager processes at various times. The queue manager makes efforts to restrict the number of files it has open, and will close files as soon as possible when it has finished accessing them.
| Quote: |
| Expanding on that idea, would anybody expect 80,000 persistent messages sitting in a queue for 1 year in a circular logging qmgr to cause any negative effect on a qmgr? |
The queue will take a little while to access when it gets loaded off of disk. Other than this I would expect the only log accesses to be when the persistent messages are added or removed from the queue, or during a checkpoint. (It's probably more complicated than this, to be honest, but I'm not familiar with the full details). |
|
| Back to top |
|
|
|
|
