分析一个由于服务扩容导致的耗时上升问题
现象
某后端服务作为入口网关,同时支持taf协议和http协议访问
taf协议访问量每日定时会变大,因此会进行定时扩容
最近一次定时扩容后,出现了大量ai告警,提示所有的http协议访问耗时都上涨了
某后端服务作为入口网关,同时支持taf协议和http协议访问
taf协议访问量每日定时会变大,因此会进行定时扩容
最近一次定时扩容后,出现了大量ai告警,提示所有的http协议访问耗时都上涨了
最近实在太忙啦,好几个月没写博客了,趁着五一放假补一篇
最近运维同学调整了告警策略,将连续coredump才告警,改成了每次coredump必告警
业务部门顿时向我报障了taf框架的coredump
一开始core在了tcmalloc,因为tcmalloc不会第一时间coredump,所以内存问题会跑一段时间才出现
本周为了Taf框架引入了限流器算法,用于Trace上报时进行限流
早在写go的时候就使用过著名的golang.org/x/time/rate限流器,这是一个令牌桶算法,它允许在保证平均rate的情况下,有一些突发流量
还用过uber开源的github.com/uber-go/ratelimit限流器,这是一个漏桶算法,它能严格的控制每个请求的最小访问间隔,并允许配置一个最大松弛量(maxSlack)用于最大间隔误差
简单介绍下两种算法的大概实现和区别,随后分别深入两种算法的实现
令牌桶算法
由一个令牌桶和生成令牌的间隔时间组成。一开始,令牌桶被填满,然后以固定的速率生成新的令牌,直到桶满为止。当请求进入系统时,需要从桶中删除一个令牌。如果桶是空的(没有令牌可以删除),请求则会被拒绝或等待。
漏桶算法
模拟了一个漏水的桶。进入系统的数据被放入桶中,然后以固定的速率流出。如果桶已满,新到的数据则被丢弃或等待。由于输出的数据流是恒定的,因此可以用于控制数据的整体速率。
维护的项目代码有很多编码不是utf-8的,导致保存会把中文注释变成乱码
不止我一个人遇到这个问题,项目中有很多已经是乱码文件是别人导致的
我研究了一下,把文件用utf-8或者gb2312打开,再转换成gbk繁体,如果转换失败,那基本就是乱码
代码如下
1 | import os |
最近的几个系统都用到了定时更新配置
获取到的配置是需要高频使用的,不能直接使用字符串
需要预处理为整数或浮点数,甚至是一个整数数组
因此整理了一下Config设计:
分为元数据Meta,配置的存储和注册Config两个模块
在维护网络库时,总能遇到一些没太大用处,但是很有意思的小知识,细细碎碎又不成体系,记录一下
2015.5.22整理:
epoll下LT和ET的处理都是大致相同的
LT模式
读buff有数据 / 写buff有空间,就触发
ET模式
读buff有数据,且数据减少或调用epoll_mod时 / 写 buff 空间增加或调用epoll_mod时,才触发
LT模式例子:
https://www.cnblogs.com/lojunren/p/3856290.html
https://github.com/hurley25/ANet
https://juejin.im/post/5ab3c5acf265da2380598efa
https://www.zhihu.com/question/22840801
https://blog.codingnow.com/2012/04/mread.html
在ET模式中,需要主动把数据读完或者写满:
读处理是一直read
返回-1,检查errno,如果是EAGAIN那么不再读(缓冲区读完),如果是其他那么说明连接出错,进行报错然后也不再读。
返回0,说明对端关闭
返回大于0,成功读到数据
写处理是一直write,直到数据写完
返回-1,检查errno,如果是EAGAIN那么不再写(缓冲区写完),如果是其他那么说明连接出错,进行报错然后也不再写。
返回大于0,成功写数据
在使用tcp时,内核的tcp上存在读写缓冲区,上层app通过这个缓冲区来和实际的网络进行通信
app <=> 内核tcp <=> network
本文主要讲述了Borg论文中引用的基于机会成本的E-PVM算法
这个算法的缺点(大型任务难以调度)是在我的场景下是可接受的
对Borg来说,任务实际是一个任务组,亲和需求的任务组需要特别多的资源
而在我的调度问题中,大型任务是很少的,因为我的调度器不提供任务组的概念,由业务来解耦任务组
我尝试理解该算法后做一些优化,然后通过模拟器模拟和分集群测试来查看是否可以提升资源利用率
《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》
facebook2015年论文,用于解决离在线混部时,约束离线任务运行在指定资源范围的问题
提出了一种基于树模型的资源调度问题
例如叶子节点是数据库卷,上面的父节点是主机,机架等等
在任务退出时,对影响到的叶子节点以及父节点(直到根节点)进行调度,来避免全部资源池的调度太过耗费性能
Bistro在架构上允许对树的独立资源的根节点,哈希或者按位置进行分区,从而进行并行调度和分布式调度