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
Building takes TOO much memory and fails #11852
Comments
have you tried exploiting memory locality via something like taskset make? |
I am seeing a similar issue when building kubernetes for mesos. My VM has 2.7GB of memory and 4 cores and go is Previously, I was using Ubuntu 14.10 64-bit and was able to work around the problem using However, after upgrading to Ubuntu 15.04 64-bit,
|
My VM is with 1 CPU will it make any difference to increase the CPUs? As far as I understand there is nothing I can do? I just have to increase the memory? |
I'm very open to things that make the build faster. From my initial looks
On Sat, Jul 25, 2015 at 6:10 AM, Anastasis Andronidis <
|
Should I close this issue? |
We are willing to take PRs that reduce this requirement, but this memory requirement isn't so big that we'll prioritize it. |
What's the recommended amount of memory needed to compile? I am still finding it to be a hit and miss with 4GB. |
Also failing here with 4GB. Have locally reverted the swagger-ui update in |
@sttts: I was able to get it to compile with |
@nikhiljindal if it's really the swagger ui we should be able to turn it off with a flag? |
I am seeing the exact same error on an 11GB linux box intermittently running docker version
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 350a636/1.6.0
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 350a636/1.6.0
OS/Arch (server): linux/amd64 This error is new to this week. I did not encounter this error before Friday of last week. Has something gone in to really blow our parallel builds? |
My workaround has been to eliminate some of the KUBE_CLIENT_PLATFORMS during my local development which is letting me reliably build now. |
We merged a new version of swagger-ui which could be leading to this: #10901 |
I can confirm that the break is during the swagger build portion. I had to scale a CI instance from 2GB to 4GB just to complete the build steps in I ran a test on our CI server w/ the original 2GB configuration, and added a build rule to revert 1 level of the merge:
This resulted in a passing build of the kubes components. (note the build failure linked is another issue all together thats unrelated) |
After increasing my VM from 1GB to 4GB, this works for me |
Yeah I also could no longer build on my macbook with a 2GB boot2docker VM. I bumped it up to 3GB:
That got me building again. |
Testing in 256mb increments from 2gb, I've also found that setting the boot2docker vm to have 3gb memory allows building to continue working for me on the current master (ed9975b) when doing Perhaps we can document this somewhere (mac development guide maybe?) as the required memory has increased by at least 1gb? Also noting that building seems to have become much more cpu intensive than when I first built kubernetes (earlier this year) as well, at least in boot2docker. |
There are PRs in flight to make the precommits faster, at least. On Thu, Jul 30, 2015 at 4:15 PM, Benjamin Elder notifications@github.com
|
I am no longer able to perform parallel builds when doing make quick I have had to push my parallel build memory flag to > 12 GB to avoid the So whatever is the root change that caused the issue , it would be good if On Thursday, July 30, 2015, Tim Hockin notifications@github.com wrote:
|
I just had a 3072mb base boot2docker crap out with the same issue. Building |
This just killed my entire workflow, have been battling this all day. Anyone get around it? Edit: I'm on AWS and scaled up to an r3.large memory optomized instance and that seemed to do the trick. But wow, hopefully scaling back down to a t2 won't kill it later |
This is a p1 based on the number of people who've complained |
@nikhiljindal Are we pretty confident that the swagger UI change is what caused this? Is there an easy way to exclude that from dev builds? |
Missed updating swagger/datafile.go while reverting swagger-ui. Doing that in #12547 |
Bumping this back down, since it seems the fire is out now? |
Is this the same error as discussed here? It looks pretty identical.
I'm using a machine with 8GB RAM, although compile isn't getting all of that due to plenty of other processes going on at the same time. It seems to be fixed in the master branch here, that compiles fine, but the 1.0.1 - 1.0.4 versions are dying with that error above for me. Was reported to us at Homebrew in Homebrew/legacy-homebrew#43833. |
I'm running into this problem as well, on a virtualbox ubuntu14.04 3GB RAM vm. It seems to be occuring on branch However, build does work fine on Upping the VM RAM to 4GB (3+GB free on build) fixes issue (as noted in conversation above) |
latest master 683f09c does not build for me in a 5GB RAM, 2 CPU core, freshly restarted Ubuntu VM with
it says that GCC cannot allocate enough memory. |
still an issue.
[edit] could overcome by adding 2GB of swap |
During my most recent experiments, I found that Kubernetes now needs 4.5GB+ to build on osx. #62219 |
4.5G failed for me this morning, so tired of going by small increases, just threw up 8GB and it worked. macOS High Sierra: 10.13.4 (17E202) |
I tried
In other words, it seems that Docker for Mac needs at least 8 GB to be able to somewhat consistently build Kubernetes currently. |
I have 16 GB of ram and my build fails |
having 16 GB of ram != exposing 16 GB to the docker daemon depending on your setup. if you're on docker for mac / windows you'll need to configure it to allow more ram for the VM |
Being able to run Linux builds on Mac is the source of much of the
complexity in the build system. I still think we should just not.
…On Thu, Dec 6, 2018 at 3:12 PM Benjamin Elder ***@***.***> wrote:
having 16 GB of ram != exposing 16 GB to the docker daemon depending on
your setup. if you're on docker for mac / windows you'll need to configure
it to allow more ram for the VM
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11852 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVHbOho7iTcTrQj-GZ4YkVJRQXXRbks5u2aRJgaJpZM4FfkvL>
.
|
the (quick-)release build is a memory hog. if you want to build only certain components you can use
this hardly peaks at 1.5GB for me. also the control plane and other images are already pre-built with each release and available at gcr.io/ - e.g. so unless one wants to re-release k8s i don't see a reason why EDIT: if you want the binaries to include a version. before calling
and then export it in a variable:
|
`make kubelet` also works - everything in `cmd` is promoted to a top-level
make rule :)
…On Fri, Dec 7, 2018 at 10:08 AM Lubomir I. Ivanov ***@***.***> wrote:
the (quick-)release build is a memory hog.
if you want to build only certain components you can use make WHAT:
make WHAT=cmd/kubelet
make WHAT=cmd/kubectl
this hardly peaks at 1.5GB for me.
also the control plane and other images are already pre-built with each
release and available at gcr.io/ - e.g.
gcr.io/google-containers/kube-apiserver.
so unless one wants to re-release k8s i don't see a reason why make
*release should be used.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11852 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVIQV1qmELamQiKgxm-JJNGBUcwwOks5u2q6WgaJpZM4FfkvL>
.
|
you just saved me about 1000 keystrokes a week |
i just have |
This issue would happen even if we told people to use a Linux VM on Mac
explicitly - the developer needs to configure enough RAM on their end.
The builds eat a _lot_ of resources wherever you build.
…On Thu, Dec 6, 2018, 15:16 Tim Hockin ***@***.*** wrote:
Being able to run Linux builds on Mac is the source of much of the
complexity in the build system. I still think we should just not.
On Thu, Dec 6, 2018 at 3:12 PM Benjamin Elder ***@***.***>
wrote:
> having 16 GB of ram != exposing 16 GB to the docker daemon depending on
> your setup. if you're on docker for mac / windows you'll need to
configure
> it to allow more ram for the VM
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#11852 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AFVgVHbOho7iTcTrQj-GZ4YkVJRQXXRbks5u2aRJgaJpZM4FfkvL
>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11852 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4Bq45sVMruPImZpeK0Zb7sGtxiv0Z8ks5u2aU2gaJpZM4FfkvL>
.
|
If someone wants to build k8s enough to boot it but isn't actually cutting
a release, something like this should suffice on a recent branch:
make quick-release-images
make kubelet kubectl kubeadm
The {quick-}release-images targets will let you build images without
building the entire release including tarballs etc. You probably don't need
any of that.
…On Fri, Dec 7, 2018, 10:45 Benjamin Elder ***@***.*** wrote:
This issue would happen even if we told people to use a Linux VM on Mac
explicitly - the developer needs to configure enough RAM on their end.
The builds eat a _lot_ of resources wherever you build.
On Thu, Dec 6, 2018, 15:16 Tim Hockin ***@***.*** wrote:
> Being able to run Linux builds on Mac is the source of much of the
> complexity in the build system. I still think we should just not.
>
> On Thu, Dec 6, 2018 at 3:12 PM Benjamin Elder ***@***.***>
> wrote:
>
> > having 16 GB of ram != exposing 16 GB to the docker daemon depending on
> > your setup. if you're on docker for mac / windows you'll need to
> configure
> > it to allow more ram for the VM
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <
> #11852 (comment)
> >,
> > or mute the thread
> > <
> https://github.com/notifications/unsubscribe-auth/AFVgVHbOho7iTcTrQj-GZ4YkVJRQXXRbks5u2aRJgaJpZM4FfkvL
> >
> > .
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#11852 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AA4Bq45sVMruPImZpeK0Zb7sGtxiv0Z8ks5u2aU2gaJpZM4FfkvL>
> .
>
|
If I try to run
hack/update-swagger-spec.sh
in my vm with less than 2GB of RAM it fails with this error:I found that this file
pkg/ui/data/swagger/datafile.go
for some reason need a lot of memory to be builded. (it is a huge file btw with 48528 lines)Is there anything we can do for that? I find it very difficult to run a VM in my laptop with more that 2GB which actually means that I can't work...
The text was updated successfully, but these errors were encountered: