In Google Cloud Platform Monitoring, is there any way to monitor memory usage by App Engine instance? I see that there is the Memory usage metric for the GAE Application resource type, but I don't see a Memory usage metric for the GAE Instance resource type.
My particular use case is that I'd like to see (and make alerts based on) memory usage per instance.
Currently there's no built-in metric to monitor per instance memory. The only way to monitor the Memory Usage within a GAE Instance is by creating a custom metric, in this link you can find more information about custom metrics.
Just remember that the amount of instances will increase according to the load, so a per instance alert shouldn't reflect the actual load of your application, that's why the memory usage is normally measured by group on the built in metric rather than per instance.
Related
Have a production web-application deployment on GAE (LAMP Stack) with autoscaled setting, and according to the documentation, Google will automatically spin-up additional instances to meet demand; this seemed to have been proven when we went live, hours before a season finale aired which would guarantee traffic hit our site, and our site did NOT fall-over even with the expected sizable influx - so kudos to Google! However, I'd be naive to think that this server architecture is done, knowing that we're still in our infancy, and we could potentially get 10 - 100x more traffic in the near future on a consistent basis when we gain popularity and move into the global market. So my question is:
Should I be implementing a Load Balancer in GCP or will GAE be able to scale "indefinitely" to accommodate?
Based on this answer: AppEngine load balancing across multiple regions you'll need to implement the load balancer if you're targeting multiple regions.
Otherwise it will be dependent on your configuration and the thresholds you've set on your GAE config.
According to https://cloud.google.com/appengine/docs/standard/go/how-instances-are-managed, there are three ways you can define scaling on your AppEngine instance:
Automatic scaling
Automatic scaling creates dynamic instances based on request rate, response latencies, and other application metrics. However, if you
specify a number of minimum idle instances, that specified number of
instances run as resident instances while any additional instances
are dynamic.
Basic Scaling
Basic scaling creates dynamic instances when your application receives requests. Each instance will be shut down when the app
becomes idle. Basic scaling is ideal for work that is intermittent or
driven by user activity.
Manual scaling
Manual scaling uses resident instances that continuously run the specified number of instances regardless of the load level. This
allows tasks such as complex initializations and applications that
rely on the state of the memory over time.
So the answer is it depends. You'll just need to base your scaling strategy on how your load distribution looks. I would expect that the automatic scaling is fine for 90% of early-stage websites, though that's just my impression.
In App Engine Dashboard-> In Combobox Summmary -> I choose Instances: there are these values:created, active.
I dont understand what does created Instances mean, active Instances mean.
Is created Instances idle Instances?
Is active Instances dynamic Instances?
Why created Instances is 3 but active Instances is 1, then my system fail.
Warning:
''While handling this request, the process that handled this request was found to be using too much memory and was terminated. This is likely to cause a new process to be used for the next request to your application. If you see this message frequently, you may have a memory leak in your application or may be using an instance with insufficient memory. Consider setting a larger instance class in app.yaml.''
Thanks
Created instances are the ones your application started in a given situation, not necessarily serving, and can also be idle. Instances are created depending on the instance scaling type you specified in your app.yaml.
Active instances are those instances that are serving traffic or have served traffic at a given timeframe.
Here's How Instances are Managed in App Engine for detailed explanation about GAE instances.
The warning you received is usually due to the available instance exceeds the maximum memory for its configured instance_class . You might need to specify higher instance class or use max_concurrent_requests to optimize your instances and properly handle requests.
You could also configure maximum and minimum number of instances in your app.yaml depending on how much traffic you would like your application to handle.
I've almost completed migrating based on google's instructions.
It's very nice to not have to call into the app-engine libraries whatsoever.
However, now I must replace my calls to app-engine-standard memcached.
Here's what the guide says: "To use a memcache service on App Engine, use Redis Labs Memcached Cloud instead of App Engine Memcache."
So is this my only option; a third party? They don't even list pricing on their page if GCE is selected.
I also see in the standard environment how-to guides there is a guide on Connecting to internal resources in a VPC network.
From that link it mentions Cloud Memorystore. I can't find any examples if this is advisable or possible to do on GAE standard. Of course it wasn't previously possible but now that GAE standard has become much more "standard", I think it should be possible?
Thanks for any advice on the best way forward.
Memorystore appears to be Google's replacement:
https://cloud.google.com/memorystore/
You connect to it using this guide:
https://cloud.google.com/appengine/docs/standard/go/using-memorystore
Alas it costs about $1.20/GB per day with no free quota.
Thus, if your data doesn't change, and requires less than 100MB of cache at a time, the first answer might be better (free). Also, your data won't explode the instance as you can control the max size of the cache.
However, if your data changes or you need more cache, MemoryStore is a more direct replacement to MemCache - just costs money.
I've been thinking about this. 2nd gen instances have twice the ram, so if global cache isn't required (as in items don't change once created - (name items using their sha256)), you can run your own local threadsafe memcache (such as https://github.com/dgraph-io/ristretto) and allocate some of the extra ram to it. It'll be faster than Memcache was, so requests can be serviced even faster, keeping the number of instances low.
You could make it global for data that does change, by using pub/sub between instances, but I think that's significantly more work.
To ease the migration to 1.12, I have been thinking of using this solution:
create a dedicated app using the 1.11 runtime.
setup twirp endpoints to act as a proxy for all the deprecated app engine services (memcache, mail, search...)
I'm very new to using Google cloud services. As I can see Google App Engine has two way of deployment. The first one is using App Engine sandbox and the second is managed VM.
So I'm interested in pricing. Is there any difference in price? For example if I choose managed VM instead sandbox.
Pricing for the Sandbox can be found on the App Engine Pricing page.
Pricing for the Managed VM's can be found on the Compute Engine Pricing page:
While in beta, pricing is based on Compute Engine Pricing for each VM. Pricing will change in the future.
Based on the linked Price pages:
The Minimum cost for a Sandboxed instance: $0.05 / hour (F1 class, 128MB RAM, 600MHz CPU)
The Minimum cost for a Managed VM: $0.063 (n1-standard-1, 3.75GB RAM, 2.75GCEU CPU)
For other classes of sandbox instances see this page: Adjusting Application Performance
Before jumping to the conclusion that Managed VMs are cheaper: each app gets 28 free instance-hours per day for Sandbox, so chances are good you won't even have to pay for any. Also with further configuration you can achieve to only pay for further "used" instance hours (e.g. you can play with min_idle_instances and max_idle_instances in your module config so additional instances only count toward instance hour billing when they are active (serving requests)).
Notes:
Price shouldn't be the only (or most important) reason to chose one over the other. They are for different things with quite different characteristics.
Sandbox instances are primarily for your application front-end: they can automatically scale as your traffic changes/grows. Many restrictions are enforced.
Managed VMs are good for background operations which can be long or CPU consuming, most of the restrictions are not applied.
In a nutshell: MVMs are for the same price about 10x more powerful.
Default GAE instances are F1: 600Mhz, 128MB, $0.05/h
Comparable MVM: 2500Mhz, 3.75GB, $0.05/h (typical use)
It's not about price, it's about environment. You would not have SQL or root FS on GAE, you can't open ports. Your code base would be hard to migrate to another VPS. As a trade-off you get zero cost maintenance and effortless instant scaling.
What exactly is a Google App Engine Instance as per their plans to change the billing model as they exit preview?
Is an instance a VM with a set of memory and a fixed amount of dedicated CPU power, memory etc or something else?
Is an instance a VM with a set of memory and a fixed amount of dedicated CPU power, memory etc or something else?
Yes, exactly that it is. A VM with a set of memory and a fixed amount of dedicated CPU power.
I can't remember how many instances a google server has but they said that in a I/O session. They also said what kind of servers google is using for App Engine ( quad core with some big amount of ram). Here it's the recording if I'm not wrong https://www.youtube.com/watch?v=7B7FyU9wW8Y
http://code.google.com/appengine/docs/adminconsole/instances.html#Introduction_to_Instances for a general description.
http://code.google.com/appengine/docs/python/config/backends.html for specifics on backends, where you have more control over the resource that you're either reserving or using on demand.