云服务器集群性能故障排查手记

做者：田逸（wx formyz）

本人的忠告

当前依然有部分人（包括一些程序员）认为，用了云主机，网上搜搜，安装文档配置一下，哪里还须要什么专业的系统管理员（俗称运维狗）。固然，这也有云服务商宣传上的暗示（买了云主机，稳定无忧，数据扔上去一劳永逸）。事实果然如此么？若是你的应用没什么流量，一天没几我的访问，还真不用花钱雇用专职系统管理员；若是你靠互联网养活一帮人，并且但愿有更多的用户访问，还有上述认知的话，我只能呵呵…

 

非系统管理员部署的环境

某个应用，所有在某公有云上。由负载均衡、四台web应用、共享数据磁盘（程序代码共享）、数据库（主从）等及部分组成。从结构上看，嗯，没什么问题。所以，好长一段时间，也没有人来找咱们作支持，咱们也不知道有这些应用存在。

 

秋天来了，帝都的天气不错嘛，想必你们心情跟天气同样，也是开心的嘛！但是最近，技术支持的qq群，老有人在呼唤，说项目的四台服务器所有负载飙高。晚上9点到11点load能到好几百。说相关人员排查了好几天，没有效果（俺独自偷笑一番）。

 

 

勘察现场

应用程序为nginx + php + mysql，那么可能的存在瓶颈与能够调整的地方大体包括：系统配置、php配置、数据库配置（云服务商的负载均衡没啥可调的）。闲话少说，催得那么急，先看看运行情况吧。

My god，跑这么高还没死，赞一個先。除了cpu负载高而外，内存也基本耗尽。按照以往的经验，有多是系统参数的设置问题（默认systcl.conf未进行设置），因而安排个人小弟从别的服务器参考一下，对其进行设置，执行sysctl –p使其生效。等访问高峰期跟踪观察，结果效果不佳，看来得亲自出马了。

 

排查及处理过程

选定时间点，即访问高峰期前一個小时，登陆系统。

 

先看看是什么把内存给干完了，ps 查看进程，发现大量的php进行。初步怀疑用户请求完数据后，为了有效关闭进程并释放资源，在征得赞成后，重启php服务。片刻，进程又把内存耗光了，不太对劲呢！

 

重复执行下列命令对php进程进行统计：

ps auxww|grep php|grep –v grep |wc  -l

ps auxww|grep php|grep –v grep |wc  -l

进程数一直保持不变，数量为601。一個进程占用好几兆内存，600个进程，最低下限耗费数G的内存，负载不高才怪了。

 

打开配置文件php-fpm.conf，一眼就看到问题所在

进程管理被错误的设置成static（静态），最大子进程为600，那么一旦启动php，无论有没有必要，都会启动一个主进程加600个子进程。配置文件php-fpm.conf 最大子进程这一行之后与动态管理相关的参数，如最大开始进程、最大空闲进程数等一概无效。修正这个问题后，时间差很少到了访问高峰期。经过人工跟踪加监控报警，基本上算是有很大改进，负载峰值load在50如下。

 

进一步的优化措施

虽然经过修正php参数设置，性能得以改善，但我对这个结果仍是不太满意。想再看看有么有能够调整的地方。因而，思路到了磁盘io这个问题上了。

 

四个服务器共享一個云nas硬盘，只保存一份程序员写的php代码。若是io性能不佳，也会严重影响整个应用的性能。

 

用mount指令查看nfs挂接状况，主要是挂接参数，结果以下：

用的是tcp协议，而在之前的实践中，我一般用udp协议（vers=3）进行挂接。考虑到云服务商提供的磁盘性能，用tcp未必就能比udp更好。因而跟其余人协商，在不影响性能访问的状况下，先修改一台服务器对nfs的挂接方式，有进一步性能提高后再修改其余的服务器，最后留一台不作更改，以便观察对比效果。

 

关服务，切换出挂接点目录，卸载nfs，用下列指令挂接从新挂接nfs：

/usr/bin/mount -t nfs -o nolock,vers=3 6e46868719-pgn67.cn-qingdao.nas.aliyuncs.com:/   /data

/usr/bin/mount -t nfs -o nolock,vers=3 6e46868719-pgn67.cn-qingdao.nas.aliyuncs.com:/   /data

再启动php等相关服务，高峰时期，效果很是明显，load值下降到5如下。

 

通过数天的观察，对比，云服务器nfs挂接方式对性能的影响也比较大。