proc下meminfo的细节
续接十年前总结的前文linux的内存管理介绍
最近遇到了Serverless平台的管理节点上报内存不准确的问题,导致调度误判从而大量oom,所以不同于前文对meminfo一笔带过,需要对meminfo做一个系统的深入了解,并对其内容做一个分类,搞清楚存在的相互联系
首先贴一个/proc/meminfo
的数据,可以看到,有49项,非常复杂
1 | MemTotal: 1950928 kB |
续接十年前总结的前文linux的内存管理介绍
最近遇到了Serverless平台的管理节点上报内存不准确的问题,导致调度误判从而大量oom,所以不同于前文对meminfo一笔带过,需要对meminfo做一个系统的深入了解,并对其内容做一个分类,搞清楚存在的相互联系
首先贴一个/proc/meminfo
的数据,可以看到,有49项,非常复杂
1 | MemTotal: 1950928 kB |
本篇总结一下信号的必要知识,以及实际场景下的处理,主要参考UNIX环境高级编程(第三版)
要先从子进程fork开始总结,因为信号和子进程息息相关
根据书中8.3节 fork以及8.6节 wait
docker相对于虚拟机
docker的缺点是因为他的本质是限制和隔离,他并不是一个独立的操作系统,只是在”宿主系统“上限制了资源使用和隔离开了各种资源的视角
cgroup在/sys/fs/cgroup
路径下,有很多诸如 cpuset、cpu、
memory 这样的子目录,也叫子系统
对于编译器而言,符号的全部相关数据都在Elf32_Sym或Elf64_Sym,以Elf32_Sym为例了解一些编译器的知识,然后再分析C++的语法
1 | typedef struct |
st_info这个结构是用于区分各种类型的,也是这一篇博文的重点,这个char结构8位
高 4 位用于表示 st_bind
:
值 | 静态链接行为 |
---|---|
STB_LOCAL |
允许在不同的目标文件中,存在多个相同名字的符号,符号之间相互隔离(无关联)。 |
STB_GLOBAL |
只允许一个目标文件存在 GLOBAL
符号定义,其它目标文件允许相同名字的未定义的符号引用,即不允许多个定义。 |
STB_WEAK |
允许在不同的目标文件中存在多个相同名字的符号。具体来说,如果同时存在一个
GLOBAL 符号和其它同名 WEAK
符号的定义,那就挑选 GLOBAL 符号(ignores the weak
ones);如果存在多个同名 WEAK 符号的定义,事实标准是挑选
linker 解析过程中接触到的第一个符号。 |
我这里特意强调了静态链接行为,因为静态链接和动态链接虽然对LOCAL的逻辑是一致的,但是动态链接器在符号重定位的时候,对GLOBAL和WEAK是一视同仁的
最近业务反馈在我负责的Serverless平台上执行的python脚本,访问azure的speechsdk失败,报错日志如下
1 | 2024-09-02 18:47:16.455 Azure OpenAI is listening. Say 'Stop' or press Ctrl-Z to end the conversation. |
业务把wss协议改成ws协议以后,就可以正常访问服务了
同时在Serverless平台以外,直接在该镜像下也是可以正常访问服务的
因此合理怀疑是Serverless平台的python脚本,使用SSL会存在问题
hexo默认的分类页面,每个分类都需要跳转才能到子页面,这样不够一目了然,考虑到当前只有百来篇博文,没必要每个分类单独跳转页面,因此打算自己实现这个功能
从Hexo添加自定义分类菜单项并定制页面布局(简洁版)大致可以知道实现一个模板文件
然后注入js代码例如
1 | hexo.extend.generator.register("test", function (locals) { |
就可以达到目的
先后尝试了几种办法,折腾了两天才最终搞定
硬件:
软件:
引导系统:Switch专用开源引导加载程序Hekate
虚拟系统:大气层(Atmosphere)18.1.0
在上一篇实现 HTTP 长连接中,研究了整体实现的方案
初步实现并上线后,相对于原先的短链接用法,整个链路的耗时下降了50%,还是挺有成就感的
在这一篇中着重讨论其中选择连接算法,单独写这一篇是因为在揣摩golang的连接池实现中发现了不符合预期的问题
golang版本如下:
1 | ~ go version |
业务有个需求是为taf的HTTP客户端实现长连接
我5年前在前公司就写过cpp的HTTP连接池版本sheep/HTTP_client实现广告项目的RTB
当初的那个实现很粗糙,凑活用就行,但是现在的这个实现是给全公司人用的,首先摆在面前的问题就是实现HTTP长连接的哪个版本?
个人倾向于1.1版本,对服务端要求低比较通用,最后确实选择了1.1版本,选定了版本随之而来又有这些问题:
是否需要实现Pipelining
是否需要解析协议上的任何控制字段
需要哪些配置字段?默认值是什么?
例如连接池的默认的空闲连接数量,这种默认设置最怕大佬问到底,为什么设为5?为什么设为10?
有现有方案就可以直接转移仇恨:为什么golang设为x?为什么nginx设为x?
以域名为粒度实现每个域名一个连接池,还是以ip为粒度
当初是实现了一个基于ip的Client用来实现rpc框架(每个ip单连接多路复用),基于Client又封装了ClientPool给redis, HTTP, mysql用(每个ip连接池)
现在看着不太对劲,HTTP的长连接应该以域名为粒度吧?
这个放到taf框架的博文里面去了,因为初版不打算为HTTP客户端实现太多功能