[Evan Huus <eapache@xxxxxxxxx>]

On Thu, Aug 29, 2013 at 10:30 AM, Dario Lombardo <dario.lombardo.ml@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe