工程

工程

Mythex 是如何构建和运行的，包括哪里出了问题、我们如何修复。

• 发布失败时，正常运行的后端永远不会被删除 — 一次失败的重新发布可能删掉应用正在运行的 API，或者让有问题的新版本继续运行。Mythex 撤销失败发布的方式有三处修复。
• 告警只触发一次，而不是每台服务器各触发一次 — 一条每天最多发送一次的告警，在一个下午里到了我们这里五次。两台服务器加上一次部署，让内存中的去重机制失效，共享状态修好了它。
• 迁移到更大的工作区，又不让任何人等待 — 我们升级到 2 GB 后，约四分之一的工作区仍停留在 1 GB。第一个修复方案让一个人等了七分钟。我们做了什么改动，又做了哪些调整。
• 数据库按实际用量计费 — 过去我们会估算每个应用的数据库费用，而这个估算在两个方向上都是错的。现在，每个数据库都按实测用量计费，精确到每小时。
• 捕获发布后立即崩溃的应用 — 有三次发布通过了健康检查，而它们的 API 在每次启动后几秒钟就会崩溃。原因在于：崩溃次数是在一个只保留最近五条记录的列表中统计的。
• 让图片密集的代理回合保持在内存范围内 — 一个代理回合在持续查看目录扫描件时，在 952 MB 处耗尽了内存。三个独立的原因，各自都把图片保留得太久，以及我们如何修复它们。
• 让长时间的代理回合保持在上下文窗口之内 — 我们的子代理会一直增长，直到模型拒绝它们，或者为了节省空间而提前停止，还会错误地计算俄语的 token 数。三项修复让长时间的 AI 工作得以完成。
• 手机休眠时保持聊天在线 — 手机会休眠、切换标签页，并在构建过程中断开网络。两个 bug 让 Mythex 的聊天停滞，或者事后只显示半条回复。我们如何找到并修复了这两个问题。
• 一个大型聊天如何可能让我们的 API 宕机 — 9 月 28 日，我们的两台 API 服务器同时耗尽了内存。第一个修复是加大内存；真正的修复是按大小而非数量加载聊天历史。
• 连按两次发布，现在只会发布一次 — 同一个应用的三个发布请求相隔 84 毫秒到达，每个都启动了一次完整的部署。我们让数据库决定由谁发布，并如实告诉其他请求真实情况。
• 修复自家网站的 SEO 经验教训 — 重复的 FAQ 标记、Google 显示的错误缩略图、没人点击的模板页面，以及边缘服务拒绝的路径：我们在 mythex.ai 上发现并修复的问题。
• 静态网站在重新发布时保持在线 — 以前在 Mythex 上重新发布静态网站时，会先清空线上文件，再上传新构建。现在旧网站会一直提供服务，直到新网站就位，更改几秒内即可生效。
• 藏在进度标签里的内存溢出崩溃 — 我们的 AI 智能体在写入一个很大的文件时内存耗尽。原因既不是模型，也不是并行的子智能体，而是一个状态标签被重复发送了 41,000 次。
• 让我们服务器卡死的缺失交换文件 — 一台生产服务器停止响应，但并没有崩溃——没有内存溢出被杀，只是在一台没有交换空间的机器上出现页缓存颠簸。发生了什么，以及我们做了哪些改变。
• 唤醒数据库时不再遇到失效连接 — 已发布的应用从休眠中唤醒时，第一个请求会卡在睡眠期间已失效的数据库连接上，耗时 10–12 秒。我们如何将其降到 2.3 秒。
• 我们一直在限制自己的服务 — 我们 API 按地址进行的速率限制，把我们自己的服务当成了一个繁忙的用户，结果在生产环境中它们开始收到 429 响应。我们如何发现并修复这个问题。
• 我们为什么把 Mythex 的服务器迁移到 ARM — 重负载工作转移到各项目的沙盒之后，我们的服务器只用了三分之一的内存。更小的 ARM 实例将成本降低了约 30%。以下是具体做法。
• 我们如何把部署的 502 错误降到零 — 一个与部署相互竞争的看门狗，以及一个发现得太晚的负载均衡器：我们如何找到这两个问题、修复它们，并把部署中的 502 从 10 个降到零。