云服务器真不要运维，别天真了！

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

本人的忠告

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

非系统管理员部署的环境

某个应用，全部在某公有云上。由负载均衡、四台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

进程数一直保持不变，数量为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

再启动php等相关服务，高峰时期，效果非常明显，load值降低到5以下。

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