Tag: systemd

CentOS 7 修改 MariaDB 的最大打开文件数

记一下这个坑

最近将一个 php 环境迁移到了 CentOS 7，一开始一切都好，但是网站正式上线后一段时间却老是出现 php-fpm 进程繁忙的情况了。

刚开始以为是 php-fpm 哪里配错了，后来才发现是 MariaDB 的问题，日志里面一直在报达到了最大打开文件数。看了下，发现最大可以打开文件数是 1024，确实小了。

limits.conf 里面是早就把限制调高了的，所以在 /etc/my.cnf 里面加了一行

open-file-limits = 10240

结果重启后却还是 1024。

最终是在 /usr/lib/systemd/system/mariadb.service 里面找到了线索

# It's not recommended to modify this file in-place, because it will be
# overwritten during package upgrades.  If you want to customize, the
# best way is to create a file "/etc/systemd/system/mariadb.service",
# containing
#       .include /lib/systemd/system/mariadb.service
#       ...make your changes here...
# or create a file "/etc/systemd/system/mariadb.service.d/foo.conf",
# which doesn't need to include ".include" call and which will be parsed
# after the file mariadb.service itself is parsed.
#
# For more info about custom unit files, see systemd.unit(5) or
# http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
# For example, if you want to increase mariadb's open-files-limit to 10000,
# you need to increase systemd's LimitNOFILE setting, so create a file named
# "/etc/systemd/system/mariadb.service.d/limits.conf" containing:
#       [Service]
#       LimitNOFILE=10000

需要由 systemd 来提高最大可以打开文件数。

于是按照提示创建了 /etc/systemd/system/mariadb.d/limits.conf 加入了

[Service]
LimitNOFILE=65535

结果发现还是老样子
…
最终，再把 /etc/my.cnf 里面的 open-file-limits = 10240 删除掉才行。。。

Systemd 让Linux 不再那么Unixy

Systemd 会让Linux 变得很不那么Unixy 是因为systemd 本身可以说是一个完全的anti-Unix 的产品。它违反了众多的Unix 的哲学：它不爱“KISS” 原则；同样对“do one thing and do it well” 也不感冒；它为了效率而牺牲了可移植性；它反对shell 脚本的使用（同样是为了效率）。。。是的，这个严重被Mac OS X 的launchd 所影响的init system 就是这么的反Unix，因为它所有一切的追求就是“功能强大”和“高效率”。

  • systemd 不Simple 也不止do one thing，它远不止一个单纯的init system。除了取代/sbin/init 作为PID 1 进程以引导整个系统启动和启动后作为整个系统的超级守护进程，systemd 还要取代cron，at 和inetd 这样的守护进程。systemd 的创造者Lennart Poettering 解释这么做的原因大概是——既然每个Linux 都得有cron，at 和inetd 这样的服务，那么让他们各自有可执行文件在系统启动时来产生新的进程就完全是用了很多重复代码了。直接让systemd 在系统启动时用同一段代码就可把cron，at 启动起来，并且启动速度上也会有提升。
  • systemd 无法移植到非Linux 内核的操作系统上去。因为它从根本上是依赖于Linux 内核的cgroups (control groups) 的。因为利用了cgroups，systemd 才可以完完全全地将一个服务的所有进程都固定在一个group 里，double-fork 也无法让一个非特权进程跳出这个group。基于cgroup，systemd 提供了很强大的针对某个服务的进程的管理[1]。
  • systemd 认为使用shell script 的结果是效率低下。脚本过多的调用了系统中的像sed，awk，find，grep 这样的工具，而每调用一次则会产生一个新的进程，这严重地影响了操作系统的启动（看看Linux 刚刚启动后，系统最大的PID 到了多少？再看看Mac OS X 的呢？）。

Lennart Poettering 说：

…if you tell me that systemd is not Unixy, then I can only agree, and I don’t feel ashamed at all of that. Because my horizon is much further than just Unix.

引入systemd 无疑与传统Unix 哲学在多方面冲突的。Linux 20 年来几乎所有方面都是在跟着传统Unix 哲学在做，sysfs 和proc 文件系统的引入尤其如是，它们使得Linux 在这点上比之“Unix 正统后代”——*BSD 更加Unixy。因为，在Unix 里一切都是文件。

Fedora 15 已经是确定要从Upstart 转向使用systemd 了，OpenSUSE也在跟进。另外重要的应该就是Debian 和Ubuntu 的反应了，Debian 到最近的6.0 也还没有使用Upstart，并且systemd 也已经进入unstable 源。而对于Ubuntu 来说，早在自行开发出Upstart 之前，他们就准备使用launchd，后来因为协议问题而未果，继而自己开发了Upstart。以后要是转向systemd 应该也算是圆了多年前的梦想吧。

[1]. http://0pointer.de/blog/projects/systemd-for-admins-4.html