成都创新互联网站制作重庆分公司

MySQL性能调优技巧以及Monyog线程缓存监测-创新互联

这篇文章主要介绍“MySQL性能调优技巧以及Monyog线程缓存监测”,在日常操作中,相信很多人在MySQL性能调优技巧以及Monyog线程缓存监测问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”MySQL性能调优技巧以及Monyog线程缓存监测”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

创新互联服务项目包括东乃网站建设、东乃网站制作、东乃网页制作以及东乃网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,东乃网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到东乃省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!

技巧#1:确定MySQL的大连接数

对于MySQL的大连接数,一次最好是发送5个请求到Web服务器。对Web服务器的5个请求中的一部分将用于CSS样式表,图像和脚本等资源。由于诸如浏览器缓存等原因,要获得准确的MySQL到Web服务器的请求比率可能很困难; 要想得到一个确切的数字,就需要分析Web服务器的日志文件。例如,可以手动访问Apache的“access_log”日志文件,也可以通过Analog或Webalizer等实用程序访问日志文件。

一旦有了对特定使用情况的准确估计,请将该比率乘以Web服务器的大连接数。例如,如果Web服务器配置为最多为256个客户端提供服务,MySQL请求与Web请求的比率为1/8,则最好将大数据库连接数设置为32。还要考虑留有安全余量,把这个数乘以2,得到最终的数量。只有在基础设施支持的情况下,才能尝试将数据库连接数的大数量与Web服务器的客户端限制相匹配。在大多数情况下,最好保持接近32。

在Monyog中查看MySQL连接

在MySQL数据库中,MySQL的大并发连接数是存储在全局变量max_connections中的。Monyog报告变量“max_connections”作为当前连接监控组中的“大允许”指标。它还将该数字除以打开的连接数,以生成连接使用百分比:

还有一个连接历史记录监控,可以帮助计算最佳的大并发连接数。它包括尝试,拒绝和成功连接的数量。此外,允许达到的大指标的百分比显示为一个进度条,可以让你快速评估服务器在过去达到的大并发连接数:

技巧#2:为临时表分配足够的内存

在某些情况下,服务器在处理语句时会创建内部临时表。临时表用于内部操作如GROUP BY和distinct,还有一些ORDER BY查询以及UNION和FROM子句(派生表)中的子查询。这些都是在内存中创建的内存表。内存中临时表的大大小由tmp_table_size和max_heap_table_size中较小的值确定。如果临时表的大小超过这个阈值,则将其转换为磁盘上的InnoDB或MyISAM表。此外,如果查询涉及BLOB或TEXT列,而这些列不能存储在内存表中,临时表总是直接指向磁盘。

这种转换的代价很大,所以考虑增加max_heap_table_size和tmp_table_size变量的大小来帮助减少在磁盘上创建临时表的数量。请记住,这将需要大量内存,因为内存中临时表的大小是基于“最坏情况”的。例如,内存表总是使用固定长度的列,所以字符列使用VARCHAR(255)。这可以使内存中的临时表比想象的要大得多—事实上,这比查询表的总大小要大很多倍!当增加max_heap_table_size和tmp_table_sizevariables的大小时,一定要监视服务器的内存使用情况,因为内存中的临时表可能会增加达到服务器内存容量的风险。

一般来说,32M到64M是建议值,从这两个变量开始并根据需要进行调优。

在Monyog中的临时表监测

临时表的监测是许多预定义的Monyog监测之一。它提供了一些临时表使用的指标,包括:

  • 允许的大值:显示tmp_table_size服务器变量的值,它定义了在内存中创建的临时表的大大小。与max_heap_table_size一起,这个值定义了可以在内存中创建的临时表的大大小。如果内存临时表大于此大小,则将其存储在磁盘上。

  • 内存表的大大小:显示max_heap_table_size服务器变量的值,该值定义了显式创建的MEMORY存储引擎表的大大小。

  • 创建的临时表总数:显示created_tmp_tables服务器变量的值,它定义了在内存中创建的临时表的数量。

  • 在磁盘上创建的临时表:显示created_tmp_disk_tables服务器变量的值,该变量定义了在磁盘上创建的临时表的数量。如果这个值很高,则应该考虑增加tmp_table_size和max_heap_table_size的值,以便增加创建内存临时表的数量,从而减少在磁盘上创建临时表的数量。

  • 磁盘:总比率:基于created_tmp_disk_tables除以created_tmp_tables的计算值。由于tmp_table_size或max_heap_table_size不足而在磁盘上创建的临时表的百分比。Monyog将这个数字显示为一个进度条和百分比,以便快速确定有多少磁盘用于临时表,而不是内存。

趋势图可用于创建的总表,磁盘上创建的表和磁盘的总比值。这些让我们看到了它们随着时间的演变:

技巧#3:增加线程缓存大小

连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联,该线程负责处理该连接的身份验证和所有请求处理。因此,线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。

MySQL提供了许多与连接线程相关的服务器变量:

线程缓存大小由thread_cache_size系统变量决定。默认值为0(无缓存),这将导致为每个新连接设置一个线程,并在连接终止时需要处理该线程。如果希望服务器每秒接收数百个连接请求,那么应该将thread_cache_size设置的足够高,以便大多数新连接可以使用缓存线程。可以在服务器启动或运行时设置max_connections的值。

还应该监视缓存中的线程数(Threads_cached)以及创建了多少个线程,因为无法从缓存中获取线程(Threads_created)。关于后者,如果Threads_created继续以每分钟多于几个线程的增加,请考虑增加thread_cache_size的值。

使用MySQL show status命令显示MySQL的变量和状态信息。这里有几个例子:

MySQL性能调优技巧以及Monyog线程缓存监测

Monyog线程缓存监测

Monyog提供了一个监控线程缓存的屏幕,名为“线程”。与MySQL线程相关的服务器变量映射到以下Monyog指标:

  • thread_cache_size:可以缓存的线程数。

  • Threads_cached:缓存中的线程数。

  • Threads_created:创建用于处理连接的线程。

Monyog线程屏幕还包括“线程缓存命中率”指标。这是一个提示线程缓存命中率的指标。如果值较低,则应该考虑增加线程缓存。在状态栏以百分比形式显示该值;它的值越接近100%越好。

如果这些指标的值等于或超过指定值,则可以将每一个指标配置为发出警告和/或严重警报。

其他相关的服务器变量

除了上述指标以外,还应该监控以下内容:

  1. InnoDB缓冲池大小: InnoDB缓冲池大小在使用InnoDB的MySQL数据库中起着至关重要的作用。缓冲池同时缓存数据和索引。它的值应该尽可能的大,以确保数据库使用内存而不是硬盘驱动器进行读取操作。

  2. 临时表大小: MySQL使用max_heap_table_size和tmp_table_size中较小的一个来限制内存中临时表的大小。拥有较大的值可以帮助减少在磁盘上创建临时表的数量,但也会增加服务器内存容量的风险,因为这个指标适用于每个客户端。一般来说,32M到64M是建议的值,从这两个变量开始并根据需要进行调优。

  3. InnoDB日志缓冲区大小: MySQL每次写入日志文件时,它都会利用可用于处理销售数据的重要系统资源。因此,将InnoDB日志缓冲区大小设置为较大值才有意义。这样,服务器在大型事务中写入磁盘的次数就减少了,从而大限度地减少了这些耗时的操作。64M是这个变量的一个很好的起点。

到此,关于“MySQL性能调优技巧以及Monyog线程缓存监测”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!

另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


网页标题:MySQL性能调优技巧以及Monyog线程缓存监测-创新互联
网页URL:http://cxhlcq.com/article/cesogd.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部