I'm trying to deploy a Nodejs8, memory intense app on Google App Engine Standard.
This is my app.yaml:
runtime: nodejs8
resources:
cpu: 1
memory_gb: 6
disk_size_gb: 10
This is my deploy command:
gcloud app deploy --project=my-project --version=0-0-12
This is the error I get when I try to access the relevant endpoint of the app:
Exceeded soft memory limit of 128 MB with 182 MB after servicing 0 requests total. Consider setting a larger instance class in app.yaml.
How come the memory_gb param is ignored? What do I need to do in order to enlarge the memory of the instances?
You're attempting to use flexible environment Resource settings into a standard environment app.yaml file, which won't work. Note that in most cases the invalid settings will be silently ignored, so you need to be careful.
For the standard environment you can't explicitly pick individual resources, you can only use the instance_class option in Runtime and app elements:
instance_class
Optional. The instance class for this service.
The following values are available depending on your service's
scaling:
Automatic scaling
F1, F2, F4, F4_1G
Default: F1 is assigned if you do not specify an instance class along with the automatic_scaling element.
Basic and manual scaling
B1, B2, B4, B4_1G, B8
Default: B2 is assigned if you do not specify an instance class along with the basic_scaling element or the
manual_scaling element.
Note: If instance_class is set to F2 or higher, you can optimize your instances by setting max_concurrent_requests to a
value higher than 10, which is the default. To find the optimal value,
gradually increase it and monitor the performance of your application.
The max amount of memory available in the currently supported standard environment instance classes is 1G, if you actually need 6G you'll have to migrate to the flexible environment.
Side note: potentially useful: How to tell if a Google App Engine documentation page applies to the standard or the flexible environment
Related
We've noticed that using GCP's Monitoring Uptime checks on one AppEngine service appears to keep it 'alive' unnecessarily - removing the monitoring configuration reduced the running instances to 0. However, we have two other AppEngine services that would happily reduce to 0 instances, even with the monitoring in place.
We've been unable to find any difference in configuration. The one other visible difference we spotted was in the 'Traffic' graphs, the instances that still shut down included 'Sent (cached)' and 'Received (cached)' as series on the graph (along side Sent and Received):
Whereas the 'problem' service only has Sent and Received:
There is no cloud load balancing in place - we're just using AppEngine to map the endpoints.
Config for both look like this, with different handlers configured:
runtime: python310
env: standard
instance_class: F1
handlers:
- *snip*
automatic_scaling:
min_idle_instances: automatic
max_idle_instances: automatic
min_pending_latency: automatic
max_pending_latency: automatic
service_account: XXXX#appspot.gserviceaccount.com
Can anyone clarify what might be different between these? Thank you.
I have made a basic App Engine Flexible Rest API that uses Cloud endpoints for authentication and uses Spring for the MVC framework.
Does anyone have any recommendations on how to switch this over to App Engine Standard?
I thought to change the app.yaml file would work but I am a bit lost.
Thanks
Modifying your app.yaml is the primary method of changing from flexible to standard environment, or vice versa. Barring any other special configuration for your particular project, this could be all you need to do.
To deploy to standard environment, instead of flexible:
Try simply commenting out the env property in your app.yaml:
#env: flex
By default, you'd deploy to the standard environment if env is not defined (is what my experience has been).
Beyond this, you'd have to look at individual properties in your app.yaml, as perhaps some of them may only apply to a specific deployment type. For example, instance_class is not a property used in flexible environment, whereas you can define that in standard environment. In theory, I would remove or comment-out instance_class if deploying to flexible environment, or just maintain a second app.yaml (e.g. named app_standard.yaml).
On a side note, one thing I did stumble upon recently (for Go, anyways):
For a flexible deployment, this failed...
# This failed for flexible deployment, but it's what Google docs states to use (no period in the number)
runtime: go111
Meanwhile, I had to define the period for flexible deployment...
# This worked on a flexible deployment (had to include the period in the number)
runtime: go1.11
However, for the exact same app, with no code changes, simply going to standard environment, I defined runtime version WITHOUT A PERIOD, as Google's docs say to do, and it worked:
# This worked for standard environment (no period in the number)
runtime: go112
Just illustrating how fine details in the app.yaml matter.
How do you change the size of the shared memory folder /dev/shm in an App Engine Flexible app?
By default it is set to 64M, too low to run many apps (e.g., chrome). I don't see any way to change it. There are ways to change it if you have access to the docker run command, but we don't have such access when launching app engine flexible apps.
A: No.
Unfortunately this isn't possible (yet?) with appengine. More than a few people have run into this issue. For some reason, the container default for /dev/shm is crazy small.
...but there are other options
If the process you want to run has the ability to configure the location of the tmpfs it uses, then you can create a tmpfs and simply point it there. Chromium can't do this.
Option 1
If you want to deploy a container to google cloud, one option is to use container engine. You can then mount a tmpfs volume to your pods like this:
spec:
volumes:
- name: dshm
emptyDir:
medium: Memory
containers:
- image: gcr.io/project/image
volumeMounts:
- mountPath: /dev/shm
name: dshm
Kubernetes has a fairly steep learning curve, but it will allow you to uncap the limit on /dev/shm.
Option 2
There is a new feature that will allow you to deploy containers to compute engine, but it's currently in alpha and you will need to apply to have your project whitelisted to use this feature.
Option 3
Of course, you could deploy containers to GCE in a more manual fashion by creating a GCE instance using COS (container optimized os)
Update from speedplane's comment
Option #4
If the goal is to run a full browser on app engine flexible, then the new versions of Firefox run in headless just fine in Docker.
This is the answer I received from Google Support (support ID 13757624):
I understand that you have inquiry if it would be possible to increase
the size of /dev/shm in App Engine Flex.
Unfortunately, this isn't possible. Since Flex is managed VM the
default value is maintained. You may try to create manually a command
on your dockerfile to change the shared cache via 'sudo' but there's
no guarantee so I can't say that it will possibly work, still worth a
try given that you are using custom runtimes otherwise, there's no
other way.
Is it possible to target a custom runtime to use a micro instance?
I tried with:
resources:
cpu: 0.5
memory_gb: 0.6
disk_size_gb: 10
But a small instance is started.
Add following to your app.yaml:
beta_settings:
machine_type: f1-micro
In App Engine, the instance type cannot be specified for the flex environment (unlike the standard environment in Python, Java and Go).
In the flex environment, the instance types are derived from the resource settings specified in your app.yaml file.
App Engine Resource Settings
It appears, that for some reason the pricing calculator lets you enter small values so the instance appears similar to a F1-micro (I was looking for around $5/month to run it) but then alas when it comes to specifying it in app.yaml it defaults to something that costs a whole lot more than an f1-micro, and you can't set the values to anything lower than what OP shows.
example very small flex instance in pricing calculator
I have problem with automatic scaling at GAE.
One of my application module have instance class F4 and folowing automatic scaling settings.
<automatic-scaling>
<min-idle-instances>2</min-idle-instances>
<max-idle-instances>5</max-idle-instances>
<min-pending-latency>automatic</min-pending-latency>
<max-pending-latency>30ms</max-pending-latency>
<max-concurrent-requests>100</max-concurrent-requests>
</automatic-scaling>
I set maximum instances as 5 but when we run some jmeter tests with 300 users running instance number is increased to more than 40.
So it's looks that GAE don't handle this parameter correctly.
Does anybody have experience with this problem?
If you REALLY wanted to use the max instances cap, you have to use the app engine Application Settings UI at appengine.google.com. You can't set the max instances in app.yaml (yet).