不同业务场景性能优化实践

云平台对不同业务场景均有较多优化配置，基于便捷及高效的原则，逐步进行优化。

场景实践：数据库业务的性能优化实践

数据库业务在云计算业务系统中是最重要的一种业务之一，对业务系统的性能、并发性、可用性都存在极高的要求。如果性能不达预期会带来较大的业务卡顿影响。

某项目的云平台在运行数据库业务时，应用系统反馈访问数据库的业务卡顿，体验不好，需要优化解决。接下来以具体案例分析，并提供平台层面在使用数据库时的优化实践。

场景描述：

  • 平台信息：ZStack Cloud云平台 4.2.0，物理机系统CentOS7.6，分布式存储计算存储分离部署。
  • 物理机信息：Intel 6258R，单颗CPU二十八核心，2颗48个核心，96个线程，该节点只运行一个96核 512G的数据库云主机。
  • 存储信息：存储万兆网络，采用纯SSD作为存储介质。
  • 网络信息：业务使用双千兆网络。
  • 数据库业务：Windows 2016云主机运行SQL server。
  • 业务卡顿的具体表现：数据库业务高峰期CPU利用率在100%运行，云主机互ping网络延迟会高，会存在丢包，丢包比例达0.3%。导致业务卡顿，影响生产业务。

性能分析：

  1. 数据库业务高峰期的CPU利用率持续在100%高位运行，物理机的CPU利用率也同时会提升到98%。
  2. 当时分布式存储IO写的延迟最高在2ms，存储网络写带宽最高在116MB/s。云主机业务网络的带宽峰值在65MB/s。可见存储层面不是整体的瓶颈。网络带宽也不是业务的瓶颈。但CPU利用率高后，导致CPU处理网络相关中断出现异常，存在丢包和延迟问题。瓶颈本身整体还是在CPU和内存层面。
  3. 数据库业务存在全表查询，会大量占用资源，也需要继续优化。

在不考虑数据库本身架构设计层面的优化（读写分离、分库分表、减少全表扫描），在底层基础设施层面，影响较大的层面有：

  • 存储性能及存储选择：随机读写的IOPS、读写延迟、IO扩展能力、IO稳定性。
    • IOPS层面：通常Ceph存储具备扩展的IOPS能力，可以达到20W以上。SAN存储根据不同配置，高阶存储也可达到数十万IOPS，甚至更高。本地存储依赖于RAID卡，同时受制于底层硬盘的数量和能力，相对而言能力较为受控。
    • IO延迟：本地存储最优、其次SAN存储、再次Ceph存储。
    • IO扩展层面：Ceph存储最优、其次SAN存储、再次本地存储。
    • IO稳定性：SAN存储最优、其次本地存储、再次Ceph存储。
    • 通常在存储选择上，核心数据库业务通常建议选择SAN存储，在5-10ms内延迟要求的数据库业务，可以选择Ceph存储。如果数据库云主机采用多个数据库配置了数据库集群配置了高可用，也可以采用本地存储（配置RAID10）。在具体的存储介质上，数据库业务建议使用高性能SSD或者PCIE SSD，可以获得更高的IOPS能力。
  • 网络性能：网络低延迟、高带宽。
  • CPU：数据库业务对CPU也有强要求，对并发比较高的场景，建议配置更多核的CPU，对密集型场景，建议配置高频的CPU。

针对上述业务进行了以下变更：

  • Virtio平台类型、Virtio blk云盘、Virtio驱动配置；
  • CPU模式配置为host-passthrough；
  • 整体CPU数量配置为84个，CPU配置了vNUMA模式，并配置了CPUPin绑定；
  • 物理机配置了大页内存，云主机使用大页内存；
  • 云主机网卡开启多队列模式；
  • 物理机在BIOS关闭了节能模式，更新了内核版本；
  • 物理机grub设置了isolcpus的CPU隔离；
  • 物理机关闭了KSM，避免后续云主机的内存同页合并。

配置完毕，云主机的CPU在业务高峰期使用平均下降到40%左右，云主机ping延迟已恢复正常，网络不再丢包。

上述的云平台在数据库层面的优化实践，可以在相关CPU压力较大的业务场景可借鉴参考优化。

总结：

针对优化的效率，一般而言，Virtio对性能的优化最高，其次是vNUMA的正确调度，接着是大页内存，再次是关闭KSM、物理机更新内核、CPU Pin影响效果差不多，最后是isolcpus的CPU隔离及其他相关优化。

场景实践：UDP视频码流丢包优化实践

在视频码流传输推送、GPU计算取流应用中，会使用UDP协议传输数据，经常会遇到UDP丢包的场景。

针对UDP协议的丢包优化可以重点参考以下要点：

  • 物理网卡或网卡驱动丢包： ​ 如果在物理机上使用ethtool -S em01 |grep errors 显示结果中 rx*_errors 有数据值 那么很可能是网卡有问题（正常情况应为0），导致系统丢包。

  • UDP 报文错误： ​ 如果在传输过程中UDP报文被修改，会导致checksum错误或者长度错误，linux在接收到UDP报文时会对此进行校验，一旦发现错误会把报文丢弃。

  • 防火墙： ​ 如果系统防火墙丢包，表现的行为一般是所有的UDP报文都无法正常接收，当然不排除防火墙只drop一部分报文的可能性。

  • UDP buffer size 不足： ​ linux系统在接收报文之后，会把报文保存到缓存区中。因为缓存区的大小是有限的，如果出现 UDP 报文过大（超过缓存区大小或者MTU大小）、接收到报文的速率太快，都可能导致 linux 因为缓存满而直接丢包的情况。此场景会严重影响UDP数据传输，也是通常优化的重点。

  • 系统负载过高：

    • 系统CPU、内存、IO负载过高都有可能导致网络丢包。
    • 比如CPU如果负载过高，系统没有时间进行报文的checksum计算、复制内存等操作，从而导致网卡或者 socket buffer 出现丢包。
    • 内存负载过高，引起应用程序处理过慢无法及时处理报文；IO负载过高，CPU都用来响应IOwait，没有时间处理缓存中的UDP报文。

具体到UDP本身的优化选项，以云主机内部为例，UDP的优化项目如下：

  • 优化1：云主机内部调整UDP Buffer。
sysctl -w net.core.rmem_max=83886080
sysctl -w net.core.rmem_default=83886080
sysctl -p
  • 优化2：云主机内部调整最大可分配的缓冲区大小。
sysctl -w net.ipv4.udp_mem="262144 41943040 83886080"
sysctl -w net.core.netdev_max_backlog=2000;
sysctl -p
  • 优化3：云主机内部调整网卡的RPS（接收包控制）相关参数。
echo 'ff' > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 'ff' > /sys/class/net/eth0/queues/tx-0/xps_cpus
echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
echo 131072 > /proc/sys/net/core/rps_sock_flow_entries

优化参数详解：

net.core.rmem_max                    #UDP接收套接字缓冲区大小的最大值(以字节为单位)。
net.core.rmem_default                #UDP接收套接字缓冲区大小的默认值(以字节为单位)。
net.core.netdev_max_backlog     #表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。
net.ipv4.udp_mem                     #表示UDP最大可分配的缓冲区空间总量,数值以页面为单位。
/sys/class/net/eth0/queues/rx-0/rps_cpus     #接收队列绑定
/sys/class/net/eth0/queues/tx-0/xps_cpus     #发送队列绑定

另外在底层虚拟化层面，可以配置网卡多队列、CPU绑定等配置网卡多队列请求和CPU绑定来优化UDP的传输。

注意事项：

  • 在UDP优化层面，也可尝试采用SRIOV网卡，相比VirtIO网卡在视频码流传输上，CPU利用率占用的更少一些。
  • UDP丢包优化，主要优化手段还是在云主机内部优化，尤其是UDP buffer的调整。
  • SRIOV对UDP视频码流传输存在一定的优化效果，但效果没有预期高。
  • 丢包测试如果采用iperf3来抓取UDP丢包，在业界也一直存在争议，可能不太准确。
  • 网络压力较大的情况下，如果使用tcpdump抓包，也会存在相应的误判，将非内核丢弃的包，认定为内核丢包。
  • 丢包判断可以在云主机内存查看UDP的error是否在持续增加，运行以下命令watch "cat /proc/net/snmp|grep Udp -w|column -t"来持续观察。

总结：

  • UDP本身是无连接不可靠的协议，适用于报文偶尔丢失也不影响程序状态的场景，对可靠性要求比较高的应用不要使用 UDP，推荐直接使用 TCP。也可以在应用层做重试、去重保证可靠性。
  • 如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失。
  • 如果系统负载过高，UDP丢包是没有有效解决方案的。如果是资源不够，快速扩容。
  • 对于系统大量接收或者发送 UDP 报文的，可以通过调节系统和程序的 socket buffer size 来降低丢包的概率 （优化参数部分内容）。
  • 应用程序在处理UDP报文时，需采用异步方式，在两次接收报文之间不要有太多的处理逻辑。

扩展阅读

云平台层面相关的优化配置

  • Virtio平台类型：Windows云主机系统支持使用Virtio来优化磁盘IO性能。
  • Virtio blk：Windows云主机云平台使用Virtio blk类型，不使用Virtio scsi，Virtio blk类型云盘在效率和性能较Virtio scsi略高。
  • Virtio驱动：使用最新的Windows Virtio驱动，以提升IO性能。
  • CPU模式：云主机开启CPU模式设置为host-passthrough，以支持数据库业务对特殊指令集的要求。
  • CPU数量：云主机的CPU数量并非越高越好，数量不合理会导致CPU异常使用率高。最佳实践：关闭物理机超线程，单个云主机的CPU上限不超过单个NUMA节点CPU的数量。
  • CPU Pin绑定：将云主机的VCPU绑定到物理的CPU，减少中断在CPU之间的切换调度，注意：物理机的CPU 0一般处理中断、虚拟化等任务，不建议将其Pin到云主机上。
  • vNUMA：NUMA架构下，多路CPU的跨CPU访问内存效率会降低，配置vNUMA结构后，使云主机在CPU访问内存时不跨物理CPU。
  • 物理机设置isolcpus：将运行业务云主机的相关物理CPU预留，将其隔离出来，底层物理机操作系统不可使用，单独配置给业务云主机使用。
  • 大页内存：使用2M的大页内存，替换默认的4K页面，减少云主机页面缓存和缺页中断的切换，提高运行性能。注意：大页内存需配合物理机的保留内存使用，为操作系统相关的基础业务保留必要的内存。
  • 网卡多队列：支持Virtio类型的网卡流量分配给多个CPU，并行处理中断。
  • 关闭内存KSM：关闭物理机内存同页合并技术，避免相同内存页面被共用。
  • 关闭CPU节能模式：物理机在BIOS层面关闭CPU节能模式，以性能模式运行。
  • 升级物理机内核：更高的内核在系统层面性能会提升，对云主机相关性能有一定提升。

results matching ""

    No results matching ""