Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to take
effect. Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.

Thanks!
Tom

Best,
Amit

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest file.
I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the instance
memory of 2GB but the heap size allocated to the application was cut in
half and I confirmed this through New Relic app. Also, the first full GC of
the app occurred when the memory of the instance was at 1.3GB. So I am not
quite sure of the description of the MEMORY_LIMIT env variable as described
in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to take
effect. Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.

Thanks!
Tom

Best,
Amit

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest file.
I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the instance
memory of 2GB but the heap size allocated to the application was cut in
half and I confirmed this through New Relic app. Also, the first full GC of
the app occurred when the memory of the instance was at 1.3GB. So I am not
quite sure of the description of the MEMORY_LIMIT env variable as described
in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to take
effect. Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.

Thanks!
Tom

Best,
Amit

This is not a environment variable you can set. To scale down the memory
allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:

https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest file.
I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the instance
memory of 2GB but the heap size allocated to the application was cut in
half and I confirmed this through New Relic app. Also, the first full GC of
the app occurred when the memory of the instance was at 1.3GB. So I am not
quite sure of the description of the MEMORY_LIMIT env variable as described
in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to take
effect. Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.

Thanks!
Tom

Best,
Amit

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the memory
allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:

https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the instance
memory of 2GB but the heap size allocated to the application was cut in
half and I confirmed this through New Relic app. Also, the first full GC of
the app occurred when the memory of the instance was at 1.3GB. So I am not
quite sure of the description of the MEMORY_LIMIT env variable as described
in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to take
effect. Unless I'm mistaken, this too is not diego-specific, and applies
to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get
overwritten. So if you don't set it, it will be set to the container
memory limit. But if you do set it, then the java buildpack can take
advantage of it in the way Sabha explained.

On Wed, Sep 2, 2015 at 5:18 PM, Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:

The MEMORY_LIMIT is used by the java buildpack to configure the various
heap parameters for a java app. This variable value is set to the container
size by default by the Cloud controller when you push the app and JBP uses
that to arrive at heap during staging.

What you have done is making the buildpack work with a lower memory
threshold even though the app itself is allowed a higher limit.

Tweak the MEMORY_LIMIT variable only when you are using JavaBP and want
to really have some additional native memory headroom to grow (due to
native memory usage or safety concerns) or to limit heap from utilizing the
full container memory size.

As Amit mentioned, always use cf scale option to change the memory or
instance count for the app container.

-Sabha

On Wed, Sep 2, 2015 at 4:17 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the
memory allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:

https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the instance
memory of 2GB but the heap size allocated to the application was cut in
half and I confirmed this through New Relic app. Also, the first full GC of
the app occurred when the memory of the instance was at 1.3GB. So I am not
quite sure of the description of the MEMORY_LIMIT env variable as described
in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf apps
indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to
take effect. Unless I'm mistaken, this too is not diego-specific, and
applies to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

Thanks for the clarification Sabha and Amit. We are using JavaBP and our
usecase is to have additional native memory headroom for the app. One
option is to tweak the open_jdk.yml file in the JavaBP to give more native
memory and reduce the heap in that process or to set this MEMORY_LIMIT env
variable. We are going with setting the MEMORY_LIMIT option.

Regards,
Siva

On Wed, Sep 2, 2015 at 5:35 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get
overwritten. So if you don't set it, it will be set to the container
memory limit. But if you do set it, then the java buildpack can take
advantage of it in the way Sabha explained.

On Wed, Sep 2, 2015 at 5:18 PM, Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:

The MEMORY_LIMIT is used by the java buildpack to configure the various
heap parameters for a java app. This variable value is set to the container
size by default by the Cloud controller when you push the app and JBP uses
that to arrive at heap during staging.

What you have done is making the buildpack work with a lower memory
threshold even though the app itself is allowed a higher limit.

Tweak the MEMORY_LIMIT variable only when you are using JavaBP and want
to really have some additional native memory headroom to grow (due to
native memory usage or safety concerns) or to limit heap from utilizing the
full container memory size.

As Amit mentioned, always use cf scale option to change the memory or
instance count for the app container.

-Sabha

On Wed, Sep 2, 2015 at 4:17 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the
memory allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:

https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the
instance memory of 2GB but the heap size allocated to the application was
cut in half and I confirmed this through New Relic app. Also, the first
full GC of the app occurred when the memory of the instance was at 1.3GB.
So I am not quite sure of the description of the MEMORY_LIMIT env variable
as described in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf
apps indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to
take effect. Unless I'm mistaken, this too is not diego-specific, and
applies to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

--
http://www.twitter.com/sivabalans

Tweaking the buildpack is less dynamic, and every time you want to make a
change you will have to tweak again, create the new buildpack, and upload
it to the CC. Moreover, maintaining your own fork of the buildpack adds
overhead when you need to consume important changes from the standard
buildpack, such as security updates.

On Wed, Sep 2, 2015 at 8:34 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the clarification Sabha and Amit. We are using JavaBP and our
usecase is to have additional native memory headroom for the app. One
option is to tweak the open_jdk.yml file in the JavaBP to give more native
memory and reduce the heap in that process or to set this MEMORY_LIMIT env
variable. We are going with setting the MEMORY_LIMIT option.

Regards,
Siva

On Wed, Sep 2, 2015 at 5:35 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get
overwritten. So if you don't set it, it will be set to the container
memory limit. But if you do set it, then the java buildpack can take
advantage of it in the way Sabha explained.

On Wed, Sep 2, 2015 at 5:18 PM, Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:

The MEMORY_LIMIT is used by the java buildpack to configure the various
heap parameters for a java app. This variable value is set to the container
size by default by the Cloud controller when you push the app and JBP uses
that to arrive at heap during staging.

What you have done is making the buildpack work with a lower memory
threshold even though the app itself is allowed a higher limit.

Tweak the MEMORY_LIMIT variable only when you are using JavaBP and want
to really have some additional native memory headroom to grow (due to
native memory usage or safety concerns) or to limit heap from utilizing the
full container memory size.

As Amit mentioned, always use cf scale option to change the memory or
instance count for the app container.

-Sabha

On Wed, Sep 2, 2015 at 4:17 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the
memory allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:


https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com>
wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the
instance memory of 2GB but the heap size allocated to the application was
cut in half and I confirmed this through New Relic app. Also, the first
full GC of the app occurred when the memory of the instance was at 1.3GB.
So I am not quite sure of the description of the MEMORY_LIMIT env variable
as described in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf
apps indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to
take effect. Unless I'm mistaken, this too is not diego-specific, and
applies to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

--
http://www.twitter.com/sivabalans

Tweaking the buildpack is less dynamic, and every time you want to make a
change you will have to tweak again, create the new buildpack, and upload
it to the CC. Moreover, maintaining your own fork of the buildpack adds
overhead when you need to consume important changes from the standard
buildpack, such as security updates.

On Wed, Sep 2, 2015 at 8:34 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the clarification Sabha and Amit. We are using JavaBP and our
usecase is to have additional native memory headroom for the app. One
option is to tweak the open_jdk.yml file in the JavaBP to give more native
memory and reduce the heap in that process or to set this MEMORY_LIMIT env
variable. We are going with setting the MEMORY_LIMIT option.

Regards,
Siva

On Wed, Sep 2, 2015 at 5:35 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get
overwritten. So if you don't set it, it will be set to the container
memory limit. But if you do set it, then the java buildpack can take
advantage of it in the way Sabha explained.

On Wed, Sep 2, 2015 at 5:18 PM, Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:

The MEMORY_LIMIT is used by the java buildpack to configure the various
heap parameters for a java app. This variable value is set to the container
size by default by the Cloud controller when you push the app and JBP uses
that to arrive at heap during staging.

What you have done is making the buildpack work with a lower memory
threshold even though the app itself is allowed a higher limit.

Tweak the MEMORY_LIMIT variable only when you are using JavaBP and want
to really have some additional native memory headroom to grow (due to
native memory usage or safety concerns) or to limit heap from utilizing the
full container memory size.

As Amit mentioned, always use cf scale option to change the memory or
instance count for the app container.

-Sabha

On Wed, Sep 2, 2015 at 4:17 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the
memory allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:


https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com>
wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the
instance memory of 2GB but the heap size allocated to the application was
cut in half and I confirmed this through New Relic app. Also, the first
full GC of the app occurred when the memory of the instance was at 1.3GB.
So I am not quite sure of the description of the MEMORY_LIMIT env variable
as described in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

What is the default memory size of an app deployed in diego? cf
apps indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to
take effect. Unless I'm mistaken, this too is not diego-specific, and
applies to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

--
http://www.twitter.com/sivabalans

To add more native memory to the JVM provisioned by the buildpack, you
need to change the memory heuristics of the algorithm that generates the
JVM -X memory settings. see
https://github.com/pivotalservices/citigroup/blob/master/java-buildpack/docs/jre-open_jdk_jre.md

One way to increase the amount of native memory and decrease the memory
allocated to the JVM heap is by setting the following env variable

cf set-env spring-music JBP_CONFIG_OPEN_JDK_JRE '[memory_heuristics:
{heap: 65, metaspace: 20}, memory_sizes: {metaspace: 256m..}]'

Here we are changing the increasing the allocation of metaspace from its
default 64m to 256m in JDK 1.8.
This will give more headroom to the native memory. This is an alternative
to setting the MEMORY_LIMIT variable.

-cheers,
Rohit Kelapure


On Wed, Sep 2, 2015 at 8:47 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tweaking the buildpack is less dynamic, and every time you want to make a
change you will have to tweak again, create the new buildpack, and upload
it to the CC. Moreover, maintaining your own fork of the buildpack adds
overhead when you need to consume important changes from the standard
buildpack, such as security updates.

On Wed, Sep 2, 2015 at 8:34 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the clarification Sabha and Amit. We are using JavaBP and our
usecase is to have additional native memory headroom for the app. One
option is to tweak the open_jdk.yml file in the JavaBP to give more native
memory and reduce the heap in that process or to set this MEMORY_LIMIT env
variable. We are going with setting the MEMORY_LIMIT option.

Regards,
Siva

On Wed, Sep 2, 2015 at 5:35 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get
overwritten. So if you don't set it, it will be set to the container
memory limit. But if you do set it, then the java buildpack can take
advantage of it in the way Sabha explained.

On Wed, Sep 2, 2015 at 5:18 PM, Sabha Parameswaran <sabhap(a)pivotal.io>
wrote:

The MEMORY_LIMIT is used by the java buildpack to configure the
various heap parameters for a java app. This variable value is set to the
container size by default by the Cloud controller when you push the app and
JBP uses that to arrive at heap during staging.

What you have done is making the buildpack work with a lower memory
threshold even though the app itself is allowed a higher limit.

Tweak the MEMORY_LIMIT variable only when you are using JavaBP and
want to really have some additional native memory headroom to grow (due to
native memory usage or safety concerns) or to limit heap from utilizing the
full container memory size.

As Amit mentioned, always use cf scale option to change the memory or
instance count for the app container.

-Sabha

On Wed, Sep 2, 2015 at 4:17 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Thanks for the response. But what I am observing is, by setting
MEMORY_LIMIT as an environment variable does take effect when I restage the
app and it reduces the memory allocated to the java app(not the container
itself) to the amount set in the variable. The app is restarted with the
same heap ratio as dictated by the buildpack but assumes the max memory
available to it is now 1GB instead of 2GB. The container still had 2GB
allocated to it and I understand that will be reduced only if I use the "cf
scale" command.
Is this the expected behavior?

Thanks
Siva

On Wed, Sep 2, 2015 at 3:55 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

This is not a environment variable you can set. To scale down the
memory allocated to your instances, do

cf scale <app-name> -m 1024M

This will tell Warden/Garden to allocate that much memory to your
containers and kill them if they exceed it. The documentation is saying
that the processes running inside the container can learn about the memory
limit applied to them via the environment variable MEMORY_LIMIT. If you
try to set this variable via set-env, it will get overwritten by the value
set by "cf scale". Again, the MEMORY_LIMIT environment variable doesn't do
anything, it's just information passed into the container via the process's
environment. To actually constrain the memory, use "cf scale" or set it in
your manifest file:


https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory

On Wed, Sep 2, 2015 at 3:08 PM, Siva Balan <mailsiva(a)gmail.com>
wrote:

We are not using Diego and we are on CF version 211.
I had my application started with 2GB of memory set in the manifest
file. I then ran the following command and restaged the app:
cf set-env <app-name> MEMORY_LIMIT 1024m
Then when I ran "cf app <app-name>", it was still showing the
instance memory of 2GB but the heap size allocated to the application was
cut in half and I confirmed this through New Relic app. Also, the first
full GC of the app occurred when the memory of the instance was at 1.3GB.
So I am not quite sure of the description of the MEMORY_LIMIT env variable
as described in
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#memory.
I did not see my application restart when the instance memory went over
1GB.
Any ideas about this behavior?

Thanks.
Siva

On Tue, Sep 1, 2015 at 7:40 PM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Responses inline.

On Tue, Sep 1, 2015 at 7:13 PM, Tom Sherrod <tom.sherrod(a)gmail.com

wrote:

What is the default memory size of an app deployed in diego? cf
apps indicate 1GB.

Yes. This isn't a diego thing, this is a CC thing.

cf set-env doesn't appear to be getting the environment variable
information to the running container. Is cf set-env the correct method to
use?

You likely need to restage the application for ENV var changes to
take effect. Unless I'm mistaken, this too is not diego-specific, and
applies to DEA containers as well.

Thanks!
Tom

Best,
Amit

--
http://www.twitter.com/sivabalans

--
http://www.twitter.com/sivabalans

--
Pivotal CF Architect
rkelapure(a)pivotal.io
cell: 9197242524