New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leaks in Docker for Mac stemming from Hyperkit #231

Closed
iMerica opened this Issue Sep 30, 2018 · 47 comments

Comments

Projects
None yet
@iMerica
Copy link

iMerica commented Sep 30, 2018

Hi,

See:

Call graph: docker/for-mac#178 (comment)

Dtrace list
$ dtrace -l -P 'hyperkit$target' -p $(pgrep hyperkit)

   ID   PROVIDER            MODULE                          FUNCTION NAME
 3210 hyperkit37931 com.docker.hyperkit                       blockif_thr block-delete
 3211 hyperkit37931 com.docker.hyperkit                       blockif_thr block-delete-done
 3212 hyperkit37931 com.docker.hyperkit                      block_preadv block-preadv
 3213 hyperkit37931 com.docker.hyperkit                      block_preadv block-preadv-done
 3214 hyperkit37931 com.docker.hyperkit                     block_pwritev block-pwritev
 3215 hyperkit37931 com.docker.hyperkit                     block_pwritev block-pwritev-done
 3216 hyperkit37931 com.docker.hyperkit                           vmx_run vmx-ept-fault
 3217 hyperkit37931 com.docker.hyperkit                           vmx_run vmx-exit
 3218 hyperkit37931 com.docker.hyperkit                           vmx_run vmx-inject-virq
 3219 hyperkit37931 com.docker.hyperkit                           vmx_run vmx-read-msr
 3220 hyperkit37931 com.docker.hyperkit                           vmx_run vmx-write-msr

While running 0 containers, here are the system calls count by process name (1 min sample, other stuff filtered out).
$ dtrace -n 'syscall:::entry { @[execname, probefunc] = count(); }'

com.docker.hyper  fsync                10
com.docker.hyper  lseek                13
com.docker.hyper  psynch_cvclrprepost  63
com.docker.hyper  readv                144
com.docker.hyper  writev               149
com.docker.hyper  read                 461
com.docker.hyper  write                464
com.docker.hyper  psynch_mutexdrop     1105
com.docker.hyper  psynch_mutexwait     1158
com.docker.hyper  select               1700
com.docker.hyper  psynch_cvsignal      16197
com.docker.hyper  psynch_cvwait        20192

I'm running 15 apps in macOS and com.docker.hyper still has the highest counts.

@kalexmills

This comment has been minimized.

Copy link

kalexmills commented Oct 10, 2018

Also seeing this. Memory leaks seem to have been a pervasive issue with hyperkit for a few years now, and the leaks keep coming back when upgrades occur. Seems that something must be done differently.

Here is a diagnostic ID which should(?) tell you everything you need to know. Please ask if any more info would be helpful.

3CBF0FFC-A3ED-4F24-944A-650842923449/20181010135026

I am running Kubernetes with a few containers: tomcat, ldap, mysql, and a few Spring Boot microservices.

@lookfirst

This comment has been minimized.

Copy link

lookfirst commented Oct 19, 2018

Came here wondering why hyperkit is taking up 2.78 GB of ram and that is with zero containers and freshly restarted...

image

95FE31E3-5295-4781-AF08-69B23B71BD7D/20181019060130

@emhagman

This comment has been minimized.

Copy link

emhagman commented Oct 25, 2018

Having the same issue: A24EF539-54C9-4F2D-A326-BD3F808506DD/20181025141141

@davidcelis

This comment has been minimized.

Copy link

davidcelis commented Nov 5, 2018

Having the same issue too! Over 4 GB of memory being used, but I'm not running any containers.

image

EA2698F1-C7B7-459E-93CF-3DA6B8CB2C5F/20181105185051

@ybert

This comment has been minimized.

Copy link

ybert commented Nov 6, 2018

Same here...
iMac, Mojave
Docker Version 18.06.1-ce-mac73 (26764)

com.docker.hyperkit is over 5.5GB of RAM with no container running
com.docker.hyperkit is over 9.5GB of RAM with elk stack and nginx + php and node containers

Diagnostic:
DC2D5189-36AD-43D6-89CB-63042103D808/20181106125353

@ovargasmahisoft

This comment has been minimized.

Copy link

ovargasmahisoft commented Nov 8, 2018

I disabled experimental features and debug.

{
  "debug" : false,
  "experimental" : false
}

Without any running container com.docker.hyperkit uses about 2.7Gb
Running a percona:latest container uses 3.4Gb

I'm using the default settings: 4CPUs, 2.0 GiB, Swap 1.0 GiB

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:31 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     false

MacOS: Mojave 10.14.1 (18B75)
MacBook Pro (15-inch, 2016)
2.7 GHz Intel Core i7
16 GB 2133 MHz LPDDR3

Diagnostic Id: 161D79AD-D3ED-4BB9-8223-AA725E6B0EA1/20181108023806
@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Nov 26, 2018

Same issue with Mojave.
Using 4GB of RAM after restart with no containers running

@mcgitty

This comment has been minimized.

Copy link

mcgitty commented Nov 28, 2018

Please find a big and fast machine to run valgrind beneath hyperkit. It will find all the red-face turning leaks. Please!

@kalexmills

This comment has been minimized.

@KatSick

This comment has been minimized.

Copy link

KatSick commented Nov 29, 2018

Same issue in Mojave

@nehbit

This comment has been minimized.

Copy link

nehbit commented Nov 30, 2018

Same issue here on OS X Mojave. About 3-4gb, without ever having run a container after its start.

@naviat

This comment has been minimized.

Copy link

naviat commented Dec 1, 2018

Same here!
No container with 5G memory
OS X Mojave

@congkhoa

This comment has been minimized.

Copy link

congkhoa commented Dec 3, 2018

Same here, OS X Mojave, about 3-4 GB memory.
Docker Version 2.0.0.0-mac81 (29211)

@jameswmcnab

This comment has been minimized.

Copy link

jameswmcnab commented Dec 3, 2018

Same here, using 3-4GB memory with no containers running.
OS X Mojave, Docker Version 2.0.0.0-mac81 (29211)

@ruslaniv

This comment has been minimized.

Copy link

ruslaniv commented Dec 7, 2018

Same here, using 2-4GB memory with no containers running.
OS X Mojave, Docker Version 2.0.0.0-mac81 (29211)

@takeit

This comment has been minimized.

Copy link

takeit commented Dec 7, 2018

Using ~4GB memory with no containers running.
OS X Mojave, Docker Version 2.0.0.0-mac81 (29211)

@holynakamoto

This comment has been minimized.

Copy link

holynakamoto commented Dec 12, 2018

Exact same issue

@nickveenhof

This comment has been minimized.

Copy link

nickveenhof commented Dec 13, 2018

Same!

@adriangay

This comment has been minimized.

Copy link

adriangay commented Dec 16, 2018

2017 MacBook Pro, High Sierra 10.13.6, Docker 8.06.1-ce-mac73 (26764). start Docker, doing nothing, Hyperkit uses 315% CPU and 1.7G memory when starting up, then levels out at 10-15% CPU and 1.8G memory (as seen in Activity Capture). I will just start and stop Docker between usages then sigh

@ibrahim-aburajab

This comment has been minimized.

Copy link

ibrahim-aburajab commented Dec 17, 2018

Same!

@ezy

This comment has been minimized.

Copy link

ezy commented Dec 18, 2018

+1

@ybod

This comment has been minimized.

Copy link

ybod commented Dec 18, 2018

Same on Mojave with Docker Version 2.0.0.0-mac82 (29268): 3 - 4Gb

Diagnostic ID: 237142F5-D921-4FCB-8D0B-D2EBF3C63C86/20181218111028

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 18, 2018

Please help me understand your logic and expectations. I think everybody ITT understands how Docker on Mac works: it is not native containers, it's container inside VM running on Mac.

If you have any experience with VM (I suppose everybody has it here), you know that VM eats memory and there's a setting of how much memory it eats. In Docker for Mac this setting resides in Advanced tab of settings:

screen shot 2018-12-18 at 3 37 10 pm

What I would expect that it eats exactly how much is set here. Realistically, I understand there's overhead and it actually eats more.

My expectations aren't met. I'm surprised it eats LESS memory than I expect it to.

screen shot 2018-12-18 at 3 42 23 pm

And I'm surprised you expect it to consume no memory at all. How is it so? Is there something I don't understand?

@adriangay

This comment has been minimized.

Copy link

adriangay commented Dec 18, 2018

@Vanuan u make a fair point in that from docker you can set 'memory'. I think the expectation is that memory is allocated as needed up to the limit, rather than its all 'taken' at once when its not in use.

@pmingram

This comment has been minimized.

Copy link

pmingram commented Dec 18, 2018

@Vanuan Based on your screenshots, I think the issue might be the confusion between "Real Mem" and "Memory". Suffice to say I doubt I'm alone in not knowing about "Real Mem" until reading up on it just now.

Having shown that column on both of my Macs, Real Mem does indeed show slightly less RAM usage than I have limited Docker to.

My expectations would be that the VM would use a lower amount of RAM on first start, and increase progressively up to the limit as Docker is utilised. Real Mem usage should not be higher than the limit set.

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 18, 2018

Ok, here are 3 metrics:

  1. VSZ reported from inside VM: docker run -it --rm --privileged --pid=host justincormack/nsenter1
  2. limit in docker settings (not sure whether it's VSS or RSS limit)
  3. VSZ reported by OS X

screen shot 2018-12-18 at 3 59 38 pm

It appears that your expectations are met. It uses lower amount on first start, increases progressively. And starts to kill random containers when the limit is reached.

@pmingram

This comment has been minimized.

Copy link

pmingram commented Dec 18, 2018

@Vanuan I hereby concede my previous view. Thank you for clarifying - and for introducing me to metrics I knew nothing about! (I work exclusively in the web land at the moment hence lack of exposure).

@iMerica

This comment has been minimized.

Copy link

iMerica commented Dec 18, 2018

I understand your point @Vanuan, but I think it's fair to expect unused memory to be reclaimed based on how Docker for Mac is marketed.

Also:

  • In the image you posted, notice how the Docker for Mac preferences calls it a Docker Engine, not a VM.
  • Notice the usage of the word "Limit". A limit it not a static value.
  • Notice now Docker themselves downplay virtualization in the marketing: https://www.docker.com/products/docker-desktop

Docker Inc is the one setting the expectations.

@rn

This comment has been minimized.

Copy link
Member

rn commented Dec 18, 2018

I'm closing this issue for the following reasons:

  • All of the comments are related to hyperkit usage in Docker for Mac. Please file issues there first and only escalate to this repository if there clearly is an issue with hyperkit.
  • If you start a VM (which Docker for Mac does) and assign a certain amount of memory to it then I would expect the VM and subsequently the VMM (hyperkit in this case) to consume that much memory. Initially it may use less but after some activity, even if idle afterwards, hyperkit has no way to give the memory back because it may still be in use by the VM (there is ballooning, but hyperkit is not implementing this)
  • Simply reporting "my process uses X GB of memory" is not really helpful. Is this virtual memory, physical memory, pinned memory? You'd have to be a lot more specific.
  • I have not seen any indication in this thread that there is a memory leak.

@rn rn closed this Dec 18, 2018

@moby moby locked and limited conversation to collaborators Dec 18, 2018

@moby moby unlocked this conversation Dec 19, 2018

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 19, 2018

@rn I'll try to answer your points and see if we can get this moving. A lot of people are having serious disruptions because of this issue and the Docker team and the hyperkit team are blaming each other, which is taking us nowhere...

  1. We did, and we've been ignored for almost 3 months (docker/for-mac#3232) as the Docker team probably think it's Hyperkit causing the issue. We can't say that for sure, of course but since the process having this issue is com.docker.hyperkit we also came here asking for help.
  2. This connects to what @Vanuan also said, but you guys are ignoring 2 important points: a) the issue only started for most of us after the update to Mojave (we didn't change the settings or the way we use Docker/Hyperkit, it just suddenly started using more RAM); b) Even though we set a RAM limit, this seems like completely ignored by the com.docker.hyperkit process. I've attached my screenshot below to show you the config and the memory usage, but if you check the docker thread you'll see people having more than 10GB used. I don't know why "Memory" differs so much from the combination of "Real Memory" and "Compressed Memory", but all I know is that my Mac starts swapping like crazy and becomes unusable shortly after I start Docker, so I guess the process is not just taking the "real" memory but it's actually holding the whole "Memory" (3.47GB in my case) from the OS. Happy to get some clarification from you if that's not the case.
  3. I agree we've not been very consistent with our screenshot, if you think this might help you, please provide a macOS command you'd deem specific enough us to execute and we'll gladly report the result.
  4. It might be a Memory leak, it might simply be that the Memory limit setting is being ignored. People labelled it memory leak because the memory keeps growing over time. Again, we're happy to provide additional information if you tell us exactly which command you want us to run.

We don't like to spend time complaining on random repositories, we're here because our work depends on this software and we're currently unable to work efficiently.
We're happy to collaborate as much as possible to get this solved.

screenshot 2018-12-18 at 14 14 40

@rn

This comment has been minimized.

Copy link
Member

rn commented Dec 19, 2018

I'm running docker for mac on Mojave/10.14.2

The command to check the memory used by hyperkit would be to find out the process id and then something like:

ps -o vsz,rss -p <hyperkit pid>

vsz is the virtual size (doesn't matter) and rss is the resident set size, this is the memory actually consumed. I have no idea what the Activity Monitor reports as memory and the documentation is very scant. There are additional columns availabe in Activity Monitor and one is called Real Memory, which looks like it most closely resembles rss..

I'm running this with watch (brew install watch) in one window to see changes over time. Or if you want to see other Docker for Mac processes as well, use something like pstree (brew install pstree) to find the child processes of Docker for Mac (which includes things likes VPNKit and osxfs) and run watch ps -o vsz,rss,pid,comm -p <pid 1>,<pid2>,<pid3>...

I have my docker for mac set to have 2GB of memory. I've started kubernetes (just to run a few container) and run various other containers. I've also run several parallel:

for i in $(seq 1000); do docker run --rm alpine wget http://www.google.com; done

and something egnerate a bit more traffic, like a speed test:

for i in $(seq 100); do docker run --rm alpine sh -c 'apk add curl python; curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python -'; done

Initially the rss increases, as I expected, but then maxes out at something like 1972180. This is in KB so the rss is 1.8GB.

It stays stable there.

@davidcelis

This comment has been minimized.

Copy link

davidcelis commented Dec 19, 2018

What I don't understand is that the rss of my hyperkit process balloons to 2GB without running any containers, and stays there:

$ ps -ef | rg hyperkit
  501  2028  2026   0  4:43PM ??         7:02.64 com.docker.vpnkit --ethernet fd:3 --port vpnkit.port.sock --port hyperkit://:62373/./vms/0 --diagnostics fd:4 --pcap fd:5 --vsock-path vms/0/connect --host-names host.docker.internal,docker.for.mac.host.internal,docker.for.mac.localhost --gateway-names gateway.docker.internal,docker.for.mac.gateway.internal,docker.for.mac.http.internal --vm-names docker-for-desktop --listen-backlog 32 --mtu 1500 --allowed-bind-addresses 0.0.0.0 --http /Users/davidcelis/Library/Group Containers/group.com.docker/http_proxy.json --dhcp /Users/davidcelis/Library/Group Containers/group.com.docker/dhcp.json --port-max-idle-time 300 --max-connections 2000 --gateway-ip 192.168.65.1 --host-ip 192.168.65.2 --lowest-ip 192.168.65.3 --highest-ip 192.168.65.254 --log-destination asl --udpv4-forwards 123:127.0.0.1:51533 --gc-compact-interval 1800
  501  2038  2029   0  4:43PM ??       205:02.20 com.docker.hyperkit -A -u -F vms/0/hyperkit.pid -c 4 -m 2048M -s 0:0,hostbridge -s 31,lpc -s 1:0,virtio-vpnkit,path=vpnkit.eth.sock,uuid=cdfbafc2-e7ee-4c67-a0ef-1550f0d56bd0 -U beb781c8-dc53-43c1-ad42-41eb2c4d8983 -s 2:0,ahci-hd,file:///Users/davidcelis/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2?sync=os&buffered=1,format=qcow,qcow-config=discard=true;compact_after_unmaps=262144;keep_erased=262144;runtime_asserts=false -s 3,virtio-sock,guest_cid=3,path=vms/0,guest_forwards=2376;1525 -s 4,ahci-cd,/Applications/Docker.app/Contents/Resources/linuxkit/docker-for-mac.iso -s 5,ahci-cd,vms/0/config.iso -s 6,ahci-cd,/Applications/Docker.app/Contents/Resources/linuxkit/docker.iso -s 7,virtio-rnd -l com1,autopty=vms/0/tty,asl -f bootrom,/Applications/Docker.app/Contents/Resources/uefi/UEFI.fd,,
  501 58371  1282   0  1:40PM ttys000    0:00.00 rg hyperkit
$
$
$ ps -o vsz,rss -p 2038
     VSZ    RSS
 6904796 2081784
$
$
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$

Based on how hyperkit is being started (-m 2048M) it seems as though the rss isn't unreasonable, as it's a little above 2GB. However, I don't have any containers running. I'd be open to hearing why this is normal, but to me it seems strange that hyperkit would be consuming the full 2GB of real memory without any running containers.

@rn

This comment has been minimized.

Copy link
Member

rn commented Dec 19, 2018

hyperkit has to allocate all the memory for the VM when creating it and then pass it to the hypervisor framework in the macOS kernel. The hypervisor framework then uses this memory to populate the pagetable for the VM. Since the macOS kernel does not know if the pages are used by the VM or not it can't just remove them

@davidcelis

This comment has been minimized.

Copy link

davidcelis commented Dec 19, 2018

Thanks for the explanation, @rn!

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 19, 2018

@rn I’ll keep that command running and update here when I see something strange, and I’d invite everyone else doing the same.

However, there’s still something I’d like to clear...
You say that vsz actually doesn’t matter (which is probably the huge value we see in Activity Monitor, will confirm over the next days that we know which command to use), but according to Google:

RSS is how much memory this process currently has in main memory (RAM). VSZ is how much virtual memory the process has in total. This includes all types of memory, both in RAM and swapped out.

So from an OS point of view, isn’t that the actual memory the process is using? It’s up to the OS then to optimise that (swapping, compression, etc...) but nevertheless, that’s still the whole amount of memory the process is taking. I would expect that value to be limited by my setting, not the amount that actually sits in RAM only.

Am I missing something?

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 20, 2018

@rn So you're saying the limit in docker for mac interface is for rss, that is amount of physical memory? So swap is unconstrained?

If swap is unconstrained by Linux VM that would mean swap is shared between OS X and Linux, right? And OS X by default doesn't have any constraints on swap (called dynamic_pager), right?

So the question is why does Linux OOM killer kill containers if swap is unconstrained? Is it because memory isn't being swapped fast enough?

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 20, 2018

I think I've started to understand why Mac users confuse disk space with RAM so often. To them, memory includes both disk space and resident memory.

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 20, 2018

Ok, it looks like we figured it out:
screen shot 2018-12-20 at 11 31 36 am

VSZ includes VM's RSS, VM's swap space and some unspecified amount of hyperkit overhead, right?

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

@Vanuan there's a generic "Memory" limit and a separate "Swap" limit in docker interface.
Still, if you sum both limits you don't get to the total "Memory" claimed by Activity Monitor (which again, I'm assuming it's vsz, but will try to confirm).
See again my screenshot below:

Memory limit + Swap limit = 2.5GB
But Docker "Memory" (again, vsz?) usage according to Activity Monitor is 3.4GB.
Where is the extra 1GB coming from?

screenshot 2018-12-18 at 14 14 40

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

@Vanuan we posted almost at the same time 😄.

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

Also, one more thing, I don't think processes can actually control how much of their memory is swapped? That's up to the OS.

So what I believe should happen, is that the process/VM should simply ask resources to the OS (Memory and Disk) and the "swap" setting in Docker should be managed internally by the VM on its own Disk space?

So that still doesn't explain the "Memory" value claimed by macOS, it shouldn't really go over the RSS setting in Docker (2GB in my case) and it's up to macOS if those 2GB will stay entirely in memory or will be swapped/compressed.

Does it make any sense?

@rn

This comment has been minimized.

Copy link
Member

rn commented Dec 20, 2018

vsz kinda matters and if it is increasing it might indicate an issue, but rss is more important in the sense that is the actually memory used. Since the complained was that "hyperkit is easting all the RAM" rss matters more. If vsz increases a lot, rapidly or constant, I'd also be worried. But I have seen neither.

I don't know how macOS is handling memory allocated to VMs, ie if it swaps it or not or what it does to pages which have been allocated to the VM

The Memory setting in the UI of docker for Mac basically says allocate xGB of host memory to the VM. The Linux VM will use this memory to run containers. And, I would expect most of that memory to be resident if the VM is running a lot of processes. The "swap" setting has nothing to do with host memory. The Linux VM has a swap partition and this is for swapping inside the VM (nothing to do with macOS)

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

Thanks @rn, I guess this partly confirms what I expressed in my previous comment, unless I'm getting it wrong:

The Memory setting in the UI of docker for Mac basically says allocate xGB of host memory to the VM. The Linux VM will use this memory to run containers. And, I would expect most of that memory to be resident if the VM is running a lot of processes.

So the "Memory" limit in Docker UI is not rss only, it's probably closer to vsz, as the OS will be allocating that memory to the process.
I also understand this memory might be taken entirely shortly after startup, although it would be preferrable to have it taken gradually, but that's another discussion.

The "swap" setting has nothing to do with host memory. The Linux VM has a swap partition and this is for swapping inside the VM (nothing to do with macOS)

Thanks for confirming on this one as well. So the "Swap" setting in Docker UI has nothing to do with macOS swap.

I don't know how macOS is handling memory allocated to VMs, ie if it swaps it or not or what it does to pages which have been allocated to the VM.

I guess this will work like for any other process, when a portion of rss is not actively used and macOS runs out of RAM, it will start swapping some of the rss.

This is all great and makes sense, but it still doesn't explain the 3.4GB value we see on Activity Monitor. That's clearly not rss as the "Real Memory" (as shown in my screenshot) can be exposed and it's lower than that. There's also the "compressed memory" value that should be added to it, that's another macOS optimisation where unused memory is compressed before being swapped, but AFAIK that's still kept in RAM.

Again, I'd invite everyone with this issue to run the command suggested by @rn in his comment

@rn Considering all the points above, are we correct to expect that the vsz (rss + compressed + macOS swap) should stay below the Docker UI memory limit?

@jameswmcnab

This comment has been minimized.

Copy link

jameswmcnab commented Dec 20, 2018

Here is a screenshot showing my Docker for Mac settings plus activity monitor showing memory usage for hyperkit and the suggested command output showing vsz and rss.

This is all with no containers running (if that makes any difference) after starting Docker for Mac from fresh and waiting for the memory usage to stabilise.

screenshot 2018-12-20 at 10 22 47am

Hopefully this helps.

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

I can also confirm that I get similar values to @jameswmcnab when asking ps:

ps -o vsz,rss -p 10267
     VSZ    RSS
 6557864 1394892

That seems like the VSZ is 6.5GB. However that doesn't match with what I see in Activity Monitor, where the com.docker.hyperkit process is currently using 3.13GB of memory.

I think we're all still missing something important from the picture.
The RSS is not a good indication of the overall footprint of a process, as it doesn't include swapping and other types of "memory pressure".
VSZ doesn't really makes sense, that's just too high.
I'd love to see where the "Memory" value from activity monitor is coming from, but I really couldn't find out even after spending several time on it...

@Vanuan

This comment has been minimized.

Copy link

Vanuan commented Dec 20, 2018

It looks like memory reported by activity monitory in "memory" column is some "average" value.

screen shot 2018-12-20 at 5 20 59 pm

And it is consistent with this article:
https://www.switchingtomac.com/tutorials/osx/understanding-memory-pressure-in-os-x-mavericks/

So it's not hyperkit behavior that changed, it's OS X memory usage reporting itself.

So what exactly does this "Memory pressure" tell us about hyperkit memory usage?

@iMacTia

This comment has been minimized.

Copy link

iMacTia commented Dec 20, 2018

@Vanuan That article still doesn't explain what the "Memory" column represents...
I just checked another app that is using 350MB of "Memory" and 62MB of "Real Memory" according to Activity Monitor. If I call ps I get the following:

ps -o vsz,rss -p 1071
     VSZ    RSS
 6450888  70240

So the RSS is consistent for all apps and represents the Real Memory 👍. We got that at least.
VSZ seems abnormally big for every app.
However this app doesn't appear to be using more than 3GB "Memory", but only 300MB.
So there must be some difference between this other app and the hyperkit process?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment