| Author |
Message
|
| suneel |
 Posted: Thu Dec 30, 2010 4:59 am Post subject: QM logs are full in windows MQ |
 |
|
Voyager
Joined: 06 Nov 2009
Posts: 89
|
Hi,
Cluster Sender channel at Sender is in retrying and at receiver side logs it is saying QM logs are full. Please help me on this.
Suneel |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Dec 30, 2010 5:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
RTFM in regard to logging - there is a very detailed and comprehensive section in the Info Centre (applicable to your version) including particular platform considerations. You should also check in regard to long-running Units-of-Work (UoW).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 30, 2010 5:09 am Post subject: Re: QM logs are full in windows MQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| suneel wrote: |
| Cluster Sender channel at Sender is in retrying and at receiver side logs it is saying QM logs are full. Please help me on this. |
Work out why the receiver side queue manager logs are full and fix it? 
If the logs really are full you should be getting more problems with that queue manager than just one channel in retry.
Common reasons the logs fill:
1) A long running transaction that doesn't commit enough or at all
2) Queue manager logs too small for the work the queue manager is doing (e.g. a production queue manager created with the default values)
Other reasons are of course possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 5:30 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Quote: |
| If the logs really are full you should be getting more problems with that queue manager than just one channel in retry. |
Agree!
I faced once such problem and Qmgr was crashed.
If you would face such an issue then before starting the qmgr again ..try to clean up the zombie processes of mq first (if they exist at all).
But yes for now..try to work on your logging system and transactions. what kind of logging do you have set there ?
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| suneel |
| Posted: Thu Dec 30, 2010 8:05 am Post subject: |
|
|
Voyager
Joined: 06 Nov 2009
Posts: 89
|
| I looged in as a MQ admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 30, 2010 8:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| suneel wrote: |
| I looged in as a MQ admin |
Congratulations.
I doubt that's helped much. Unless you tried some commands as well?
(Note: do not delete the queue manager logs "to free up space". That will end badly.)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 8:19 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| suneel wrote: |
| I looged in as a MQ admin |
so.. what are you upto now..
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 30, 2010 8:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| shashivarungupta wrote: |
| Quote: |
| If the logs really are full you should be getting more problems with that queue manager than just one channel in retry. |
Agree!
..try to clean up the zombie processes of mq first (if they exist at all).
|
Please explain what a zombie process is, and how to go about cleaning them up.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 9:01 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| bruce2359 wrote: |
| shashivarungupta wrote: |
| Quote: |
| If the logs really are full you should be getting more problems with that queue manager than just one channel in retry. |
Agree!
..try to clean up the zombie processes of mq first (if they exist at all).
|
Please explain what a zombie process is, and how to go about cleaning them up. |
A zombie process or defunct process is a process that has completed execution but still has an entry in the process table.
"Kill -9 PID" to clean them.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 30, 2010 9:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, but what is a zombie process? How is a zombie process identified? How is a zombie process different from a non-zombie process?
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Dec 30, 2010 11:17 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
IMHO, killing processes would be the absolute last thing I'd contemplate or recommend to attempt to resolve a logs-full problem. Killing processes is the last thing I'd contemplate in problem-determination and resolution.
Killing a process is dangerous. IMHO, advising someone else to kill a processes with little actual knowledge of the underlying problem is unprofessional. It's suneel's career, not yours.
suneel has only 4 posts. I gather from this, that he/she is not familiar enough with WMQ system administration to make any value judgments as to what is and what is not a zombie process - whatever a zombie process is or isn't.
_________________
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 |
|
|
| exerk |
| Posted: Thu Dec 30, 2010 1:41 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| Killing a process is dangerous. IMHO, advising someone else to kill a processes with little actual knowledge of the underlying problem is unprofessional. It's suneel's career, not yours. |
And another fine piece of advice from the same source HERE...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Dec 30, 2010 2:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Cluster Sender channel at Sender is in retrying and at receiver side logs it is saying QM logs are full. Please help me on this. |
This is expected behavior. At both ends of a channel WMQ logs information about channel status.
The Sender channel in RETRYING state likely means that its partner Receiver channel is not able to start (due to no log space); and the Sender is waiting for the next RETRY interval to expire to try again to start the channel.
The solution will likely be to increase log size at the qmgr at the Receiver end of the channel.
Out of curiosity, what is the Receiver channel status?
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Jan 03, 2011 11:17 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
thanks for you suggestions..
as i said earlier in my post to suneel that first of all he has to "..work on your logging system and transactions." because of which he faced problems.
I just gave a scenario which I faced and qmgr got crashed., due to less space in the FS. After that I asked unix/aix team to increase the FS for /var/mqm. As qmgr was down unexpectedly, we checked whether any qmgr process is lying in the process state table or not before we start the qmgr after resolving the FS issue.
My intention was not to direct to anyone to kill any mq process without a proper reason.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 04, 2011 9:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
shashivarungupta: One of the challenges in writing technical documentation is being precise. It is difficult, but necessary, if the reader is to gain from your knowledge and experience.
As an example, you wrote: "..work on your logging system and transactions."
This in not precise. It does not offer the reader any clear and meaningful steps to follow. How, for example, is the OP to work on his/her logging system? Exactly what steps? Where to start doing so?
Exactly what WMQ settings should be examined? Exactly how should this be done? Exactly what commands? Once examined, how will the OP know how to interpret the results? Which, if any, are zombies? What do you mean by transactions in this context?
...we checked whether any qmgr process is lying in the process state table or not...
Exactly what commands did you execute to make this determination? Exactly how did you distinguish between good and bad processes?
Which processes belong in the process table? Which do not? Exactly how should to OP determine which processes to kill?
_________________
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 |
|
|
|
|
