记一次出产数据库不测重启的经验

最终设置如下： 

#thread pool  
   thread_handling=pool-of-threads  
   #Group的数目，默以为体系CPU的个数，充实操作CPU资源  
   thread_pool_size=24  
   #每个group的最大线程数为thread_pool_oversubscribe+1  
   thread_pool_oversubscribe=3  
   performance_schema=off  
   #extra connection，防备线程池满的环境下无法登录MySQL  
   extra_max_connections = 8  
   extra_port = 33333 

备注：线程池在Percona,MariaDB,Oracle MySQL企业版中提供，Oracle MySQL社区版并不提供。

线程池貌似并不会直接导致内存不接纳，网上有说同时开启Thread pool和PS会呈现内存泄漏，可是 今朝Percona server 5.7.21-20+版本已经修复了这个题目，显然是不存在的。

慢查询

因为是出产情形，这个题目拖得时刻有点长，，那么慢查询会不会影响内存行使题目呢？带着这个题目，查察了慢查询靠山列表，在数据库奔溃的前一个时刻段，简直有不少慢查询语句。可是这并不能在必然水平上声名题目，因为处事器的 MySql 处事在杀死之前，内存已经见底，此时毗连数并不多，也就三四十来个阁下，大多处于休眠状态，而且此时已经占用了大部门的Swap空间。也就是说，在资源有限的环境下一定会呈现不少慢查询语句。

小结

其拭魅这个"不测"一点也不料外，着实已经产生了多次了。可是照旧做个小结吧，由于最终没有确认题目呈此刻那边，以是照旧宣布了吧，万一有专业的DBA碰着相同的题目还可以小小的解惑一下。

【编辑保举】

1. 亚马逊将在2019年底之前弃用全部Oracle数据库
2. 数据库运维的那些困难，我们用呆板进修办理了
3. 12月数据库榜单，整体排名不变如昨，Oracle 分数接连降落
4. 黑客进攻数据库的六大本领
5. 2018年12月环球数据库排行榜：Oracle惨不忍睹！

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!