saltstack执行state.sls耗时长的坑

一直用的 jenkins + saltstack 自动化构建发布项目,一共也就不超过20台服务器,奈何运行时间越来越慢,并且负载越来越高(这里大部分都是使用state模块),但是不用state模块效率挺高的,所以初步锁定坑应该在 state配置以及运行机制上.

查阅各种资料果不其然,需要注意几点.

Minion 配置



By default, the Salt fileserver recurses fully into all defined environments
to attempt to find files. To limit this behavior so that the fileserver only
traverses directories with SLS files and special Salt directories like _modules,
enable the option below. This might be useful for installations where a file root
has a very large number of files and performance is negatively impacted. Default
is False.

# 关闭软连接
fileserver_followsymlinks: False
# 忽略软连接
fileserver_ignoresymlinks: True
# 见上面的引文
fileserver_limit_traversal: True

虽然我修改了minion配置里的 fileserver_limit_traversal 为true 但是效果还是不明显,因为这个fileserver目录里面太多文件了(node打包等一系列文件全在里面,文件数太多了(⊙﹏⊙)b),由上面的引文可见

默认情况,每次执行state文件,minion都会发出 “_file_list” 命令从master同步整个文件列表。当fileserver(即master端配置文件中file_roots设置的目录)中的文件比较多的情况下,会增大集群负载.

再github上也搜到类似的问题,提供思路

参考:

http://vearne.cc/?p=88

https://github.com/saltstack/salt/issues/30498

原文地址:https://www.cnblogs.com/loveyouyou616/p/10831623.html

时间: 2024-10-10 23:22:09

saltstack执行state.sls耗时长的坑的相关文章

saltstack state.sls常用功能模板编写

saltstack常用功能模块编写 一.简介 Master - 控制中心,salt命令运行和资源状态管理端 Minions - 需要管理的客户端机器,会主动去连接Master端,并从Master端得到资源状态信息,同步资源管理信息 States - 配置管理的指令集 Modules- 包含命令行下运行的指令,和在配置文件里面使用的指令模块可以的函数可以在命令行下运行 Grains - minion端的变量,静态 pillar - minion端的变量,动态,可自定义 highstate - 给m

saltstack   state.sls 与 state.highstate

这里简单介绍一下state.sls 与 state.highstate 与区别,这也是自己在使用过程中的一点心得吧. 环境介绍:salt 2015.5.0 (Lithium) top.sls state.highstate 这个是全局的所有的环境的所有的状态生效: state.sls 用来指定特定sls进行处理. 当使用  salt '*' state.highstate 没有任何问题 可是当执行 salt '*' state.sls servers_packages 发现没法执行 翻看官方文档

saltstack/salt的state.sls的使用

SLS(代表SaLt State文件)是Salt State系统的核心.SLS描述了系统的目标状态,由格式简单的数据构成.这经常被称作配置管理 首先,在master上面定义salt的主目录,默认是在/srv/salt/下面,vim /etc/salt/master: file_roots: base: - /srv/salt dev: - /srv/salt-dev 然后,在/srv/salt下面创建top.sls文件(如果有的话,就不用创建了,直接编辑好了) vim top.sls base:

高并发,执行耗时短的任务,还有低并发,执行耗时长的任务,各自选取什么样的线程池比较合理?为什么?如果业务场景是高并发,且任务耗时长时,有什么解决思路?

线程池的关键点是:1.尽量减少线程切换和管理的开支: 2.最大化利用cpu.对于1,要求线程数尽量少,这样可以减少线程切换和管理的开支:对于2,要求尽量多的线程,以保证CPU资源最大化的利用. 所以对于任务耗时短的情况,要求线程尽量少,如果线程太多,有可能出现线程切换和管理的时间,大于任务执行的时间,那效率就低了:对于耗时长的任务,要分是cpu任务,还是io等类型的任务.如果是cpu类型的任务,线程数不宜太多:但是如果是io类型的任务,线程多一些更好,可以更充分利用cpu.所以:高并发,低耗时的

saltstack/salt的state.sls和pillar定义以及使用

SLS(代表SaLt State文件)是Salt State系统的核心.SLS描述了系统的目标状态,由格式简单的数据构成.这经常被称作配置管理 首先,在master上面定义salt的主目录,默认是在/srv/salt/下面,vim /etc/salt/master: file_roots:    base:      - /srv/salt    dev:     - /srv/salt-dev 然后,在/srv/salt下面创建top.sls文件(如果有的话,就不用创建了,直接编辑好了) vi

saltstack(五) saltstack的state状态管理

一,YAML语法 首先先了解一下YAML,默认的SLS文件的renderer是YAML renderer.YAML是一个有很多强大特性的标记性语言.Salt使用了一个YAML的小型子集,映射非常常用的数据结构,像列表和字典.YAML renderer的工作是将YAML数据格式的结构编译成为Python数据结构给Salt使用. YAML语法有三个注意事项,具体如下: 1,使用空白字符为文件缩排表示结构,不过不能使用TAB 2,注释用#号 3,字符串平常不使用引号,如果有需要,可以使用单引号或双引号

实践:耗时短的任务和耗时长的任务

一.耗时长的任务:消耗时间长的任务,以睡眠两秒为例. 二.耗时短的任务:消耗时间短的任务,以分配耗时长的任务到指定进程为例. 三.任务分配进程:异步进程.将收到的长耗时任务 以对同一用户的多次操作要排队的原则  分配到任务进程. 补充: 1.  hash:key + value,以key取值的圆环式增长实现hash圆环. 1.1 hash:key+1保存未被分发的任务,max_key记录当前最大的key,min_key记录当前未被分发出去的最小的key. 2.保存未完成的正在处理的任务. 3.任

sql server 根据执行计划查询耗时操作

1 with QS as( 2 select cp.objtype as object_type, /*类型*/ 3 db_name(st.dbid) as [database], /*数据库*/ 4 object_schema_name(st.objectid,st.dbid) as [schema], /*架构*/ 5 object_name(st.objectid,st.dbid) as [object], /*对象名*/ 6 convert(char(16),qs.creation_ti

SQLServer中的执行计划缓存由于长时间缓存对性能造成的干扰

本文出处:http://www.cnblogs.com/wy123/p/7190785.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 先抛出一个性能问题,前几天遇到一个生产环境性能极其低下的存储过程,开发人员根据具体的业务逻辑和返回的数据量,猜测到这个存储过程的执行应该不会有这么慢.当时意识到可能是执行计划缓存的问题,因为当前这个存储过程的写法还是比较遵守参数化SQL的规范的(如果是动态即席查询SQL就不