ratop
Carter Bullard
carter at qosient.com
Mon Oct 29 15:54:16 EDT 2007
Hey CS Lee,
Getting back to your original ratop question. Should ratop() be taking
100% of the CPU. ratop() isn't the biggest hog on the machine, but
it can get busy if there are a lot of flows to track. There are two
ways
to help it. One is to decrease the number of trackable flows. The
biggest CPU hit is sorting the display list, and so getting the number
of trackable flows helps a lot. The second is to decrease the number
of sorts per second, and that is dictated by how often the display is
updated. The default is to update the screen a little over 2x per
second.
So, to decrease the number of flows, you can filter or change the
flow model. Filtering is straight forward. Type ":f" and then type the
filter. To change the flow model, type ":m" and then edit the list of
flow key items.
To change the display refresh rate, type ":u" and edit the update
refresh timer.
Carter
On Oct 22, 2007, at 2:24 AM, CS Lee wrote:
> Hi Carter,
>
> First of all, congratulations for the argus 3.0 release, and I'm
> looking forward for the client suite to reach that state.
>
> For ratop question, yes, it is over 1000 records per second.
>
> The explanation of radark is brilliant. And I have question
> regarding it, I tried the command in the radark -
>
> Here's my data -
>
> ra -nnr loadbalance.arg - ip
> 19:33:06.063023 e 6 10.0.0.46.36024 -
> > 216.67.244.22.80 3 3 629
> 198 RST
> 19:33: 27.653232 e 6 10.0.0.46.45640 -
> > 216.67.244.22.80 2 2 140
> 138 RST
> 19:33:57.899913 e 6 10.0.0.46.2540 -
> > 216.67.244.22.80 2 1
> 108 60 RST
> 19:33:58.907789 e 6 10.0.0.46.2541 -
> > 216.67.244.22.80 2 1
> 108 60 RST
> 19:33:59.915817 e 6 10.0.0.46.2542 -
> > 216.67.244.22.80 2 1
> 108 60 RST
> 19:34:00.923744 e 6 10.0.0.46.2543 -
> > 216.67.244.22.80 2 1
> 108 60 RST
> 19:34:01.931729 e 6 10.0.0.46.2544 -
> > 216.67.244.22.80 2 1
> 108 60 RST
> 19:34:02.939714 e 6 10.0.0.46.2545 -
> > 216.67.244.22.80 2 1
> 108 60 RST
>
> Then I tried -
>
> racluster -M norep -r loadbalance.arg -w loadbalance.racluster
>
> racluster -M norep rmon -m smac saddr daddr -r
> loadbalance.racluster - appbytes gt 0
> 19:33:06.063023 e ip 10.0.0.46 <-
> > 216.67.244.22 3 3 629
> 198 CON 19:33: 06.063023 e ip
> 216.67.244.22 <-> 10.0.0.46
> 3 3 198 629 CON
>
> I'm pretty clear until this part. 10.0.0.0/24 is the local net.
>
> The first call to racluster() generates the list of src and dst IP
> addresses for flows that had some form of user data exchanged,
> creating two entries for each set of src/dst IP pairs (using the -M
> rmon we remove the src and dst semanitcs by creating entries (A ->
> B and B -> A).
>
> But when I do -
>
> racluster -M norep rmon -m smac saddr daddr -r
> loadbalance.racluster -w - - appbytes gt 0 | racluster -L0 -m smac
> saddr -s +smac - src net 10.0.0.0/24 and not dst net 10.0.0.0/24
> and src pkts gt 0
> StartTime Flgs Proto SrcAddr Sport
> Dir DstAddr Dport SrcPkts DstPkts SrcBytes
> DstBytes State SrcMac
> 19:33:06.063023 e ip 10.0.0.46 <-
> > 0.0.0.0 3 3 629
> 198 CON 0:1b:77:5b:f4:3f
> 19:33:06.063023 e ip 10.0.0.46 <-
> > 0.0.0.0 3 3 198
> 629 CON 0:50:e8:2:3d:ca
>
> For me it doesn't look right especially the second record. I'm not
> clear about the purpose of second parsing.
>
> Thanks.
>
>
>
> On 10/7/07, Carter Bullard <carter at qosient.com> wrote:
> Hey CS Lee,
> No, unless your processing 1000's of records per second.
> Use ^G to display the processing stats at the bottom of the
> screen. How records per second are you processing?
>
> Carter
>
> On Oct 6, 2007, at 1:08 AM, CS Lee wrote:
>
>> Hi all,
>>
>> I'm running argus dev on Ubuntu 7.04, and using ratop to monitor
>> the traffic in realtime. Is it normal that ratop utilizes lots of
>> resources as I have this -
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 14256 root 25 0 25572 19m 1164 R 98 0.9 1273:40 ratop
>>
>>
>>
>> --
>> Best Regards,
>>
>> CS Lee<geekooL[at]gmail.com>
>>
>> http://geek00l.blogspot.com
>
>
>
>
> --
> Best Regards,
>
> CS Lee<geekooL[at]gmail.com>
>
> http://geek00l.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20071029/88fd57ce/attachment.html>
More information about the argus
mailing list