大型网站典型故障案例分析(摘录)

最新推荐文章于 2024-07-20 20:04:43 发布

njit_peiyuan

最新推荐文章于 2024-07-20 20:04:43 发布

阅读量187

点赞数

文章标签：数据库运维 python

原文链接：https://my.oschina.net/newchaos/blog/1555856

版权

2019独角兽企业重金招聘Python工程师标准>>>

一.写日志也会引发故障

故障现象：某应用服务器集群发布不久后就出现多台服务器相继报警，磁盘可用空间低于警戒值，并且很快有服务器宕机，登录到线上服务器，发现log文件夹的文件迅速增加，不断消耗磁盘空间。

原因分析：这是一个普通的应用服务器集群，不需要存储数据，因此服务器里配置的是一块100G的小硬盘，安装操作系统，web服务器，java虚拟机，应用程序后，空闲空间只有几十G了，正常下够有了，但是该应用的开发人员将log输出的level全局配置为Debug,这一次简单的web请求就产生大量的log文件输出，在高并发的用户请求下，很快消耗完不多的磁盘空间。

经验教训：

应用程序自己的日志输出配置和第三方组建日志输出要分别配置

检查log配置文件，日志输出级别至少为warn,并且检查log输出代码调用，调用级别符合真实日志级别

二.高并发访问数据库引发的故障

故障现象：某应用发布后，数据库load居高不下，远超过正常水平，持续报警

原因分析：检查数据库，发现报警是因为某条sql引起的，这条sql是一条简单的有索引的查询，不应该引起报警，经检查其执行频率过高，追查这个sql,发现被网站首页应用调用，主页被访问多了，这个sql也就被执行的多了

经验教训：

首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索服务器获取。

首页最好是静态的

三.缓存引发的故障

故障现象：没有新应用发布，但是数据库服务器突然load飙升，并很快失去响应，DBA将数据库访问切换到备机，Load也很快飙升，并失去响应，最终引发全站瘫痪

原因分析：缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别比其他服务器要低一些，人们认为缓存是改善性能的手段，失去一些缓存也没有什么问题，有时候关闭一两台缓存服务器也确实没啥问题，所以长期疏于管理。结果这次一个缺乏经验的工程师关闭了关闭了缓存服务器全部的几十台memcached,导致了网站全部瘫痪的重大事故

经验教训：

当缓存不仅仅是提高性能，而是成为网站架构不可或缺的一部分时，对缓存服务器的管理需要提高到和其他服务器一个级别

四.应用启动不同引发的故障

故障现象：某应用发布后，服务器立即崩溃

原因分析：应用程序web环境使用apache+jboss的模式，用户请求通过apache转发到jboss。在发布时apache和jboss同时启动，由于jboss启动需要加载很多应用并初始化，花费时间较长，结果jboss没有完全启动，apache已经启动完毕并接受用户请求，大量的请求阻塞在jboss进程中，导致jboss崩溃。除了apache和jboss启动不同步的情况，还有很多类似的情况，都需要后台服务器准备好，前台应用才能启动，否则会导致故障

经验教训：

在本例中，启动脚本首先启动jboss，然后在脚本中不断用curl访问这个特定页面，直到ok,才启动apache。

五.大文件读写独占磁盘引发的故障

故障现象：某应用主要功能是管理用户图片，接到部分用户投诉，表示上传图片非常慢，原来只需一秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。

原因分析：图片需要使用存储，最有可能出错的是存储服务器，检查存储服务器，发现大部分文件只有几百kb,而有几个文件非常大，有几百兆，读写这些大文件一次需要几十秒，这段时间，磁盘一般这个文件操作独占，导致其他用户的文件读写慢。

经验教训：

存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共存储，批处理用的大文件可以使用其他类型的分布式文件系统

六.滥用生产环境引发的故障：

故障现象：监控发现某个时间段内，某个应用突然变慢，内部网络访问延迟非常厉害

原因分析：检查发现，该时段内网卡流量也下降，但是没找到原因。过了一阵子才知道，原来有工程师在线上生产环境进行性能压力测试，占用了大量交换机带宽

经验教训：

访问现象生产环境要规范，一不小心就会导致大事故