Message-ID: <3A955B29.5B071252@cup.hp.com> Date: Thu, 22 Feb 2001 10:32:09 -0800 From: Rick Jones <raj@cup.hp.com> Subject: Re: problem of memory with tcptrace
I suspect that tcptrace wants to bring just about everything into RAM.
If your trace file is large enough, tcptrace will not be able to do
that. You can add swap and even RAM to be sure, but then if your
tcptrace binary is 32-bit, it will not be able to have more than 3-4GB
of memory. At that point you would have to go to a 64-bit tcptrace
binary - even then you still need the ram and the swap.
I ran into a slightly similar problem with some traces - there were it
seems enough distinct connections in one of my traces that tcptrace
encounterd the file dscriptor limit for my box at the time. I'm not
_certain_ if it was the total number of connections/flows in my trace,
or the maximum simultaneous - it all depends on whether or not tcptrace
was closing a "a2b.mumble" file when it saw the last FIN (and perhaps
re-opening later if another packet was seen).
I've also had similar problems with HP's ttv (thread trace visualizer)
tool. It wanted to read an entire set of trace files into RAM instead of
churning through them in chunks.
rick jones
-- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... ---------------------------------------------------------------------------- To unsubscribe, send a message with body containing "unsubscribe tcptrace" to majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 02/23/01 EST