mysql不集群_为什么mysql集群不使用CPU的多个内核？

我检查了MySQL Cluster开发团队,Frazer Clement提供了这个详细的响应.让我们知道您的测试是如何进行的.提出MySQL Cluster特有问题的好地方是论坛：forums.mysql.com/list.php？25

那个CPU没有超线程

所以它有2个真正的核心.

它还指出,当设置为2时,将会：

1 local query handler (LQH) thread

1 transaction coordinator (TC) thread

1 transporter thread

1 subscription manager (SUMA) thread

使用普通的ndbd,所有这些函数都在1个线程中,ndbmtd和MaxNoOfExecutionThreads = 2,它们被分割出来,如图所示.请注意,这是一个“功能”拆分 – 每个线程都有不同的角色,因此需要不同的CPU来完成其部分工作.对于给定的吞吐量,每种线程类型消耗的CPU量将不同.

较高的MaxNoOfExecutionThreads值将增加LQH线程的数量,这些线程应分别占用“LQH”工作的相等份额,并相互平衡.但是,其他线程将具有不同的CPU消耗量.

最后,ndbmtd以一种循环方式使用LockExecuteThreadToCpu = 0,1行.不幸的是,为了提供均衡的CPU所提供的CPU数量,有太多的执行线程(4).那么会发生的是,单个LQH线程被赋予一个CPU,而其他三个线程共享另一个CPU.这可以解释所看到的不平衡.

请注意,线程到cpus的映射在启动时会在每个ndbmtd进程的stdout(ndb_out日志)中输出.使用类似的配置,我看到以下内容：

NDBMT：num_threads = 4

实例化DBSPJ instanceNo = 0

将threadId = 3936锁定为CPU id = 0

将threadId = 3935锁定到CPU id = 0

将threadId = 3937锁定为CPU id = 0

警告：使用LockExecuteThreadToCPU指定的CPU太少.只需要2个但需要4个,这可能会引起争用.

将LQH线程分配给专用CPU和其他线程将共享剩余

thr：2 tid：3940 cpu：0 OK PGMAN(1)DBACC(1)DBLQH(1)DBTUP(1)备份(1)DBTUX(1)RESTORE(1)

thr：3 tid：3933 cpu：1 OK CMVMI(0)

thr：1 tid：3939 cpu：1 OK BACKUP(0)DBLQH(0)DBACC(0)DBTUP(0)SUMA(0)DBTUX(0)TSMAN(0)LGMAN(0)PGMAN(0)RESTORE(0) DBINFO(0)PGMAN(5)

thr：0 tid：3938 cpu：1 OK DBTC(0)DBDIH(0)DBDICT(0)NDBCNTR(0)QMGR(0)NDBFS(0)TRIX(0)DBUTIL(0)DBSPJ(0)

我们可以看到一个执行线程(3940)被锁定到CPU 0,而其他线程被锁定到CPU 1. 3940是一个LQH工作线程(因为它有一个数字> 0的DBLQH块(DBLQH(1)) ).

在此示例中,CMVMI(网络IO接收器),DBLQH(0)/ SUMA(0)和DBTC(0)线程都锁定到CPU 1.

因此,根据使用的流量,CPU 0与CPU1消耗的CPU量将失去平衡.请注意,“维护”线程也会锁定到CPU 0,如果CPU 0饱和,可能会使事情变得更糟.

如果此流量类型的瓶颈是LQH处理,那么将MaxNoOfExecutionThreads增加到4或更高将导致有2个LQH’工作者’,每个将分配一个核心.但是,其他线程也将使用其中一个核心,这将限制该核心上LQH工作人员的资源.

如果LQH工作人员不是瓶颈,那么拥有额外的LQH工作人员可以减少可用于其他线程的CPU,并降低吞吐量.

我建议尝试流量负载,检查ndbmtd输出以了解映射,测量可实现的吞吐量和延迟,以及观察CPU核心的平衡和利用率.