启用并发后,App Engine任务队列会丢失超过30%的作业

时间:2015-03-10 17:35:26

标签: google-app-engine

这是一个更新。 我删除了重试限制。可以解释为什么任务丢失了。 我还根据Google的建议减少了最大并发数。 这是当前队列定义:

<queue>
    <name>OsmOrderQueue</name>
    <rate>20/s</rate>
    <max-concurrent-requests>10</max-concurrent-requests>
    <bucket-size>100</bucket-size> 
    <retry-parameters>
        <min-backoff-seconds>30</min-backoff-seconds>
        <max-backoff-seconds>30</max-backoff-seconds>
        <max-doublings>0</max-doublings>
    </retry-parameters>
</queue>

此外,这是后端定义。我添加了一个定义来覆盖默认实例。

<backend name="osm-backend">
  <class>B8</class>
  <instances>4</instances>
      <options>
    <dynamic>true</dynamic>
    <public>true</public>
  </options>
</backend>

但我没有看到部署的实例数量有任何变化。它始终是1。 我用

进行了更新
appcfg.cmd update <war directory> 

即使队列正在运行,也会更新队列定义。这是一个很酷的功能。

现在的情况令人难以置信地与众不同。现在这些任务将持续近3000秒,然后进行切换。我打赌我这次要收费了!

    2015-03-14 05:06:57.387 /sampleServlet 500 2869079ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=maptest-backend

    E 2015-03-14 05:06:57.387 A problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the nex



2015-03-14 05:06:57.386 /sampleServlet 500 2879643ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=maptest-backend
        E 2015-03-14 05:06:57.386 A problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the nex

    2015-03-14 05:06:57.384 /sampleServlet 500 2889684ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=maptest-backend
    E 2015-03-14 05:06:57.384 A problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the nex

2015-03-14 04:47:33.062/sampleServlet 200 3674187ms 0kb instance = 0 AppEngine-Google; (+ http://code.google.com/appengine)module = default version = maptest-backend

顺便说一下,我正在执行的任务没有线程化。它从数据存储区和云存储中读取并写入大查询。这应该是我认为应用引擎中最常见的模型。如果我自己运行其中一个任务,它通常在大约200-300秒内完成。令人难以置信的B8机器速度慢。我可以在我的电脑上处理相同文件的读取,大约需要10秒钟。我希望我能在我的任务或队列定义中看到错误,但我不能。性能怎么这么差?如何如此细微地配置任务队列?我不理解......

我正在尝试使用具有以下配置的任务队列并行完成作业。

<queue>
    <name>OsmOrderQueue</name>
    <rate>1/s</rate>
    <max-concurrent-requests>8</max-concurrent-requests>
    <bucket-size>4</bucket-size> 
    <retry-parameters>
        <task-retry-limit>7</task-retry-limit>
        <min-backoff-seconds>10</min-backoff-seconds>
        <max-backoff-seconds>200</max-backoff-seconds>
        <max-doublings>2</max-doublings>
    </retry-parameters>
</queue>

最大尺寸是否比铲斗尺寸大?这是奇怪的吗?

我提交了100份工作。我检查了我的日志,确实输入了100个任务。我尝试过只有一个并发会话,所有任务都已处理完毕。但这是我看到的那种错误。我看到许多HTTP代码为500.但是,总和不等于丢失的工作。另外,我有一个找不到bigQuery的工作!!!

请注意,有些作业运行时间差不多5分钟,我付费,然后死了,并说他们正在转移到另一台机器。但他们没有出现。

奇怪的是,当我用非并发性测试它时,它们都运行良好。但我需要通过并行运行来加快这个过程。我不认为我的servlet有并发问题,因为我从代码执行中寻找异常,而且没有我能看到的。那么为什么Google的任务队列失败了呢?

最后,为什么到达bigQuery的URL错误如下面的日志末尾所示?

 2015-03-09 21:42:07.024 /sampleServlet 500 212866ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend

    0.1.0.2 - - [09/Mar/2015:21:42:07 -0700] "POST /sampleServlet HTTP/1.1" 500 0 "https://1-dot-mindful-highway-451.appspot.com/upload" "AppEngine-Google; (+http://code.google.com/appengine)" "osm-backend.mindful-highway-451.appspot.com" ms=212866 cpu_ms=785288 cpm_usd=0.000061 queue_name=OsmOrderQueue task_name=77053872005060790511 exit_code=107 instance=0 app_engine_release=1.9.18 

    W 2015-03-09 21:42:07.024

    Process moved to a different machine.

    2015-03-09 21:42:07.023 /sampleServlet 500 227518ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
    W 2015-03-09 21:42:07.023 Process moved to a different machine.

    2015-03-09 21:42:07.022 /sampleServlet 500 203726ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
    W 2015-03-09 21:42:07.022 Process moved to a different machine.

    2015-03-09 21:42:07.020 /sampleServlet 500 196668ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
    W 2015-03-09 21:42:07.020 Process moved to a different machine.

    2015-03-09 21:42:07.019 /sampleServlet 500 220996ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
    W 2015-03-09 21:42:07.019 Process moved to a different machine.

    2015-03-09 21:41:43.699 /_ah/start 404 3160ms 0kb instance=0 module=default version=osm-backend
    I 2015-03-09 21:41:43.699 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ

    2015-03-09 21:38:21.758 /_ah/start 404 1968ms 0kb instance=0 module=default version=osm-backend
    I 2015-03-09 21:38:21.757 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ

    2015-03-09 20:15:51.414 /_ah/stop 200 13ms 0kb instance=0 module=default version=osm-backend 




    2015-03-09 20:04:27.355 /_ah/start 404 2547ms 0kb instance=0 module=default version=osm-backend
    I 2015-03-09 20:04:27.355 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ

    2015-03-09 20:04:11.770 /sampleServlet 500 241352ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
    W 2015-03-09 20:04:11.770 Process moved to a different machine.



       2015-03-09 20:00:12.995 /_ah/start 404 2154ms 0kb instance=0 module=default version=osm-backend
       I 2015-03-09 20:00:12.995 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ



   BIG QUERY FAILED...
   2015-03-09 21:51:06.675 /sampleServlet 200 576506ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend

   0.1.0.2 - - [09/Mar/2015:21:51:06 -0700] "POST /sampleServlet HTTP/1.1" 200 0 "https://1-dot-mindful-highway-451.appspot.com/upload" "AppEngine-Google; (+http://code.google.com/appengine)" "osm-backend.mindful-highway-451.appspot.com" ms=576507 cpu_ms=484901 cpm_usd=0.156302 queue_name=OsmOrderQueue task_name=21675006186640709011 pending_ms=13531 instance=0 app_engine_release=1.9.18 
   2015-03-09 21:51:06.671

   com.example.lifescore.SampleServlet uploadFileToBigQuerry: New table throws exception e:java.io.IOException: Could not fetch URL: https://www.googleapis.com/upload/bigquery/v2/projects/mindful-highway-451/jobs?uploadType=resumable&upload_id=AEnB2UqDHFbMpUsL5m_a88fWh0hnhYzxp20qbbQlHe1mplsiNyo0g0Roktir0Gk5E6yUkBblXrTjz6cxw7aWF3m0dT03Q6CiQA

根据建议,我将存储桶大小增加到100并删除了max-concurrent-request行。它没有任何影响。我发布了100个作业,它们都在队列中,但仍然按顺序运行。我没有看到任何并行运行的作业。此转储在队列中显示86,但只有6个正在运行。

队列名称最大速率强制速率存储区大小队列中最大并发最早的任务任务在最后一分钟运行中运行 OsmOrderQueue 1.0 / s 0.10 / s 100.0 2015-03-10 18:25:28(0:09:45前)86 6 6

但有趣的是,失败的500事件似乎要追随 一个ahStart。

2015-03-10 18:37:16.358 /sampleServlet 500 230964ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:37:16.358 Process moved to a different machine.

2015-03-10 18:37:16.357 /sampleServlet 500 68596ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:37:16.357 Process moved to a different machine.

2015-03-10 18:37:16.355 /sampleServlet 500 88692ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:37:16.355 Process moved to a different machine.

2015-03-10 18:37:16.354 /sampleServlet 500 99255ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:37:16.354 Process moved to a different machine.

2015-03-10 18:36:51.219 /_ah/start 404 2620ms 0kb instance=0 module=default version=osm-backend
I 2015-03-10 18:36:51.219 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ

这是在大约20次完美运行之后(但是很慢,每次约5分钟) 大约在5 500之后出现了

2015-03-10 18:15:16.894 /sampleServlet 500 114343ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.894 Process moved to a different machine.

2015-03-10 18:15:16.893 /sampleServlet 500 98997ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.893 Process moved to a different machine.

2015-03-10 18:15:16.892 /sampleServlet 500 154237ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.892 Process moved to a different machine.

2015-03-10 18:15:16.891 /sampleServlet 500 139429ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.891 Process moved to a different machine.

2015-03-10 18:15:16.890 /sampleServlet 500 122964ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.890 Process moved to a different machine.

2015-03-10 18:15:16.889 /sampleServlet 500 130682ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.889 Process moved to a different machine.

2015-03-10 18:15:16.888 /sampleServlet 500 163503ms 0kb instance=0 AppEngine-Google; (+http://code.google.com/appengine) module=default version=osm-backend
W 2015-03-10 18:15:16.887 Process moved to a different machine.

2015-03-10 18:14:52.896 /_ah/start 404 2668ms 0kb instance=0 module=default version=osm-backend
I 2015-03-10 18:14:52.860 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This requ

2015-03-10 18:12:35.918 /_ah/start 404 2518ms 0kb instance=0 module=default version=osm-backend
I 2015-03-10 18:12:35.917 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. 

这是一个任务级别表现的图像,其中包含500个事件,没有记录任何错误或异常(只是移动到另一台机器)......非常糟糕啊!

我试图添加图片,但SO说我需要更高的声誉。任何人都可以帮助我。谢谢

3 个答案:

答案 0 :(得分:4)

如果您指定<max-concurrent-request>,那么只要您的存储桶中有令牌,您的所有任务队列都可以并行执行。 I have answered this in detail over here。您真的需要阅读文档over here

  

我看到许多HTTP代码为500.但是,总和不等于   失去了工作。

我可以想象你会看到比预定任务多500个,因为失败的任务会重试。

  

另外,我找不到bigQuery的工作!!

在与服务交谈时会出现偶尔的故障并考虑你的重试策略。确保您的通话为idempotent

答案 1 :(得分:0)

这里看起来有两个问题:1)你没有得到你期望的并行性,2)你的任务被取消并转移到其他机器上。

至于1:根据您发布的内容,您的设置看起来是正确的(一旦您从队列配置中删除了max-concurrent-requests)。队列状态行报告强制速率为0.10 / s。如果实例的数量有上限,我希望看到这个。您是否在处理过程中看到实例数量增加(doc)?

如果您正在使用后端,请务必设置最大数量实例(&#39;实例&#39;选项);它默认为一个。更好的是,切换到模块,因为不推荐使用Backends,并且您将拥有更多控制权(doc)。

至于2:虽然预计应用程序会移动,但30%的费率似乎很高。我希望在修复之后这会变得更好。如果这仍然是一个问题,请跟进此主题。

如果您需要一些短期的想法,以下是一些解决方法:

  • 使用多个实例但关闭模块多线程。 (这将只允许每个实例进行一次计算,减少负载,但也会降低实例效率)
  • 检查您的结果(即保存中间结果并检查任务启动时的中间结果)。

答案 2 :(得分:0)

更好的日志记录向我展示了主要问题。我发现我提交的每个任务都是在我的主转换函数中花费绝大部分时间,而不是等待来自数据存储区或bigquery的数据。我挖了进去,发现我犯了一个非常初级的编码练习错误,也就是说,我连接字符串来生成输出文件,这导致任务时间呈指数级降低,每个文件最多接近一个小时。我不会像我一样相信它 之前检查过代码,但谷歌支持建议(这是一个很好的!)在本地测试。我验证了我的本地代码显示指数时间增加。使用sb.append(新行字符串)和file = sb.toString()更改为stringBuilder。

因此,随着许多长时间运行的任务进入队列,我强调了队列逻辑,获得了移动到另一台机器的500状态。

当我重构代码以使用stringBuilder时,相同的任务在几秒钟内完成。在这种情况下,我毫不费力地让100个任务顺利运行并且没有按预期错​​过任何任务。我设法完成了如下工作。                          OsmOrderQueue             20 / s的             10             100                              10                 100                 2                      

我确实看到最多10个并行运行并且性能良好 更快的运行任务。

但是,当您使用大查询时,您会了解表更改限制会影响系统设计。所以我回到更大的文件,这将意味着更长的任务时间,但更少的任务。在这种情况下,我想知道我是否会再次看到“转向另一台机器”现象。

所以我猜,我会说当任务不长时我的任务队列工作正常。