浅谈mysql 系统用户最大文件打开数限制

纸上得来终觉浅，绝知此事多宕机...记录一下自己很蠢的一次故障处理过程。

上周的时候，一个刚上线的系统又开始反映登不上了，因为最近这个系统也老是出现这个问题，开发也一直在找问题中，所以也没太在意。于是登上操作系统，mysql -uroot -p登录数据库，然后就一直没反应，登不上...

交代一下，mysql是装在mysql用户下的，装的时候虽然对数据库参数有进行调优，但是操作系统层面没做调整，所以mysql用户的最大文件打开数限制为默认的1024，用ulimit -n可以查询。然后我在用mysql的root账号登录数据库的时候也是在mysql这个系统用户下登录的，然后看了下当时服务器的负载，cpu和内存这些都很正常，但是存在大量应用到数据库的连接。

到这儿问题应该就很清楚了，系统用户mysql文件打开数可能达到了最大限制，当然不能打开更多的连接。

然而当时我并没有想到这一点，我想到的不是换个系统用户登录，不是停掉应用，而是重启数据库。。。而且这个数据库跑的不只这一个业务，虽然也都不是什么重要的业务。。。

于是我就准备重启数据库，仍然是在mysql用户下执行mysqladmin -uroot -p shutdown。毫无疑问，这肯定也是没有反应的，道理跟前面root账号连不上数据库是一样的，ctrl+C后有以下报错

^Cmysqladmin: connect to server at 'localhost' failed
error: 'Lost connection to MySQL server at 'waiting for initial communication packet', system error: 4'

然后我就做了个更蠢的操作，虽然想着可能会丢数据，杀掉了mysql进程。。。然后重启mysql，系统也就可用了。是真的很蠢，做完之后马上就想起有多种更好的处理方法，却选择了最蠢的一种。

今天再登上数据库看的时候，发现有几个参数跟我配置文件里写的不一样，比如max_connections、table_open_cache等，都是设置的默认值，看了下上次启动日志，确实也有告警

2019-03-15T08:14:03.038750Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 12010)
2019-03-15T08:14:03.038911Z 0 [Warning] Changed limits: max_connections: 214 (requested 2000)
2019-03-15T08:14:03.038916Z 0 [Warning] Changed limits: table_open_cache: 400 (requested 5000)

很明显，mysql根据参数设置计算了实例需要打开的最大文件数超过了当前系统用户的最大限制，于是没有使用该参数而使用了默认值。当然启动起来数据库也是可用的，启起来后也可以手动把设置参数

set global max_connections=2000;
set global table_open_cache=5000;

只不过就很有可能出现我之前出现的问题了，也就是数据库连接数并没有达到max_connections的限制，用户仍然连接不上。需要说明的是，正常情况下就算连接数满了，mysql仍然会为root用户保留一个连接，也就是root用户是可以登录数据库查看问题的。

要解决也很简单，增大操作系统用户mysql的限制值就行了，在配置文件/etc/security/limits.conf后面加上新的限制值就行了。

mysql  soft  nofile 32768
mysql  hard  nofile 65535

以上所述是小编给大家介绍的mysql 系统用户最大文件打开数限制详解整合，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对我们网站的支持！

赞 (0)

相关推荐

  • MySQL Limit性能优化及分页数据性能优化详解

    MySQL Limit可以分段查询数据库数据,主要应用在分页上.虽然现在写的网站数据都是千条级别,一些小的的优化起的作用不大,但是开发就要做到极致,追求完美性能.下面记录一些limit性能优化方法. Limit语法: SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset LIMIT子句可以被用于强制 SELECT 语句返回指定的记录数.LIMIT接受一个或两个数字参数.参数必须是一个整数常量. 如果给定两个参数,第一个参数指定

  • MySQL数据库存储过程和事务的区别讲解

    事务是保证多个SQL语句的原子型的,也就是要么一起完成,要么一起不完成 存储过程是把一批SQL语句预编译后放在服务器上,然后可以远程调用 存储过程: 一组为了完成特定功能的SQL语句集(或者自定义数据库操作命令集), 根据传入的参数(也可以没有), 通过简单的调用, 完成比单个SQL语句更复杂的功能, 存储在数据库服务器端,只需要编译过一次之后再次使用都不需要再进行编译:主要对存储的过程进行控制. 优点: 1.执行速度快.尤其对于较为复杂的逻辑,减少了网络流量之间的消耗,另外比较重要的一点是存储

  • MySQL数据库大小写敏感的问题

    在MySQL中,数据库对应数据目录中的目录.数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个,取决于存储引擎).因此,所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性.这说明在大多数Unix中数据库名和表名对大小写敏感,而在Windows中对大小写不敏感. 一个显著的例外情况是Mac OS X,它基于Unix但使用默认文件系统类型(HFS+),对大小写不敏感. 在windows下表名不区分大小写,所以在导入数据后,有可能所有表名均为小写,而再从win导入linux后,在

  • Mysql查看最大连接数和修改最大连接数的讲解

    MySQL查看最大连接数和修改最大连接数 1.查看最大连接数 show variables like '%max_connections%'; 2.修改最大连接数 set GLOBAL max_connections = 200; 以下的文章主要是向大家介绍的是MySQL最大连接数的修改,我们大家都知道MySQL最大连接数的默认值是100, 这个数值对于并发连接很多的数据库的应用是远不够用的,当连接请求大于默认连接数后,就会出现无法连接数据库的错误,因此我们需要把它适当调大一些.在使 用MySQ

  • python使用adbapi实现MySQL数据库的异步存储

    python使用adbapi实现MySQL数据库的异步存储

    之前一直在写有关scrapy爬虫的事情,今天我们看看使用scrapy如何把爬到的数据放在MySQL数据库中保存. 有关python操作MySQL数据库的内容,网上已经有很多内容可以参考了,但都是在同步的操作MySQL数据库.在数据量不大的情况下,这种方法固然可以,但是一旦数据量增长后,MySQL就会出现崩溃的情况,因为网上爬虫的速度要远远高过往数据库中插入数据的速度.为了避免这种情况发生,我们就需要使用异步的方法来存储数据,爬虫与数据存储互不影响. 为了显示方便,我们把程序设计的简单一点,只是爬

  • MySQL索引类型Normal、Unique和Full Text的讲解

    MySQL的索引类型有普通索引(normal),唯一索引(unique)和全文索引(full text),合理使用索引可大大提升数据库的查询效率,下面是三种类型的索引的介绍 normal:这是最基本的索引,它没有任何限制,MyIASM中默认的BTREE类型的索引,是我们大多数情况下用到的索引. unique:表示唯一的,不允许重复的索引,如果该字段信息保证不会重复.例如身份证号用作索引时,可设置为unique. full text : 表示全文搜索的索引,仅可用于 MyISAM 表. FULLT

  • MySQL分库分表总结讲解

    项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多.以至于查询变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈. 当出现这种情况时,我们可以考虑分库分表,即将单个数据库或表进行拆分,拆分成多个库和多个数据表,然后用户访问的时候,根据一定的算法与逻辑,让用户访问不同的库.不同的表,这样数据分散到多个数据表中,减少了单个数据表的访问压力.提升了数据库访问性能. 下面是对项目中分库分表的一些总结: 单库单表 单库单表是最常见的数据库设计,例如,有一张用户(use

  • MySQL不同表之前的字段复制

    有时候,我们需要复制某个字段一整列的数据到另外一个新的字段中,这很简单,SQL可以这么写: UPDATE tb_1 SET content_target = content_source; 大概写法如下: Update {your_table} set {source_field} = {object_field} WHERE cause 有Navicat等工具更好,可以直接选中一列数据,拷贝粘贴到你需要的列中.如果是同一个表那没什么问题,如果是新表,请保持它们的行数是一致.如果行数不一致,你可

  • MySQL优化方案参考

    MySQL优化方案参考

    优化可能带来的问题 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统. 优化手段本来就有很大的风险,只不过你没能力意识到和预见到! 任何的技术可以解决一个问题,但必然存在带来一个问题的风险! 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果. 保持现状或出现更差的情况都是失败! 本文整理了一些MySQL的通用优化方法,做个简单的总结分享,旨在帮助那些没有专职MySQL DBA的企业做好基本的优化工作,至于具体的SQL优化,大部分通过加适当的索引即可达到效果,更复杂

  • MySQL可重复读级别能够解决幻读吗

    MySQL可重复读级别能够解决幻读吗

    引言 之前在深入了解数据库理论的时候,了解到事物的不同隔离级别可能存在的问题.为了更好的理解所以在MySQL数据库中测试复现这些问题.关于脏读和不可重复读在相应的隔离级别下都很容易的复现了.但是对于幻读,我发现在可重复读的隔离级别下没有出现,当时想到难道是MySQL对幻读做了什么处理? 测试: 创建一张测试用的表dept: CREATE TABLE `dept` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) DEFAULT

随机推荐