python的import问题踩坑
在Serverless平台的研发过程中,意外在python的import问题上踩坑了
大概还是对python的包管理基本原理不够了解,首先对python的包管理机制做一个总结,然后分析这一次踩坑的问题
python的包管理
Import基本语法
Python 中 import 有四种常见语法形式:
在Serverless平台的研发过程中,意外在python的import问题上踩坑了
大概还是对python的包管理基本原理不够了解,首先对python的包管理机制做一个总结,然后分析这一次踩坑的问题
Python 中 import 有四种常见语法形式:
本文整理一下遇到的编译问题,最常见的就是编译时缺符号,重定义
但是一般来说cmake生成的make语句会隐藏实际的gcc语句,如果手写的makefile,也有可能是目标规则没配置正确
查看实际的gcc语句
特殊命令
VERBOSE = 1或者V=1,主要看makefile怎么写的,一般都能用
通用的
make -n
实际上是只输出make试图运行的指令
查看目标规则情况
make -d
将打印 Make 为每个目标尝试的所有规则(包括内置规则)
最近业务报障,使用taf框架编译成动态库,从3.4.5.8-notrace版本换成3.4.6.0-notcmalloc版本后
dlopen打开动态库报错cannot allocate memory in static TLS block,业务认为是不带tcmalloc导致的
我的最终结论是taf框架的动态库编译强制开启了静态TLS,这个线程私有变量区是存在上限的,trace代码有超大的线程私有变量,导致dlopen失败
总结了一下何时会开启静态TLS,并且如何解决
截止25年1月12日,打算使用dlmopen来装载serverless平台第三方动态库的计划,在挣扎了2周后正式宣布破产
总的来说dlmopen虽然已经有几十年历史了,但是在当前还是非常不成熟的,有很多细节问题没有解决
想用上dlmopen,需要深入理解glibc的实现原理,和patches的可能bug斗智斗勇,这个投入产出比很低
serverless平台的设计原理属于机密,略过不提
首先分析一下我所见过的权重负载均衡算法的平滑性缺点,最后着重分析来自Nginx的默认算法:平滑加权轮询算法(Smooth Weighted Round-Robin )
首先负载均衡算法的平滑性,我认为包含两个重要特征:
在较大的某个时间窗口内一定会访问某些节点:
违反这个特征,会导致部分节点的使用率过低
这可以认为是一种稳定性,稳定的访问有权重的节点
不能太过连续访问某些节点
违反这个特征,会导致部分节点使用率过高,导致过载
续接十年前总结的前文linux的内存管理介绍
最近遇到了Serverless平台的管理节点上报内存不准确的问题,导致调度误判从而大量oom,所以不同于前文对meminfo一笔带过,需要对meminfo做一个系统的深入了解,并对其内容做一个分类,搞清楚存在的相互联系
首先贴一个/proc/meminfo
的数据,可以看到,有49项,非常复杂
1 | MemTotal: 1950928 kB |
本篇总结一下信号的必要知识,以及实际场景下的处理,主要参考UNIX环境高级编程(第三版)
要先从子进程fork开始总结,因为信号和子进程息息相关
根据书中8.3节 fork以及8.6节 wait