reduce msmq storage folder size??

[Katdoggy]

I have a Windows 2003 Ent server with 3.5g ram.. Runs a 3rd party
app installed and configured by outside contractor (who is not available
to help me at the moment)
I discovered the MSMQ storage folder is 4.38g
with over 2000 files in it dating back to when the app was installed
back in April of 2007. The server is getting unstable, and on reboot
sits at the "applying computer settings" for 7 minutes. I determined
this is how long it is taking the MSMS service to start. After
awhile I start getting all kind of weird desktop errors, like shortcuts
won't open etc.. I believe I am about out of kernel memory because
of msqm. Reboots help for awhile, but it eventually gets bad again.

There are many private queues, but one queue has says it has 4,383,050
messages
all the other queues show 0. This is NOT a real busy application, so I suspect
I have tons of old messages.. What is the best way to delete them? I know
very little about MSMQ. Should I set a machine quota or do I need to
chase down my vendor??

[Frank Boyne]

Post by Katdoggy
There are many private queues, but one queue has says it has 4,383,050
messages

That seems a little excessive!

Post by Katdoggy
This is NOT a real busy application, so I suspect
I have tons of old messages..

That seems likely. What you don't know is whether the application
design requires those messages or not. If you are really unlucky the
application is using MSMQ as a 'database' to store all those records in
which case, getting rid of them could affect the correct operation of
your application. That would be a really bad design and one your vendor
should change.

On the other hand, your application may just have some bug that leaves
messages behind after they've been processed, in which case getting rid
of the messages wouldn't affect the correct operation of your
application. Getting rid of the messages now might make it harder for
your vendor to diagnose and repair the problem (if it doesn't happen
frequently).

A third possibility is that the queue in question is a Dead Letter Queue
or Journal queue containing copies of messages. Typically, messages in
DLQs and Journals are processed and removed by some program, often a
separate program from the main application. It is possible your
application has some sort of DLQ/Journal processor that either isn;t
running when it should or is failing when it does run.

The name of the queue might give us a clue as to its use/purpose.

Post by Katdoggy
What is the best way to delete them?

Assuming the messages can be discarded without affecting the operation
of the application, one easy way to get rid of them manually is to run
Computer Management, expand Services, then Message Queueing, then Public
Queues (or Private) and finally the queue in question. Right click on
Queue Messages below the queue in question and select All Tasks and then
Purge.

That will discard all the messages from the queue and (I think) will
free up kernel memory. It won't free up the disk space right away. The
disk space will only be made available when the MSMQ "garbage collector"
runs through the disk files discarding the ones that are no longer used.
The frequency of that is controlled by the MessageCleanupInterval
registry value with a default value of six hours.
http://support.microsoft.com/kb/199312

You can also just stop and start the MSMQ service (or reboot the system)
to force the cleanup to happen and to be absolutely sure you get the
kernel memory back.

In the longer term ou need to work with your vendor to figure out where
these messages are coming from and what needs to be done with them to
ensure they don't build up like this again. There are various MSMQ
feartures that can help -- like the Time To Be Received property that
can be used to 'kill' a message if it isn't processed within a certain
period. The specific solution depends on your application and on the
messages in question so it probably doesn;t help to speculate too much
here.

Post by Katdoggy
Should I set a machine quota or do I need to
chase down my vendor??

Setting a quota probably isn't a good idea as it may stop messages being
delivered to your system which will have an adverse effect on your
application

[John Breakwell (MSFT)]

Hi Frank,

One minor comment on your comprehensive action plan.
I would definitely recommend setting a machine quota once this problem has
been resolved and the root cause found.
If it was my system I would rather that the application stopped working than
the server became unstable.

Cheers
John Breakwell (MSFT)

Post by Frank Boyne

Post by Katdoggy
There are many private queues, but one queue has says it has 4,383,050
messages

That seems a little excessive!

Post by Katdoggy
This is NOT a real busy application, so I suspect
I have tons of old messages..

That seems likely. What you don't know is whether the application design
requires those messages or not. If you are really unlucky the application
is using MSMQ as a 'database' to store all those records in which case,
getting rid of them could affect the correct operation of your
application. That would be a really bad design and one your vendor should
change.
On the other hand, your application may just have some bug that leaves
messages behind after they've been processed, in which case getting rid of
the messages wouldn't affect the correct operation of your application.
Getting rid of the messages now might make it harder for your vendor to
diagnose and repair the problem (if it doesn't happen frequently).
A third possibility is that the queue in question is a Dead Letter Queue
or Journal queue containing copies of messages. Typically, messages in
DLQs and Journals are processed and removed by some program, often a
separate program from the main application. It is possible your
application has some sort of DLQ/Journal processor that either isn;t
running when it should or is failing when it does run.
The name of the queue might give us a clue as to its use/purpose.

Post by Katdoggy
What is the best way to delete them?

Assuming the messages can be discarded without affecting the operation of
the application, one easy way to get rid of them manually is to run
Computer Management, expand Services, then Message Queueing, then Public
Queues (or Private) and finally the queue in question. Right click on
Queue Messages below the queue in question and select All Tasks and then
Purge.
That will discard all the messages from the queue and (I think) will free
up kernel memory. It won't free up the disk space right away. The disk
space will only be made available when the MSMQ "garbage collector" runs
through the disk files discarding the ones that are no longer used. The
frequency of that is controlled by the MessageCleanupInterval registry
value with a default value of six hours.
http://support.microsoft.com/kb/199312
You can also just stop and start the MSMQ service (or reboot the system)
to force the cleanup to happen and to be absolutely sure you get the
kernel memory back.
In the longer term ou need to work with your vendor to figure out where
these messages are coming from and what needs to be done with them to
ensure they don't build up like this again. There are various MSMQ
feartures that can help -- like the Time To Be Received property that can
be used to 'kill' a message if it isn't processed within a certain period.
The specific solution depends on your application and on the messages in
question so it probably doesn;t help to speculate too much here.

Post by Katdoggy
Should I set a machine quota or do I need to
chase down my vendor??

Setting a quota probably isn't a good idea as it may stop messages being
delivered to your system which will have an adverse effect on your
application

[Katdoggy]

Hopefully I will be able to meet with the vendor late today. I
do want a quota set up to prevent this from happening again.
If the vendor gives me permission to purge I will. I will
also try adding more memory to the server.
Looks like the messages are old, probably a misbehaving
application. Thanks everyone for your input.

Post by John Breakwell (MSFT)
Hi Frank,
One minor comment on your comprehensive action plan.
I would definitely recommend setting a machine quota once this problem has
been resolved and the root cause found.
If it was my system I would rather that the application stopped working than
the server became unstable.
Cheers
John Breakwell (MSFT)

Post by Frank Boyne

Post by Katdoggy
There are many private queues, but one queue has says it has 4,383,050
messages

That seems a little excessive!

Post by Katdoggy
This is NOT a real busy application, so I suspect
I have tons of old messages..

That seems likely. What you don't know is whether the application design
requires those messages or not. If you are really unlucky the application
is using MSMQ as a 'database' to store all those records in which case,
getting rid of them could affect the correct operation of your
application. That would be a really bad design and one your vendor should
change.
On the other hand, your application may just have some bug that leaves
messages behind after they've been processed, in which case getting rid of
the messages wouldn't affect the correct operation of your application.
Getting rid of the messages now might make it harder for your vendor to
diagnose and repair the problem (if it doesn't happen frequently).
A third possibility is that the queue in question is a Dead Letter Queue
or Journal queue containing copies of messages. Typically, messages in
DLQs and Journals are processed and removed by some program, often a
separate program from the main application. It is possible your
application has some sort of DLQ/Journal processor that either isn;t
running when it should or is failing when it does run.
The name of the queue might give us a clue as to its use/purpose.

Post by Katdoggy
What is the best way to delete them?

Assuming the messages can be discarded without affecting the operation of
the application, one easy way to get rid of them manually is to run
Computer Management, expand Services, then Message Queueing, then Public
Queues (or Private) and finally the queue in question. Right click on
Queue Messages below the queue in question and select All Tasks and then
Purge.
That will discard all the messages from the queue and (I think) will free
up kernel memory. It won't free up the disk space right away. The disk
space will only be made available when the MSMQ "garbage collector" runs
through the disk files discarding the ones that are no longer used. The
frequency of that is controlled by the MessageCleanupInterval registry
value with a default value of six hours.
http://support.microsoft.com/kb/199312
You can also just stop and start the MSMQ service (or reboot the system)
to force the cleanup to happen and to be absolutely sure you get the
kernel memory back.
In the longer term ou need to work with your vendor to figure out where
these messages are coming from and what needs to be done with them to
ensure they don't build up like this again. There are various MSMQ
feartures that can help -- like the Time To Be Received property that can
be used to 'kill' a message if it isn't processed within a certain period.
The specific solution depends on your application and on the messages in
question so it probably doesn;t help to speculate too much here.

Post by Katdoggy
Should I set a machine quota or do I need to
chase down my vendor??

Setting a quota probably isn't a good idea as it may stop messages being
delivered to your system which will have an adverse effect on your
application

[John Breakwell (MSFT)]

Don't add more RAM to help MSMQ unless you have a real performance issue
that memory can help.
In your case there are just loads of old messages hanging around that
probably just need purging.
If you purge the queue and messages don't build up again then the RAM will
just be a waste of money.

Post by Katdoggy
Hopefully I will be able to meet with the vendor late today. I
do want a quota set up to prevent this from happening again.
If the vendor gives me permission to purge I will. I will
also try adding more memory to the server.
Looks like the messages are old, probably a misbehaving
application. Thanks everyone for your input.

Post by John Breakwell (MSFT)
Hi Frank,
One minor comment on your comprehensive action plan.
I would definitely recommend setting a machine quota once this problem has
been resolved and the root cause found.
If it was my system I would rather that the application stopped working than
the server became unstable.
Cheers
John Breakwell (MSFT)

Post by Frank Boyne

Post by Katdoggy
There are many private queues, but one queue has says it has 4,383,050
messages

That seems a little excessive!

Post by Katdoggy
This is NOT a real busy application, so I suspect
I have tons of old messages..

That seems likely. What you don't know is whether the application design
requires those messages or not. If you are really unlucky the application
is using MSMQ as a 'database' to store all those records in which case,
getting rid of them could affect the correct operation of your
application. That would be a really bad design and one your vendor should
change.
On the other hand, your application may just have some bug that leaves
messages behind after they've been processed, in which case getting rid of
the messages wouldn't affect the correct operation of your application.
Getting rid of the messages now might make it harder for your vendor to
diagnose and repair the problem (if it doesn't happen frequently).
A third possibility is that the queue in question is a Dead Letter Queue
or Journal queue containing copies of messages. Typically, messages in
DLQs and Journals are processed and removed by some program, often a
separate program from the main application. It is possible your
application has some sort of DLQ/Journal processor that either isn;t
running when it should or is failing when it does run.
The name of the queue might give us a clue as to its use/purpose.

Post by Katdoggy
What is the best way to delete them?

Assuming the messages can be discarded without affecting the operation of
the application, one easy way to get rid of them manually is to run
Computer Management, expand Services, then Message Queueing, then Public
Queues (or Private) and finally the queue in question. Right click on
Queue Messages below the queue in question and select All Tasks and then
Purge.
That will discard all the messages from the queue and (I think) will free
up kernel memory. It won't free up the disk space right away. The disk
space will only be made available when the MSMQ "garbage collector" runs
through the disk files discarding the ones that are no longer used. The
frequency of that is controlled by the MessageCleanupInterval registry
value with a default value of six hours.
http://support.microsoft.com/kb/199312
You can also just stop and start the MSMQ service (or reboot the system)
to force the cleanup to happen and to be absolutely sure you get the
kernel memory back.
In the longer term ou need to work with your vendor to figure out where
these messages are coming from and what needs to be done with them to
ensure they don't build up like this again. There are various MSMQ
feartures that can help -- like the Time To Be Received property that can
be used to 'kill' a message if it isn't processed within a certain period.
The specific solution depends on your application and on the messages in
question so it probably doesn;t help to speculate too much here.

Post by Katdoggy
Should I set a machine quota or do I need to
chase down my vendor??

Setting a quota probably isn't a good idea as it may stop messages being
delivered to your system which will have an adverse effect on your
application

[Frank Boyne]

Post by John Breakwell (MSFT)
One minor comment on your comprehensive action plan.
I would definitely recommend setting a machine quota once this problem
has been resolved and the root cause found.
If it was my system I would rather that the application stopped
working than the server became unstable.

Good point John.

My concern with quotas is that they bring things to an abrupt (but
temporary) halt.

Message N arrives driving things over the quota and now message N+1 will
not be delivered to the system - at least not until the quota-exceeded
condition is repaired. If the quota is exceeded at the wrong time (late
Friday afternoon?) message delivery might be suspended for hours or even
days.

I guess ideally you have a properly tuned MSMQ application that doesn't
get into trouble in the first place and have a reasonably large quota in
place to guard against the unforseen.

[John Breakwell (MSFT)]

Frank, you are highlighting people process issues :-)

Here's a choice:

1 It's Friday afternoon and MSMQ messages accumulate due to a back-end
problem until quota is reached when the application stops working. No-one
notices until Monday morning when the SysAdmin comes in and fixes the
back-end problem.

2 It's Friday afternoon and MSMQ messages accumulate due to a back-end
problem but there is no quota set so eventually the server crashes with
insufficient kernel memory. No-one notices until Monday morning when the
SysAdmin comes in and tries to bring the unresponsive and unstable server
back to life without losing any of the accumulated messages. Fun ensues.
Later that day the SysAdmin finds time to fix the back-end problem.

Your call.

Cheers
John

Post by Frank Boyne

Post by John Breakwell (MSFT)
One minor comment on your comprehensive action plan.
I would definitely recommend setting a machine quota once this problem
has been resolved and the root cause found.
If it was my system I would rather that the application stopped working
than the server became unstable.

Good point John.
My concern with quotas is that they bring things to an abrupt (but
temporary) halt.
Message N arrives driving things over the quota and now message N+1 will
not be delivered to the system - at least not until the quota-exceeded
condition is repaired. If the quota is exceeded at the wrong time (late
Friday afternoon?) message delivery might be suspended for hours or even
days.
I guess ideally you have a properly tuned MSMQ application that doesn't
get into trouble in the first place and have a reasonably large quota in
place to guard against the unforseen.