Re: Memory consumption in tshark

[Evan Huus <eapache () gmail com>]

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