在多线程副本上,性能架构表replication_applier_status_by_coordinator
而且replication_applier_status_by_worker
分别显示副本的协调线程和应用程序工作线程的状态信息。对于具有多个通道的副本,将标识每个通道的线程。
如果详细信息设置为显示信息消息,多线程副本的协调器线程还会定期将统计信息打印到副本的错误日志中。统计信息根据协调器线程分配给应用程序工作线程的事件量打印,最大频率为每120秒打印一次。该消息列出了相关复制区域通道的统计信息,或默认的复制区域通道(未命名):
- 秒时间
-
当前时间与上次将此信息打印到错误日志之间的秒差。
- 事件分配
-
自协调线程启动以来,协调线程已排队到所有应用程序工作线程的事件总数。
- 工作队列已超过超限水平
-
当前排队到任何应用程序工作线程的事件数量超过了溢出级别,该级别设置为最大队列长度(16384个事件)的90%。如果该值为零,则没有应用程序工作线程在其容量的上限上运行。
- 由于工人队列已满而等待
-
由于应用程序工作线程的队列已满,协调器线程在调度事件时必须等待的次数。如果该值为零,则没有应用程序工作线程耗尽它们的容量。
- 由于总尺寸而等待
-
协调器线程在安排事件时必须等待的次数,因为
replica_pending_jobs_size_max
或slave_pending_jobs_size_max
已经到了极限。这个系统变量设置用于保存尚未应用的事件的应用程序工作线程队列的最大可用内存(以字节为单位)。如果一个异常大的事件超过了这个大小,事务将被持有,直到所有应用程序工作线程都有空队列,然后处理。所有后续事务都将被保留,直到大型事务完成。 - 等待时间冲突
-
协调器线程在调度事件时必须等待的纳秒数,因为事件所依赖的事务尚未提交。如果
replica_parallel_type
或slave_parallel_type
被设置为数据库
(而不是LOGICAL_CLOCK
)时,该值始终为零。 - 等待(计数)工人工作时
-
协调器线程短时间内休眠的次数,在两种情况下可能会这样做。第一种情况是,协调器线程分配一个事件,并发现应用程序工作线程的队列已被填满,超出了最大队列长度的10%的欠运行级别,在这种情况下,它最多休眠1毫秒。第二种情况是
replica_parallel_type
或slave_parallel_type
被设置为LOGICAL_CLOCK
协调线程需要将事务的第一个事件分配给应用程序工作线程的队列,它只对队列为空的工作线程执行此操作,因此如果没有空队列,协调线程将休眠,直到有一个队列为空。 - 等待工人工作
-
协调器线程在等待空的应用程序工作线程队列时所休眠的纳秒数(即,在上面描述的第二种情况中,其中
replica_parallel_type
或slave_parallel_type
被设置为LOGICAL_CLOCK
并且需要分配事务的第一个事件)。