一个openvpn无法安装的问题 问题背景 某个新同时电脑 openvpn 安装不成功，分别让其测试使用了管理员权限以及最新版的 openvpn 客户端，但最终都是报的同一个错误，如下: tap_create_adapter: DinstallDevice failed error OpenVPNMSICA tap_create_adapter Error 536870397 分析日志 经过排查后，并没有发现明确的问题，但是其他案例给了我们启发，可以通过日志文件 C:/Windows/INF/setupapi.dev.log 查看到具体的安装异常: openvpn unable to select best compatible driver 可以看到 openvpn 无法选择正确的驱动安装上，导致最后的报错，所以基本上可以确定是电脑、或者其他软件影响的问题 参考文档 https://forums.openvpn.net/viewtopic.php?t=31235 文档没有明确的解决方案，最后是升级系统解决了 解决 既然是电脑、或者软件、或者硬件不匹配导致驱动无法正常安装，所以最后推荐尝试重新安装系统，再重新安装后反馈问题解决

h3c无线之雷达信道的影响 0x1 现象 部分区域的同事基本上同时断网（漫游到其他AP上），同时观察此AP，发现指示灯为绿色常亮，过一段时间（大概数十秒或数分钟）后恢复正常。 架构及型号： AC： MSG360-20 AP: WAP712c、WAP712C-LI AC接三层下，AC下联POE交换机，AP接入POE交换机，所有配置基本上都是型号模板配置，所以应该不是配置问题，因为目前基本上相同的配置，只收到此AP有故障现象。 0x2 初步排查 通过对比时间，AP指示灯状态，再检索日志，发现如下异常： Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client f46a-dd6e-2ced went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client e00a-f671-e9f1 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client acbc-3278-d889 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client c889-f3ac-2271 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client bc03-5872-49fd went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). 可以看到先提示了信道改变，原因是: Radar channel recover ，然后下面就是客户端离线，原因是通道（信道）改变。 于是登录AC控制台查看了信道射频相关的配置，可以确定没有开启信道定时自动调优，但AP的信道设置是自动信道不锁定，结合信道会变化，怀疑是这里问题，于是修改为自动信道并锁定。 但设置后并没有恢复正常超过半天，又出现了同样的问题。所以可确定不是此配置影响，而目前最大的疑问在于，为什么锁定了信道仍然会自动变化，为什么其他AP不会变化，难倒是AP物理上存在故障了？ 0x3 radar? 在修改锁定信道也无法解决问题后，又尝试重启了AP，但后续也发现无法解决，所以目前为止比较怀疑的是AP硬件或者软件存在故障或BUG 不过仍然在百度和google查询了 Radar channel recover ，毕竟这里可能是唯一的错误信息了，但检索基本没有得到有效信息。 在一筹莫展的时候，我反复在想为什么配置了 锁定信道 但仍然会切换，这显然是软件行为，比锁定信道的优先级都高，于是我查询 H3C 中关于信道锁定的部分配置 auto lock ，这一查，终于发现了蹊跷： 【缺省用户角色】 network-admin 【参数】 channel-number：手动配置的射频工作信道。取值范围由区域码和射频模式决定。 auto lock：自动选择信道并加锁模式，由设备根据实际环境自动选择最优信道，并将该信道锁定。 auto unlock：自动选择信道并解锁模式。由设备根据实际环境自动选择最优信道，并将该信道设置为无锁模式。 【使用指导】 在手工指定工作信道模式时，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。AP会在30分钟后将信道切换回手工指定的信道，并静默一段时间，如果在静默时间内没有发现雷达信号，则开始使用该信道；如果发现雷达信号，则再次切换信道。 在自动选择信道模式上，无论信道加锁与否，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。 在只看参数的时候我觉得挺正常的， lock、unlock 在是意料之中的行为，不过在使用指导中发现了关键字 雷达，并且整体解释大意为，不论是手动设置、自动设置信道，不论是否加锁，只要检测到雷达信号，则会立即切换到其他信道，这和我遇到的现象是一模一样的。所以断网的原因终于找到了，那为什么会出现这个问题呢？ 0x4 原因 首先AP进行了信道切换，所以可以判断雷达也是有相关的信道，并且可能在当时发生冲突了。所以我们可以了解雷达信道的范围，检索的资料如下： 什么是雷达信道 信道52，56，60，64，100，104，108，112，116，120，124，128，132，136，140，144可作为雷达信道，如果某国家和地区支持的信道和雷达信道有重叠，则使用信道时请尽量避开雷达信道。当AP工作在5G射频频段时，AP通过DFS功能，进行雷达检测，当检测到雷达信道后会自动切换到其他工作信道，避免干扰雷达。 思科关于DFS和雷达信号的介绍 在了解了基本情况之后，我们大概可以知道，是因为AP检测到了相同信道的雷达信号，所以立即切换了信道，但这里仍然有疑点，室内真的存在雷达信号吗？并且一天中随机出现，这个我们无法验证，但解决办法是什么呢？ 既然雷达信道和wifi信道有一定重合，但wifi信道也较多，所以可以手动设置AP信道，在当前网络架构中完全不使用雷达信道 关闭雷达检测 `radar-detect disable` （不建议此方法） 此次问题是发生在室内，正常应该不存在雷达信号，所以基本上是误判，可以提交问题给厂家 或者 尝试升级 AC 固件版本。（本次升级后解决，如果升级后仍未解决可以采用更换非雷达信道办法） PS. 关于多个AP使用雷达信道 AP检测雷达信号使用的DFS技术，虽然是同一个信道，但能够判断具体是 WIFI 信号还是雷达信号，所以多个AP使用同一个雷达信道，也是不会发生切换的 其他 最后通过检索之前日志中的 radar ，发现不少 AP 其实是切换过信道的 Dec 4 09:20:44 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 40 to 60, Reason: Radar channel recover. Dec 4 09:21:21 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 165 to 56, Reason: Radar channel recover. Dec 4 12:16:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 153, Reason: Avoid radar channel. Dec 4 12:16:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 48, Reason: Avoid radar channel. Dec 4 12:46:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 153 to 52, Reason: Radar channel recover. Dec 4 12:46:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 48 to 56, Reason: Radar channel recover. Dec 4 13:25:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 165, Reason: Avoid radar channel. Dec 4 13:55:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 165 to 60, Reason: Radar channel recover. Dec 4 15:21:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 52, Reason: Avoid radar channel. Dec 4 15:51:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 52 to 60, Reason: Radar channel recover. Dec 4 18:02:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 48, Reason: Avoid radar channel. Dec 4 18:32:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 48 to 52, Reason: Radar channel recover. Dec 4 18:34:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 60, Reason: Avoid radar channel. Dec 4 19:04:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 60 to 56, Reason: Radar channel recover. Dec 4 19:40:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 60 to 161, Reason: Avoid radar channel. Dec 4 19:54:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 52 to 44, Reason: Avoid radar channel. Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:24:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 44 to 52, Reason: Radar channel recover.

Linux OOM分析工具 0x00 https://www.carstengrohmann.de/oom/ https://carstengrohmann.de/oomanalyser.html

gitlab高负载高cpu使用率 0x1 问题 gitlab某个时刻非常卡，网页打开都很慢。登录后可以看到负载较高、cpu使用率较高，可以确定是cpu使用过高引起的。 继续 在 top 中排序 发现 bundle 进程使用率非常高，根据进程号查询明细，可以看到是 sidekiq 进程 0x2 分析解决 sidekiq在gitlab服务中是作为任务调度使用的，相关的内容在管理员后台 -> 监控 -> 后台任务 中。所以调整的思路是控制任务的并发以及减小任务量 办法一：减少并发 # gitlab的优化 # Reduce the number of running workers to the minimum in order to reduce memory usage puma['worker_processes'] = 2 sidekiq['max_concurrency'] = 9 # Turn off monitoring to reduce idle cpu and disk usage prometheus_monitoring['enable'] = false 通过修改 gitlab.rb 配置文件，减少最大并发数以及关闭性能监控等节省性能 方法二：关闭无效任务 本来在原图中，是可以看到有相当多的已停滞任务，查看明细会继续调度时间重试，这些任务基本上都是 email_on_push ，详情就是推送合并触发邮件，并且目的邮箱已经不存在了，所以是可以取消的，那么 email_on_push　是在哪里开启呢，通过查看gitlab页面后，发现在： 设置->集成 存在 '推送时发送电子邮件' '流水线状态电子邮件' # 进入设置关闭即可 不过这里出现了个最大的问题，此功能看起来是在某个中央仓库中早就启用，很多仓库都是从这个仓库fork过去的，所以非常多的仓库都存在这个设置，如今只能慢慢手动关闭了，发现一个处理一个。这样的话我们继续观察后台停滞任务，基本上不会再有新增和重试了

nfs优化与错误Lock reclaim failed、Input/output error 0x0 异常 挂载目录卡住，查看 /var/log/messages 有如下错误: NFS: nfs4_reclaim_open_state: Lock reclaim failed 0x1 参数优化 先说说系统参数优化: _netdev,vers=4.0,rw,noatime,nodiratime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,proto=tcp 基本上挂载的时候跟直接使用这些参数即可，其中 vers=4.0 需要显示的写出来，centos7测试使用 vers=4 或者不写的情况下，使用 mount 可以观察得到版本为 4.1 ，所以为了使用 4.0 版本，一定要显示写 4.0 0x2 服务优化 如果并发较大的情况下，可以增大 nfs 的进程数，以提高并发 0x3 系统优化 linux对nfs客户端同时请求数进行了限制，可以用下面的命令查询，大部分机器默认是2，是比较小的。可以通过以下命令查询当前的数值: cat /proc/sys/sunrpc/tcp_slot_table_entries 内核编译的默认最大是2，可以增大设置成128，需要重新挂载nfs echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf echo "options sunrpc tcp_max_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf sysctl -w sunrpc.tcp_slot_table_entries=128 优化后重启机器，或者重新挂载nfs PS. 服务器 fstab 或者命令挂载实例： /etc/fstab 192.168.xx.xx:/aaa/bbb /opt/bbb nfs _netdev,vers=4.0,rw,noatime,nodiratime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,proto=tcp 0 0 mount mount -t nfs -o _netdev,vers=4.0,rw,noatime,nodiratime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,proto=tcp 192.168.xx.xx:/mnt/dev1/aaa /tmp/aaa 2023.12.07 补充更新 上面的内核参数以及挂载方法只是当时临时解决了问题，但是后来在其他机器上无法解决。所以并不是一个最终方案。试过了nfs3、nfs4.0、nfs4.1版本，更换过机器多种版本内核，仍然无法解决，可以参考抓包内容： 在挂载4.0版本的时候，ls文件卡住，包内容如下： 可以看到双方有非常多的设置 clientid、确认 的操作，这显然是不正常的 在挂载4.1版本的时候，ls文件很快，创建文件、读取文件、vi文件错误，但是创建目录可以 抓包内容（仅对vi做抓包、后续观察more是同样的问题）： 可以看到有非常多的 NFS4ERR_EXPIRED 这明显也是不正常的，因为不管是链接还是会话，都不可能这么快过期，在一个 vi 或者 more 的时间过期多次 关于此错误代码的解释 13.1.5.3. NFS4ERR_EXPIRED (Error Code 10011) A stateid or clientid designates locking state of any type that has been revoked or released due to cancellation of the client's lease, either immediately upon lease expiration, or following a later request for a conflicting lock. 在后续的查阅资料中也基本没有相关的案例、或者没有解决办法。于是猜测是 openbds 的 nfs BUG 之类。但是业务太多，其他几个挂载点目前没问题，不好重启 nfs 服务。 基于我们场景的现状，小文件非常多，有大量web项目war包解压出来的，还有jenkins打包的代码文件，所以目前的想法是采用多个 nfs 服务来提供这些不同服务的挂载。首先是避免大量读写小文件到一个 nfs 中处理不过来，再就是出现问题的时候，其中某个nfs重启也不影响其他的。