From ea0ca62584f689b14adda9f5e84a9cd887638988 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 30 Jun 2020 15:18:24 +0800 Subject: [PATCH 1/4] Fix typos in 3 DC in 2 cities deployment doc --- three-data-centers-in-two-cities-deployment.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 4d9260001d6d..9cd5fb9d293e 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -18,7 +18,7 @@ TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建 本文以北京和西安为例，阐述 TiDB 分布式数据库两地三中心架构的部署模型。 -例中，北京有两个机房 IDC1 和 IDC2，异地西安一个机房 IDC3。北京同城两机房之间网络延迟低于 3ms，北京与西安之间的网络使用 ISP 专线，延迟约 20ms。 +例中，北京有两个机房 IDC1 和 IDC2，异地西安一个机房 IDC3。北京同城两机房之间网络延迟低于 3 ms，北京与西安之间的网络使用 ISP 专线，延迟约 20 ms。 下图为集群部署架构图，具体如下： @@ -51,7 +51,7 @@ TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建 - 如上图所示，北京有两个机房 IDC1 和 IDC2，机房 IDC1 中有三套机架 RAC1、RAC2、RAC3，机房 IDC2 有机架 RAC4、RAC5；西安机房 IDC3 有机架 RAC6。 - 如上图中 RAC1 机架所示，TiDB、PD 服务部署在同一台服务器上，还有两台 TiKV 服务器；每台 TiKV 服务器部署 2 个 TiKV 实例（tikv-server），RAC2、RAC4、RAC5、RAC6 类似。 - 机架 RAC3 上安放 TiDB Server 及中控 + 监控服务器。部署 TiDB Server，用于日常管理维护、备份使用。中控 + 监控服务器上部署 TiDB Ansible、Prometheus、Grafana 以及恢复工具； -- 另可增加备份服务器，其上部署 Mydumper 及 Dranier，Drainer 以输出 file 文件的方式将 binlog 数据保存到指定位置，实现增量备份的目的。 +- 另可增加备份服务器，其上部署 Mydumper 及 Drainer，Drainer 以输出 file 文件的方式将 binlog 数据保存到指定位置，实现增量备份的目的。 ## 配置 @@ -129,7 +129,7 @@ alertmanager_servers: ![label 逻辑定义图](/media/three-data-centers-in-two-cities-deployment-03.png) -PD 设置为 PD 设置 TiKV 部署位置等级信息。 +PD 设置中添加 TiKV label 的等级配置。 ``` server_configs: @@ -162,7 +162,7 @@ tikv_servers: 在两地三中心的架构部署中，从性能优化的角度，除了常规参数配置外，还需要对集群中相关组件参数进行调整。 -- 启用 tikv grpc消息压缩 由于涉及到集群中的数据在网络中传输，需要开启 gRPC 消息压缩，降低网络流量。 +- 启用 TiKV gRPC 消息压缩 由于涉及到集群中的数据在网络中传输，需要开启 gRPC 消息压缩，降低网络流量。 ``` server.grpc-compression-type: gzip @@ -181,13 +181,13 @@ tikv_servers: raftstore.raft-max-election-timeout-ticks: 1200 ``` -- 调度设置，在集群启动后，通过 `tiup ctl pd` 工具进行调度策略修改。修改 TiKV raft 副本数按照安装时规划好的副本数进行设置，在本例中为 5 副本。 +- 调度设置，在集群启动后，通过 `tiup ctl pd` 工具进行调度策略修改。修改 TiKV Raft 副本数按照安装时规划好的副本数进行设置，在本例中为 5 副本。 ``` config set max-replicas 5 ``` -- 禁止向异地机房调度 Raft Leader，当 Raft Leader 在异地数据中心时，会造成不必要的本地数据中心与异地数据中心间的网络消耗，同时由于网络带宽和延迟的影响，也会对 TiDB 的集群性能产生影响。需要禁用异地中心的 raft leader 的调度。 +- 禁止向异地机房调度 Raft Leader，当 Raft Leader 在异地数据中心时，会造成不必要的本地数据中心与异地数据中心间的网络消耗，同时由于网络带宽和延迟的影响，也会对 TiDB 的集群性能产生影响。需要禁用异地中心的 Raft leader 的调度。 ``` config set label-property reject-leader dc 3 From e0376d51d9439df2aa3b21a4c4e3e8054f28844a Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 30 Jun 2020 15:23:56 +0800 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Lilian Lee --- three-data-centers-in-two-cities-deployment.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 9cd5fb9d293e..21dfd4eb7a98 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -18,7 +18,8 @@ TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建 本文以北京和西安为例，阐述 TiDB 分布式数据库两地三中心架构的部署模型。 -例中，北京有两个机房 IDC1 和 IDC2，异地西安一个机房 IDC3。北京同城两机房之间网络延迟低于 3 ms，北京与西安之间的网络使用 ISP 专线，延迟约 20 ms。 +本例中，北京有两个机房 IDC1 和 IDC2，异地西安一个机房 IDC3。北京同城两机房之间网络延迟低于 3 ms，北京与西安之间的网络使用 ISP 专线，延迟约 20 ms。 + 下图为集群部署架构图，具体如下： @@ -162,7 +163,8 @@ tikv_servers: 在两地三中心的架构部署中，从性能优化的角度，除了常规参数配置外，还需要对集群中相关组件参数进行调整。 -- 启用 TiKV gRPC 消息压缩 由于涉及到集群中的数据在网络中传输，需要开启 gRPC 消息压缩，降低网络流量。 +- 启用 TiKV gRPC 消息压缩。由于涉及到集群中的数据在网络中传输，需要开启 gRPC 消息压缩，降低网络流量。 + ``` server.grpc-compression-type: gzip @@ -181,7 +183,8 @@ tikv_servers: raftstore.raft-max-election-timeout-ticks: 1200 ``` -- 调度设置，在集群启动后，通过 `tiup ctl pd` 工具进行调度策略修改。修改 TiKV Raft 副本数按照安装时规划好的副本数进行设置，在本例中为 5 副本。 +- 调度设置。在集群启动后，通过 `tiup ctl pd` 工具进行调度策略修改。修改 TiKV Raft 副本数按照安装时规划好的副本数进行设置，在本例中为 5 副本。 + ``` config set max-replicas 5 From 99a86074ef0153ac302ddabe7ae77f446727d4b8 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 30 Jun 2020 17:18:38 +0800 Subject: [PATCH 3/4] Update three-data-centers-in-two-cities-deployment.md --- three-data-centers-in-two-cities-deployment.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 21dfd4eb7a98..755d24b19d36 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -20,7 +20,6 @@ TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建 本例中，北京有两个机房 IDC1 和 IDC2，异地西安一个机房 IDC3。北京同城两机房之间网络延迟低于 3 ms，北京与西安之间的网络使用 ISP 专线，延迟约 20 ms。 - 下图为集群部署架构图，具体如下： - 集群采用两地三中心部署方式，分别为北京 IDC1，北京 IDC2，西安 IDC3； @@ -165,7 +164,6 @@ tikv_servers: - 启用 TiKV gRPC 消息压缩。由于涉及到集群中的数据在网络中传输，需要开启 gRPC 消息压缩，降低网络流量。 - ``` server.grpc-compression-type: gzip ``` @@ -185,7 +183,6 @@ tikv_servers: - 调度设置。在集群启动后，通过 `tiup ctl pd` 工具进行调度策略修改。修改 TiKV Raft 副本数按照安装时规划好的副本数进行设置，在本例中为 5 副本。 - ``` config set max-replicas 5 ``` From 1e36b7f85851b2f34961b0a70f47680393cb8de5 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 30 Jun 2020 20:05:28 +0800 Subject: [PATCH 4/4] Update tune-operating-system.md --- tune-operating-system.md | 61 ++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 30 deletions(-) diff --git a/tune-operating-system.md b/tune-operating-system.md index 9f2e66303d51..305347284dd4 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -1,45 +1,46 @@ --- title: 操作系统性能参数调优 +summary: 了解如何进行 CentOS 7 系统的性能调优。 category: reference --- # 操作系统性能参数调优 -本文档仅用于描述如何优化 Centos 7 的各个子系统。 +本文档仅用于描述如何优化 CentOS 7 的各个子系统。 > **注意：** > -> 1. Centos 7 操作系统的默认配置适用于中等负载下运行的大多数服务。调整特定子系统的性能可能会对其他子系统产生负面影响。因此在调整系统之前，请备份所有用户数据和配置信息； -> 2. 请在测试环境下对所有修改做好充分测试后，再应用到生产环境中。 +> + CentOS 7 操作系统的默认配置适用于中等负载下运行的大多数服务。调整特定子系统的性能可能会对其他子系统产生负面影响。因此在调整系统之前，请备份所有用户数据和配置信息； +> + 请在测试环境下对所有修改做好充分测试后，再应用到生产环境中。 ## 性能分析工具 系统调优需要根据系统性能分析的结果做指导，因此本文先列出常用的性能分析方法。 -### 60s 分析法 +### 60 秒分析法 -此分析法由《性能之巅》的作者 Brendan Gregg 及其所在的 Netflix 性能工程团队公布，所用到的工具均可从发行版的官方源获取，通过分析以下清单中的输出，可定位大部分常见的性能问题。 +此分析法由《性能之巅》的作者 Brendan Gregg 及其所在的 Netflix 性能工程团队公布。所用到的工具均可从发行版的官方源获取，通过分析以下清单中的输出，可定位大部分常见的性能问题。 -1. uptime -2. dmesg | tail -3. vmstat 1 -4. mpstat -P ALL 1 -5. pidstat 1 -6. iostat -xz 1 -7. free -m -8. sar -n DEV 1 -9. sar -n TCP,ETCP 1 -10. top ++ uptime ++ dmesg | tail ++ vmstat 1 ++ mpstat -P ALL 1 ++ pidstat 1 ++ iostat -xz 1 ++ free -m ++ sar -n DEV 1 ++ sar -n TCP,ETCP 1 ++ top -具体用法可查询相应 man 手册。 +具体用法可查询相应 `man` 手册。 ### perf -Perf 是 Linux 内核提供的一个重要的性能分析工具，它涵盖硬件级别（CPU/PMU，性能监视单元）功能和软件功能（软件计数器，跟踪点）。详细用法请参考 [perf Examples](http://www.brendangregg.com/perf.html#Background)。 +Perf 是 Linux 内核提供的一个重要的性能分析工具，它涵盖硬件级别（CPU/PMU 和性能监视单元）功能和软件功能（软件计数器和跟踪点）。详细用法请参考 [perf Examples](http://www.brendangregg.com/perf.html#Background)。 ### BCC/bpftrace -Centos 从 7.6 版本起，内核已实现对 bpf 的支持，因此可根据上述清单的结果，选取适当的工具进行深入分析。相比 perf/ftrace，bpf 提供了可编程能力，和更小的性能开销。相比 kprobe，bpf 提供了更高的安全性，更适合在生产环境上使用。关于 BCC 工具集的使用请参考 [BPF Compiler Collection (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)。 +CentOS 从 7.6 版本起，内核已实现对 bpf 的支持，因此可根据上述清单的结果，选取适当的工具进行深入分析。相比 perf/ftrace，bpf 提供了可编程能力和更小的性能开销。相比 kprobe，bpf 提供了更高的安全性，更适合在生产环境上使用。关于 BCC 工具集的使用请参考 [BPF Compiler Collection (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)。 ## 性能调优 @@ -47,22 +48,22 @@ Centos 从 7.6 版本起，内核已实现对 bpf 的支持，因此可根据上 ### 处理器——动态节能技术 -cpufreq 是一个动态调整 CPU 频率的模块，可支持五种模式。为保证服务性能应选用 performance 模式，将 CPU 频率固定工作在其支持的最高运行频率上，不进行动态调节。命令为 `cpupower frequency-set --governor performance`。 +cpufreq 是一个动态调整 CPU 频率的模块，可支持五种模式。为保证服务性能应选用 performance 模式，将 CPU 频率固定工作在其支持的最高运行频率上，不进行动态调节，操作命令为 `cpupower frequency-set --governor performance`。 ### 处理器——中断亲和性 - 自动平衡：可通过 `irqbalance` 服务实现。 - 手动平衡： - 1. 确定需要平衡中断的设备，从 Centos 7.5 开始，系统会自动为某些设备及其驱动程序配置最佳的中断关联性。不能再手动配置其亲和性。目前已知的有使用 `be2iscsi` 驱动的设备，以及 NVME 设置； - 2. 对于其他设备，可查询其芯片手册，是否支持分发中断，若不支持，则该设备的所有中断会路由到同一个 CPU 上，无法对其进行修改，若支持，则计算 `smp_affinity` 掩码并设置对应的配置文件，具体请参考[内核文档](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)。 + - 确定需要平衡中断的设备，从 CentOS 7.5 开始，系统会自动为某些设备及其驱动程序配置最佳的中断关联性。不能再手动配置其亲和性。目前已知的有使用 `be2iscsi` 驱动的设备，以及 NVMe 设置； + - 对于其他设备，可查询其芯片手册，是否支持分发中断，若不支持，则该设备的所有中断会路由到同一个 CPU 上，无法对其进行修改。若支持，则计算 `smp_affinity` 掩码并设置对应的配置文件，具体请参考[内核文档](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)。 ### NUMA 绑核 -为尽可能的避免跨 NUMA 访问内存，我们可以通过设置线程的 CPU 亲和性来实现。对于普通程序，可使用 numactl 命令来绑定，具体用法请查询 man 手册。对于网卡中断，请参考下文网络章节。 +为尽可能的避免跨 NUMA 访问内存，可以通过设置线程的 CPU 亲和性来实现 NUMA 绑核。对于普通程序，可使用 `numactl` 命令来绑定，具体用法请查询 `man` 手册。对于网卡中断，请参考下文网络章节。 ### 内存——透明大页 -对于数据库应用，不推荐使用 THP，因为数据库往往具有稀疏而不是连续的内存访问模式，且当高阶内存碎片化比较严重时，分配 THP 页面会出现较大的延迟。伴随使能 THP 的直接内存规整功能，也会出现系统 CPU 使用率激增的现象，因此建议关闭。 +对于数据库应用，不推荐使用 THP，因为数据库往往具有稀疏而不是连续的内存访问模式，且当高阶内存碎片化比较严重时，分配 THP 页面会出现较大的延迟。若开启针对 THP 的直接内存规整功能，也会出现系统 CPU 使用率激增的现象，因此建议关闭 THP。 ``` sh echo never > /sys/kernel/mm/transparent_hugepage/enabled @@ -92,7 +93,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler 默认块大小适用于大多数使用情况。但是，如果块大小（或多个块的大小）与通常一次读取或写入的数据量相同或稍大，则文件系统将性能更好，数据存储效率更高。小文件仍将使用整个块。文件可以分布在多个块中，但这会增加运行时开销。 -使用 mkfs 命令格式化设备时，将块大小指定为文件系统选项的一部分。指定块大小的参数随文件系统的不同而不同。有关详细信息，请查询对应文件系统的 mkfs 手册页，比如 `man mkfs.ext4`。 +使用 mkfs 命令格式化设备时，将块大小指定为文件系统选项的一部分。指定块大小的参数随文件系统的不同而不同。有关详细信息，请查询对应文件系统的 `mkfs` 手册页，比如 `man mkfs.ext4`。 #### 挂载参数 @@ -100,18 +101,18 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler ### 网络 -网络子系统由具有敏感连接的许多不同部分组成。因此，Centos 7 网络子系统旨在为大多数工作负载提供最佳性能，并自动优化其性能。因此，通常无需手动调整网络性能。 +网络子系统由具有敏感连接的许多不同部分组成。因此，CentOS 7 网络子系统旨在为大多数工作负载提供最佳性能，并自动优化其性能。因此，通常无需手动调整网络性能。 网络问题通常由硬件或相关设施出现问题导致的，因此在调优协议栈前，请先排除硬件问题。 -尽管网络堆栈在很大程度上是自我优化的，但是在网络数据包处理过程中有许多要点可能会成为瓶颈并降低性能： +尽管网络堆栈在很大程度上是自我优化的。但是在网络数据包处理过程中，以下方面可能会成为瓶颈并降低性能： - 网卡硬件缓存：正确观察硬件层面的丢包方法是使用 `ethtool -S ${NIC_DEV_NAME}` 命令观察 drops 字段。当出现丢包现象时，主要考虑是硬/软中断的处理速度跟不上网卡接收速度。若接收缓存小于最大限制时，也可尝试增加 RX 缓存来防止丢包。查询命令为：`ethtool -g ${NIC_DEV_NAME}`，修改命令为 `ethtool -G ${NIC_DEV_NAME}`。 -- 硬中断：若网卡支持 Receive-Side Scaling（RSS 也称为多网卡接收）功能，则观察 /proc/interrrputs 网卡中断，如果出现了中断不均衡的情况，请参考处理器调优章节。若不支持 RSS 或 RSS 数量远小于物理 CPU 核数，则可配置 Receive Packet Steering（RPS，可以看作 RSS 的软件实现），及 RPS 的扩展 Receive Flow Steering (RFS)。具体设置请参考[内核文档](https://www.kernel.org/doc/Documentation/networking/scaling.txt)。 -- 软中断：观察 /proc/net/softnet\_stat 监控，如果除第三列的其他列的数值在增长，则应适度调大 net.core.netdev\_budget 或 net.core.dev\_weight 值，使 softirq 可以获得更多的 CPU 时间。除此之外，也需要检查 CPU 使用情况，确定哪些任务在频繁占用 CPU，能否优化。 +- 硬中断：若网卡支持 Receive-Side Scaling（RSS 也称为多网卡接收）功能，则观察 `/proc/interrrputs` 网卡中断，如果出现了中断不均衡的情况，请参考处理器调优章节。若不支持 RSS 或 RSS 数量远小于物理 CPU 核数，则可配置 Receive Packet Steering（RPS，可以看作 RSS 的软件实现），及 RPS 的扩展 Receive Flow Steering (RFS)。具体设置请参考[内核文档](https://www.kernel.org/doc/Documentation/networking/scaling.txt)。 +- 软中断：观察 `/proc/net/softnet\_stat` 监控。如果除第三列的其他列的数值在增长，则应适度调大 `net.core.netdev\_budget` 或 `net.core.dev\_weight` 值，使 softirq 可以获得更多的 CPU 时间。除此之外，也需要检查 CPU 使用情况，确定哪些任务在频繁占用 CPU，能否优化。 - 应用的套接字接收队列：监控 `ss -nmp` 的 `Recv-q` 列，若队列已满，则应考虑增大应用程序套接字的缓存大小或使用自动调整缓存的方式。除此之外，也要考虑能否优化应用层的架构，降低读取套接字的间隔。 - 以太网流控：若网卡和交换机支持流控功能，可通过使能此功能，给内核一些时间来处理网卡队列中的数据，来规避网卡缓存溢出的问题。对于网卡测，可通过 `ethtool -a ${NIC_DEV_NAME}` 命令检查是否支持/使能，并通过 `ethtool -A ${NIC_DEV_NAME}` 命令开启。对于交换机，请查询其手册。 - 中断合并：过于频繁的硬件中断会降低系统性能，而过晚的硬件中断会导致丢包。对于较新的网卡支持中断合并功能，并允许驱动自动调节硬件中断数。可通过 `ethtool -c ${NIC_DEV_NAME}` 命令检查，`ethtool -C ${NIC_DEV_NAME}` 命令开启。自适应模式使网卡可以自动调节中断合并。在自适应模式下，驱动程序将检查流量模式和内核接收模式，并实时评估合并设置，以防止数据包丢失。不同品牌的网卡具有不同的功能和默认配置，具体请参考网卡手册。 -- 适配器队列：在协议栈处理之前，内核利用此队列缓存网卡接收的数据，每个 CPU 都有各自的 backlog 队列。此队列可缓存的最大 packets 数量为 netdev\_max\_backlog。观察 /proc/net/softnet\_stat 第二列，当某行的第二列持续增加，则意味着 CPU [行-1] 队列已满，数据包被丢失，可通过持续加倍 net.core.netdev\_max\_backlog 值来解决。 -- 发送队列：发送队列长度值确定在发送之前可以排队的数据包数量。默认值是 1000，对于 10Gbps 足够。但若从 `ip -s link` 的输出中观察到 TX errors 值时，可尝试加倍：`ip link set dev ${NIC_DEV_NAME} txqueuelen 2000`。 +- 适配器队列：在协议栈处理之前，内核利用此队列缓存网卡接收的数据，每个 CPU 都有各自的 backlog 队列。此队列可缓存的最大 packets 数量为 `netdev\_max\_backlog`。观察 `/proc/net/softnet\_stat` 第二列，当某行的第二列持续增加，则意味着 CPU [行-1] 队列已满，数据包被丢失，可通过持续加倍 `net.core.netdev\_max\_backlog` 值来解决。 +- 发送队列：发送队列长度值确定在发送之前可以排队的数据包数量。默认值是 1000，对于 10 Gbps 足够。但若从 `ip -s link` 的输出中观察到 `TX errors` 值时，可尝试加倍该数据包数量：`ip link set dev ${NIC_DEV_NAME} txqueuelen 2000`。 - 驱动：网卡驱动通常也会提供调优参数，请查询设备硬件手册及其驱动文档。