![Linux 服务器性能分析 - 如何查看导致高负载的原因](https://linux22.com/image/523739/Linux%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%80%A7%E8%83%BD%E5%88%86%E6%9E%90%20-%20%E5%A6%82%E4%BD%95%E6%9F%A5%E7%9C%8B%E5%AF%BC%E8%87%B4%E9%AB%98%E8%B4%9F%E8%BD%BD%E7%9A%84%E5%8E%9F%E5%9B%A0.png)
如果服务器负载过高,我会使用 top 和类似工具来排查原因。但是,这只有在我能够在服务器遇到问题时进行分析时才有效。
有哪些好工具可以找到以前服务器负载过高的根本原因?例如,我计划每 5 分钟执行一次 cron 作业来保存“top”输出、apache 服务器统计信息、mysql 进程列表等。但这似乎不太优雅,想知道是否有人已经想出了一些实用程序来实现这一点。
答案1
对于持续监控,您可以考虑安装munin
。它将每 5 分钟收集一次信息并生成图表,让您了解瓶颈所在。我还使用sar
可以在后台模式下运行的收集数据到磁盘的程序。这提供了有关瓶颈的非常详细的信息。要了解过去运行的进程,您将需要进程记帐包。
答案2
我喜欢 collectd,但最近我开始玩弄 pcp(性能副驾驶)。它有一些很好的历史诊断功能。[1]:http://oss.sgi.com/projects/pcp/
答案3
您的非优雅解决方案实际上是一个不错的解决方案,无需设置单独的监控控制台(想想 SNMP 陷阱)。如果您正在运行 RHEL/CentOS 风格的系统,请确保您已安装“sysstat”(并将其打开)以收集有关 CPU、内存、磁盘 I/O 等的持续统计数据。(请参阅 /etc/sysconfig/sysstat.* 配置文件进行调整)。
收集到基础统计数据后,您可以用它来查明负载趋势发生的时间(因此,除了看到高 CPU 之外,您的 proc 队列是否备份?您是否看到分页中的重大故障?您的交换利用率如何?),然后您可以将其与您的“mysqladmin proc stat”类型列表等关联起来。如果是 LAMP 堆栈,请获取总 httpd 进程,然后进行快速求和/除法以找出要记录的平均进程大小。在 MySQL 中启用慢查询日志,然后捕获这些坏家伙并查找一些需要索引的表。
有时低技术并不是什么坏技术。:) 如果能用刀子,为什么还要用电锯呢?
答案4
在顶上。
它是 top/htop 的补充,因为它可以随时间收集统计数据。