表达式队列调优

根据每次安装的服务器资源、表达式计数和复杂性,表达式引擎可能需要进行调优。 一般而言,该过程涉及一次重复调优和度量一个参数的性能,直到该性能无法再提升为止。这些记录必须保留。针对硬件、使用情况和设置的更改需要进行新一轮的调优。
作为管理员,必须针对每次安装检查以下应用程序:
表 1. 表达式队列调优应用程序设置
设置 单元 缺省值 运行时* 描述 调优提示
formula.queue.maxage 小时 24 保留表达式队列历史记录的最大小时数。仅删除运行的表达式。 这是通过使用公式完成的。 保留运行的条目数旨在用于表达式统计信息(高级 > 表达式队列),以及检查求值循环。对循环进行求值时,该数字在高吞吐量设置中可能会较小,以减小表的大小。
formula.queue.maxsize 条目数 500000 表达式队列中条目的最大数目。清除任务通过删除历史记录保持输入计数小于该数字。仅删除运行的表达式。 这会覆盖最长期限设置。 为了获得更佳的性能,应对该数字进行调优,以减小高负载期间队列历史记录大小,以及保存历史记录。该数字适当的近似值是略小于最长期限时间段内的吞吐量平均值。
formula.execution.batch.size 条目数 30 在每次分配运行时针对一个线程所分配的表达式队列条目数。这些条目被标记为“已启动”,该线程会运行,并在分配新的批处理前已完成。 表达式会同时在几个节点上的一些线程上并发运行,但是始终遵照明确依赖关系的时间顺序。如果队列上的两个表达式没有关联,那么它们可以按照非添加时的顺序运行。表达式条目可能取决于另一条目的值。如果该条目(表达式条目取决于它的值)的实例不在表达式之前运行,那么表达式条目可能不运行。 这(以及并发性)需要通过分配来避免冲突、不一致顺序和冗余工作。分配的代价较昂贵,所以一些表达式是按照上述需求和采用给定顺序运行时的条件一次就分配好的。如果分配了大量表达式,那么会节约分配开销,但这“锁定”了并发性,反之亦然。如果表达式形成了很长的依赖关系链,通常的做法是减小该数字;如果依赖关系链很短或者依赖关系极少,那么增加该数字。 您可以在运行时更改该值,并对其进行调优,直到找到合适的最佳值。最佳值很少小于 10 或大于 200。
formula.cleanup.interval 毫秒 1800000 清理表达式队列的频率。此处强制进行最长期限和最大大小设置。仅执行队列删除。第一次清理是在服务器启动时,此时会完成特殊维护。同样,每隔两周会完成一次计时器表达式完整性检查(在夜间)。 大部分情况下,缺省值是合适的。 如果吞吐量较高,清理时间会较长,不过还应该更常执行清理,反之亦然。因此,如果该时间增加过长,需引起注意,这是因为当负载骤然增加时(例如,在一次导入或添加属性后),可能会造成执行中断或性能不佳。
formula.background.interval 毫秒 10000 检查表达式队列以便新的未分配表达式运行的频率。当完成一个批处理后,新的检查会立即开始,而不会等待一定时间间隔。 如果在下一个时间间隔发生时队列未处于“已完成”状态,那么会衍生一个新的工作程序线程来重复工作。 Rational® Focal Point™ 较早的版本中,执行是异步和即时的。当表达式移动到数据库时,一定会出现死锁的风险。 这是检查表达式队列以便新表达式运行的时间间隔,即用户必须等待表达式运行的最大时间(包括执行时间)。如果时间间隔过短,只会不必要地浪费一些资源。这也会影响并发性的上升:如果在该时间间隔内未完成在上一个时间间隔启动的工作程序线程,那么还会启动另一个线程 (till thread.per.nodes)。如果上升速度较慢,可以降低该数字。如果表达式很少使用,可以稍微增加该数字。
formula.max.background.threads.per.node 计数 2 针对每个节点运行表达式的最大并发线程数。实际的最大数目动态取决于在应用程序线程池中是否存在自由线程。 如果要完成更多工作,background.interval 中描述的并发性上升会增加每个时间间隔内节点上的表达式求值线程数。请注意,这是最大值。这需要应用程序线程池中具有自由线程,该线程池会根据核心(虚拟或其他)数目自动进行调优。它还要求不使用池中最近的线程。您可以用该数字进行试验,这不会中断任何操作。然而,不能保证更高的性能,因为这在很大程度上取决于要保持的数据库的并行能力。该值过低的标志是该队列经常有未求值的表达式。
formula.cleanup.enabled 布尔值 true 缺省情况下,表达式队列清除处于启用状态。除了出于调试目的或运行性能测量时必须阻止清除,任何时候都不得将其禁用。 该设置不存在调优,不得更改,必须保持其缺省值“true”。

反馈