在FME Server上分析任务统计资料

了解如何最大限度地利用手头资源是一项随处可见的挑战。

每天早晨，我坐下来，登录电脑，展望即将召开的会议以及尚未完成的工作任务。有一种看待自己与工作之间的关系的方式是：我自己即是完成所有任务的资源。也就是说，我需要列一个清单，分清轻重缓急。这样很有用—我可以写下我这一天的首要目标，然后一点点的去完成它们。

但想象一下：我在最后一刻才被告知我的下一个任务并不重要，所以我可以将其从我的待办事项清单中划去。然后呢，这篇博客的截止日期又突然提前了。行吧，或许我能接受这些改变。然而，如果你有许多人员（或者资源）需要管理，并且这些人（或者资源）都受到这些更改的影响的时候，会发生什么呢？如果工作任务优先级在不断地变化又该怎么办呢？

与其说是“想象”，不如说这是一个很现实的问题。事情的确在不断地变化，而且还能变得很快。尤其是在FME Server中优先排序数据工作流时。此时你的资源是FME引擎而并非人，这些任务则是需要处理的工作。

这就是为什么我们在FME Server中引进了“任务统计资料”，以及一种崭新的方式来管理FME引擎的分布和待处理的工作任务。然后你猜怎么着？它可以自己扩展，并且只需要配置它一次。

在FME Server上的任务统计资料

让我们来了解一下我到底说的是什么。到底什么是任务统计资料呢？

FME Server中的任务统计资料包含了作业处理时间，CPU占用信息以及内存占用信息，以便更好地了解它们在FME Server中的活跃水平以及它们的任务是如何执行的。

任务统计资料可以在 Jobs > Completed by customizing the columns 处找到。也可以在查看单独工作空间时浏览。以下是最新可用的任务统计资料：

• 总运行：FME Server运行任务的总次数。
• 平均运行时长：处理任务的总共时间（请注意：”运行时长“以前被称为”持续时间“）。这项数据很有用，因为它让我们能知道”预期“的时长是多久。
• 平均CPU百分比：实际处理所花费的时长，并不包括任何的网络活动。（平均CPU时间/平均运行时间）
• 平均CPU时间：全部调用的平均CPU时间。
• 平均内存占用峰值：一项作业在处理时所需的平均内存占用量。

 

好了，现在你有了这些信息，你接下来可能就要问了，”我现在该干啥呢？“

这里是一些你可以采取的行动：

• 当平均内存占用峰值较高——尤其是超过1GB时——此时工作空间本身可能会出现效率低下的情况。并且当平行运行任务时，这些工作空间也会面临互相争夺资源的风险。
• 如果你看见平均CPU时间较低，这就是一个很好的信号，这些任务已经准备好利用Dynamic Engines(以及它们的CPU time payment model即CPU时间支付模型)
• 对于那些似乎永远不会在总运行上增加的任务，你可以从FME Server中清理或者删除它们，以确保所有事情都整齐有条理——当然啦，一定要先对工作空间的所有者核查一下！

队列控制：利用任务统计资料以确定优先级和重新确定优先级

在以前，FME Server管理员会创建一个队列，然后只能分配资源库（即工作空间的集合），由一个或者多个FME引擎处理。一旦这些都设置好之后，虽然它可以被更改，但通常只有在遇到瓶颈或者其他问题时，才会根据所分配的FME引擎数量或者资源库来更改它。以前这是一个很不错的解决方法，但是它需要管理员进行大量的监控。

工作流看起来是这样的：

 

现在呢，通过新增的任务统计资料，我们还增加了新的队列控制功能：任务路由（Job Routing）和新的引擎分配规则（Engine Assignment Rules）。

首先让我们从如何在队列配置分离引擎配置和任务（替换资源库）开始。

像以前一样，从创建FME Server队列开始。

不过现在你可以对如何使用任务路由规则（Job Routing Rules）分配任务有更多的控制权。FME Server仍支持分配整个工作空间资源库（Repository of Workspaces），但这也正是任务统计资料发挥作用之处。

 

在这个图片里的例子中，我正在创建一个任务路由规则(Job Routing Rules), 其中任何占用内存超过2GB的工作空间都将被分配给myQueue。通过这种方法，我可以在有足够可用内存的机器上分配引擎以处理它们。通过限制所使用的引擎数量，我可以确保系统也有足够的资源，不会让处理过程陷入停顿。

 

我并没有忘记分配FME引擎，你忘了没？让我们来看看引擎分配规则(Engine Assignment Rules)：

仍然有个选项可以选择特定的引擎来分配给特定的FME Server Queue， 但现在有了FME引擎“属性“的一个概念。

引擎属性(Engine Properties)是怎么用的呢？当一个FME引擎连接至FME Server时，它会向FME Server Core报告信息，这些信息我们能够看到。这就意味着我们可以根据FME引擎的特征来动态地分配它们。

 

目前只有包括：FME引擎类型（标准或动态Standard or Dynamic）和操作系统（用于部署混合Windows或者Linux引擎）等少数几个属性可用。将来会有更多的产品出现，以实现更大的灵活性。

如果我能有FME Server像这样来管理我自己的日常任务就好了！

现在我已经告诉了您关于任务统计数据和FME Server中的新队列控制选项的所有内容，我敢打赌你正在好奇应该在什么时候开始使用它? 答案很简单:如果你有FME Server 2021或更新版本，从今天开始用起来吧!

还有一些东西会让你的配置更加有效:

• 作业需要多次运行才能获取可靠的统计数据。
• 如果输入参数或源数据在运行之间发生显著的变化，那么你所创建的规则可能无法捕获离群值（outliers）。
• 规则的顺序很重要: 引擎分配(Engine Assignment)和任务路由规则(Job Routing Rules)会按照列出的顺序进行计算 (你可以把它想象成if-else语句)。
• 在可能的情况下使用范围(Ranges)代替绝对值(Absolute Value)。
• 队列(Queue)本身可以被优先级排序——在你有着将一个FME引擎放在多个队列中的引擎分配规则(Engine Assignment Rules)时，这很有用。
• 从简单的开始，然后再扩展, 循序渐进。

为自动缩放(Auto-Scaling)铺平道路

你看完了所有的信息，而我却对自动缩放只字未提? 对于任何参加过我们网络研讨会的人来说，你可能了解我们对于FME Server的一个长期愿景是让你能够配置你的FME引擎，以自动缩放(Auto-Scaling)来响应你的部署需求。

在本文自动缩放时什么意思呢？ 好吧，这都是和FME引擎相关。虽然有些用户可以全天候为FME引擎提供资源(CPU、内存)，但这并不是最理想的人工任务。有了自动缩放，就不需要人工手动地管理资源了。相反，FME将自动为你添加和删除引擎以确保你的工作流持续有效地运行。

你可能就在想了：“但更多的引擎就意味着更多的钱啊！” 事实并非如此。我们已经引入了动态引擎(Dynamic Engines)来平衡这个等式的财务方面。比起直接为引擎付费，你只需要为CPU时间(CPU time)付费。这与新的任务统计数据(Job Statistics)相结合，将使你更加容易地预算花费，并了解预期的结果。

至于等式的另一边，管理方面呢？这正是我们现在着手努力的方面。任务路由(Job Routing)和引擎分配规则(Engine Assignment Rules)将成为我们如何处理FME Server的自动缩放引擎(Auto-Scaling Engines)的基石。它引入了崭新的方法来管理跨FME Server队列的引擎分布。到目前为止，我们已开始引入可以用作标准的新属性和新度量。

下一步将是利用这些信息来指示有多少引擎正在运行。是的，你将能扩展常规引擎或动态引擎(Regular or Dynamic Engines)。我能告诉你的是，要解决这个问题并不简单，所以我希望我们能继续看到这些逐步的改进，以便我们在每个版本中都能更进一步。