Skip to content
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

RAM/memory allocation with LCOW/windows containers? #1357

Closed
rlpowell opened this issue Nov 24, 2017 · 34 comments
Closed

RAM/memory allocation with LCOW/windows containers? #1357

rlpowell opened this issue Nov 24, 2017 · 34 comments

Comments

@rlpowell
Copy link

Expected behavior

I expected LCOW mode to give my containers access to all of my Windows' box's RAM.

Actual behavior

The RAM appears to be capped to 1G, per /proc/meminfo

Also, there is no longer anything in the Docker Settings to change it.

Information

B20175AC-8170-4955-8409-C1846A7F82E7/2017-11-24_12-20-54

C:\Users\rlpowell>systeminfo | findstr em
System Boot Time:          2017-11-24, 11:51:51
System Manufacturer:       LENOVO
System Model:              20AQCTO1WW
System Type:               x64-based PC
System Directory:          C:\WINDOWS\system32
System Locale:             en-us;English (United States)
Total Physical Memory:     7,901 MB
Available Physical Memory: 4,486 MB
Virtual Memory: Max Size:  17,071 MB
Virtual Memory: Available: 7,411 MB
Virtual Memory: In Use:    9,660 MB
Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.

C:\Users\rlpowell>docker run -it rlpowell/shell head /proc/meminfo
MemTotal:         995516 kB
MemFree:          828124 kB
MemAvailable:     763408 kB
Buffers:            2668 kB
Cached:            20488 kB
SwapCached:            0 kB
Active:            15280 kB
Inactive:          10580 kB
Active(anon):      12572 kB
Inactive(anon):    10572 kB

C:\Users\rlpowell>docker run -it rlpowell/shell free -g
              total        used        free      shared  buff/cache   available
Mem:              0           0           0           0           0           0
Swap:             0           0           0

C:\Users\rlpowell>docker run -it rlpowell/shell free -m
              total        used        free      shared  buff/cache   available
Mem:            972         113         808          20          50         745
Swap:             0           0           0

Steps to reproduce the behavior

Run any linux contain in Windows Container mode.

@rlpowell
Copy link
Author

This appears, at first glance, to be equivalent to microsoft/opengcs#145 , which is linked from moby/moby#33850 .

(Which is unfortunate, as several of my compilation steps require 2G just to show up, so I can't test LCOW at all ;_; )

@liquidboy
Copy link

liquidboy commented Jan 30, 2018

I encountered this limitation when trying to use Node in a LCOW container where node was trying to go above 2GB and hitting an "out of memory exception". I was using Node in a LCOW as a build agent. Please let us increase this hard limit above 2GB..

This is the snippet of the "sh" script we run that shows us calling Node saying its ok to go up to 3GB (-max-old-space-size) . This is common in build agents building complex repositories.. [the example i use is trying to build the ANGULAR repository..

NGC="node --max-old-space-size=3000 pwd/dist/tools/@angular/compiler-cli/src/main"

Below is the Node error i got showing the "process out of memory" in Node

<--- Last few GCs --->

[818:0x25e0a70] 21353 ms: Scavenge 685.4 (727.1) -> 673.7 (729.1) MB, 10.5 / 0.0 ms allocation failure
[818:0x25e0a70] 21411 ms: Scavenge 688.2 (730.1) -> 676.6 (732.1) MB, 9.9 / 0.0 ms allocation failure
[818:0x25e0a70] 21515 ms: Scavenge 690.9 (733.1) -> 679.2 (735.1) MB, 10.1 / 0.0 ms allocation failure
[818:0x25e0a70] 21580 ms: Scavenge 693.4 (735.6) -> 682.6 (738.1) MB, 11.7 / 0.0 ms allocation failure

<--- JS stacktrace --->
Cannot get stack trace in GC.
FATAL ERROR: NewSpace::Rebalance Allocation failed - process out of memory
1: node::Abort() [node]
2: 0x121a2cc [node]
3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
5: 0xaea93b [node]
6: v8::internal::MarkCompactCollector::Evacuate() [node]
7: v8::internal::MarkCompactCollector::CollectGarbage() [node]
8: v8::internal::Heap::MarkCompact() [node]
9: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
10: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
11: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
12: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
13: 0x10eea048463d
./build.sh: line 403: 818 Aborted $TSC -p ${TSCONFIG}

@fizxmike
Copy link

Any update on this? I'm launching a java app in a container and it freaks out that it "sees" only ~900 MB available and dies (of course things work find on linux docker host).

The closest answer I got was in this cryptic post mentioning JOB_OBJECT_LIMIT_JOB_MEMORY, but I don't know how to implement, my Windows Foo is very weak.

FYI, I'm running windows server 1709 and docker (17.10.0-ee-preview-3)

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@nerumo
Copy link

nerumo commented Jul 31, 2018

/remove-lifecycle stale

@bloodybeet
Copy link

Could someone please provide an estimate for when we can run LCOW with +2GB RAM? We would very much like to use LCOW mostly to be able to bind to localhost whilst still using linux containers (or has anyone found out how to do that with the MobyLinux VM?)

@icenine457
Copy link

Also looking for this issue to be fixed, as I'm containerizing a ASP.Net application using SQL Server, which requires 2 GB RAM to run.

@greyphoenix
Copy link

+1 for this.

@pccruiser
Copy link

+4096 for this!

Same situation. Want to use SQL Linux in a container while also testing asp.net application that requires windows. No reason this can't be done other than an arbitrary memory limit! I have 32GB of RAM so that is very frustrating!!

@jimpriest
Copy link

Just ran into this myself. Not enough memory.

@nayala0791
Copy link

/remove-lifecycle stale

@KwalityKoder
Copy link

This is a massive blocker for us. We have a Linux container running WildFly that needs (and gets 3Gb) when Docker for Windows is running in Linux Container mode.
Switching Docker for Windows to Windows Container mode, I can see (using cat /proc/meminfo) that the same container is only given less than 1Gb of memory, and WildFly consequently dies.

@bloodybeet
Copy link

bloodybeet commented Nov 21, 2018 via email

@KwalityKoder
Copy link

Can someone from the docker development team, please advise:
a) When this issue is scheduled to be fixed?
b) That there is absolutely no workaround?

@SteveTownsendBway
Copy link

SteveTownsendBway commented Nov 22, 2018

My experience is that this can be worked around by building your own dockerd using the moby/moby master branch merged (locally) into the pull here moby/moby#37296 that fixes this issue. The merge to master is pending but I could not wait. I am now able to docker run --memory 6144m for example.
In my case this was needed to get Linux SQL Server up and running: needs 2GB, but without fix, hard limit is 1GB.

@KwalityKoder
Copy link

@SteveTownsendBway We plan to use docker-compose to run our Linux containers via LCOW.
Will moby/moby#37296 fix this issue for docker-compose too?
Will the docker-compose mem_reservation: flag suddenly start working again? Or will a new PR be required for docker-compose?

@DecisionSystems
Copy link

Problem for us as well. Trying to run .Net Framework container alongside Linux container on Windows 10 Build 17134 and latest Docker with LCOW enabled. Let a guy experiment please!

@SteveTownsendBway
Copy link

SteveTownsendBway commented Nov 22, 2018 via email

@qbikez
Copy link

qbikez commented Nov 24, 2018

Will the docker-compose mem_reservation: flag suddenly start working again? Or will a new PR be required for docker-compose?

@KwalityKoder After applying moby/moby#37296, mem_limit in docker-compose works. mem_reservation still gives an error: "invalid option: Windows does not support MemoryReservation".

Iristyle added a commit to Iristyle/puppet-agent that referenced this issue Dec 5, 2018
 - There are 2 current issues with building the Alpine based agent
   container in Azure:

   - LCOW doesn't support memory limits on containers and gcc currently
     gets an OOM (out of memory) error during compilation. This issue is
     documented in a few places, notably:

		 docker/for-win#1357
     moby/moby#37296

   - Multi-stage builds aren't fully supported in LCOW, though some
     portions are working. Of note, the following issue is still open:

		 microsoft/opengcs#156

     And other issues have been resolved:

		 microsoft/opengcs#168
     microsoft/opengcs#169

     The LCOW "epic" should eventually be updated when support is complete:

     moby/moby#33850

     It's difficult at this time to tell if the current multi-stage
     support is adequate given the blocking memory problem. It may very
     well be enough.

 - For now, disable the Azure pipelines steps for building until the
   point at which they can be re-enabled.
Iristyle added a commit to Iristyle/puppet-agent that referenced this issue Dec 5, 2018
 - There are 2 current issues with building the Alpine based agent
   container in Azure:

   - LCOW doesn't support memory limits on containers and gcc currently
     gets an OOM (out of memory) error during compilation. This issue is
     documented in a few places, notably:

		 docker/for-win#1357
     moby/moby#37296

   - Multi-stage builds aren't fully supported in LCOW, though some
     portions are working. Of note, the following issue is still open:

		 microsoft/opengcs#156

     And other issues have been resolved:

		 microsoft/opengcs#168
     microsoft/opengcs#169

     The LCOW "epic" should eventually be updated when support is complete:

     moby/moby#33850

     It's difficult at this time to tell if the current multi-stage
     support is adequate given the blocking memory problem. It may very
     well be enough.

 - For now, disable the Azure pipelines steps for building until the
   point at which they can be re-enabled.
@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@jimpriest
Copy link

/remove-lifecycle stale

@sreejith-mq
Copy link

As other people have mentioned, this is pretty much covered under moby/moby#37296. According to the latest comment on that thread, the feature is now part of docker nightly builds. However no ETA on when this will be part of edge/stable of CE or EE

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@dmastag
Copy link

dmastag commented Jun 10, 2019

/remove-lifecycle stale

@temuera
Copy link

temuera commented Jun 21, 2019

/remove-lifecycle stale

@idontsov
Copy link

Any update?

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@idontsov
Copy link

idontsov commented Oct 8, 2019

/remove-lifecycle stale

@idontsov
Copy link

idontsov commented Oct 8, 2019

/lifecycle frozen

@AAATechGuy
Copy link

AAATechGuy commented Apr 17, 2021

faced similar issue today, when trying to spawn up linux (sql) image on LCOW, via docker-desktop.
image

@gauravshegokar
Copy link

/remove-lifecycle frozen

@gauravshegokar
Copy link

/remove-lifecycle stale

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Aug 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests