This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Wireshark not releasing memory back to OS while open…

1

Hi all, I am running some tests with Wireshark 1.8.4 on OSX (10.8.6). Long story short:

  • Open 700MB capture with default settings except Sub-dissector reassembly disabled
  • Wireshark memory usage at a nice 700 MB or so
  • Follow stream that is huge
  • Follow stream pop-up window displays
  • Memory usage now at 3GB (meh, not great, but OK)
  • Close follow stream pop-up and clear tcp.stream filter
  • Memory usage now at 2.7GB

Ideally I would expect the memory usage to drop back to the 700MB seen prior. Now if I do the same steps again, we creep from the current 2.7 GB back up to the 3GB. So it looks like Wireshark allocates as much memory as it needed to do the follow-stream filter, does not fully release it all, but reuses this leftover 2GB that was not released. In the end it does not seem to leak more memory, but it never releases all it had.

I'm not programming expert from a memory perspective, but for those have dug into this, any idea why Wireshark would not release all the way back to 700MB? With multiple captures and multiple instances of Wireshark open, I would rather not have one instance using more memory than what it needs at that time.

asked 24 Jan '13, 12:39

Magnus%20Mortensen's gravatar image

Magnus Morte...
56114
accept rate: 50%


2 Answers:

1

So it looks like Wireshark allocates as much memory as it needed to do the follow-stream filter, does not fully release it all, but reuses this leftover 2GB that was not released.

That's how many memory allocators work - freeing the memory doesn't release it back to the OS, it just adds it to a pool from which future allocations are satisfied.

Note that what a memory allocator really allocates, on modern OSes, is virtual address space; not all of that virtual address space is necessarily in main memory - it might be on swap space.

What are you using to determine the memory usage? Activity Monitor and, if so, which column (real or virtual memory)? vmmap? Some other tool?

answered 24 Jan '13, 17:57

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Guy, My hunch was what you indicated. For my tests I was using Activity Monitor, focussing on the 'Real Mem' column for wireshark-bin. The whole reason I started looking into this was that while going through two very large capture files (2 x 700MB, full packet) , simultaneously (two instances of wireshark-bin), OS X's indication of "Free Memory" dropped to near zero and anything being done at the moment in wirseshark ground to a halt. At the time this was happening there was over 2GB of what OS X dubs as 'Inactive Memory'. From my reading this memory is free to be used by the system, but still contains cached data from application that may have used it in the past. This pseudo-free memory seems never to be re-used by wireshark (just an observation, but I may be way off). When I reach <50MB "Free" memory, I usually find that perforamcne is improved by running purge from the command line (frees inactive memory into free memory) and wireshark picks back up processing until we hit the <50MB free situation again.

Ideally, if wireshark used only the memory it needed at the time, i could have both files open with wireshark humming at a svelt 700mb RAM usage. If I were to run a task on one capture (follow stream) and then close that stream (reverting back to the initial state of post-capture-loaded, I would hope to have just the two instances at 700MB of ram each. And...

alt text

(24 Jan '13, 18:39) Magnus Morte...

0

If "free memory" always has a large value on an OS X machine, that means you paid too much for your machine. :-)

Just because it's low, that's not necessarily a bad thing.

I'd have to spend some time looking at the xnu VM code to determine exactly what "free" and "inactive" memory are; if a page fault occurs that requires either a page-in from a file or swap space or the zero-fill-on-demand allocation of a page, the VM code will probably prefer to take a "free" page frame rather than an "inactive" page frame and would probably prefer to take an "inactive" page frame than an "active" page frame ("wired" page frames are ineligible, as they're "wired down" into memory). I'd have to spend some more time looking at the VM code to see what rules it uses to decide which "inactive" page frame to take.

answered 24 Jan '13, 18:50

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%