![服务器无法应对,CPU 平均负载飙升至 33.0](https://linux22.com/image/570120/%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%97%A0%E6%B3%95%E5%BA%94%E5%AF%B9%EF%BC%8CCPU%20%E5%B9%B3%E5%9D%87%E8%B4%9F%E8%BD%BD%E9%A3%99%E5%8D%87%E8%87%B3%2033.0.png)
基本上,我的服务器在负载过大的情况下出现故障。这是一个编辑新闻网站,流量不规律地激增。我正绞尽脑汁试图稳定 LAMP 配置。
Current Time: Wednesday, 14-Dec-2011 15:13:06 SAST
Restart Time: Wednesday, 14-Dec-2011 14:08:44 SAST
Parent Server Generation: 0
Server uptime: 1 hour 4 minutes 21 seconds
Total accesses: 52825 - Total Traffic: 530.2 MB
CPU Usage: u281.32 s20.44 cu0 cs0 - 7.82% CPU load
13.7 requests/sec - 140.6 kB/second - 10.3 kB/request
19 requests currently being processed, 13 idle workers
我是不是疯了?或者我的专用服务器应该轻松承担这个负载吗?
- 英特尔 i7
- 8GB DDR3
- 软 raid 1
- CentOS6
平均负载通常在 3 左右,但今天两次攀升至 30+;转储其客户端并稳定回 2。
“top” 显示没有什么有趣的东西,mysql 的 CPU 使用率为 11%。
您认为这可能是硬件问题吗?我发现在负载不佳的情况下,RAID 可能会因无响应的 ATA 接口而堵塞?
您认为对于这个尺寸的盒子来说,有多少个请求是合理的?
答案1
“平均负载”数字实际上并不是负载 - 它是处于“正在运行”或“可运行”状态的线程数。前述线程能等待某件事发生 - 例如分页操作或 I/O(这会导致性能不佳,I/O 通常是一种共享资源,如果多个线程正在等待它,则很有可能会有更多的线程加入等待队列)。
在运行 MySQL 服务器的设置中,我看到了类似的数字,原因是在较长的更新操作期间对常用表进行锁定争用。您可以通过向 MySQL 服务器发出 SHOW PROCESSLIST 命令进行检查(PHPMyAdmin 甚至将此作为一项功能公开)。对此的快速解决方案是在 MySQL 配置中启用低优先级更新。
答案2
您需要获得更详细的指标来查明问题。
我通常会评论
- 磁盘输入输出
- 内存使用情况
- 交换使用
- 网络使用情况
- Apache 中的连接数/秒
- 数据库中每秒查询数
- 防火墙问题
- 网络堆栈(例如时间等待、打开连接)
从这里开始,我开始研究 Apache、MySQL 和系统的日志。
最后,转向任何特定于应用程序的问题。
一些工具:
- Munin 或 Cacti(或其他提供详细统计数据的工具)
- Sysstat 和捆绑工具(iostat、vmstat 等)
- Apache 中的扩展状态
- 在 MySQL 中记录慢查询
- 任何操作码缓存、内存缓存等的缓存报告
- http://www.webpagetest.org/用于前端检查
- 对于应用程序问题,我的一些客户已经成功使用了 New Relic
借助良好的工具包和系统的方法,您通常可以开始解决问题。
一些有用的测试:
- 访问静态内容(img 或 css)
- 访问 phpinfo 或 hello world 页面
- 使用简单的数据库连接访问 php 页面并关闭
- 使用数据库连接访问 php 页面,选择,关闭
- 使用数据库连接访问 php 页面并写入和关闭
- 访问 Web 应用程序
通过对每个测试进行计时,您可以开始找出延迟可能发生的位置。我曾看到高负载的服务器非常快速地返回静态内容。第一个字节的时间非常短。这表明应用程序层存在问题。继续检查应用程序堆栈,直到找到速度变慢的原因。
虽然很乏味,但这个过程对我来说很有帮助,一旦你习惯了它,你就可以很快完成它。
答案3
这种情况会定期发生吗?也就是说,您每天都知道这种情况什么时候发生吗?
当时正在运行 Cron 作业吗?
哪些进程(top 或 htop 应该显示)正在运行?
您正在运行什么磁盘子系统? RAID 类型? 控制器类型?(在不同的通道上...?)
服务器负载不仅仅是 CPU 使用率。它还可能是网络过载或驱动器系统过载。
您是否正在检查磁盘,看看驱动器是否存在问题?其中一个驱动器可能出现故障?
您需要缩小范围,看看到底发生了什么,如果是数据库堵塞,您的网站是否真的有大量点击,您的流量如何,日志中是否有消息,服务器是否正在运行某种类型的批量作业,这会占用大量的磁盘 I/O……?所有这些情况都可能导致服务器“负载”激增。您需要缩小范围,看看哪里出了问题以及出了什么问题。如果每次都几乎在同一时间发生,请检查 cron 计划以及可能在服务器上执行任何日常工作的东西,包括备份或磁盘转储。
如果它与其他内容相关...可能是更新特定类型的新闻报道...请检查您的带宽使用情况。检查您的日志,看看您是否受到恶意用户的某种扫描或探测。
答案4
对于没有耐心或者懒惰的人来说,扩展:
- 缓存数据库结果(memcached)和静态内容(varnish、nginx);
- 将资产服务与应用服务分开(图像、js、css,从不同的主机提供服务);
- 将数据库与应用程序分离;
- 在多个服务器之间对应用程序访问进行负载平衡;
当然,你必须像 Bart 所说的那样在检查服务器并确保服务器正在尽其所能之前这样做。我的意思是,如果你当前的设计还有改进的空间,那就先做吧,但即使在这种情况下,缓存也会有很大帮助。