Hi all, I am running some tests with Wireshark 1.8.4 on OSX (10.8.6). Long story short:
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 Morte... |
2 Answers:
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 Harris ♦♦ |
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 Harris ♦♦ |
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...