yeyong

VictoriaLogs 的内存占用主要由“内部缓存 + 近期日志块 + 查询结果缓存”三部分组成。官方默认会自动探测物理机内存并按比例分配，但你可以通过以下两类启动参数把上限压下来，或者固定在一个具

经我在某环境中观察实践，基本满足以下规律 也就是通过不断的试验，只要符合了其中一个，就可以认为是要采集的指标 另外返回值是一个大列表，目前常用的方式是取其中最大值，即单板最高的使用率作为整机的使用率，

虽然知道很容易修改，但是这个默认设置让我有点没想到，结果就是客户环境只能看到7天的数据 而且很糟糕的一点，就是一旦我修改这个值，那么原来的历史数据都被清理掉（尽管只有7天的），这也让我不太适应 不是说

下面是一套“边写边测”的通用套路，确保 page.locator() / wait_for_selector() 在提交代码前就能一次跑通，不用每次都重跑完整流程。 官方“秒测”工具：Playwrig

这是一个积累的记录，比较杂乱，但是看完了应该可以跑通这个目标，放在这里做参考 extras 里并没有叫 gcc-arm64-linux-gnu 的 manifest， 但 “gcc-aarch64-n

把“所有服务”塞进 一个容器，再用 supervisor 做进程管家，这种“胖容器”模式在早年起家时很常见；如今云原生时代更推荐 一进程一容器 的拆分方式。 问了kimi，它的回答是这样的 1. 架构

经过国庆期间的努力，到昨天为止已经可以很顺利的做出arm64镜像并在本地测试运行， 并且部署到真正arm64机器上也没有什么问题。 这个事情可以说完成大半了， 在此记录一下大概过程（可能会有遗漏）

其实是一件简单的事，但是老忘记，还是记录下 可以，一行参数就能让容器用宿主机本地时区，无需改镜像、无需装任何包： 解释 /etc/localtime 是 时区数据文件（二进制），挂进去容器即可； /e

出现 docker buildx build 拉取基础镜像比传统 docker build 明显“卡”的情况，90 % 不是 BuildKit 本身变慢，而是默认路径被改变后，把镜像拉到了另一张网卡