Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 1 subscriber
  • Views 2373 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SEC 4.5 with additional message relay: Lots old msg-packets

DetlevRackow

Hi,

during the last two weeks, I have encountered this problem twice.

We have about 7,000 clients wich update from server1 or server2, they are separated into a number of groups and update policies for the groups point either to a web-cid on server1 or server2.

Server1 hosts the SEC with the database, Server2 is just a SUM, and acts as a message relay for the machines which get their updates from there. About half of our machines connect to Server2.

The package on Server2 has been modified with the customized mrinit.conf (there is a KB-article for this), and Server2 will show "message relay" in it's RMS-status report. The article describes the required registry-settings, I have checked them too.

This works quite well. Since a lot of our machines are not always online, the average number of connected clients is usually in the range of 4,500+.

Twice, the number of connected machines dropped down to below 1,000 during regular business hours. When I looked at Server1, I found nearly 80,000 msg-packets in the Envelope-folder. Removing these old messages and restarting the message router was an immediate fix: The number of connected machines improved over about an hour and was back to normal values.

A majority of the orphan packages had a similar timestamp.

I have no idea why the server produced such an enormous number of message-packets, and why this happens only on Server1.

Server2 is totally unaffected, it shows about 3,000 packets in the envelope-folder. This seems to be a healthy number.

We configured the message relay in fall 2010.

Is there any way to diagnose this behaviour?

My first attempt for a workaround is to use delage32.exe and remove msg-files which are older than 7 days. While this is no real cure, it should mitigate the effect.

Best regards,

Detlev

:11681


This thread was automatically locked due to age.
  • 0

    Hello Detlev,

    the lower the number the better but if it doesn't increase over time (i.e. "old" packages are eventually removed by SEC or the relay) it shouldn't be a problem.

    The first question is whether the packages are upstream (from client to server) or downstream - it's easily to see if you inspect a package.

    Downstream packages are sent when you request something (update now, resolve, full scan), an applicable policy or group-membership is changed. If you send many request at the same time they are "queued" there and subsequently worked off except those where the client can't be reached. Ideally they should either get sent at some time in the future or "time out" and get deleted (AFAIK this process was never "perfect" but since 4.5 I've practically no orphaned messages). 

    If the packages are upstream it means that SEC can't keep up with incoming messages. Again you can find out what they are, where they are from and where they should be sent to by looking at the contents.

    That's I think a first step.

    Christian

    :11685
Unfiltered HTML