程序连接数据库响应慢!是Thread pool参数捣的鬼吗?

 

数据库版本:percona-mysql 5.6.16

在很长一段时间,都会出现程序连接数据库,出现响应慢的情况,正常在几到几十毫秒之间,但是偶尔会出现上百毫秒的情况;

开始由于开发重新设置并调整过程序连接池,一直怀疑是连接池的问题,但是问题依旧;

[[214120]]

因为使用的版本是 percona-mysql 5.6.16 并且使用了数据库连接池。

Thread Pool 根据参数 thread_pool_size 被分为若干个 group, 每个 group 维护 client 发起的 connections, 当 MySQL 建立 connection 时, 

MySQL 根据 connection 的 thread id 对 thread_pool_size 取模, 将 connection 发起的 sql 语句分配到对应的 group。每个 group 的*** worker

数量为 thread_pool_oversubscribe+1。若 worker 达到***数量后还是不足以处理回话请求, 则连接在本 group 上等待, 导致 sql 语句的 rt 增大;

因此将 thread_pool_oversubscribe 参数调大,但是问题依旧;

[[214121]]

检查 thread_cache_size,服务器内存大小为 64G,thread_cache_size=128;

每建立一个连接,都需要一个线程来与之匹配,此参数用来缓存空闲的线程,以至不被销毁,如果线程缓存中有空闲线程,这时候如果建立新连接,MYSQL 就会很快的响应连接请求;

  1. show status like '%thread%'
  2.  
  3. Variable_name Value 
  4.  
  5. Threads_cached     0 
  6.  
  7. Threads_connected   219 
  8.  
  9. Threads_created     655068 
  10.  
  11. Threads_running     48 

使用 show status 查看当前 mysql 连接情况:

  1. SHOW STATUS WHERE Variable_name LIKE '%Thread%'

Threads_cached : 代表当前此时此刻线程缓存中有多少空闲线程。

Threads_connected : 代表当前已建立连接的数量,因为一个连接就需要一个线程,所以也可以看成当前被使用的线程数。

Threads_created : 代表从最近一次服务启动,已创建线程的数量。

Threads_running : 代表当前激活的(非睡眠状态)线程数。并不是代表正在使用的线程数,有时候连接已建立,但是连接处于 sleep 状态,这里相对应的线程也是 sleep 状态。

***将 thread_cache_size 设置成与 threads_connected 一样。

  1. show variables like '%thread%'
  2.  
  3. +-----------------------------------------+-----------------+ 
  4.  
  5. | Variable_name                           | Value           | 
  6.  
  7. +-----------------------------------------+-----------------+ 
  8.  
  9. | innodb_purge_threads                    | 1               | 
  10.  
  11. | innodb_read_io_threads                  | 4               | 
  12.  
  13. | innodb_thread_concurrency               | 0               | 
  14.  
  15. | innodb_thread_sleep_delay               | 10000           | 
  16.  
  17. | innodb_write_io_threads                 | 4               | 
  18.  
  19. | max_delayed_threads                     | 20              | 
  20.  
  21. | max_insert_delayed_threads              | 20              | 
  22.  
  23. | myisam_repair_threads                   | 1               | 
  24.  
  25. | performance_schema_max_thread_classes   | 50              | 
  26.  
  27. | performance_schema_max_thread_instances | -1              | 
  28.  
  29. | pseudo_thread_id                        | 8735851         | 
  30.  
  31. | thread_cache_size                       | 128             | 
  32.  
  33. | thread_concurrency                      | 24              | 
  34.  
  35. | thread_handling                         | pool-of-threads | 
  36.  
  37. | thread_pool_high_prio_mode              | transactions    | 
  38.  
  39. | thread_pool_high_prio_tickets           | 4294967295      | 
  40.  
  41. | thread_pool_idle_timeout                | 60              | 
  42.  
  43. | thread_pool_max_threads                 | 100000          | 
  44.  
  45. | thread_pool_oversubscribe               | 40              | 
  46.  
  47. | thread_pool_size                        | 12              | 
  48.  
  49. | thread_pool_stall_limit                 | 500             | 
  50.  
  51. | thread_stack                            | 262144          | 
  52.  
  53. | thread_statistics                       | OFF             | 
  54.  
  55. +-----------------------------------------+-----------------+ 

可以不断刷新,如果 Threads_cached = 0 且 Threads_created 不断增大,那么当前 thread_cache_size 的值设置要改大,改到 Threads_connected 值左右,

再结合物理内存 1G  —> 8;2G  —> 16; 3G  —> 32; >3G  —> 64 二个情况综合考虑一下值, 将 thread_cache_size 改为 512;

注译:

Threads_cached : 代表当前此时此刻线程缓存中有多少空闲线程。

Threads_connected : 代表当前已建立连接的数量,因为一个连接就需要一个线程,所以也可以看成当前被使用的线程数。

Threads_created : 代表从最近一次服务启动,已创建线程的数量。

Threads_running : 代表当前激活的(非睡眠状态)线程数。并不是代表正在使用的线程数,有时候连接已建立,但是连接处于 sleep 状态,这里相对应的线程也是 sleep 状态。

 

修改 thread_cache_size 为 512 后,重新测试程序连接数据库响应时间,速度极快,不再出现程序连接数据库响应慢的情况! 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/267467.html<

(0)
管理的头像管理
上一篇2025-05-06 10:40
下一篇 2025-05-06 10:42

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注