在为总计4330个请求提供服务后，已超过243 MB的软内存限制，其中307 MB。考虑在app.yaml中设置更大的实例类
情况：
我的项目大多是自动化的任务。我的GAE (标准环境)应用程序有40个这样的crons作业，都在默认模块(前端)上运行：
- description: My cron job Nth
url: /mycronjob_n/ ###### Please note n is the nth cron job.
schedule: every 1 minutes每个cron作业
@app.route('/mycronjob_n/')
def mycronjob_n():
for i in (0,100):
pram = prams[i]
options = TaskRetryOptions(task_retry_limit=0,task_age_limit=0)
deferred.defer(mytask,pram)mytask在哪里
def mytask(pram):
#Do some loops, read and write datastore, call api, which I guesss taking less than 30 seconds.
return 'Task finish'问题：
作为问题的标题，我的RAM快用完了。前端实例小时数增加到100小时。
我的错误想法？
- 延迟任务在后台运行，因为它不是用户在访问网站时发送请求。
- 我把cronjobs_n分成几个不同的小任务，因为我认为这有助于减少每个cronjobs_n的运行时间，从而减少实例的内存consumption.
我的问题：(目的:尽量降低前端和后端实例的时长，我接受延迟)
- 是否将延迟任务计为请求？1分钟内我有多少个请求? mycronjob_n的
- 40个请求或mycronjob_n的
- 40个请求x 100 mytask = 4000
如果3-4个实例无法处理4000个请求，为什么GAE不再增加10 - 20个F1实例，然后在空闲时关闭？我在app.yaml中设置了自动缩放。我在这里看不到GAE自动缩放的含义。
- 优化我的应用程序的最佳方法是什么？如果将延迟任务算作请求，那么将mycronjob_n分成不同的小任务是没有意义的，对吧？我的意思是，我现在的方法是一样的：
@app.route('/mycronjob_n/') def mycronjob_n()：
对于(0,100)中的i: pram = pramsi options = TaskRetryOptions(task_retry_limit=0，task_age_limit=0) mytask(pram) #调用函数mytask
在这里，我的应用程序是否每分钟有40个请求，每个请求运行100 x 30秒=3000秒？那么，这种方法是否也会返回内存不足呢？我是否应该创建一个在F1实例上运行后端服务，并将所有cron作业放在该后端服务上？我听说一个请求可以运行24小时。
- 如果我将默认服务实例从F1更改为F2，F3，我还能获得28小时的免费服务吗？我听说免费层只适用于F1。如果我的后端服务在B2上运行，而不是在B1上运行，我的后端服务是否会获得9小时的免费服务？
我的遗憾：-我很遗憾我选择了GAE来做这个项目。我选择它是因为它有空闲层。但我意识到自由层只是出于兴趣/测试的目的。如果我运行一个真正的应用程序，成本会增加得非常快，这让我觉得GAE很昂贵。尽管我尽了最大努力优化数据存储的读/写，但它们的开销还是很大的。前端时间也总是很长。我每月为GAE支付40美元。每月40美元，如果我选择Heroku，Digital Ocean，也许我可以得到更好的服务器？你认为这样对吗？
回答 1
Stack Overflow用户
发布于 2018-08-29 10:24:25
- 是的，任务队列请求(包括延迟)也是请求，它们只是可以比用户请求运行更长时间。他们需要实例来为他们提供服务，这些实例计入实例小时数。因为您每分钟至少有一个cron作业在运行-您不会有任何15分钟的空闲时间间隔允许您的实例关闭-所以您需要始终至少有一个实例在运行。如果您使用F1/B1以外的任何实例类-您将超过免费实例小时数配额。参见Standard environment instances账单。
- 您似乎有这样一种印象，即请求的数量是导致成本上升的原因。它不是，至少不是直接的。罪魁祸首很可能是正在运行的实例数量。
如果3-4个实例无法处理4000个请求，
为什么不再添加10 - 20个F1实例，然后在空闲时关闭？
GAE最有可能做到这一点--生成几个实例。但是你每分钟都在发送请求，它们不会达到空闲状态足够长的时间，所以它们不会关闭。这会使您的实例运行数小时。
你可以对它做两件事：
- 将您的延迟任务错开，这样它们就不需要同时处理。更少的实例(甚至是单个实例？)在这种情况下可能需要处理它们。查看Combine cron jobs to reduce number of instances和Preventing Google App Engine Cron jobs from creating multiple instances (and thus burning through all my instance hours)
- tune你的应用的伸缩配置(但范围是有限的)。请参阅Scaling elements.
您还应该仔细阅读How Instances are Managed。
- 可以，超出免费配额只需付费，与实例类别无关。无论如何，计费都是以F1/B1为单位的-从上面的计费链接：
Important：当您按实例小时数计费时，您的计费行项目中将看不到任何实例类。相反，您将看到相应的实例小时数倍数。例如，如果您使用一个F4实例一个小时，您不会看到列出"F4“，但您会看到按F1费率计费的四个实例小时。
关于内存使用率，将cron作业分成多个任务不一定有帮助，请参阅App Engine Deferred: Tracking Down Memory Leaks
最后，比较GAE和Heroku的成本，Digital Ocean不是一个苹果对苹果的比较: GAE是PaaS，而不是IaaS，我预计它会更贵。选择一个或另一个真的取决于你。
https://stackoverflow.com/questions/52067297
复制相似问题