docker / for-mac

Bug reports for Docker Desktop for Mac
https://www.docker.com/products/docker#/mac
2.43k stars 118 forks source link

Memory Leakage com.docker.hyperkit #3232

Closed Sebastianbrg closed 5 years ago

Sebastianbrg commented 6 years ago

NOTES TO FUTURE READERS OF THIS THREAD. PLEASE READ THE WHOLE THREAD BEFORE REPLYING. IN PARTICULAR, PLEASE UNDERSTAND: 1) There is a bug in MacOS that it reports twice the amount of memory actually allocated. 2) It is normal that all the memory has to be reserved up front before any containers are running, because of the way that virtualisation works in MacOS Hypervisor.framework.

See https://docs.google.com/document/d/17ZiQC1Tp9iH320K-uqVLyiJmk4DHJ3c4zgQetJiKYQM/edit?usp=sharing for a detailed investigation on this.

-- Stephen Turner


Expected behavior

No memory leakage.

Actual behavior

Memory leakage.

Information

Diagnostic logs


Docker for Mac: Version 18.06.1-ce-mac73 (26764)
Mibeon commented 5 years ago

Is there any chance to get this ram eating bug fixed by docker?????

I don't understand that. So many people has this issue and there's no response from docker. Guys, that is not a way to handle bugs. Dissatisfaction is big.

@users has anyone any ideas about this big trouble???? Most of us has 16GB ram (maybe someone 32GB or even less than 16 GB) and all other tools are also taking lots of ram. So we try to keep the ram usage down. And for no containers running everything about 1 GB ram for docker is unacceptable.

We need a solution for that f*****g (sorry) issue.

Peace.

kalexmills commented 5 years ago

Based on the comments left in this issue it is not clear to me that the issue is not actually with one of the myriad different tools folks are using to measure their memory usage.

Rather than posting screenshots or copying output of whatever tool we are using to measure memory this week, maybe we could all utilize the Diagnostics tool that Docker has built into their product, so that their devs can use the information they have carefully curated in a format they already work with on a daily basis.

EDIT: On another note, the source for the hyperkit process which seems to be eating up so much memory actually lives in a totally different repo, so I wouldn't be surprised if the Docker team has decided to ignore the particular incarnation of the issue represented by this thread.

marcotoci commented 5 years ago

Based on the comments left in this issue it is not clear to me that the issue is not actually with one of the myriad different tools folks are using to measure their memory usage.

"myriad of tools"????? I only see screenshot of mac's "activity monitor", here

(And yes, I have the same problem, Docker is taking 3.7 GB with no container running, and I only have 8GB in my mac. Completely unusable.)

jeanpauldejong commented 5 years ago

Based on the comments left in this issue it is not clear to me that the issue is not actually with one of the myriad different tools folks are using to measure their memory usage.

Rather than posting screenshots or copying output of whatever tool we are using to measure memory this week, maybe we could all utilize the Diagnostics tool that Docker has built into their product, so that their devs can use the information they have carefully curated in a format they already work with on a daily basis.

EDIT: On another note, the source for the hyperkit process which seems to be eating up so much memory actually lives in a totally different repo, so I wouldn't be surprised if the Docker team has decided to ignore the particular incarnation of the issue represented by this thread.

I'd love for the issue to be with the tools measuring it. But as @marcotoci said that is highly unlikely. And as @Mibeon said, it would be really good if the docker team actually responds and acknowledges as this is a big issue.

@kalexmills if it is related to another repo then great, but again the docker team need to engage manage that. They were quick to engage on the other issue raised for this topic to shut it down, so why the silence now?

jhaagmans commented 5 years ago

@jhaagmans

Your point about as resident memory vs virtual memory is a distinction without a difference. My operating system sees it as the highest consumer of memory, and also the highest consumer of battery power.

I was referencing the comment bij @ijc in #178 where he tells us to disregard the memory use reported by apple's Activity monitor because the resident memory is what you should look at and noting that my RSS is actually much higher than you would expect from an idle docker setup. Also, I disagree with your statement, there is a huge difference between resident and virtual memory. However, it seems to be a relevant distinction to only a few people (maybe running other software versions).

The rest of us are actually having issues running docker for mac to the point where a large number of us are currently unable to use it (including you, it seems) on the latest versions of docker and MacOS.

kalexmills commented 5 years ago

Here is the related ticket on the hyperkit repo, in case anyone wants to file helpful info there https://github.com/moby/hyperkit/issues/231

@marcotoci screenshots are great, but my point was that diagnostic IDs are going to be more helpful. Comments that only include a screenshot won't help the devs to debug and potentially resolve the problem. As @jhaagmans mentions above, Activity Monitor doesn't track resident memory. Even if it did, just knowing that Docker is taking up a bunch of resident memory on your box doesn't help to diagnose why that might be the case in your environment.

I agree with @jhaagmans, big difference between resident and virtual memory. If it is relevant to Docker, then I hope that the diagnostics tool would measure both.

emhagman commented 5 years ago

@kalexmills I think people are just extremely frustrated as people use Docker for work and it is clear there is an issue, whether it was to do with real vs virtual memory or whatever. Your post just seemed to dismiss the issue all together in the first paragraph.

Based on the comments left in this issue it is not clear to me that the issue is not actually with one of the myriad different tools folks are using to measure their memory usage.

While you're correct, that the Diagnostic ID is better to use, that first paragraph just wasn't really useful and I can see why it would piss some people off...

I agree, the Diagnostic ID will probably help, but I for one didn't even know about that feature! I'll post mine in the hyperkit issue.

octavioamu commented 5 years ago

just adding my id here since is an already know issue CFD3E0AF-92AC-4F15-BBA4-C9DE2AED25CD/20181101230018 Docker version 18.06.1-ce, build e68fc7a

MyPublicGitHubAcct commented 5 years ago

Here's another... iMac, Mojave Docker Version 18.06.1-ce-mac73 (26764) 74B55C11-C1ED-4B72-BBE5-81984B861236/20181102173243

ybert commented 5 years ago

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

wilsontgh commented 5 years ago

Here too..

MacBook Pro 12" Late-2016, Mojave Docker Version 18.06.1-ce-mac73 (26764) 3.6GB of RAM with no containers (I only have 8GB RAM)

Diagnostic ID: E524A6C3-D8F9-42AF-A9A8-4E4E1CA47498/20181107032842

lauramosher commented 5 years ago

Definitely seeing some weirdness that may be relevant to this thread:

MacBook Pro 13" 2018, Mojave 10.14 Docker for Mac Commputer Edition — Version 18.06.1-ce-mac73 (26764)

com.docker.hyper kit sits consistently at ~300% CPU and ~3.6GB of RAM usage.

Diagnostic ID: 762540E6-26D7-4980-B3C6-B7D5B2EE1B45/20181107141322

avxkim commented 5 years ago

And now they will fix their enterprise edition Docker first, but community edition would get the fix after a half year, lol

Sacharified commented 5 years ago

Same issue here, huge memory usage with no containers running since upgrading to Mojave. Used to idle at ~1GB

screenshot 2018-11-07 at 14 48 01

Macbook Pro 13" 2017, MacOS Mojave 10.14 Docker Community Edition Version 18.06.1-ce-mac73 (26764) Channel: stable b0f14f1dac

Diagnostic ID: C3837B6F-712C-4C83-A396-9D52339D50F8/20181107144152

chaseWillden commented 5 years ago

I'm getting it too

bravecorvus commented 5 years ago

bump

heather7532 commented 5 years ago

same here

sorenmh commented 5 years ago

Same issue here. Containers using ~300MB, hyperkit eats 3.7GB.

activity monitor and docker stats
hdnha11 commented 5 years ago

Same issue here. My Diagnostic ID: DDC358E4-C9D2-40CC-93B6-3C756B6B588C/20181114080221

screen shot 2018-11-14 at 3 04 58 pm
arsirantala commented 5 years ago

Same issue. My diagnostic ID: FAA66E6C-A7EC-4ABF-A2BB-37CA27FE2F16/20181115093627

MacBook Pro (2017) and Mojave.

jhaagmans commented 5 years ago

32544309-FFE8-4A22-8631-E0539CFD14E5/20181115105433

Still a huge issue for us.

arsirantala commented 5 years ago

By installing the edge version (and by setting no experimental settings (with debug:false as well), and by setting memory and swap to mimimum the memory consumption dropped in my case from 9.4 GB to 6.7 GB.

lrhacker commented 5 years ago

I'm seeing a similar issue. With no containers running, the com.docker.hyperkit process is sitting at 7.93GB of RAM.

Diagnostic ID: 729A62AC-3D2A-47AA-A4BE-7C88EF6EFCD2/20181116201718 MacBook Pro (Mid 2015) Mojave Docker Community Edition, Version 18.06.1-ce-mac73 (26764)

dunera commented 5 years ago

same issue image

fubarhouse commented 5 years ago

Subscribing - also affected and this should be fixed.

edit: I usually configure with ~6-8 GB RAM, but I've scaled back to 2-3 because I run out of RAM literally. There are some applications I literally cannot build and develop locally because of this.

yakubiw commented 5 years ago

screen shot 2018-11-22 at 7 04 53 pm

Same issue, idle with no containers - 16GBs of RAM on Mojave

lyz1990 commented 5 years ago

Mojave, no containers, same issue

1

eexbee commented 5 years ago

same issue on Mojave

iMacTia commented 5 years ago

Same issue on Mojave, using 4GB of RAM used with no containers running

yanosh-igor commented 5 years ago

same issue on Mojave. 3Gb used.

andrewalf commented 5 years ago

Please fix memory and cpu usage, empty docker eats ram and battery. Macos Mojave too :(

iMacTia commented 5 years ago

Updating to the latest version solves nothing (probably because the engine is the same)

Version 2.0.0.0-mac78 (28905)

bravecorvus commented 5 years ago

bump bump

markshust commented 5 years ago

i can confirm that increasing the swap mem in D4M increases the memory usage reported within activity monitor by a non-relational amount.

Version 2.0.0.0-mac78 (28905)

robotdan commented 5 years ago

As mentioned in issue #178 , this may be a hyperkit issue? https://github.com/moby/hyperkit/issues/231

jhaagmans commented 5 years ago

It probably is @robotdan, but their policy is that we should report bugs downstream.

jessechahal commented 5 years ago

I think I have you guys beat with mem usage on my 2014 macbook pro image image believe it or not this is actually a huge improvement over 30mins ago... It was at 24GB + of swap usage earlier.... My current configuration for docker is image

My version of docker for mac image

EduardRakov commented 5 years ago

I used to have the same issue on mojave, so I had to downgrade back to High Sierra and now everything is ok. :(

shmink commented 5 years ago

@EduardRakov Interesting. What were your Mojave vs High Sierra memory uses at? I don't suppose you did a diagnostic upload for both OS?

EduardRakov commented 5 years ago

@shmink On Mojave hyperkit used ~5.95Gb (no containers, limit 2Gb of RAM for Docker), after downgrade to High Sierra it takes now ~1.9Gb (4 containers, limit 2Gb of RAM for Docker). Btw, before I update my High Sierra to Mojave it worked fine as now, so I faced this issue only on Mojave. MacBook Pro (Retina, 15-inch, Mid 2014) 16Gb RAM

kaspergrubbe commented 5 years ago

I am still on Sierra (the release before High Sierra that @EduardRakov is running), and I am seeing the same issues as everyone else in this thread.

ezy commented 5 years ago

I'm on Mojave running Docker 2.0.0.0-mac81 (29211) - same issue

ybod commented 5 years ago

I'm also on Mojave running Docker Version 2.0.0.0-mac82 (29268) and have the same issue (3.77 Gb)

shmink commented 5 years ago

It would be nice if someone from docker could drop in to let us know they're on the case or something...

avxkim commented 5 years ago

I just lowered ram and swap dedicated to docker (to minimum).

robabby commented 5 years ago

Upgraded to Mojave over the weekend and started experiencing this issue today. Really makes work a chore. Would love to avoid downgrading.

williamconnolly commented 5 years ago

Same issue on Mojave as well, version 2.0.0.0-mac81 (29211). I've actually downgraded, and am still experiencing the same memory usage on version 18.06.0-ce-mac70! I exported all containers and imported them again, after uninstalling the Docker app itself.

I did not muck around with any ~/Library or cache directories, however. So it seems to me that downgrading has no effect, unfortunately.

The memory usage seems to follow a pattern: max memory + max swap + all container's actual usage put together. It's as if Docker reserves all the space, then doesn't actually use any of it.

d1820 commented 5 years ago

same issue, with was right after restarted docker...

1gb swap 3gb max

image

image

image

laszlolaszlo commented 5 years ago

I have the same issue. macOS 10.14.2 Docker version 18.09.0, build 4d60db4 Experimental function: Off CPUs: 4 Memory: 4GB SWAP: 1GB

pamtrak06 commented 5 years ago

I upgrade to Mojave and then I have the same issue (3 gb of memory usage !). macOS 10.14.2 - Docker version 18.03.0, build 4d60db4

I solve it by removing docker for Mac and install docker toolbox