文章

合并连接两段历史，并记录项目的结果快照。普通的双分支分叉合并，会创建同时把两个原末端作为父级的新提交。这些父级关系让更早的提交仍然可达，却不能证明最终文件保留了每一项预期行为。合并既是图上的连接，也是内容上的决定；只检查其中一面，会漏掉另一面真实存在的错误，不能把“两个父提交都还在”当作功能没有丢失的证据。 父级保留历史，不把它改写成单线 如果当前末端是传入末端的祖先，快进可以直接移动当前分支引用，不需要额外合并提交。当两侧各自拥有新提交后，普通合并才产生双父级结果：第一个父级是合并前的当前末端，第二个是传入末端。图中依然包含两条历史线，并没有把它们重新写成一串线性提交。阅读历史时，应区分分支名字的变化与提交图本身的形状。 Git 通常借助合并基点协调两侧末端；更复杂的历史可能涉及多个基点。相对共同祖先比较，可以区分某一侧确实修改的内容和保持不变的上下文。但文本结果干净，只表示选定合并机制找到了一种组合文件的方法，不代表 Git 理解了应用接口、业务规则或发布依赖。这些含义仍需通过源码关系、约定和测试来判断。 记录连接之前先审阅结果树 开始前应明确并保留当前工作状态。未提交修改可能阻止合并，也可能让失败后重建原状态变得复杂。不能假定中止操作能够恢复任意在合并前或合并期间发生的编辑。还应记录真正被连接的分支末端对象，让审阅和后续检查针对稳定对象，而不是继续变化的名称；否则两次观察可能根本不是同一组输入。 如果流程要求显式审阅合并提交，可以让 Git 在记录提交之前暂停。但不提交选项无法阻止快进，所以即使线性情况也要求生成合并提交时，需要同时关闭快进。暂停后检查暂存变化，把候选结果与两个父级分别比较，并运行任意一侧所影响的测试。下面的实验正是在这个暂停点发现行为不兼容，先修复再记录合并，而不是把有问题的组合直接当成成功。 压缩合并是另一种选择：--squash 准备组合内容，但不记录 MERGE_HEAD，之后普通提交也不会把传入末端记作父级。因此，即便最终文件看起来相同，祖先关系以及未来合并的判断基础也可能不同。需要保留双父级证据时，不能把压缩提交误认为普通合并的等价记录。 坏掉的样子 文本冲突不限于两边改动同一行。删除、重命名、二进制变化及其他不兼容操作，都可能需要人工决定。应使用工作区状态及索引中的未合并条目识别未解决路径。普通文本冲突中的标记方便查看双方内容，但没有发现这些字符串，不能证明所有冲突已经解决，更不能代替对二进制文件或路径结构的检查。 解决应遵循组合后程序的真实契约，再暂存具体路径并继续或提交。删除标记、执行暂存，只是在告诉 Git 已经提供了解法，不是在证明解法正确。生成文件应先协调权威输入，再通过生成器重建；不能把两个生成结果拼成看似合理的输出，否则下次构建还会覆盖人工拼接，甚至与输入表达的规则不一致。 更隐蔽的是文本干净却行为损坏。一条分支可能收紧函数参数形式，另一条同时增加仍按旧形式调用的代码。它们修改不同文件，各自测试都可以成功，组合后却失败。因此，集成测试必须覆盖这次组合新形成的调用关系，不能只是把两份分支测试摘要并排放在一起，就认为结果也已经通过同样验证。 策略选择还可能主动丢弃内容。偏向传入方的冲突选项，会优先采用传入方的冲突片段，同时保留其他非冲突变化；它不是自动保留双方意图的通用规则。另一种名为 ours 的策略则保留当前目录树，却仍把另一侧历史记录为已合并。因此，双父级图不能证明传入实现真的被采用。类似选择必须有明确依据并审查内容，不能只为让冲突提示消失而使用。 快速验证 在 POSIX 系统上使用 Python 3 和 Git 2.28 或更新版本运行下面实验。全部工作都在临时仓库，使用示例身份，没有远端，关闭钩子与签名，并排除继承的 Git 路由和个人配置。一条分支要求 Python 接口使用关键字参数，另一条分支新增位置参数调用。关闭字节码写入，是为了避免测试产生的缓存混入工作树状态，便于准确检查最终仓库是否干净。 import os import subprocess import sys import tempfile from pathlib import Path env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")} env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull) with tempfile.TemporaryDirectory(prefix="git-merge-demo-") as directory: root = Path(directory) def git(*args): return subprocess.run( ["git", "-c", "user.name=Merge Example", "-c", "user.email=merge@example.invalid", "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args], cwd=root, env=env, text=True, capture_output=True, check=True, ) def python(*args): return subprocess.run([sys.executable, "-B", *args], cwd=root, text=True, capture_output=True) git("init", "-q", "-b", "main") (root / "api.py").write_text('def render(name):\n return "Hi " + name\n') git("add", "api.py") git("commit", "-qm", "base API") git("switch", "-qc", "topic") (root / "api.py").write_text('def render(*, name):\n return "Hi " + name\n') git("add", "api.py") git("commit", "-qm", "require a named argument") topic = git("rev-parse", "HEAD").stdout.strip() topic_test = python("-c", 'from api import render; print(render(name="Ada"))') print("topic-test-passed:", topic_test.returncode == 0 and topic_test.stdout == "Hi Ada\n") git("switch", "-q", "main") (root / "client.py").write_text('from api import render\nprint(render("Ada"))\n') git("add", "client.py") git("commit", "-qm", "add a caller") main = git("rev-parse", "HEAD").stdout.strip() main_test = python("client.py") print("main-test-passed:", main_test.returncode == 0 and main_test.stdout == "Hi Ada\n") git("merge", "--no-ff", "--no-commit", "topic") print("text-merge-clean:", not git("ls-files", "-u").stdout and git("rev-parse", "MERGE_HEAD").stdout.strip() == topic) broken = python("client.py") print("combined-behavior-failed:", broken.returncode != 0 and "TypeError" in broken.stderr) (root / "client.py").write_text('from api import render\nprint(render(name="Ada"))\n') fixed = python("client.py") assert fixed.returncode == 0 and fixed.stdout == "Hi Ada\n", fixed git("add", "client.py") git("commit", "-qm", "merge topic and adapt the caller") print("reviewed-merge-parents:", git("rev-parse", "HEAD^1").stdout.strip() == main and git("rev-parse", "HEAD^2").stdout.strip() == topic) print("fixed-and-clean:", not git("status", "--porcelain").stdout) 六个观察都应为真。两条分支各自检查成功，Git 也没有报告未合并路径，但组合后的调用抛出类型错误。把调用方适配为关键字参数后，恢复预期输出，再记录合并。最终提交拥有两个准确的父级，工作树干净。这验证了一次真实的干净合并故障及其修复，也说明历史仍然可达，与最终行为正确，是必须分别验收的两件事。 ...

慢启动在 TCP 发送端探索路径可承受的未确认数据量时，逐步扩大拥塞窗口。数据充足且确认模式合适时，经典行为是在多个往返间近似指数增长。“每个 RTT 翻倍”是有用的简化模式，不是无条件计时器规则。窗口变化依赖传输反馈和实现的增长条件，不能只根据连接已经打开多久，就推断它获得了多少发送预算。 坏掉的样子 connect 之后等待，不会自动把拥塞窗口预热。应用没有发送数据时，就没有支持这种增长的数据确认。很小的交换，也可能在用满已有发送预算之前便结束。期待每个短请求都出现大幅翻倍序列，是把受应用数据量限制的传输误认成持续积压的发送端。缺少明显增长，并不自动说明慢启动没有工作或连接存在故障。 现代系统初始窗口也不统一为一到两个段。RFC 6928 描述了允许更大初始窗口的实验性扩展，本次 Linux 发送端起步为十个段。单位同样重要：Linux TCP_INFO 的 snd_cwnd 以段为单位，许多协议说明则用字节描述拥塞窗口。推算未确认数据量之前，应同时查看发送 MSS，避免将段数直接当成字节数或当前实际在途段数。 慢启动并非总要持续到第一次丢失，之后统一彻底缩回起点。慢启动阈值帮助决定启动增长与拥塞避免，具体实现还可能采用额外启动检测；重传超时恢复也不同于快速恢复。把同一条示意曲线套到所有算法、丢失信号和工作负载，即使读到了真实指标，也可能作出错误诊断。首先需要确认当前连接处于哪个阶段。 快速验证 将脚本保存为 check-slow-start.py，准备 Docker 后运行 python3 check-slow-start.py。一次性环境使用 Python 3.11.16 和 iproute2 6.1.0，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持嵌套命名空间。客户端和目标通过新建 veth 相连，netem 在两个方向的出口各添加十毫秒延迟，全部变更仅作用于虚拟端点： from pathlib import Path from tempfile import TemporaryDirectory import json,subprocess,uuid recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n' program=r""" from contextlib import ExitStack,contextmanager from pathlib import Path from tempfile import TemporaryDirectory import json,os,select,signal,subprocess,time def run(*args,check=True,input=None,timeout=8): result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout) if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr) return result def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs) def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs) def stop(process): if process.poll() is None: process.terminate() try:process.wait(timeout=2) except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2) def line(process,timeout=3): assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded' value=process.stdout.readline();assert value,('child exited without a response',process.stderr.read()) return value def spawn(stack,command): process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True) stack.callback(stop,process);return process @contextmanager def lab(names): with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack: root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc)) stack.callback(run,'umount',str(proc)) for name in names: run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False) ip(name,'link','set','lo','up') def setting(name,key,value): assert name in names path=proc/'sys'/key.replace('.','/') return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip() yield root,stack,setting def wire(left,left_if,right,right_if,left_addresses,right_addresses): run('ip','link','add',left_if,'type','veth','peer','name',right_if) for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]: run('ip','link','set',interface,'netns',name) for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else [])) ip(name,'link','set',interface,'up') def nft(name,script):return ns(name,'nft','-f','-',input=script) def counters(name): data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={} for entry in data['nftables']: rule=entry.get('rule',{}) if 'comment' in rule: for expression in rule['expr']: if 'counter' in expression:found[rule['comment']]=expression['counter']['packets'] return found info_code=r''' import struct def tcp_info(stream): raw=stream.getsockopt(socket.IPPROTO_TCP,socket.TCP_INFO,104);assert len(raw)==104 offsets={'snd_mss':16,'unacked':24,'rtt_us':68,'snd_ssthresh':76,'snd_cwnd':80,'total_retrans':100} return {'ca_state':raw[1],**{key:struct.unpack_from('=I',raw,offset)[0] for key,offset in offsets.items()}} ''' with lab(['client','target']) as (root,stack,setting): wire('client','c0','target','t0',['192.0.2.1/30'],['192.0.2.2/30']) for name,interface in [('client','c0'),('target','t0')]: ns(name,'tc','qdisc','add','dev',interface,'root','netem','delay','10ms','limit','10000') server_code=r''' import socket,json,hashlib,sys size=int(sys.argv[1]);listener=socket.socket();listener.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) listener.bind(('192.0.2.2',18080));listener.listen();print('listening',flush=True) with listener.accept()[0] as connection: connection.settimeout(6);remaining=size;digest=hashlib.sha256() while remaining: chunk=connection.recv(min(65536,remaining));assert chunk;remaining-=len(chunk);digest.update(chunk) assert digest.hexdigest()==hashlib.sha256(b'x'*size).hexdigest() connection.sendall((digest.hexdigest()+'\n').encode()) ''' client_code=info_code+r''' import socket,json,time,threading,sys,hashlib size=int(sys.argv[1]);stream=socket.socket();stream.settimeout(6) stream.setsockopt(socket.IPPROTO_TCP,socket.TCP_CONGESTION,b'reno');stream.connect(('192.0.2.2',18080)) initial=tcp_info(stream);time.sleep(.06);idle=tcp_info(stream);assert idle['snd_cwnd']==initial['snd_cwnd'] done=threading.Event();errors=[];samples=[initial,idle];reply=[] def transfer(): try: stream.sendall(b'x'*size) with stream.makefile('rb') as incoming:reply.append(incoming.readline().decode().strip()) except BaseException as error:errors.append(repr(error)) finally:done.set() worker=threading.Thread(target=transfer);worker.start();deadline=time.monotonic()+7 while not done.wait(.005): assert time.monotonic()<deadline,'transfer deadline exceeded' snapshot=tcp_info(stream) if snapshot!=samples[-1]:samples.append(snapshot) worker.join(timeout=1);assert not worker.is_alive() and not errors,errors samples.append(tcp_info(stream));assert reply==[hashlib.sha256(b'x'*size).hexdigest()] assert all(row['total_retrans']==0 for row in samples),samples if size>1:assert max(row['snd_cwnd'] for row in samples)>initial['snd_cwnd']*2,samples else:assert max(row['snd_cwnd'] for row in samples)==initial['snd_cwnd'],samples print(json.dumps({'bytes':size,'algorithm':stream.getsockopt(socket.IPPROTO_TCP,socket.TCP_CONGESTION,16).split(b'\0')[0].decode(), 'before_data':initial,'after_idle_without_data':idle,'samples':samples,'sha256':reply[0]}));stream.close() ''' results={} for label,size in [('short',1),('bulk',1048576)]: service=spawn(stack,['ip','netns','exec','target','python3','-u','-c',server_code,str(size)]);assert line(service).strip()=='listening' results[label]=json.loads(ns('client','python3','-c',client_code,str(size),timeout=10).stdout) service.wait(timeout=2);assert service.returncode==0 print(json.dumps({'egress_delay_each_direction_ms':10,'transfers':results})) """ name='xbcatm-tcpflow-'+uuid.uuid4().hex[:10] def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs) try: with TemporaryDirectory(prefix=name+'-') as directory: root=Path(directory);(root/'Dockerfile').write_text(recipe) build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN', '--memory','256m','--pids-limit','128',name,'python3','-',input=program) assert result.returncode==0,result.stderr print(json.dumps(json.loads(result.stdout),sort_keys=True)) finally: docker('rm','-f',name);docker('image','rm',name) 客户端明确选择 Reno，避免实验悄悄受不同默认拥塞控制器影响。发送之前记录 TCP_INFO，在没有数据的情况下等待六十毫秒，然后再次记录。两次观察窗口均为十个段。这直接检验“新连接只要保持打开，拥塞预算就会按时间增长”的错误预期。增加等待时间与提供可确认的数据，属于不同输入，不能互相替代。 ...

nginx 不会给所有 location 表达式计算一份通用的具体程度分数。普通前缀按匹配长度选择，精确 location 可以结束搜索，竞争正则则按声明顺序求值。某个表达式在人看来更窄，也可能输给前面更宽的正则。把这些选择规则混在一起，是许多看似仔细的路由变更影响意外路径的原因，必须分别理解每类规则。 坏掉的样子 通用 .css 后缀正则，可以先于后面的 /assets/ 限定正则获胜。后者因为包含目录，看起来似乎更具体，但 nginx 不会比较两个模式在语义上谁更窄。在这里的平面结构中，只要两者都匹配，顺序就决定使用哪个配置。路径更长或正则文字更多，都不是正则之间的额外优先分。 调整普通前缀顺序是另一回事。把 /assets/ 移到 / 之前，不会让它“更优先”；在采用前缀结果时，更长匹配本来就决定它获胜。如果把所有 location 都当成同一个先匹配先使用列表，审阅可能做出无效调整，却漏掉真正控制故障路径的正则顺序。修改文本与修改行为之间，需要通过规则和请求证据连接。 较短的 ^~ 前缀，也不是整个子树的永久保护层。如果存在更长的普通前缀并被选中，较短的标记前缀就不再是抑制正则阶段的候选。因此，新增一个看似无害的更详细前缀，可能让原来停留在标记 location 的请求重新被后缀正则接管。这种变化不能仅凭新增块自身内容看出来。 快速验证 下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。 使用宿主 Python、Docker 和固定 nginx 镜像运行脚本。实测为 Linux arm64 上的 nginx 1.28.0、Docker 29.3.1。它构建两份临时配置，分别执行 nginx -t，再通过宿主回环端口发送真实请求。每份配置都只使用平面 location，结束时清理自己的容器、镜像标签和私有网络，不修改既有服务： ...

过期与逐出都可能让一次成功查找变成未命中，但它们回答的是不同问题。过期服从键的截止时间，逐出则在内存压力下移除符合条件的键。延长 TTL 不能阻止容量驱动的逐出，扩大内存也不能纠正应用写错的截止时间。必须先确定实际发生了哪种变化，才能判断应该检查写入协议、调整容量，还是重新设计缓存用途。 时间与容量是两个独立维度 带有过期设置的键在 Redis 中称为 volatile。Redis 会在访问和主动清理过程中检查过期键，但这不承诺键一定存活到截止时间。显式删除、替换以及适用的逐出策略，都可能提前改变结果。因此，不管最初设定的期限还有多久，缓存客户端都必须能处理未命中，不能把较长 TTL 当作某条数据不会丢失的保证。 maxmemory 是 Redis 进行内存管理决策时使用的统计上限，不是操作系统 RSS 的硬上限。复制与追加日志缓冲区可能包含不计入逐出判断的内存，进程开销、分配器行为和持久化任务也需要容量余量。大型命令还可能短暂超过配置值。规划时既要考虑缓存预算，也要考虑运行整个进程的环境，不能把两者设成同一个数字就认为足够。 先确定候选范围，再讨论排序 allkeys 类策略不管键有没有 TTL，都会把它纳入候选；volatile 类策略则只考虑带过期设置的键。在各自候选范围内，LRU 偏向最久未访问的键，LFU 使用访问频率信息，random 类策略随机选择。Redis 的 LRU、LFU 是近似算法，不保证全局精确的受害键顺序。volatile-ttl 偏向剩余寿命较短的条目，也不是只清除已经到期的数据。 noeviction 在无法满足内存限制时拒绝增长内存的命令，而不是为了腾空间丢键；已有数据仍可能正常读取。但它不是持久性保证，普通过期、显式删除、进程故障和持久化配置仍然分别起作用。应检查当前实例实际配置，不能根据某种部署形式或集群名称，推断所有环境都使用相同默认策略。 volatile 策略如果找不到带 TTL 的候选键，在这种场景下就表现得像 noeviction。选了 volatile-lru，不会自动把持久键变成可丢弃数据。反过来，把会话或权威记录与可重建缓存混放在 allkeys 策略之下，它们也会成为候选。键名前缀只是命名约定，不会给逐出算法建立独立的数据保护边界。 坏掉的样子 未命中突然增加，可能来自过期、逐出、主动失效或键构造变化。需要把 expired_keys、evicted_keys 的增量，与同期请求负载和写命令结果一起看。这些是累计计数，应比较有限时间区间，并考虑重启或重置；仅看到逐出数上升，还不能知道哪个应用功能失去了哪些数据。 ...

请求计数器回答进程累计记录了多少事件，速率则回答这些事件到来得有多快。Prometheus 的 rate 估计指定范围内每秒平均增长量，修正能够观测到的计数器重置，并向范围边界进行外推。结果具有明确的时间单位，适合观察负载变化；但它不是两次抓取之间全部事件的精确还原，更不能凭空补回没有采到的重启历史。 采样决定能够推断多少事实 普通计数器在重置前持续增长，进程重启是常见的重置原因。相邻已观测样本出现下降时，计数器函数会按重置处理。不过，如果两次抓取之间已经重启并重新累计，而且新值超过旧样本，重置可能完全不可见。提高抓取频率可以提升观测分辨率，但任何查询都不能确定地恢复一段没有被记录的历史。 应先对每条计数器序列求 rate，然后聚合结果。如果先求和，一台实例的增长可能掩盖另一台实例的重置。标签决定序列身份，替换实例使用新标签时，是开始另一条序列，不是自动接续旧实例。队列长度等仪表值本来就允许正常下降，把它们交给计数器速率函数，会把真实下降错误解释为重置。 选择的范围也是指标含义的一部分 范围选择器左开右闭。在第五分钟求 [5m] 时，恰好位于第零分钟的样本不在范围内。对普通浮点计数器求速率至少需要两个可用样本；只有一个样本时得到空结果，并不表示业务流量为零。因此，范围不仅要覆盖正常抓取周期，还需要考虑偶发漏抓后的样本数量，不能仅凭希望曲线更灵敏就无限缩短。 较长窗口通常会平滑短促突发，也让突发离开平均值的时间更晚；较短窗口响应更快，但观测更少，而且可能变成空结果。应依据事件持续时间与检测目标选择范围，并在面板上明确标注。irate 使用最后两个样本，rate 使用所选范围，两者可以针对同一指标回答不同问题，只要面板清楚说明各自含义，不把数值当成同一种口径比较。 规则评估周期决定何时提出查询问题，不决定目标已经被抓取了多少次。如果目标每分钟才采集一次，即使面板每秒刷新，也不会凭空产生新的观测。分析告警响应速度时，需要分别检查采集与评估这两个周期，不能只缩短页面刷新时间。 坏掉的样子 刚创建的序列可能要等第二个样本到来后才出现在速率面板。把所有空值都补成零，可能掩盖采集故障。遇到空白，应先检查原始序列、时间戳和抓取状态，再判断业务是否空闲。另一种问题是窗口太长：短时间过载已经影响用户，但平均线被长窗口稀释，看起来始终平稳，告警因而没有达到阈值。 重置修正不代表缺口对准确性没有影响。漏抓可能隐藏突发或多次重启，范围边界的外推本身也属于估计。increase 以事件数量单位表达相应的范围估计，即使原始计数器只有整数，也可能返回小数。如果场景需要精确账务或计费总数，应依靠业务记账记录，不能把监控面板描述成可以完整重建交易流水的工具。 快速验证 保存为 rate.py，运行 python3 rate.py。环境需要已经安装的 promtool，可以从 PATH 找到，或用 PROMTOOL 指定其可执行文件路径。本轮使用 Python 3.12.14 与 promtool 3.14.0。真实查询引擎在临时目录中评估合成样本，不启动服务器、监听端口或容器，也不联系外部服务。 from pathlib import Path from tempfile import TemporaryDirectory import os import shutil import subprocess # Uses a real, installed promtool; no server or Docker runtime is started. promtool = shutil.which(os.environ.get("PROMTOOL", "promtool")) if not promtool: raise SystemExit("Set PROMTOOL to an installed promtool executable") tests = r"""evaluation_interval: 1m tests: - interval: 1m input_series: - series: "demo_requests_total{instance=\"steady\"}" values: "0+60x5" - series: "demo_requests_total{instance=\"restart\"}" values: "100 160 220 20 80 140" - series: "demo_requests_total{instance=\"gaps\"}" values: "0 60 _ 180 _ 300" - series: "demo_requests_total{instance=\"one\"}" values: "_ _ _ _ _ 7" - series: "combined_requests_total" values: "100 220 340 200 320 440" promql_expr_test: - expr: "rate(demo_requests_total{instance=\"steady\"}[5m])" eval_time: 5m exp_samples: - labels: "{instance=\"steady\"}" value: 1 - expr: "abs(rate(demo_requests_total{instance=\"restart\"}[5m]) - 5/6) < bool 1e-12" eval_time: 5m exp_samples: - labels: "{instance=\"restart\"}" value: 1 - expr: "increase(demo_requests_total{instance=\"restart\"}[5m])" eval_time: 5m exp_samples: - labels: "{instance=\"restart\"}" value: 250 - expr: "irate(demo_requests_total{instance=\"restart\"}[5m])" eval_time: 5m exp_samples: - labels: "{instance=\"restart\"}" value: 1 - expr: "rate(demo_requests_total{instance=\"gaps\"}[5m])" eval_time: 5m exp_samples: - labels: "{instance=\"gaps\"}" value: 1 - expr: "rate(demo_requests_total{instance=\"one\"}[5m])" eval_time: 5m exp_samples: [] - expr: 'abs(sum(rate(demo_requests_total{instance=~"steady|restart"}[5m])) - 11/6) < bool 1e-12' eval_time: 5m exp_samples: - labels: '{}' value: 1 - expr: 'abs(rate(combined_requests_total[5m]) - 7/3) < bool 1e-12' eval_time: 5m exp_samples: - labels: '{}' value: 1 """ rules = r"""""" with TemporaryDirectory(prefix="prometheus-query-check-") as directory: root = Path(directory) (root / "tests.yml").write_text(tests, encoding="utf-8") if rules: (root / "rules.yml").write_text(rules, encoding="utf-8") result = subprocess.run([promtool, "test", "rules", "tests.yml"], cwd=root, text=True, capture_output=True, timeout=45) print(result.stdout, end="") if result.returncode: print(result.stderr, end="") raise SystemExit(result.returncode) 断言全部通过时输出 SUCCESS。稳定序列每秒增加一个请求。对于 100 160 220 20 80 140，五分钟 rate 为 5/6，increase 为二百五十，irate 为一。这些结果不同，是因为范围排除了最初样本，随后修正可见重置，再把所得到的平均增长外推到请求时长；二百五十不能被描述为原始样本直接观测到的增量。 ...

声明式分区让 PostgreSQL 对外提供一张逻辑表，同时把行存放在不同分区中。父表负责写入路由，并作为统一查询入口；真正持有数据的是物理分区。它的主要收益往往来自生命周期管理和选择性访问，但选择分区时，也会影响键、查询形态和运维锁，不能只把它看作拆文件。 逻辑父表与物理子表 分区父表本身没有行存储。每个已挂载分区保存符合边界的行，可以有自己的存储参数、索引和维护活动。分区索引也类似，是各物理分区索引的集合，并不是在父表上再保存一整份相同数据。理解这一点，有助于区分统一入口与实际占用磁盘的关系。 范围、列表和哈希分区使用不同划分规则。应根据真实访问和保留要求选择键：按月保存事件可能适合范围分区，其他负载可能需要不同分布。声明式分区本身不会把这些分区自动分散到独立数据库服务器。本地分区仍共享所在数据库的资源和事务环境，不能因为表被拆开，就推断它已经实现分布式分片。 保持父表名字稳定，可以简化应用入口，但不能证明应用代码完全不用改。查询需要暴露适合的分区键限制，才可能从裁剪受益；主键与外键引用也可能需要重新设计。原本按全局唯一标识操作的调用，必须保留同样的身份语义，不能在物理拆分过程中悄悄改变其含义。 分区键不只影响路由 分区表上的唯一或主键约束必须包含全部分区键列，而且这些约束要求分区键不含表达式。各分区的独立索引，不能自行证明其他分区中不存在相同键。因此，day 与 id 的复合主键，并不保证 id 在不同日期之间仍然全局唯一。 从单表全局 id 主键迁移时，这个差别尤其重要。只是把日期加入主键，可能弱化原有身份契约。更改之前，应检查调用方、引用关系和重复防护要求。分区键不是可以完全脱离公开数据模型进行调整的纯物理参数，否则原来按 id 更新一行的操作，可能开始匹配多行。 修改分区键可以把行移动到另一个分区。目标分区必须存在并接受该行，索引和约束仍然生效。这是真实数据变更，不是免费的元数据修改。如果保留策略已经移除了目标范围，迟到的修正可能失败，即使逻辑父表仍然存在。生命周期设计应同时考虑正常新增和历史更正。 坏掉的样子 DETACH 把一张表从分区层级移除，但保留该表及其数据。通过父表查询时不再看到它，脱离后的关系仍可单独检查或导出。DROP 则会连同分区数据一起删除。脱离不等于删除，这两种操作也都不会自动生成已经验证过的归档或备份，不能因为维护命令成功就认定数据已妥善保留。 分区维护需要锁。普通 detach 需要父表上的强锁，可能等待长时间运行的操作，也会影响并发访问。PostgreSQL 提供锁行为不同的并发脱离形式，但有额外限制，例如不能放在显式事务块中执行，也不能用于包含 DEFAULT 分区的父表。并发脱离若被中断，还可能需要 FINALIZE 才能完成后续维护。应按照实际契约选择操作，不能把“元数据操作”理解为“一定不会阻塞”。 分区过多也会增加规划和内存成本，没有一个普遍适用的行数阈值能证明分区一定划算。应测量有代表性的读取和维护操作，在写入需要前创建未来分区，并明确迟到数据与保留策略如何配合。对于较小且索引合理的表，大量细碎分区可能只增加管理工作，而没有带来足够收益。 快速验证 把下面内容保存为 partition-lifecycle.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-lifecycle.sql。实验使用临时分区和普通事务内 detach，最后回滚移除整个测试环境。 ...

HorizontalPodAutoscaler 把配置的指标转换为副本建议，因此选择指标与聚合口径本身就是应用设计的一部分。增加副本应该能够降低所测压力，或提升真正有用的吞吐量，否则控制器可能只增加费用，却无法缓解瓶颈。应设置明确的最小与最大副本数，但成本上限不等于性能保障，更不代表到达上限之后仍能处理任何规模的请求。 区分测量与控制 HPA 通常周期性协调，控制器默认同步间隔为十五秒。对于按 Pod 平均的目标，基本计算是当前副本数乘以当前指标与目标指标的比值，再向上取整。CPU 利用率相对于资源 requests 计算，不是相对于 limits，也不是整台节点的总容量。把分母理解错，会让看起来合理的百分比对应完全不同的扩容时机。 跨 Pod 求平均，与对时间序列做移动平均是两回事。Metrics Server 的 CPU 用量来自一个测量窗口，自定义适配器则有自己的查询与取样语义。HPA 并不会统一替每种输入做一个可配置时间窗口的平滑。容差、就绪处理、稳定窗口与速率策略属于控制层，是围绕指标建议的不同机制，不能全部称作“先平滑再决策”。 先确定单位，再讨论目标数字。按 Pod 的自定义指标使用 AverageValue；对象和外部指标可使用 Value 或 AverageValue，扩缩意义不同。整个队列的总积压与每副本平均积压不是可以随意互换的输入。资源利用率还要求提供相应资源请求。即使接口返回正常数字，如果它衡量的不是实际瓶颈，控制器依旧可能做出没有业务价值的动作。 选择增加副本能够改善的信号 CPU 常适合计算密集型服务，但必须先有可用的资源指标接口，并非所有集群天然具备。工作者等待数据库时，可能 CPU 很低、延迟很高；增加更多工作者反而加重数据库压力。依赖自动扩缩之前，应验证目标值是否对应每副本能够持续承担的真实工作，而不是只确认图表会随着请求变化。 请求速率、在途工作与消费积压都需要明确范围。按 Pod 的指标应保留必要的逐 Pod 观测，不能一概预聚合成每工作负载一条序列；对象或外部指标则要聚合到指定工作负载或队列，排除无关流量。避免不必要的用户级、请求级标签，防止查询成本膨胀和选择条件变得难以解释。聚合不是越少越好，而是必须与指标类型的契约一致。 副本字段要有明确负责人 HPA 会读取目标的 scale 信息，并修改副本数。Deployment 初始 replicas 不是 HPA 下限，真正配置的地板是 minReplicas。若部署流程反复提交一个固定副本数，便可能与 HPA 争抢同一字段。应明确配置所有权，并提前安排取消自动扩缩之后使用什么静态规模；不要把最初的副本值说成控制器永远不读取、也完全无关的数字。 ...

巨型页可以增加每条地址翻译缓存能够覆盖的内存范围，在合适负载下减少翻译开销。但效果取决于访问模式和硬件，不能仅因为申请了很大一块内存，就断定程序频繁发生 TLB 缺失。描述工作集需要的页数减少，也不表示所有翻译能够同时装入处理器的 TLB；页数算术、硬件容量与真实性能是三个不同问题。 页大小是一项输入 x86 常见基准页为 4 KiB，但 Linux 的页大小依赖架构与配置，应读取运行系统而不是把四千多字节当作普遍常量。支持的巨型页尺寸同样会变化；2 MiB 与 1 GiB 是常见例子，不是所有处理器的完整列表。跨机器比较时，应先确认单位和实际尺寸，再比较统计数字。 对理想化的连续 8 GiB 范围，4 KiB 粒度需要 2,097,152 个页面，2 MiB 粒度只需 4,096 个。这只是映射覆盖率计算，没有测量硬件 TLB 容量、缺失率、页表遍历延迟，或同时驻留的翻译数量。不同页面大小对应的翻译缓存结构还可能具有不同容量，因此不能把两种页数之差直接称为实际节省的 TLB 项。 显式池与透明分配 Hugetlb 提供显式申请的大页，并由内核维护相应池。持久池中的页面不能同时用于普通分配，也不能在内存压力下换出。池可以在启动时准备，也能在运行中调整，还可能允许额外的 surplus 页面。启动较早时通常更容易获得连续内存，但这并不表示大页只能一次性在开机前决定数量，之后永远无法改变。 透明巨型页采用另一套机制。依内核支持和政策，较大的匿名内存分配既可能发生在缺页时，也可能由后续合并产生。THP 不只是后台线程，也不要求管理员先准备 hugetlb 池。现代内核还可以支持多种 THP 尺寸，不能把每次透明分配都等同于一个两兆字节映射，更不能用 hugetlb 总数代替 THP 使用量。 ...