web服务器访问缓慢，作为运维人员，如何定位故障

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

故障的表现是什么？无响应？报错？

故障是什么时候发现的？

故障是否可重现？

有没有出现的规律（比如每小时出现一次）

最后一次对整个平台进行更新的内容是什么（代码、服务器等）？

故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)

基础架构（物理的、逻辑的）的文档是否能找到

是否有监控平台可用 （比如Munin、Zabbix、 Nagios、 New Relic…

什么都可以）

是否有日志可以查看 （比如Loggly、Airbrake、 Graylog…）

最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在

代码如下:

$ w

$ last

用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in

the kitchen is enough）

三、之前发生了什么

$

history查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT

环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥

代码如下:

$ pstree -a

$ ps aux

这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

代码如下:

$ netstat -ntlp

$ netstat -nulp

$

netstat -nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项

（鄙人一点浅薄的看法：IP 地址看起来更方便）。

找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

 代码如下:

$ free -m

$ uptime

$ top

$

htop

注意以下问题:

还有空余的内存吗 服务器是否正在内存和硬盘之间进行swap

还有剩余的CPU吗 服务器是几核的 是否有某些CPU核负载过多了

服务器最大的负载来自什么地方 平均负载是多少

七、硬件

代码如下:

$ lspci

$ dmidecode

$

ethtool

有很多服务器还是裸机状态，可以看一下：

找到RAID 卡 (是否带BBU备用电池)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。

网卡是否设置好

是否正运行在半双工状态 速度是10MBps 有没有 TX/RX 报错

八、IO 性能

代码如下:

$ iostat -kx 2

$ vmstat 2 10

$ mpstat

2 10

$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

检查磁盘使用量：服务器硬盘是否已满

是否开启了swap交换模式 (si/so)

CPU被谁占用：系统进程 用户进程 虚拟机

dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源 还是你的PHP进程

九、挂载点 和 文件系统

 代码如下:

$ mount

$ cat /etc/fstab

$ vgs

$

pvs

$ lvs

$ df -h

$ lsof +D / / beware not to kill your box

/

一共挂载了多少文件系统

有没有某个服务专用的文件系统 (比如MySQL)

文件系统的挂载选项是什么： noatime

default 有没有文件系统被重新挂载为只读模式了？

磁盘空间是否还有剩余

是否有大文件被删除但没有清空

如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

 代码如下:

$ sysctl -a | grep

$ cat

/proc/interrupts

$ cat /proc/net/ip_conntrack / may take some time on busy

servers /

$ netstat

$ ss -s

你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？

SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好,

不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量

在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？

如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning

了解网络性能调优的一些要点。

十一、系统日志和内核消息

 代码如下:

$ dmesg

$ less /var/log/messages

$

less /var/log/secure

$ less /var/log/auth

查看错误和警告消息，比如看看是不是很多关于连接数过多导致？

看看是否有硬件错误或文件系统错误

分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

 代码如下:

$ ls /etc/cron + cat

$ for user in

$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

是否有某个定时任务运行过于频繁

是否有些用户提交了隐藏的定时任务

在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了,

不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。

MySQL;

在mysqllog找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题

PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。

Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比

看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？

HA-Proxy;

后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

在服务器上运行的都是些啥？

这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。

这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！

伴随着对信息化要求的不断提升，相信多数单位都会架设自己的Web服务器，来在Internet网络中发布信息、宣传自我。为了保证任何一位上网用户都能顺畅地访问到Web服务器中的内容，网络管理员在正式发布Web信息之前往往需要设置一下IIS服务器，以便确保单位的Web网站可以始终如一地稳定运行。然而很多时候，我们都会遇到Web服务器访问失败的故障现象，面对Web服务器故障，我们往往会表现得手忙脚乱，根本不知道该从何处着手，来解决这些Web服务器故障。其实，造成Web服务器故障的因素有很多，我们需要对此进行逐一排查，才能高效解决对应的Web服务器故障现象。Web服务器故障现象为了充分展示单位的形象，扩大单位的知名度，单位领导要求网络管理员，立即拿出方案，组建有个性化特色的Web站点，不仅确保单位内部的员工可以通过内网正常访问Web站点，同时还要保证外网用户也能快速地访问到本单位的站点内容。依照领导指示精神，网络管理员立即行动，挑选了一台运行性能非常高效的计算机作为服务器系统，并在其中安装、配置了Windows Server 2003系统，同时利用该系统自带的IIS组件架设了Web服务器;为了提高Web站点的访问速度，网络管理员特地将Web站点所在的计算机直接连到单位千兆核心交换机上，同时将目标主机的IP地址设置成与单位普通员工所用计算机处于相同网段的地址。刚开始的时候，无论是内网用户，还是外网用户，所有用户都能正常地访问单位的Web站点。可是，没有多长时间，单位内网用户在访问Web站点时，就遇到了访问失败的Web服务器故障，具体表现为无论从哪一台客户端系统出发，使用内网地址访问单位的目标站点时，系统屏幕上都会弹出身份验证对话框，要求单位员工必须输入访问账号与密码，可是当网络管理员尝试以Web站点的系统管理员身份进行登录操作时，发现始终登录不进去;更让人感觉到不可理解的是，网络管理员赶到Web服务器现场，查看其安全配置时，发现目标Web站点根本就没有启用登录验证设置，那身份验证对话框究竟是怎么弹出来的呢Web服务器故障排查由于造成这类Web服务器故障的因素比较多，我们必须要对各种可能因素进行依次排查，才能找到具体的Web服务器故障原因，启凡合肥网络公司分析如何采取针对性措施来快速解决故障现象：1、检查安全登录设置考虑到在访问目标Web站点的时候，系统弹出了身份验证对话框，这就意味着目标Web站点可能在安全登录方面没有配置正确，造成了用户访问Web内容时必须要输入访问账号。依照这样的分析思路，网络管理员准备先检查一下Web服务器的安全登录配置参数，看看其中的设置是否正确;想到做到，网络管理员立即来到目标Web主机现场，以特权账号登录其中，并依次单击“开始”/“设置”/“控制面板”选项，从弹出的系统控制面板窗口中，找到“管理工具”功能图标，并用鼠标双击该图标选项，进入对应系统的管理工具列表窗口;接着再用鼠标双击IIS功能图标，弹出对应系统的IIS主控台窗口，从该窗口的左侧列表区域，找到目标Web站点所在的计算机名称，并用鼠标右键单击该计算机名称，从弹出的右键菜单中执行“属性”命令，弹出目标Web主机的属性设置窗口;在该属性设置窗口中点选“目录安全性”选项卡，打开目录安全性选项设置页面;下面，在该设置页面的“身份验证和访问控制”设置项右边，单击“编辑”按钮，进入身份验证和访问控制设置对话框，网络管理员发现其中的“匿名访问”、“集成Windows验证”等选项都处于选中状态，于是他尝试着将这些参数选项取消选中，之后重新从内网的一台计算机中进行Web访问，可是相同的故障现象仍然存在;于是，网络管理员再次选中了“匿名访问”、“集成Windows验证”等选项，可是让他感觉非常失望的是，上面两个选项无论是选中还是没有选中，好像故障现象都存在，这就说明目标Web主机的安全登录设置与上面的故障现象并没有什么关系。2、检查上网连接设置既然登录设置以及权限设置，都影响不了Web服务器访问失败的故障现象，那问题可能出在其他地方。考虑到单位的Web服务器自从搭建成功后，网络管理员很少去改动它，那么服务器自身出现问题的可能性比较小，于是网络管理员决定从普通客户端的网络连接设置着手，看看是否是客户端自身原因引起的。网络管理员担心局域网中可能存在ARP病毒，造成了普通客户端系统访问目标Web站点时，上网数据包被强行转发到其他的主机上了，于是他立即登录进入单位局域网的核心交换机后台系统，并利用系统自带的诊断命令，对内网中每一个上网端口进行了扫描、诊断，结果发现所有上网端口的工作状态都是正常的，而且内网网络中也不存在由ARP病毒引起的地址冲突现象，这说明内网网络中不存在ARP病毒。接着网络管理员又对几台普通客户端系统的网络线缆连通性进行了测试，发现它们的状态也是正常的，并且从客户端系统中执行ping命令，来测试目标Web站点IP地址的连通性时，也是正常的，这说明普通客户端系统是可以正常访问目标Web站点的。后来，网络管理员担心客户端系统采用了代理局域网方式上网，因为采用这种方式访问目标Web站点时，需要先输入代理服务器的登录账号与密码，难道我们在进行Web站点访问操作时，系统屏幕弹出的身份验证对话框，是针对代理服务器的为了排除这种因素，网络管理员立即打开客户端系统的IE浏览器窗口，依次单击其中的“工具”/“Internet选项”，打开Internet选项设置对话框，单击其中的“连接”标签，并在对应标签设置页面中，网络管理员发现本地客户端系统并没有启用代理服务器设置，这说明Web服务器访问失败的故障与客户端系统的上网连接设置没有任何关系。3、检查目录访问权限会不会是目标Web站点所指向的主目录，对普通用户的访问权限进行了限制呢联想到在搭建FTP站点时，如果不对FTP站点的主目录开放用户访问权限的话，那么普通用户是无法通过IE浏览器登录进入FTP站点的;为此，网络管理员立即打开目标Web站点的系统资源管理器窗口，从中找到对应的主目录，用鼠标右键单击该主目录，从弹出的快捷菜单中执行“属性”命令，打开对应主目录的属性设置对话框;点选其中的“安全”选项卡，网络管理员看到其中并没有everyone账号的访问权限，难道是没有对everyone账号进行授权，造成了Web服务器访问失败的故障现象为了验证这样的猜测是否正确，网络管理员立即单击安全选项设置页面中的“添加”按钮，将everyone账号添加到账号列表中来，同时为该账号设置了合适的访问权限，最后单击“确定”按钮执行设置保存操作，原以为这样的设置操作可以解决问题了，不过网络管理员再次尝试从普通客户端系统进行Web站点的访问操作时，发现还是无法成功，很明显造成上述故障现象的因素可能不是目录访问权限。4、检查授权模式配置在排除了客户端系统的自身因素后，网络管理员再次将目光聚焦到Web服务器身上。经过上网咨询相关问题，网络管理员估计Windows Server 2003服务器系统的授权模式可能被意外修改，因为服务器授权模式要是设置不当时，很可能出现用户无论输入什么登录账号都无效的故障现象。想到做到，网络管理员立即登录进入Web服务器系统，依次单击“开始”/“设置”/“控制面板”命令，在弹出的控制面板窗口中双击“授权”图标，弹出授权模式配置窗口，在这里网络管理员发现目标Web站点当前使用的是“每服务器”授权模式;为了判断该参数是否对Web访问有影响，网络管理员将授权模式修改为了“每设备或用户”选项，并且重新启动了一下Web服务器系统，然而这样的调整也没有取得任何效果，看来授权模式配置也对Web访问操作没有直接的影响。5、检查其他Web服务经过上述排查，网络管理员确认Web服务器以及客户端系统自身状态都是正常的，单位内网的线路也是正常的，那为什么客户端系统偏偏会在访问单位Web站点时，弹出身份验证对话框，并且无论输入什么用户账号都没有用呢经过仔细分析，网络管理员估计局域网中可能同时存在其他的Web服务，而其他Web服务恰好又抢用了单位Web服务器的站点地址，最后造成了单位员工在进行Web访问时，实际上是访问了其他一个没有经过正确配置的Web站点。正当网络管理员准备排查局域网中究竟是否存在其他的Web服务时，一个故障电话突然打了进来，说单位新买的打印机突然无法正常网络打印了，那么这个故障会不会与Web服务器访问失败现象有什么必然的联系呢想到这一点，网络管理员立即赶到网络打印机现场，登录进入该设备的后台管理页面，检查其配置参数时，发现该设备的日志页面提示说存在地址冲突现象，仔细一看，网络管理员发现那个冲突的地址竟然就是单位Web站点的地址，难道我们从内网客户端系统访问目标站点时，访问的却是打印机后台管理系统既然存在地址冲突现象，网络管理员立即动手为网络打印机重新分配了一个地址，之后他再次对目标Web站点进行了访问操作，这一次很顺利地打开了对应站点内容，显然Web服务器故障现象已经被成功解决了。Web服务器故障总结经过更深入地检查，网络管理员发现打印机设备默认运行了Web服务，那样一来打印用户就能通过Web方式对打印设备进行远程管理;而在默认状态下网络打印机没有启用匿名访问功能，如此一来当网络打印机使用了单位Web站点的IP地址时，上网用户其实访问的就是打印机后台管理页面，而该页面是需要进行身份验证的，这也是普通用户为什么访问目标站点时会弹出身份验证对话框的原因了，而网络管理员由于没有输入网络打印机授权的用户账户，才会出现无论输入什么用户账号也不能成功登录的现象了。此次Web服务器故障的元凶就是这个原因。回顾上面的Web服务器故障排除过程，我们发现此次的Web服务器故障排查其实很简单，如果我们能够及时注意到局域网中新增加了网络打印机的话，那么在进行故障排查时我们或许就能注意到该变化会对Web服务器故障造成影响了。为此，我们日后在排查网络故障之前，应该先观察网络环境中是否存在变化，如果有变化的话，再对该变化展开针对性思考与联想，那样的话故障解决起来就不会绕弯子了。