Hin
Le vendredi 09 octobre 2009 à 10:43 -0400, Jeff Morriss a écrit :
> Erlend Hamberg wrote:
> Give it a try. Here's what I just did (for fun :-)):
>
> Starting condition: a whole bunch of RAM free (forget how much, probably
> around 2-2.5 Gb), no swap in use.
>
> Start wireshark loading a 7.6 million packet capture file.
> Linux appears to keep free RAM in the ~20-30 Mb range, but swap usage
> grows to 1.5 Gb. Wireshark consumes 4120 Mb.
>
> Scrolling around the packet list is actually not too slow now. But
> doing even something simple (that does not involve going through the
> packet list) like Statistics->Summary takes 1-2 minutes. (Normally the
> summary page is basically instantaneous.) I didn't even try filtering.
>
Are Swap and the capture file on the same disk? Seeks storm. If you can,
try with the swap on a different disk. I don't use swap that much but I
made a quick test with a slow external drive. In vmstat Linux was able
to keep the wa columns under 20% most of the time for the SVN version,
not too bad and not much room for improvement, and it was really a slow
disk.
>
> Using memory mapped files would probably help quite a bit with keeping
> the UI responsive because only Wireshark's, for example, packet data
> would be on disk but the executable pages and "core" memory like the
> statistics could be kept in RAM (or at least whatever the OS gives us).
If you have two disks yes. Otherwise at some point Wireshark will start
to swap and you get a seeks storm again.
>
> One could imagine having different allocators (like ep_ and se_ today)
> that use malloc & friends (for "core" stuff) or go to the mmap'd pool
> (for packet data, etc.).
A better layout between write once and read/write data may help a lot
too. It will obfuscate the code though.
Didier
