读性能慢-物理环境排查

🌌 运维指南 Trouble Shooting 指南
1

  1. 客户端到 Load Blance\TiDB Server 网络情况

  • 问题定位
    在执行 SQL 请求客户端，通过 Ping 命令确认到目标IP 之间的网络情况（如环境已禁止了 ICMP 协议可以使用 Tcping 进行确认）。一般内网环境 Ping 命令延迟应在 200μs 左右，丢包率在 0%。跨机房环境延迟在 2ms-5ms左右，丢包率小于 1%（如果网络环境存在丢包情况，延迟情况将被放大）。如果希望更加详尽的监控统计，可以使用 “MTR” 或 “WinMTR”

  • 解决方法
    更换更加稳定的网络线路，建议满足万兆带宽，Ping 延迟在 200μs 以内，丢包率 0%

4

  1. 服务器是否有网络异常

    网络抖动

  • 问题定位
    通过 TiDB 监控
    Blackbox-expoter → Network Status → Ping Latency
    来确认 Instance 到各个 host 的网络情况，正常情况下各个服务器延迟抖动应在 2ms 以内，如果抖动过大需要排查对应 Host 网络延迟的根因。
    （如果展示数据因为过长而不能看清，可以通过修改 监控面板 Edit → A → Legend → {{ping}} 来展示 目标 Host IP）

    image
    image1014×370 62.6 KB

  • 解决方法
    更换更加稳定的网络线路，建议满足万兆带宽，Ping 延迟在 200μs 以内，丢包率 0%

    带宽打满

  • 问题定位
    通过监控项
    Overview → System Info → Network Traffic
    观察问题时间段内是否有 host出现网络带宽接近 100%

  • 解决方法
    如果服务节点间的混部导致的网络带宽打满情况，请排查部署是否符合 部署最佳实践
    如果问题节点是 某一 TiDB 节点，应排查 TiDB 的请求是否经过 LB 进行负责均衡，避免所有请求都集中在一台 TiDB 上。

5

  1. 系统配置是否符合最佳实践

    TiDB Server -> 计算密集型服务
    TiKV Server -> IO密集型服务、计算型服务
    TiFlash Server -> IO密集型服务、计算密集型服务
    PD Server -> 均衡型服务

  • 问题定位
    TiDB 分布式数据库，为了满足生产环境的可用性，对硬件资源是有较高要求，往往很多性能问题都是由于硬件资源不达标导致的，性能表现异常。所以请一定核对现有集群是否满足配置要求

    组件 CPU 内存 磁盘 网络
    TiDB 16 Core+ 32 GB+ SAS HDD 万兆网卡
    TiKV 16 Core+ 32 GB+ SSD 万兆网卡
    PD 4 Core+ 8 GB+ SSD 万兆网卡
    TiFlash 48 Core+ 128 GB+ SSD or more 万兆网卡
    TiCDC 16 Core+ 64 GB+ SAS HDD 万兆网卡

    注意：

    CPU 主频应至 ≥ 2 GHz
    SSD 磁盘 顺序写随机读的 IOPS 应≥ 10000+，带宽 > 1000 MB
    SSD 磁盘容量推荐 1T 以上，但不要大于 2T。防止当 TiKV 实例管理的 region 数量过多。如果磁盘容量在 3T 或以上，在 CPU 与内存资源满足的情况下可以考虑 单机双 TiKV 实例部署

    同时相关系统设置也应符合最佳实践建议

  • 解决方法
    按照最佳实践配置部署服务器
    TiDB 软件和硬件环境建议配置
    TiDB 环境与系统配置检查

6

  1. 硬件资源不足

    CPU 资源不足

  • 问题定位
    HOST System Info
    Overview → System Info
    查看各 Host 的 CPU Core、CPU Usage、CPU Load
    TiKV CPU
    Overview → TiKV → CPU
    查看各 TiKV Instance CPU 使用情况（此处统计的是每个 CPU CORE 的 SUM 值 ）
    TiDB CPU
    TiDB → Server → CPU Usage
    查看各 TiDB CPU 使用情况 （此处统计的是每个 CPU CORE 的 SUM 值 ）
    通常TiDB 实例与TiKV 实例均对 CPU 有一定要求，如果实例存在混部，很容易导致资源竞争，从而影响 TiDB 集群的读性能
    PS. 如果 TiDB Server 与 PD 进行混部。当 TiDB CPU 很高，且当前 HOST 上的 PD 实例为 Leader ，将可能影响 PD 处理 TSO 的性能，从而影响 TiDB 集群读性能

  • 解决方法
    统一各服务模块的硬件配置
    如 HOST 资源不满足，或者相同模块实例配置不统一，将会出现不可预测的情况。TiKV 实例尤为明显，尤其 IO 性能与 CPU 性能各 host 不统一时，会出现局部热点情况。
    缩容混部的服务实例
    如是实例的混部，可以参考官方文档 “混合部署拓扑” 进行配置
    如果资源不满足官方推荐配置，强烈建议避免混部服务，可使用 TiUP 对实例进行 缩容操作

    IO 资源不足

  • 问题定位
    Disk-Performance → Disk Latency 磁盘响应延迟(默认看到的是 Read Latency，需要通过 修改监控面板来展示写 Write Latency)

    image
    image932×436 92.5 KB

    正常情况Latency 应小于 1ms ，不应高于 2ms

    Disk-Performance → Disk Bandwidth 磁盘带宽
    SSD 的接口协议分为 NVME 、AHCI 一般对应 PCIE 接口与 SATA 接口
    PCIE 3.0 理论带宽 32Gib
    SATA 3.0 理论带宽 6GiB
    PS.由于各品牌和型号不一，IOPS 性能也不同这里同时给出一个 IOPS 的参考值
    iofile 测试 16K chunk 顺序写与随机读性能均 ≥ 10000 IOPS

    image
    image904×242 58.3 KB

  • 解决方法

    升级硬件

    更换带宽更高的硬件设备，或者缩容混部的服务实例
    如果是 PCIE 接口的 SSD ，理论上可以一台 HOST 服务器部署两个 TiKV 实例
    缩容混部的服务实例
    如是实例的混部，可以参考官方文档 “[混合部署拓扑] (https://docs.pingcap.com/zh/tidb/stable/hybrid-deployment-topology)” 进行配置
    如果资源不满足官方推荐配置，强烈建议避免混部服务，可使用 TiUP 对实例进行 缩容操作

7

感谢分享