Comment # 7
on bug 10068
from Guy Harris
Given the
The following example is for sampling a 10MB PCAPNG file at 1s. I am
showing the Memory allocation for tshark-bin and kernal_task at an interval of
5 seconds in GB:
Tshark - kernel_task
0 - 1.7
0.4 - 1.7
4.0 - 1.7
6.6 - 1.7
10.3 - 1.7
10.7 - 1.7
10.1 - 1.7
9.5 - 1.7
8.9 - 1.7
7.5 - 5.7
6.9 - 5.7
5.8 - 5.7
5.2 - 5.7
4.6 - 5.7
4.1 - 9.7
3.1 - 9.7
2.8 - 9.7
2.9 - 9.7
3.1 - 9.8
3.1 - 9.8
...
2.0 - 9.8
Repeated runs show that tshark, on this file, can peak at up to 14GB. This
does not caus an increase in memory pressure. Memory pressure starts increasing
as soon as memory growth of tshark and kernel_task invert. In other words, as
soon as tshark memory allocation decreases and kernel_task memory increases,
memory pressure shoots up, virtuall memory allocation and compressed memory
start increasing until memory pressure reaches the red zoneand starts ti impact
the whoile system.
data, what *might* be happening is that, up to the 8.9GB point, all the memory
for tshark - or, at least, all the anonymous pages for tshark - are in memory
and uncompressed, and that, somewhere after that point, either memory
compression or paging is kicking in, reducing the amount of physical memory
consumed by tshark, but *increasing* the memory consumed by the kernel for data
structures to allow compressed pages to be uncompressed or to keep track of
pages stored in the swapfiles.
What are the equivalent statistics if you run on Mountain Lion? Paging would
happen on Mountain Lion as well, but memory compression wouldn't, so the kernel
data structures might be for memory compression, unless the data structures to
keep track of paged-out pages are bigger in Mavericks.
You are receiving this mail because:
- You are watching all bug changes.
