CCAV - 媚眼如初 岁月如故 - Linux
type: channel
link: https://ccav.me/tag/Linux/
items: RPS和RFS网卡多队列性能调优实践
items: LVM卷删除恢复
items: chattr命令用法

RPS和RFS网卡多队列性能调优实践
type: item
date: 2025-04-08T22:57:00+08:00
description: 前言为了解决 LVS ksoftirqd CPU 使用率 100% 导致网卡软中断丢包，我和同事们一起搜索了大量的资料去分析问题，特别是感谢美团技术团队的分享帮助我们快速梳理优化思路，最后明确了如何重构 RPS 和 RFS 网卡多队列的优化脚本。个人认为这是一个大家可能普遍会遇到的问题，文章内的分析思路和解决方案未必是最优解，也欢迎各位分享自己的解决方法。RPS 和 RFS 网卡多队列性能调优实践更新历史2019 年 07 月 03 日 - 初稿阅读原文 - https://wsgzao.github.io/post/rps/扩展阅读Redis 高负载下的中断优化 - https://tech.meituan.com/2018/03/16/redis-high-concurrency-optimization.html事故复盘我们遇到的问题属于计划外的 incident，现象是某产品用户在线率突然降低，LVS Master 同时收到 CPU High Load 告警，检查发现该节点出现网卡大量断开重连和丢包情况，应急切换到 LVS Slave 也出现上述问题，在排除掉流量异常和外部攻击后选择切换 DNS 到背后的 Nginx Real Servers 后服务逐步恢复。复盘核心原因在于系统初始化时 rps 优化脚本没有成功执行，这个脚本起初是因为早期 DBA 团队遇到过 CPU 负载较高导致网卡异常，这个优化脚本也一直传承至今，却已经没有人知道为什么添加。现在大多数服务器没有执行成功而被大家一直所忽视显然也是 post check 没有做到位。在早期大家都停留在 Bash Shell 运维的阶段，没有专职的团队来管理确实容易失控，好在现在可以基于 Ansible 来做初始化和检查，运维的压力也减轻了一部分。通过 Google 搜索相关知识的过程中，我们也发现在不少人都会遇到这样类似的问题。比如这篇文章提到 lvs/irqlvs 的性能问题，软中断耗尽 CPU 单核后到达处理极限瓶颈现象：当压力较大时，Lvs 服务器 CPU 的其中一个核使用率达到 100%（处理软中断）。当 Lvs 服务器处理软中断的那个核使用率达到 100%，就到达系统处理上限。占用 CPU 的是进程 “ksoftirqd”，它未能使用到多核。做双网卡绑定，然后调试内核 SMP，中断主要是来自网卡的，不是 LVS 本身。需要把 2 个网卡来的 IRQ 均衡在双核 CPU 上面。和华为的工程师们在交换经验的时候对方分享了一个关于 RSS 和 RPS 关系图，之后的内容还会引用美团技术团队的分析我们遇到的情况是缺少可用服务器资源选择把用户外部请求流量和 Codis Cache Cluster 内部流量临时混在了同一个 LVS 上，虽然看上去 CPU 和 traffic 的整体压力都不算高，但是 CPU 的处理压力可能恰好集中在了和外网 Bond1 网卡相同的 Core 上最后引起了 ksoftirqd 软中断，而内网 Bond0 网卡就没有监控到任何丢包。虽然我们也有正常开启 irqbalance，但不清楚是不是因为受到 cpupower performance 和 NUMA 的影响最后也没能阻止事故的发生，最终的优化方案主要是手动开启 RPS 和 RFS，大致步骤如下：set cpupower cpupower frequency-set -g performance，CPU 优化建议使用 cpupower 设置 CPU Performance 模式activate rps/rfs by script: rps.shdouble ring buffer size: ethtool -G p1p1 [rx|tx] 4096, check ethtool -g p1p1double NAPI poll budget: sysctl -w net.core.netdev_budget=600add zabbix monitor on net.if.in[eth0,errors,dropped,overruns], CPU softirq time system.cpu.util[,softirq]#!/bin/bash # chkconfig: 2345 90 60 ### BEGIN INIT INFO # Provides: rps # Required-Start: $local_fs $remote_fs $network $syslog # Required-Stop: $local_fs $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-De…

LVM卷删除恢复
type: item
date: 2022-12-15T10:56:00+08:00
description: 该文章内容提及的第二步有一定几率会出现事故的风险。 LVM删除一些分区后数据仍然保留在磁盘内，只要没有被完全覆盖是可以恢复的。大致上3个步骤完成：第一步查找出日志位置，第二步恢复分区，第三步激活分区。以下内容的约定：卷组名为vggroup，kvm*_img为卷。恢复卷的对象是kvm22572_img第一步查找日志#vgcfgrestore -l /dev/vggroup vgcfgrestore -l /dev/vggroup|grep -B2 -A1 lvremove 执行后可以看到类似以下的日志内容。在日志内找到了kvm22572_img卷然后对应的File是/etc/lvm/archive/vggroup_01087-654942930.vg-- File: /etc/lvm/archive/vggroup_01087-654942930.vg VG name: vggroup Description: Created *before* executing 'lvremove -v -f /dev/vggroup/kvm22572_img' Backup Time: Thu Dec 15 10:35:29 2022 -- File: /etc/lvm/backup/vggroup VG name: vggroup Description: Created *after* executing 'lvremove -v -f /dev/vggroup/kvm22572_img' Backup Time: Thu Dec 15 10:35:29 2022 第二步对卷进行恢复vgcfgrestore /dev/vggroup -f /etc/lvm/archive/vggroup_01087-654942930.vg *执行命令后会有回显信息 Restored volume group vggroup第三步对卷做激活。lvchange -a y /dev/vggroup/kvm22572_img 本文转载自 http://www.kvm.la/910.html

chattr命令用法
type: item
date: 2017-04-28T22:20:00+08:00
description: chattr命令常用于锁定一个文件，禁止任何人修改/替换文件lsattr //查看文件属性 chattr +i //锁定文件 chattr -i //删除+i的属性 i表示不得任意更动文件或目录