在MariaDB中，有太多的sleep进程导致了”打开文件过多”错误的处理措施

在这里记录了一份简略的备忘录，用于调查旁边发生的事件。除了这里写的，还可能需要在客户端应用程序中实施连接池。

睡眠时间比较长的情况

一些文章建议将wait_timeout设置得更短一些（可以通过使用set global进行在线更新）。
在MySQL中，处理出现“Too many connections”问题的方法 – 容易理解的系统开发备忘录 | MySQL – sleep进程的积累

已经相当短了吗↓，我以为是从60缩短到40进行了咨询的情况。
→ 根据 show full proccesslist; 的观感，除了 replication 之外的用户没有超过40秒的 sleep 进程。
通过 show global status; 观察到 Max_userd_connections 没有增加，
thread_cache_size 和 max_connections 似乎已经足够了。
→ 看起来不需要调整其他超时值，应该没问题。

MariaDB [(none)]> show global variables like '%timeout%';
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 10       |
| deadlock_timeout_long      | 50000000 |
| deadlock_timeout_short     | 10000    |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 50       |
| innodb_rollback_on_timeout | OFF      |
| interactive_timeout        | 28800    |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 30       |
| net_write_timeout          | 60       |
| slave_net_timeout          | 30       |
| thread_pool_idle_timeout   | 60       |
| wait_timeout               | 40       |
+----------------------------+----------+
13 rows in set (0.01 sec)

顺便说一下，在原版5.7里面有一个参数叫做max_execution_time，可以在服务器端设置查询超时时间。

MySQL 5.7的详细解释，是一本技术指南，旨在不落后于不停进化的发展（奥野幹也著） | 出版社为翔泳社。

然而在MariaDB中，似乎无法在10.1版本中进行该设置↓。

MariaDB 10.1和MySQL 5.7之间的系统变量差异 – MariaDB知识库

针对打开的文件过多的对策

现在虽然没有出现错误日志，但为了以防万一，将限制设置为无限制应该是个好主意。

在CentOS 7上的MariaDB出现了“接受错误：打开文件过多”。

由于CentOS7系统版本，需要在/usr/lib/systemd/system/mariadb.service文件的[service]段落中添加以下内容，然后重新加载systemctl守护程序以重新启动mariadb进程：
LimitNOFILE=infinity

MySQL调整器

`query_cache_limit (> 1M, or use smaller result sets)`

数据库的缓存似乎几乎没有使用，是否考虑减少限制呢？

`innodb_buffer_pool_instances(=22)`

据手册上的说法，将innodb_buffer_pool_size除以1GB的结果是有效的。根据MySQL 5.6参考手册的14.13.1.4节“使用多个缓冲池实例”，该值在5.6版本中不支持动态更改，如果要更改，需要在my.cnf文件中进行追加，并重新启动mariadb。根据MySQL 5.6参考手册的14.12节“InnoDB启动选项和系统变量”，可以了解更多相关信息。

展示全球状态；以查看概要。

由于”Created_tmp_disk_tables”和”Sort_merge_passes”等致命问题的值为0，所以我认为应该还好。

http://dbstudy.info/files/20130318/tuningathon5_mysql56.pdf 可在此链接中找到有关于MySQL5.6优化的文件。
http://qiita.com/tyoro/items/5436a5172b547e5e52f5 这个链接中可以找到相关的文件。

我在搜索时似乎记得连接池在商业版本中有所不同。这个是指的吗？MySQL :: MySQL企业级可扩展性。

以上 。