From: Aaron T. <syn...@gm...> - 2007-04-30 20:52:34
|
Another update for this issue.. yep.... HUGE memory leak. Amazing what missing one word does... Anyways, the following patch causes tcpprep's footprint to be ~1MB compared to 800MB for the tests below. Index: src/common/get.c =================================================================== --- src/common/get.c (revision 1830) +++ src/common/get.c (working copy) @@ -340,7 +340,7 @@ get_addr2name4(const u_int32_t ip, u_int8_t dnslookup) { struct in_addr addr; - char *new_string = NULL; + static char *new_string = NULL; if (new_string == NULL) new_string = (char *)safe_malloc(255); This of course will be in 3.0.1 -Aaron On 4/30/07, Aaron Turner <syn...@gm...> wrote: > Quick update. Long story short, I'm unable to reproduce Sharon's > issue with tcpprep taking a long time (minutes). > > My analysis: > I downloaded the LLDOS 2.0.2 - Scenario Two inside & outside pcaps from: > http://www.ll.mit.edu/IST/ideval/data/2000/2000_data_index.html (see > bottom of page) > > these are relatively large pcaps (230-280MB) containing around 1M > packets each. So not as big as Sharon's test set, but at least in the > ballpark. > > $ tcpprep -V > tcpprep version: 3.0.0 (build 1826) > Copyright 2001-2007 by Aaron Turner <aturner at synfin dot net> > Cache file supported: 04 > Not compiled with libnet. > Compiled against libpcap: 0.9.5 > 64 bit packet counters: disabled > Verbose printing via tcpdump: enabled > > $ time tcpprep -o inside.cache -c 172.16.0.0/12 -i inside.tcpdump > > real 0m16.065s > user 0m12.122s > sys 0m1.602s > > $ time tcpprep -o outside.cache -c 172.16.0.0/12 -i outside.tcpdump > > real 0m21.963s > user 0m16.062s > sys 0m1.933s > > Above is on an Apple MacBookPro (OS X 10.4.9) w/ 3GB of RAM and > 2.16Ghz Core2Duo. Notice each run took well under 30 seconds. > > The one thing I did notice is that tcpprep's total RAM usage went way > up... around 800MB. Off the top of my head I don't know if that's > "normal" or not. It could be a memory leak- I'll have to look into > it. But if you don't have much free RAM and your box is swapping a > lot, it could explain the slowness. |