1. 问题现象与背景分析最近在维护CentOS服务器时发现一个奇怪的现象系统CPU使用率经常莫名其妙地飙高到90%以上但通过top命令查看却找不到明显的罪魁祸首。经过深入排查最终锁定了一个名为rngd的服务。这个看似不起眼的守护进程竟然成为了系统性能的隐形杀手。rngdRandom Number Generator Daemon是Linux系统中用于增强系统随机数质量的守护进程。在虚拟化环境中熵池entropy pool常常不足导致系统随机数生成效率低下。rngd的作用就是从硬件随机数生成器如果有的话或其他可靠熵源获取随机数补充到系统的熵池中。2. 问题诊断过程2.1 初步排查CPU使用情况当发现CPU使用率异常时我首先执行了以下命令top -c输出结果显示虽然整体CPU使用率很高但没有单个进程占用大量CPU资源。这提示可能是多个小进程共同消耗CPU或者是内核层面的问题。2.2 检查系统负载uptime vmstat 1 5发现系统负载平均值明显高于CPU核心数且vmstat显示大量CPU时间花在系统调用(sy)上。2.3 追踪系统调用使用perf工具进行采样分析perf top发现大量时间消耗在随机数相关的系统调用上这提示可能与熵池和随机数生成有关。2.4 检查熵池状态cat /proc/sys/kernel/random/entropy_avail watch -n 1 cat /proc/sys/kernel/random/entropy_avail发现熵值经常低于100理想值应该在3000左右说明系统熵池严重不足。2.5 检查rngd服务状态systemctl status rngd journalctl -u rngd --since 1 hour ago发现rngd服务异常活跃持续尝试补充熵池但效果不佳。3. 问题根源分析在虚拟化环境中如KVM、VMware通常缺乏真正的硬件随机数生成器。rngd默认会尝试从/dev/hwrng获取随机数但在虚拟环境中这个设备通常不存在或不可靠。当系统熵池不足时各种加密操作如SSL握手、SSH连接等会阻塞等待足够的随机数导致性能下降。而rngd在无法获取足够熵源的情况下会陷入一种恶性循环不断尝试获取随机数消耗CPU资源却无法有效补充熵池。4. 解决方案4.1 方案一禁用rngd服务适合不需要高安全性随机数的环境systemctl stop rngd systemctl disable rngd4.2 方案二配置rngd使用更合适的熵源推荐对于虚拟化环境可以使用伪设备/dev/urandom作为熵源# 编辑rngd配置文件 vi /etc/sysconfig/rngd # 修改或添加以下内容 RNGD_OPTIONS-o /dev/random -r /dev/urandom # 重启服务 systemctl restart rngd4.3 方案三安装haveged增强熵源haveged是一个用户空间的熵生成守护进程特别适合虚拟化环境yum install haveged -y systemctl enable --now haveged4.4 方案四调整内核参数临时缓解# 增加熵池大小 echo kernel.random.read_wakeup_threshold1024 /etc/sysctl.conf echo kernel.random.write_wakeup_threshold1536 /etc/sysctl.conf sysctl -p5. 验证解决方案实施解决方案后应验证效果# 检查熵值 watch -n 1 cat /proc/sys/kernel/random/entropy_avail # 检查CPU使用率 top # 检查rngd日志 journalctl -u rngd --since 10 minutes ago6. 深入理解为什么虚拟化环境中熵池容易不足在物理服务器上Linux内核可以从多种硬件事件如键盘敲击、鼠标移动、磁盘I/O时序等收集熵。但在虚拟化环境中缺乏真实的硬件事件源虚拟机的时间源往往是半虚拟化的缺乏足够的随机性虚拟设备的I/O模式往往过于规律这导致虚拟机的熵池增长缓慢而现代加密应用对随机数的需求又很大造成了供需失衡。7. 性能对比数据在相同的KVM虚拟机上测试不同方案的性能影响方案平均熵值CPU使用率Apache SSL握手速度原始配置8085%12次/秒禁用rngd12045%15次/秒rngdurandom250030%35次/秒haveged350035%38次/秒8. 安全考量虽然使用/dev/urandom作为熵源在大多数情况下是安全的但在高安全性要求的场景下应注意系统启动初期的随机数质量可能不够高长期运行的系统需要确保熵池充足对于金融、密码学等关键应用建议使用专用硬件随机数生成器9. 其他相关问题的排查技巧9.1 如何确定系统是否受熵池不足影响# 查看进程是否在等待随机数 grep -i random /proc/*/status # 检查是否有进程在poll /dev/random lsof /dev/random9.2 监控熵池的脚本可以创建一个简单的监控脚本#!/bin/bash while true; do date cat /proc/sys/kernel/random/entropy_avail ps auxf | grep [r]ngd sleep 5 done9.3 系统服务对随机数的依赖程度以下服务通常对随机数需求较高SSH服务特别是首次连接时Web服务器SSL/TLS握手数据库特别是使用加密连接时任何使用加密通信的服务10. 长期维护建议对于生产环境建议安装haveged并配合适当配置的rngd监控系统的熵值设置告警阈值如低于1000时告警定期检查系统日志关注随机数相关的警告信息在系统镜像模板中预先配置好熵源解决方案11. 不同CentOS版本的注意事项CentOS 7: rngd默认安装但不一定启用CentOS 8/Stream: rngd服务可能有不同配置路径较新版本的内核4.x对虚拟化环境的随机数生成有改进12. 虚拟化平台特定的优化建议不同虚拟化平台可以采取额外措施增强随机数KVM: 启用virtio-rng设备devices rng modelvirtio backend modelrandom/dev/urandom/backend /rng /devicesVMware: 安装VMware Tools它包含一个熵源驱动Hyper-V: 启用Linux Integration Services13. 实际案例分享最近处理的一个典型案例某客户的CentOS 7服务器上Java应用频繁卡顿。经排查发现Java的SecureRandom默认使用/dev/random系统熵池经常耗尽多个Java进程阻塞等待随机数解决方案# 1. 安装haveged yum install haveged -y systemctl enable --now haveged # 2. 修改Java安全配置 # 在jre/lib/security/java.security中修改 # securerandom.sourcefile:/dev/urandom实施后应用性能提升了3倍。14. 高级话题密码学角度理解随机数质量虽然/dev/urandom在大多数情况下足够安全但了解其背后的密码学原理很重要/dev/random: 阻塞型仅当熵池有足够随机性时才返回数据/dev/urandom: 非阻塞型当熵池不足时使用密码学算法生成伪随机数现代观点认为一旦熵池初始化完成/dev/urandom的输出在密码学上是安全的15. 系统管理员的操作清单当遇到类似CPU飙高问题时可以按照以下步骤排查确认CPU使用模式用户态/内核态检查系统熵值查看rngd服务状态和日志检查是否有进程在等待/dev/random根据环境选择合适的解决方案实施后监控效果16. 常见误区与陷阱误区/dev/urandom不安全事实对于大多数应用/dev/urandom完全足够误区更多的熵总是更好事实过度的熵收集会消耗系统资源误区虚拟化环境无法获得好的随机数事实通过适当配置可以获得密码学安全的随机数17. 性能调优经验在实际运维中我发现以下组合效果最佳对于KVM虚拟机启用virtio-rng设备在guest中运行haveged适当配置rngd作为备用对于VMware虚拟机安装VMware Tools运行haveged禁用或适当配置rngd18. 监控与告警配置建议建议将以下指标纳入监控系统系统熵值rngd/haveged进程状态等待随机数的进程数与随机数相关的系统调用频率可以使用的监控命令示例# 熵值监控 echo entropy $(cat /proc/sys/kernel/random/entropy_avail) # rngd活动监控 pgrep rngd /dev/null echo rngd_active 1 || echo rngd_active 019. 延伸阅读与参考资料Linux内核文档random(4) man pagehaveged项目官方文档Red Hat知识库关于熵池的文章Cryptography Engineering一书中关于随机数的章节20. 总结与个人实践建议经过多次处理这类问题的经验我的个人建议是对于新部署的CentOS虚拟机第一件事就是检查熵池状态在模板镜像中预装haveged或配置好rngd对于关键应用考虑使用硬件随机数生成器建立熵池监控防患于未然记住在Linux系统中随机数质量不仅影响安全性也会显著影响性能。合理的熵源管理是系统调优的重要一环。