本节描述集群性能上潜在的限制平台因素，如何度量集群是否接近或超过这些限制，以及纠正这些条件的可用选项。“平台因素”指的是硬件资源，如CPU、内存、磁盘和网络I/O子系统。有关潜在的软件相关因素，请参见使用HAProxy管理数据分布、负载平衡ClustrixDB或理解ClustrixDB Explain输出。

CPU负载

ClustrixDB中总体性能下降的一个常见原因是CPU争用。在理想的情况下，当集群在当前节点数量的给定工作负载下达到最大TPS时，就会发生这种情况:所有CPU核心都很忙，额外的负载会导致查询延迟增加。这里的解决方案是向集群添加更多的节点，提供额外的计算、内存和存储容量。

CPU不平衡

在其他情况下，即使没有充分利用集群，CPU争用也会成为瓶颈;也就是说，集群中的负载不是最优均衡的。这可能是由于一些外部因素造成的，比如查询效率低下，或者客户端连接在节点之间的分布很差(如果不是通过VIP连接的话)。次优配置也可能是问题的根源，比如一个表没有均匀地分布在集群中，尽管系统花了很大力气来自动管理这个问题。

监视CPU负载

CPU负载反映了ClustrixDB集群中每个节点的CPU核心的繁忙程度。

SHOW LOAD命令给出所有节点的所有核心上的当前平均负载(不考虑核心0，它是为特定任务保留的)。在平衡良好的系统上，显示负载输出可以很好地指示当前系统的总体利用率。

表系统。cpu_load提供了一个更细粒度的CPU利用率视图，分解出每个节点上的各个CPU核心。它显示了一个load列(它是当前负载的瞬时度量)和total_busy(它计算繁忙时间的秒数(从数据库启动开始)。当CPU 100%繁忙时，load为1,total_busy每秒增加1。因此，total_busy可以更好地度量总体利用率。

统计信息收集过程statd(在使用statd监视集群中描述)收集系统。cpu_load值，并在统计clustrix.cpu.load.node.N.cpu中生成一个反映间隔时间内负载的增量。从SHOW LOAD中收集瞬时cpu最小值、平均值和最大值，并将其存储在clustrix.cpu.load_min, clustrix.cpu.load_avg, and clustrix.cpu.load_max.

查询数据库statd可以让您了解系统在一段时间内的执行情况。应该研究不均衡的节点CPU利用率，因为不均衡的负载会导致给定集群大小的延迟和吞吐量降低。造成负载不平衡的最常见原因是索引分布不好(请参阅管理数据分布)。

ClustrixGUI有一个CPU使用率图表，其中显示了过去24小时内所有节点上的最小、最大和平均CPU使用率，并分别显示每个节点上的瞬时平均CPU使用率。使用超过80%的cpu使用率的集群将受益于额外的容量，并且可能由于cpu不足而经历更高的延迟。请参阅扩展您的 Flex-Up.。

内存和磁盘I/O

缓冲区管理器遗漏率

缓冲区管理器的丢失率(在SHOW LOAD中显示为bm_miss_rate)表示读取操作丢失缓冲区缓存的频率，必须改为访问磁盘。对于带有旋转磁盘的中等负载系统，超过2%的bm_miss_rate可能与较差的系统性能相关。持久的高bm_miss_rate表明工作集(工作负载经常访问的表和索引行)超过了所有节点上可用的缓冲区缓存(内存)总量。这可能导致更高的查询延迟

如《数据分布缓存效率》中所述，缓存是ClustrixDB节点的补充。因此，可以通过向集群添加更多的节点来降低给定工作负载的bm_miss_rate(在此之前，需要将数据重新分配到新添加的节点)。在导致更多停机的同时，当然也可以向现有的节点添加更多的内存来增加总的缓存大小，从而降低bm_miss_rate。

bm_miss_rate可能会因为用户查询访问不太常见的行数据而出现峰值，例如，一些解析查询读取工作集中通常不包含的历史数据，或者运行mysqldump之类的备份任务。

磁盘延迟和吞吐量

缓冲区管理器丢失的实际成本取决于磁盘延迟。对于flash/ ssd，随机读I/O相当快，而旋转磁盘相对较慢。因此，在SSD系统上，bm_miss_rate可能远远超过2%，而不会对性能产生明显的影响。结合bm_miss_rate检查磁盘延迟指标可以帮助查明磁盘I/O子系统缓慢的原因。

以下是statd收集到的与磁盘延迟和吞吐量相关的最有用的指标:

• clustrix.io.vdev.read_latency_us.node.N.vdev.N and  clustrix.io.vdev.write_latency_us.node.N.vdev.N 表示每个节点对vdev的读写的响应时间。我们通常最关心vdev 2，它对应于每个节点的主数据存储。这里的高延迟，加上超过2%的bm_miss_rate，通常会导致较差的查询响应时间(而CPU利用率仍然相对较低)。
• clustrix.io.disk.pct_utilization.node.N.disk.X 为承载vdev文件的各个物理磁盘提供磁盘利用率度量(例如，通过md RAID设备)。它的计算方法类似于sar或iostat的利用率;此设备为I/O提供服务的运行时间百分比，其中接近100%的值表示磁盘已饱和。如果任何一个磁盘显示的值明显高于其他磁盘，那么它的性能可能很差(例如，旧的SSD经历了太多的写周期)。
• clustrix.io.vdevs.bytes_read_per_sec and clustrix.io.vdevs.bytes_written_per_sec 提供了从数据库到存储系统的整个集群范围的磁盘吞吐量度量。这些值的显著增加，加上查询延迟的增加，可能意味着I/O瓶颈。

使用SHOW LOAD

SHOW LOAD提供了一个磁盘实用工具度量，它是利用率百分比的平均值 (clustrix.io.disk.pct_utilization.node.N.disk.X, ) 遍历所有节点中的所有磁盘。

另外，请注意，SHOW LOAD反映了过去15秒内的读写活动。写操作通常在每个节点上进行缓冲，然后在定期的检查点中写入，因此预期会出现定期的峰值。但是，如果写负载始终很高，这就意味着在下一个写开始之前，检查点没有刷新所有的写，这可能表示写饱和状态

使用SAR

要更深入地研究磁盘I/O子系统的性能，可以使用sar之类的工具。

sar -b将提供从系统中所有磁盘读写缓冲区的全局视图。它给出了每个节点上磁盘利用率的总体指示器。

root@ip----:~$ sar -b
Linux 2.6.-358.14..el6.x86_64 (ip----) // _x86_64_ ( CPU)

:: PM tps rtps wtps bread/s bwrtn/s
:: PM 3143.40 374.40 2769.00 22281.60 19230.40
:: PM 3861.28 671.86 3189.42 41255.09 22692.22
:: PM 2556.43 375.10 2181.33 22207.23 14547.79
:: PM 3208.38 526.15 2682.24 32175.65 15326.15
:: PM 2202.00 502.00 1700.00 31121.76 9654.29
:: PM 2572.40 402.20 2170.20 24441.60 17152.00
:: PM 1290.18 285.37 1004.81 17590.38 5861.32
:: PM 3287.82 553.69 2734.13 34430.34 20011.18

这些数字本身并不是立即有用的，因为需要了解特定平台的磁盘子系统的基线性能。

sar -d -p将为系统上的每个存储设备提供许多指标，其中一些是立即有用的:

root@ip----:~$ sar -d -p
Linux 2.6.-358.14..el6.x86_64 (ip----) // _x86_64_ ( CPU)
:: PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
:: PM xvdap1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
:: PM xvdb 421.69 4820.88 3129.32 18.85 1.06 2.52 1.41 59.32
:: PM xvdc 391.97 4473.90 2923.69 18.87 0.90 2.31 1.37 53.88
:: PM xvdd 519.28 4986.35 3868.27 17.05 1.02 1.96 1.12 58.13
:: PM xvde 453.21 4268.27 3529.32 17.21 0.81 1.80 1.08 49.10
:: PM md0 3112.65 18562.25 13452.21 10.29 0.00 0.00 0.00 0.00

:: PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
:: PM xvdap1 0.20 3.19 0.00 16.00 0.00 7.00 7.00 0.14
:: PM xvdb 470.86 4804.79 3164.87 16.93 1.04 2.22 1.27 59.72
:: PM xvdc 518.56 4502.99 3580.04 15.59 0.86 1.65 0.99 51.28
:: PM xvdd 373.45 4534.93 2420.76 18.63 0.91 2.44 1.38 51.68
:: PM xvde 348.70 5148.10 2146.11 20.92 0.95 2.73 1.54 53.71
:: PM md0 2998.60 19003.59 11310.18 10.11 0.00 0.00 0.00 0.00

这里特别有趣的是平均队列大小(avgqui -sz)和利用率水平(%util)。如果队列大小通常大于2，或者利用率超过75%，那么很可能在磁盘I/O上出现工作负载瓶颈。这些数字应该是有用的，即使没有首先建立一个性能基线(就像sar -b的情况)。

搜索“linux sar”以获得更多关于运行和解释sar输出的信息。注意，iostat也可以用来提供类似的信息(sar和iostat都是基于内核在/proc/diskstats中收集的信息)。

网络吞吐量和延迟

数据库通常不受网络约束(与文件服务器相比)，但是，集群数据库系统依赖于节点之间的低延迟链接。对于大多数工作负载，节点之间的通信并不会消耗大量的带宽，但是，可以使用较高的消息速率;OS TCP层通常在避免网络拥塞方面做得很好。然而，当同一接口同时服务大量客户端连接和节点间通信流时，可能会出现问题，特别是在涉及进行某些软件切换的虚拟化层时;在基准测试中，我们已经看到这些因素对事务吞吐量提供了有效的限制，而标准吞吐量测试(MB/s)意味着有足够的带宽可用。

下面我们讨论两种方法来评估网络是否出现性能瓶颈。

节间的延迟

internode_latency显示每个节点上的数据库进程之间通信的往返延迟。

sql> select * from internode_latency order by ,;
+--------+----------+------------+
| nodeid | dest_nid | latency_ms |
+--------+----------+------------+
| | | 0.05 |
| | | 0.313 |
| | | 0.419 |
| | | 0.329 |
| | | 0.081 |
| | | 0.415 |
| | | 0.495 |
| | | 0.421 |
| | | 0.083 |
+--------+----------+------------+
rows in set (0.00 sec)

注意，这包括数据库进程接收和响应ping的时间，因此要测试网络延迟，请在空闲集群上运行测试。但是，这也意味着过载的数据库进程通常会导致更高的节点间延迟时间，因此可以在繁忙的系统上使用internode_latency来检测性能一般不佳的节点。在这种情况下，您通常会看到一个模式，其中一个节点报告从其他节点具有更高的延迟，而从该节点到其他节点的延迟较低:

sql> select * from internode_latency order by ,;
+--------+----------+------------+
| nodeid | dest_nid | latency_ms |
+--------+----------+------------+
| | | 0.051 |
| | | 0.285 |
| | | 10.888 | <<==
| | | 0.425 |
| | | 0.057 |
| | | 8.818 | <<==
| | | 0.487 |
| | | 0.457 |
| | | 0.156 |
+--------+----------+------------+
rows in set (0.01 sec)

请注意，上述条件是通过在节点上从linux shell运行多个CPU密集型进程(在本例中为gzip)强制实现的。

网络吞吐量

网络统计信息由statd收集，并以clustrix.io.network.*.node.*. .if.*的形式提供。其中最有用的例子有:

• clustrix.io.network.rx_bytes.node.1.if.eth0
• clustrix.io.network.rx_packets.node.1.if.eth0
• clustrix.io.network.tx_bytes.node.1.if.eth0
• clustrix.io.network.tx_packets.node.1.if.eth0

这些是原始计数器。可以通过第三方监视工具(如Cacti、Nagios或Zabbix)生成delta。

还可以使用第三方工具监视带宽使用情况，如bwm-ng。在高带宽工作负载(如备份、恢复或从多个客户端获取并行数据)期间，这对于实时监控特别有用。

ClustrixDB不太关心网络带宽。我们只观察到在虚拟环境中运行的高并发基准测试遇到VM平台每秒数据包限制的问题。