21. ClustrixDB 识别平台限制

本节描述集群性能上潜在的限制平台因素，如何度量集群是否接近或超过这些限制，以及纠正这些条件的可用选项。“平台因素”指的是硬件资源，如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平台每秒数据包限制的问题。