ratop hangs server

[Carter Bullard]

Hey Zack,
Crashing the server is slightly different, but I would highly recommend
that you put a radium between ratop and argus.

The ratop problem is that we have to linearly search the process queue for each
update interval.  The screen refresh interval is pretty fast, but because
we have to calculate some aggregates in case you're looking at percentages,
we have to linearly go through each queue every update interval, which
locks the queues, etc …..  So you're running out of cycles, I suspect.

Try changing a few parameters, such as the RA_UPDATE_INTERVAL
to a number that is a couple of seconds.  That is in the ~/.rarc file, if you
have one.

I can thread ratop.1 more than it is, and get back some horsepower,
but that will come in argus-3.0.8.

You can also modify the timeout values and refresh values using
and ":u" in ratop.1 itself.  You can also change the flow idle timeout
value using the ":T" option. (don't use the ":t" option, there seems to
be a bug in that…..).  These will help you're ratop to perform better.

Also, using a complex racluster.conf file, so that you control the
timeouts etc of specific flows will help a huge amount.

Carter 

On Mar 20, 2012, at 9:47 AM, Zach Brown wrote:

> So it's definitely not using up all the memory on the machine but it does 
> appear that that queue length does get long enough that the delay may be
> upsetting
> argus. I actually did set up radium and argus but that still produced the 
> same result server side (Both radium and argus locked up and had to be 
> kill'ed -9)
> 
> If I aggregate to a /16 like you suggested it will continue to process okay
> and my process queue hangs at about 12k. Without it, I captured stats just
> before it died as you requested:
> 
> ProcessQueue 181320 DisplayQueue 181321 TotalRecords   223749  Rate   7866.3247
> rps
> 
> ratop is still responsive. I can issue commands and exit. 
> 
> Is there anything else you'd like me to try? I'm fine with the answer that
> ratop can't keep up, I was just hoping we could keep it from crashing the
> server.
> 
> Thanks!
> Zach
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120321/097134e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120321/097134e4/attachment.bin>