一起聊聊Zabbix的MySQL优化
来源:SegmentFault
时间:2023-01-11 15:25:44 472浏览 收藏
来到golang学习网的大家,相信都是编程学习爱好者,希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《一起聊聊Zabbix的MySQL优化》,介绍一下MySQL、性能优化、高可用、监控、Zabbix,希望对大家的知识积累有所帮助,助力实战开发!
为 Zabbix 优化 MySQL
标签(空格分隔): Zabbix MySQL Optimizing 优化
Zabbix 和 MySQL
在大型的 Zabbix 环境中,遇到的挑战大部分是 MySQL 以及更具体的说是 MySQL 磁盘 IO。
考虑到这一点,我将提出一些优化,这将有助于你的 MySQL 最好的使用磁盘(必然的将帮助你的 Zabbix 最好的利用 MySQL)和可用的硬件资源。
SSD 是一个转折
“MySQL 在 SSD 上是否会运行的更好?”我已经一次次的在公共场合或私人场合听到这个问题。
我可以毫不怀疑的告诉你,如果 IO 是你当前的瓶颈 - 要么因为一些查询花费了太多时间和直到查询完成(延迟)你看到 diskstat 报告每秒 100-250 次读,要么因为你的请求超过磁盘负载和长时间等待(吞吐量),SSD 将肯定会对你有极大的帮助,而不是一点点。
考虑这个:最快的旋转磁盘最高可以每秒做 250 随机 IO 操作(这一点上,它是物理限制),并且单个的查询只会从一个磁盘读取,即使你用 16 块盘做了 RAID10,因此如果你需要读 15,000 数据点来展示一个图形,从磁盘读取这些数据点将花费 60s。
企业级的 SSD 磁盘,使用单个线程可以做 15,000 或者甚至超过每秒 16k 随机读(16k 是一个 InnoDB 块大小),并且当你增加吞吐量,它会表现的更好!因此这意味着在前面示例中的查询仅仅只会花费 1s 而不是 60s,这是一个很大的不同之处。好处是在同样的 SSD 上,相同时间内你可以运行更多的请求,并且总的 IO 操作数量将仅仅增加。而一个旋转盘将不得不在多个请求之间共享 250 个可用的 IO 操作。
SSD 不会打败旋转盘的唯一区域是顺序操作,特别是单个线程的顺序写,如果这是你的工作特点(可能的情况就是你主要在收集数据而几乎从不读它),这时你或许需要考虑其他的策略。
MySQL 配置
除了提升你的磁盘 IO 子系统,其他的方式是降低你的 IO 压力,并且我准备介绍一些 my.cnf 变量来帮助你。
注意,大部分的调优对任何高性能 MySQL 设置是通用的,尽管有些是明确适用于 Zabbix,因为你可以以放宽一些参数为代价获取更大的影响,最糟糕的情况是,丢失收集数据的 1s,从会议期间讨论,对任何人来说没有什么大不了的。
innodb_buffer_pool_size - 如果你有一个专属的 MySQL 服务器,尽可能设置的越高越好(上学是整个可用内存的 75% 左右),否则,你将同服务器上的其他进程平衡它。但是如果它仅仅是 zabbix 服务器,我依然建议设置的比较高,接近总的内存的 75%。
innodb_buffer_pool_instances - 在 MySQL 5.5, 设置它为 4, 在 MySQL 5.6 – 设置它为 8 或者甚至是 16。
innodb_flush_log_at_trx_commit = 0 - 这是折中的显著改善写入吞吐量的方案,特别是你没有一个非易失性高速缓存的磁盘子系统。基本上你引发的是在 MySQL 或是服务器 crash 时的 1s 的写损失。很多网站的实际运行它(很多网站依然运行在 MyISAM 上),我十分确定这不是一个 Zabbix 设置问题。
innodb_flush_method = O_DIRECT - 如果你是运行在 Linux,设置它。
innodb_log_file_size - 你想要这些事务日志(默认是有两份)保持 1 - 2 小时有价值的写入数据。为了做决定,你可能需要看下你的 MySQL 服务器的 Zabbix graphs,但是你也可以从 mysql 命令行运行以下的命令:
mysql> pager grep seq; show engine innodb statusG select sleep(3600); show engine innodb statusG PAGER set to 'grep seq' Log sequence number 8373513970951 ... Log sequence number 8373683996767
这两个数字的不同的之处就是 InnoDB 在上一个小时写入的字节数。因此在以上的服务器,我将设置 innodb_log_file_size=128M 并且以 256M 日志大小空间结束以允许我存储超过 1 个小时有价值的写入数据到事务日志中(See this on changing the log file size if you run MySQL 5.5 or earlier)
innodb_read_io_threads, innodb_write_io_threads - 不要深思这些,它们不像看起来那么重要,特别是如果你使用异步 IO(你可以通过在 mysql cli 运行 “show global variables like ‘innodb_use_native_aio'” 来检查)。在 MySQL 5.5 和 5.6 你通常想使用异步 IO(AIO),因此检查 mysql log 来明白为什么。如果没有,那就是说,如果你没有使用 AIO 并且不准备使用,仅仅设置这些值为 8 即可。
innodb_old_blocks_time = 1000 - 这个可以帮助你防止 由于偶尔的 scans 造成的 buffer pool 污染。这个目前在 MySQL 5.6 中是默认的(在 5.5,需要明确设置)。
innodb_io_capacity - 设置这个是为了你的磁盘 IO 子系统能处理更多的写 iops。对于 SSDs,这个应该最少为几千(2000 可能是一个好的开始),然而对于一些旋转磁盘值稍微有点低 - 500-800,依赖于磁盘数量。对于今天的大多数系统,默认的 200 明确是太低的。
sync_binlog=0 - 这是默认设置,但以防万一它是大于 0,关闭它,除非你运行的不是 Zabbix。不同步 binary logs 的代价是万一 master 宕机,副本没有同步,但是如果由于 binary log 同步,你不断触及 IO 瓶颈,仅仅因为你想避免每五年一次同步到备机的麻烦,当 master 宕机了,你应该重新考虑这个选项。
query_cache_size=0, query_cache_type=0 - 这是禁止查询缓存。大部分时间你不需要查询缓存。并且如果你没有通过这些设置在内核中禁止它,查询(尤其是小的)可能会受到影响,由于查询缓存的互斥竞争。
sort_buffer_size, join_buffer_size, read_rnd_buffer_size - 如果你配置了这些变量,取消这些改变(仅仅移除它们或是注释它们)。我发现在大多数客户端服务器,这是失调的前三名变量。然而在大部分情况下,不改变它们是最好的。仅仅让它们保留默认值。
tmpdir - 有时候指定 tmpdir 为 /dev/shm 是一个好注意,以至于 on-disk temporary 表实际是写入内存中,但是在 MySQL 5.5 有一个重要的警告:如果你这样做了,它禁用了 AIO acorss the board,因为 tmpfs 不支持 AIO。因此我将监控在当前 tmpdir(/tmp) 的活跃性,并且如果我发现它有问题的时候,切换到 /dev/shm。
MySQL Partitioning
我知道 Zabbix 支持 Partitioning,为了更容易的数据裁剪。尽管如此,我认为这里有一些特别的好处你可以从 partitions 获得。如果你已经通过 date 来 partitions,实际上是 subpartitions。
对于 Zabbix 的 KPI,你可能听了一次又一次,是 “每秒的新值”数,你可以在 Zabbix 状态中发现的。基本上,该值越高,你的 zabbix 的吞吐量越好。并且这就是很多人遇到的 zabbix 的限制 - MySQL 不能在每秒插入足够的新值。
除了我上面已经提到的优化(它们应该大大增加你的写吞吐量),我将鼓励你尝试分片(如果你还没有使用分片)或者是通过 BASH subpartitions,正如我们在 partitioning in some cases can increase the throughput of InnoDB 发现的那样。
我没有特别的在 Zabbix 中测试它,因为它不被 Zabbix 支持。你可以 hack 它使得它能正常工作。但是如果你已经做了所有的变更,依然没有得到足够的 new values per second (并且这不是你的硬件限制)。尝试通过 hash partitioning 或 subpartitioning 表的 key。
On MySQL High Availability
这有使得 MySQL 高可用的选项,虽然很多人认为它不是这样的。我们已经在我们的博客中写了很多,因此我就不重复了,我将给你一个资源参考:
文中关于mysql的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《一起聊聊Zabbix的MySQL优化》文章吧,也可关注golang学习网公众号了解相关技术文章。
-
499 收藏
-
244 收藏
-
235 收藏
-
157 收藏
-
101 收藏
-
335 收藏
-
467 收藏
-
303 收藏
-
176 收藏
-
368 收藏
-
475 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 507次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 484次学习
-
- 狂野的寒风
- 这篇博文出现的刚刚好,太详细了,很好,码起来,关注师傅了!希望师傅能多写数据库相关的文章。
- 2023-03-04 19:48:28
-
- 默默的巨人
- 太给力了,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢老哥分享文章内容!
- 2023-02-27 04:41:08
-
- 爱听歌的短靴
- 受益颇多,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢作者分享技术贴!
- 2023-02-15 15:32:00
-
- 无辜的白昼
- 这篇技术贴出现的刚刚好,细节满满,很棒,已收藏,关注师傅了!希望师傅能多写数据库相关的文章。
- 2023-01-30 13:32:01
-
- 沉静的睫毛
- 太全面了,码住,感谢老哥的这篇博文,我会继续支持!
- 2023-01-29 19:26:39
-
- 迅速的皮带
- 这篇文章真是及时雨啊,很详细,感谢大佬分享,mark,关注楼主了!希望楼主能多写数据库相关的文章。
- 2023-01-20 03:54:10
-
- 阳光的玫瑰
- 写的不错,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,看完之后很有帮助,总算是懂了,感谢作者分享文章内容!
- 2023-01-19 12:35:03
-
- 开心的巨人
- 这篇技术文章出现的刚刚好,楼主加油!
- 2023-01-19 06:15:39
-
- 孝顺的橘子
- 太细致了,已收藏,感谢大佬的这篇技术文章,我会继续支持!
- 2023-01-18 00:00:00
-
- 个性的电脑
- 太细致了,收藏了,感谢up主的这篇文章,我会继续支持!
- 2023-01-17 20:31:20