Home page logo
/

wireshark logo Wireshark mailing list archives

Re: Memory consumption in tshark
From: Evan Huus <eapache () gmail com>
Date: Thu, 29 Aug 2013 10:35:47 -0400

On Thu, Aug 29, 2013 at 10:30 AM, Dario Lombardo <
dario.lombardo.ml () gmail com> wrote:

Running the same command as before (I mean without valgrind) with -n, I
get 1.5G of memory consumption, as without -n.


That's expected.


 That's quite useful actually: it looks like the majority of the memory
is being used to store address-resolution data from all of the DNS packets
so that if those IP addresses show up later we can resolve them immediately
(without having to ask the system name resolver).


It's a cache, isn't it?


Basically, but it's also more. If your capture contains a DNS packet
resolving a name in a certain way, and the system name resolver gives a
different answer, we prefer the DNS packet in the capture (since presumably
the capture was on some local network where that name resolves
differently). For this reason we can't just drop old cache entries unless
name resolution is disabled completely.

 It doesn't look like there's a way to disable this at the moment (I
believe we still store the names even if name resolution is disabled), but
it should be easy enough to fix. The add_ipv4_name and add_ipv6_name
functions should probably be no-ops if all name resolution is disabled.
Then simply passing the -n flag will greatly reduce your memory usage
(though it won't yet).


What about a circular buffer? Instead of storing all the resolution, you
could create a circular buffer of N resolutions. This should give you the
control of the maximum amount of ram eaten by this part of the code. Once
reached the maximum you could
- delete older entries
- delete newer entries
- keep the existing entries making the following through the resolver
Just an idea. Disabling resolution when -n is used is to be implemented
anyway IMHO.


We use a hash table right now to permit fast lookup. Implementing expiry on
top probably isn't easy enough to bother with. This isn't really an issue
unless you've got a massive number of DNS packets in your capture :)




___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org
?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault