公司有个项目，用到了mqtt的服务，用了mosquitto作为服务端程序。mosquitto当然偷懒直接用yum安装了。安装完配置完，接入了若干台设备测了一下没什么问题，于是开始大批量的接入设备。然而发现，到后面mqtt服务开始变得不可用起来，基本无法连接成功，所以猜测是服务端出现了问题。上服务器用netstat查看了一下连接数，发现连接数大概在1000个左右，无法再往上突破了。这让我觉得可能是系统限制了进程的最大连接数。开了mosquitto的log，看了下log文件也实锤了我的想法。于是，按照之前往上教的常规方法，开始修改系统最大连接数限制。
一开始改的，是 /etc/security/limits.conf 这个文件，因为以前在vyos系统（debian）上，似乎确实是有效的。改了之后，在shell中输入ulimit -n看到数字也确实变大了，但试了之后发现依旧只能到1000左右的连接，没有生效。以为是mqtt可能用不同用户跑的，也试过切换到root用户，重启过系统，都没有效果。于是再研究，发现有个/etc/security/limits.d/的目录，目录下有一个文件，里面有条记录似乎覆盖了limits.conf ，也一块儿改掉之后，重新开mqtt服务，问题依旧存在。
想起来之前看nginx的service文件的时候，看到有个PreExe的地方，用ulimit -S -n语句设置了最大具柄数（我并没有验证过nginx的那种做法是否有效，毕竟nginx似乎从来没因为这个出过问题），遂效仿之。然而，还是打脸了。
实在没有什么招数的时候，发现直接执行mosquitto服务端在前台跑，是可以突破1000连接数的，瞬间连接数就到了上千。由于时间限制，遂临时用screen将mosquitto跑在了前台凑活下。每次服务器重启都需要手动的再用screen开起来，很是麻烦，但临时也没有什么其他更好的方案了。
就这么凑活着凑活着，凑活了蛮久，直到今天，换了新的服务器，系统由自己安装（之前的系统不是自己装的，是本来就装好了的，对于有系统洁癖的我来讲可能会甩锅说之前的系统可能有问题），要迁移mqtt服务。这次提前配置好了一切的ulimit，以为万无一失的部署了mqtt。然而，当设备流量开始切过来的时候，再次出现了熟悉的一幕。但这次我不希望还是用以前但方案，这次一定要把原因找出来。当然，流程还是要走的，之前走过的流程依旧重新走了一边，结果当然也是一样的残酷，毕竟程序是不会骗人的。不一样的地方是这次搜的资料更多一点，多了一个修改/etc/sysctl.conf的步骤，修改了fs.file-max和fs.nr_open，问题依旧。也有帖子说要在/etc/pam.d/login文件下加一句session required /lib64/security/pam_limits.so
都试了之后，开始怀疑人生。。。。
好的吧，最后觉得，service文件自身是否会支持一些限制资源使用的参数配置，故开始往这方面搜索资料，终于功夫不负有心人，有帖子给了我答案。
帖子里说，在CentOS7以前的版本，采用service来控制服务，那个时候，limits.conf文件是起作用的，而在CentOS7下，采用systemd来控制服务，limits.conf的配置对systemd启动的服务将不再起作用。深究其原因，就是limits.conf这里的配置，只适用于通过PAM认证登录用户的资源限制，它对systemd的service的资源限制不生效。如果要对systemd的服务进行资源限制配置，直接在对应服务的service文件的[service] section下增加如下配置即可
LimitCORE=infinity LimitNOFILE=100000 LimitNPROC=100000
上面的配置只对某个服务生效，当然也可以配置全局的参数，在服务没有配置Limit配置的时候，就会用全局的参数。全局的配置，放在文件 /etc/systemd/system.conf 和 /etc/systemd/user.conf。 同时，也会加载两个对应的目录中的所有.conf文件 /etc/systemd/system.conf.d/*.conf 和 /etc/systemd/user.conf.d/*.conf，配置内容如下：
DefaultLimitCORE=infinity DefaultLimitNOFILE=100000 DefaultLimitNPROC=100000
经过上述配置，终于mqtt复活了。只能说啊，CentOS7真坑，让我不禁怀疑nginx的那个配置到底生效了没。
附上相关链接：http://smilejay.com/2016/06/centos-7-systemd-conf-limits/