应用零改动迁EKS实测

作者把同一套 Node.js 应用从家庭 k3s 服务器迁到 Amazon EKS，应用代码、容器镜像、Helm chart 与 GitOps 交付模型全部原样保留，但平台层暴露了三个家庭环境不存在的假设：网络、工作节点规格与 AWS 访问。

测试用 Terraform 创建了最小环境：一个 EKS 1.36 集群、一个托管 AMD64 工作节点、两个跨可用区公共子网、AWS Load Balancer Controller 与 Argo CD Core。控制平面创建耗时 5 分 51 秒，CI 检查 13 秒完成，Argo CD 部署两个健康副本，并在 5 秒内纠正了一次手动扩缩容漂移（k3s 上同类测试为 42 秒）。

过程中踩了三个坑：工作节点因私有访问未开启无法加入集群；计划中的 t3.medium 被 AWS 拒绝，改用 c7i-flex.large（2 vCPU / 4 GiB）；交互式登录刷新不稳定，临时创建角色完成剩余操作后清理。预估环境成本约 0.24-0.27 美元/小时，清理脚本在测试后完整执行。

结论清晰：Kubernetes 让工作负载可移植，但网络、实例选择、身份与负载均衡集成仍需 AWS 特定工程。家庭 k3s 仍是日常学习环境，EKS 只作为短期验证目标。

#开发者 #工具 #Kubernetes #EKS #ArgoCD #Terraform #GitOps #k3s #AWS #Helm
@DevToolboxHub

PostgreSQL max_connections 详解：内存、连接数与性能的平衡

max_connections 不是决定查询并发数的参数，而是 PostgreSQL 为每个客户端后端预留共享内存的预算。默认 100，范围 1–262,143。它决定：

- 允许的客户端后端数目；
- 预留的共享内存大小（每个后端占用 PGPROC、pg_stat_activity 行、锁表等）。
- 需要在主机重启后才能修改。

在 18.6 上，默认 shared_buffers 时，max_connections=100 时共享内存约 150 MB；1,000 时 197 MB；5,000 时 389 MB。锁表占用随连接数线性增长。热备机必须与主机使用相同或更大的 max_connections，否则启动失败或在 WAL 中警告。

连接成本
空闲后端仅占约 1 MB 私有内存；活跃后端会消耗 work_mem、hash join 内存等。超过核心数的活跃连接会导致上下文切换、锁竞争，吞吐量下降。

云服务默认值
- Heroku：500 → 5,000（Advanced tier）
- AWS RDS：公式 LEAST(DBInstanceClassMemory/9531392, 5000)
- Azure：MIN(memoryGib*0.1049164697034809, 5000)
- Google Cloud SQL：16 GB 仅 500。

默认值已从 100 提升至 17–50 倍，取决于内存。建议使用 RDS Proxy 等连接池器来避免“too many clients”错误。

实践建议
1. 先在备机调高 max_connections，再在主机调高；反之则会导致恢复暂停。
2. 监控 pg_stat_activity、wait_event_type、load average，及时发现锁竞争。
3. 对高并发应用使用连接池，避免直接打开数百连接。

#开发者 #工具 #PostgreSQL #max_connections #云数据库 #RDSProxy
@DevToolboxHub

Postgres逻辑复制磁盘暴涨之谜

逻辑复制从 Postgres 10 起就是内置功能，但很少有人注意到 CREATE SUBSCRIPTION 语法里那个不起眼的 WITH 子句。它展开后有十多个选项，其中几个直接决定逻辑复制如何消耗存储资源。默认情况下，不带任何参数的订阅完全能正常工作，所以大多数生产环境的订阅都从未调整过这些选项。

问题往往在不知不觉中出现：生产系统挂着多个下游逻辑副本，某天磁盘监控突然报警，pg_replslot 目录被成千上万个匿名文件塞满。这些文件是逻辑解码过程中产生的 spill 文件——当解码事务超出 logical_decoding_work_mem（默认 64MB）的内存预算时，剩余内容会被写入磁盘。每个复制槽对应一个 walsender 进程，各自维护独立的 reorderbuffer，N 个订阅就意味着 N 份解码、N 份 spill，互不共享。

根本原因在于 walsender 必须等待事务提交记录出现，才能把完整事务交给输出插件发送给订阅端。WAL 并非按提交顺序写入，并发事务的 WAL 记录交错排列，还可能中途回滚，所以解码出的变更只能先暂存在 reorderbuffer 里。内存放不下就溢出到 pg_replslot 目录，长事务或大事务会让 spill 文件迅速膨胀。Postgres 17 及更早版本中 streaming 参数默认 off，发布端必须先把整个事务解码并存储完毕才能传输。

实测中，一个 30 万行的单事务在三个订阅节点上各产生 114MB spill 文件，发布端 pg_replslot 目录总计占用 342MB。同一份 WAL 被解码三次、写盘三次。把 logical_decoding_work_mem 调低到 64kB 后，单事务 spill 次数高达 1775 次。更隐蔽的是，事务提交后目录立即清空，只剩累计计数器，现场证据几乎为零。

Postgres 18 已把 streaming 默认值从 off 改为 on，发布端解码后直接转发给订阅端，不再本地落盘。但 TOAST 大字段仍可能触发本地 spill，只是暴露面大幅缩小。Postgres 16 起还支持 parallel 模式，变更直接交给订阅端的并行 apply worker，连临时文件都不需要。pg_stat_subscription 视图里能看到 parallel apply worker 的行，其 leader_pid 为空。

Postgres 17 及更早版本的用户只需一条 ALTER SUBSCRIPTION ... SET (streaming = on) 即可启用流式传输，无需重启，apply worker 会自动重启生效。Postgres 13 及更早版本不支持 streaming 选项，建议尽快升级。文档对 reorderbuffer 和 spill 风险的描述相当简略，DBA 排查时很难联想到这个参数。检查一下自己的订阅配置，pg_subscription 表里 substream 列一眼就能看出当前设置。

#开发者 #工具 #Postgres #逻辑复制 #数据库 #DBA #流式复制
@DevToolboxHub

Cohere发布218B参数稀疏翻译模型 North Small Translate

Cohere 推出了 218 B 参数的 Mixture‑of‑Experts（MoE）翻译模型 North Small Translate，专门为机器翻译设计。模型采用稀疏架构，128 个专家中每个 token 仅激活 8 个，实际活跃参数约 25 B。支持 50 种语言，WMT26 评测得分 83.60，使用多轮自我校正可提升至 84.36。

该模型的硬件需求相对可控：4‑bit 量化版可在单个 NVIDIA B200 或两块 H100 上运行；BF16 精度需四块 B200 或八块 H100。为生产环境提供商业许可与 Model Vault 部署。

对开发者而言，North Small Translate 让翻译任务从复杂提示转为直接函数调用，减少工程成本。可通过 API 或下载权重（CC BY‑NC 4.0）进行评估。

GitHub: GitHub

🔗 原文：点击查看

#开发者 #工具 #Cohere #MoE #翻译模型 #NVIDIA #HuggingFace #PythonSDK
@DevToolboxHub

Postgres角色限制可被会话自身绕过

给 AI 代理数据库角色设置 statement_timeout 和只读事务，是常见的加固手段。但实测表明，这些限制只约束会话的初始状态，代理在自己的会话里可以随时解除。

用 SET 命令即可当场关闭限制，且不会留下 ALTER 痕迹。更隐蔽的是通过连接串或 PGOPTIONS 环境变量传入 -c 参数，source 显示为 client，优先级高于角色级 user 设置，日志里连 SET 都看不到。

PostgreSQL 15 引入的 GRANT SET ON PARAMETER 也无法补救：USERSET 参数本就允许所有角色修改，REVOKE 不会写入 pg_parameter_acl，实际不生效。真正有效的约束是 CONNECTION LIMIT、对象权限和 pg_terminate_backend，这三者无法从会话内部绕过。

测试基于 PostgreSQL 18.6，事务超时对比在 17.11 和 16.15 上完成。给代理数据库授权时，别把超时和只读设置当作安全边界。

🔗 原文：postgr.es/p/9ul

#开发者 #工具 #PostgreSQL #数据库安全 #AI代理 #权限控制 #USERSET
@DevToolboxHub

K8s v1.37 原生直方图转正Beta

Kubernetes v1.37 将原生直方图（Native Histograms）支持升级为 Beta，并默认启用。该特性此前在 v1.36 以 Alpha 引入（KEP-5808），通过采用 Prometheus 原生直方图，Kubernetes 组件能以更高精度暴露延迟与耗时指标，同时显著降低遥测存储与抓取开销。

经典直方图要求指标作者预定义静态累积桶边界（le 标签），存在三大问题：桶边界靠猜，延迟分布变化后失去可见性；每个桶边界单独导出为一条时间序列，推高基数与 TSDB 存储成本；histogram_quantile() 依赖静态桶间线性插值，桶跨度大时分位数误差明显。

原生直方图以动态指数桶替代静态用户定义桶，单条时间序列内包含正负跨度、零阈值与指数缩放因子。优势包括：自动适配纳秒到小时级任意值域；时间序列数量最多减少 90%；默认设置下分位数计算最坏相对误差约 5%。

实现位于共享指标子系统 k8s.io/component-base/metrics，采用双暴露机制：经典桶与原生跨度同时输出，现有 Prometheus、仪表盘与告警规则无需改动。默认指数配置为 BucketFactor 1.1、MaxBucketNumber 160。kube-apiserver、kube-scheduler、kubelet、kube-controller-manager 与 kube-proxy 均自动继承支持。

抓取配置按 Prometheus 版本区分：3.0+ 推荐在 scrape_configs 中设置 scrape_native_histograms: true 与 always_scrape_classic_histograms: true；2.40–2.x 需以 --enable-feature=native-histograms 全局启用。迁移建议分四步：双格式采集、查询迁移至原生直方图语法、在预发/生产验证、确认无误后关闭经典格式抓取，时间序列数量可减少约 90%。回滚灵活，采集端设 scrape_native_histograms: false 即可，组件端可用 --feature-gates=NativeHistograms=false 关闭。

原生直方图正朝 GA 推进，SIG Instrumentation 将持续评估生态就绪度与性能表现，并规划经典静态桶的长期弃用路径。

🔗 原文：点击查看

#开发者 #工具 #Kubernetes #Prometheus #可观测性 #SIGInstrumentation #KEP5808 #监控 #云原生
@DevToolboxHub

LinkDigest：一键把小红书内容转成可读文本

小红书、抖音、TikTok 等短视频平台的帖子往往只在页面中以图片或视频形式呈现，普通 HTTP 请求无法直接获取文本。LinkDigest 通过两步流程：先抓取页面的 state blob，再解析其中的 imageList 与文本信息，生成带时间戳、OCR 文字、图片描述、标题与元数据的 Markdown 或 JSON。一次请求即可得到完整的文字稿，支持 17 张图的帖子生成 381 条文本片段、13 条关键信息，耗时约 119 秒。服务提供 REST API、MCP 接口和 Web 控制台，免费提供三次摘要。

该工具不支持 Bilibili（HTTP 412）、Instagram（需登录）和 Facebook。若某部分内容无法读取，返回结果会标记为 degraded；完全无法读取则返回空结果且不计费。

GitHub GitHub

#开发者 #工具 #LinkDigest #小红书 #短视频抓取

🔗 原文：点击查看