标签:避免 over 触发器 延迟 参数优化 gen 速度 注释 bin
zabbix:性能优化
一只叫羊的羊 2019-03-20 15:16:18 739 收藏
展开
zabbix性能低下的表现如下:
zabbix队列有太多被延迟的item,可以通过administration-queue查看
zabbix绘图中经常出现断图,一些item没有数据
带有nodata()函数的触发器出现flase
前端页面无响应,或者响应慢
解决方案如下:
不要使用默认的模板,使用自己定制的模板
数据库调优
架构优化,如使用 分布式,个服务器功能独立
Item 、Trigger调优
变换更好的硬件
一:性能优化的依据
对zabbix server本身进行监控,选择zabbix-server的监控模板Template APP Zabbix Server。
然后看到zabbix-server内部监控情况:
通过上面的图,我们可以发现监控的指标有剩余的容量、性能这些。通过这些我们可以知道zabbix性能的瓶颈在哪里。例如:如果剩余的容量很小了,我们就可以调大zabbix_server.conf中的缓存参数,直到剩余的容量变大。
二:zabbix配置文件的参数优化
下面就是zabbix_server.conf文件内容
#通过日志可以分析当前服务状态。
LogFile=/tmp/zabbix_server.log #日志文件路径。
LogFileSize=1 #日志文件最大值(MB),超过则滚动,设为0表示不回滚。
DebugLevel=3 #调试日志级别:
# 0 - Zabbix进程启停基本信息。
# 1 - 严重信息。
# 2 - 错误信息。
# 3 - 警告。
# 4 - 调试模式。
# 5 - 调试模式-加强版。
#数据库配置,若数据库与服务器在同一机器上,使用socket模式可以提高访问速度。
DBSocket=/tmp/mysql.sock
#轮询进程数,通过并发来提高轮询或者捕获的效率,同时用来避免poller busy问题,根据CPU数量与系统负载综合调优。
StartPollers=80 #基本轮询进程数,范围0-1000。
StartIPMIPollers=0 #IPMI轮询进程数,若无智能卡监控,可置为0。
StartPollersUnreachable=1 #不可达主机的轮询进程数,包括IPMI和JAVA。
StartTrappers=1 #捕获模式进程数,若无active模式的客户端,则可减小该进程。
StartPingers=20 #ICMP ping数量,当大量使用ping用于心跳检测时,可适量增加。
StartDiscoverers=1 #自动发现实例数,若关闭此功能则减少该数量。
StartHTTPPollers=7 #HTTP轮询实例数,当使用到内置的WEB监测时,适量增加该值。
StartTimers=1 #定时器实例数。
StartEscalators=20 #扩展实例数。
StartDBSyncers=20 #DB同步器线程数。
StartJavaPollers=5 #JAVA轮询实例,当大量监控JMX时需要增加此项。
StartProxyPollers=1 #代理轮询线程。
#缓存配置
CacheSize=8M #128K-8G,缓存配置项的大小,用于存储 host, item, trigger 数据。监控项
CacheUpdateFrequency=60 #提交缓存频率。
HistoryCacheSize=16M #历史缓存大小。
HistoryIndexCacheSize=4M #历史索引缓存大小。
TrendCacheSize=4M #趋势缓存大小。
ValueCacheSize=8M #历史项目值缓存,设为0表示禁用项目值缓存,history value 缓存大小,当缓存超标了,将会每隔 5 分钟往 server 日志里面记录。
#用户配置
AllowRoot=0 #是否允许使用 root 启动, 0:不允许, 1:允许,默认情况下她会使用 zabbix 用户来启动 zabbix 进程。
User=zabbix #服务使用的用户。
#超时配置
Timeout=4 #端探测超时时间。
TrapperTimeout=300 #捕捉器超时时间。
UnreachablePeriod=45 #不可达时间,超过视为不可达。
UnavailableDelay=60 #不可达期间尝试周期。
UnreachableDelay=15 #不可用期间尝试周期。
HousekeepingFrequency=1 #housekeeping 数据归档周期(h),housekeep 执行频率,默认每小时回去删除一些过期数据。如果 server 重启,那么 30 分钟之后才执行一次,接下来,每隔一小时在执行一次。。
MaxHousekeeperDelete=5000 #housekeeper表记录,一次删除的数据不能大于 MaxHousekeeperDelete。
SenderFrequency=30 #Zabbix尝试发送未发送数据频率,5-3600s。
1
就可以根据自己的需要按照上面的内容进行配置。
三:zabbix的架构优化
常用的zabbix架构:(说明:Zabbix最简单的架构,常用于监控主机比较少的情况下。)
分布式架构:Server-Proxy-Agentd模式
说明:Zabbix分布式架构,常用于监控主机比较多的情况下,使用Zabbix Proxy进行分布式监控,有效的减轻了Zabbix Server端的压力。
四:Items工作模式及Trigger的优化
zabbix中的item默认的工作模式是被动模式,可以通过设置主动模式来提高Server的性能。
Trigger中正则表达式函数last()、nodata()的速度是最快的,min()、max()、avg()是最慢的,尽量使用速度快的函数。
五:zabbix的数据库优化
数据库优化的方法有:
对数据库软件本身的优化。采用更高性能的数据库版本
对数据库本身的参数进行调优配置
对zabbix数据库结构进行优化,例如:对history.*、trends.*等表进行分表操作,会很大的提高数据库的性能。
配置数据库本身的参数:
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
1
2
…
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。
zabbix数据库进行分表操作:
MySQL 5.5为写入工作负载留下了巨大的瓶颈 - 每个索引都有锁定锁定,因此当时只有一个线程可以插入索引条目,这可能是一个重要的瓶颈。 我们通过其中一列的散列分区表获得了2x +更好的性能,我希望随着更多内核的增益可以更高。
具体操作脚本github链接:https://github.com/itnihao/zabbix-book/blob/master/03-chapter/partitiontables.sh
六:其他优化手段
服务器硬件
想通过几个简单的配置让服务器提高成倍的性能,想法很好,但是基本不太现实。简单的说,你需要搭配更好的CPU、更大的内存,更快的硬盘:条件允许的花,可以考虑购买SSD,它比更大的cpu和更大的内存带来的效果更好,或者考虑使用SAS 15K硬盘,组raid等等,总之一句话,配置优化不动的情况,增加硬件投入,别绞尽脑汁搜索:zabbix如何优化之类的文章,你在浪费时间。
操作系统
使用最新的操作系统,优化、定制化操作系统内核。应该会有些作用,但是肯定不大。
参考博客链接如下:
http://www.talkwithtrend.com/Article/242299
https://sre.ink/zabbix-turn-conf/#respond
https://segmentfault.com/a/1190000001638101
————————————————
版权声明:本文为CSDN博主「一只叫羊的羊」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_34355232/java/article/details/88689723
标签:避免 over 触发器 延迟 参数优化 gen 速度 注释 bin
原文地址:https://www.cnblogs.com/magita/p/12893648.html