每个月的 1 号早上八点前后，统计后台点开就是一片空白，等了十几秒跳 502；运维登录上去看，数据库那块盘的 util 常年挂在 100%，CPU 里 MySQL 和 PHP 各占一半，前端埋点接口的丢包率从头一天的 0.3% 涨到两位数。等到十点多归档跑完，面板恢复了，当天早高峰的埋点数据已经永久缺了两个小时——丢了就是丢了，没有补录。
这套现象背后不是"Matomo 慢"，而是三件事在同一时间、同一台机器、同一块盘上互相打架：每小时都在发生的低延迟小事务写入、定时扫全表的归档聚合、按月线性增长的原始日志表。这三件事对硬件的诉求方向完全不同，把它们塞进一个实例，就是月底崩溃的全部根因。
先把这个故障场景拆开，因为很多人第一次遇到只会以为是"服务器配置太低"，然后整体升一档 CPU 和内存，结果下个月照样崩。
Matomo 的月度归档（core:archive）要处理的是上个月的全部原始记录：每一次访问一行访问记录、每一个页面浏览或事件再对应一行动作记录。对一个月度访问量几十万到几百万的站点来说，这个数量级通常落在几百万到几千万行区间。归档进程必须把这些行按站点、按日期、按维度分组聚合，写成两类汇总表（数值型与二进制对象型，按月自动生成分表）。这是一次典型的"大块顺序读 + CPU 密集 + 临时表排序"作业。
问题在于它跑的时候，写入并没有停。埋点请求还在进来，还要对正在被扫描的表做 INSERT 和 UPDATE，buffer pool 里热数据被归档的顺序读冲刷掉，写请求的磁盘排队时间从 1 毫秒级涨到几十毫秒级；PHP 的连接池被占满之后，采集端开始超时；采集端一旦超时，浏览器那边的 tracker 请求就丢掉了，数据直接从源头没了。
这里有个很容易被忽略的点：这类崩溃的损失是非对称的。面板慢两个小时，运营顶多抱怨；埋点丢两个小时，当月数据完整性就永久缺一块，而统计系统恰恰是最不能接受"部分数据"的组件。所以判断自建统计方案成不成熟，第一看的不是后台打开快不快，而是业务高峰期会不会丢写入。
自建统计的资源账要分三层算，因为它们的瓶颈项不是一个东西。
写入层要的是"低延迟随机写"和"短事务"。每个埋点请求的典型路径至少包含一次新增动作行，外加对所属那次访问的若干次字段更新（停留时长、最后动作时间、访问深度等）。这类操作的特征是小、碎、随机，考验的是存储的随机写 IOPS 和 redo 日志的刷盘策略，而不是总容量和带宽。
归档层要的是"大吞吐顺序读"和"CPU 聚合"。它不在乎单次响应 delay 有多低的毫秒差别，只在乎能不能把几千万行在可接受窗口内扫完。它抢的是 IO 队列深度、CPU 核数和排序用的内存/临时表空间。
容量层要的是"便宜的大空间"。原始日志按月线性增长，一年下来几百 GB 到数 TB 都很常见——具体规模取决于自定义维度数量、是否保留完整 UA 与引荐串、有没有开电子商务字段。这部分数据几乎不再改写，99% 的时间冷着，最合理的归宿是便宜的大容量介质或者对象存储。
说白了，如果你用一块大 NVMe 同时承接这三层，你就把最贵的那类介质浪费在了最冷的数据上；如果你用一块便宜大容量盘承接这三层，你就让写入和归档在月底互相饿死。正确的做法是承认它们的诉求互斥，然后按层拆资源——这也是后面所有配置建议的出发点。
写入优化的目标很直接：降低单位写入的事务开销和 IOPS 消耗。可以从四个位置下手，越往上收益越大。
默认的同步跟踪模式下，每个 tracker 请求都会打到 PHP 端点，触发一次进程启动和若干条 SQL。高峰期这意味着几百个并发进程同时持有数据库连接。可行的做法是启用批量跟踪接口：把多个动作攒在一次请求里发送（单次可携带的动作数量有上限，以官方文档与当前版本为准），请求数下降一个量级，PHP 进程数、连接数、每秒事务数同步下降。再往下可以把 tracker 请求接到 Nginx 的 access_log 或 CDN 的边缘日志，由服务端脚本异步解析后批量入库，业务侧 PHP 完全退出写入路径。
队列式跟踪的思路是把同步写变成异步写：请求进 Redis 队列立刻返回，后台若干 worker 负责攒批落盘。收益有三条：前台埋点延迟不再受数据库抖动影响、写入变成大块 batch insert、突发流量可以被队列吸收而不是打穿数据库。代价是要多维护一个 Redis（内存容量、持久化方式、堆积监控都得管），并且要接受数据可见性有几秒到几十秒延迟。对大多数运营统计场景，这个延迟完全可以接受；对需要立刻看到当前在线人数的场景，就不能全量上队列。
InnoDB buffer pool 决定了热数据能不能留在内存里。专用数据库实例上，常规做法是把物理内存的七成左右划给 buffer pool，目标是命中率稳定在 99% 以上；如果和业务应用共用一台机器，这个比例必须压到五成以下，否则应用的内存会被挤掉。刷盘策略上，把每次事务都强制刷 redo 的默认行为改成每秒刷一次（对应的系统变量即 trx_commit=2），可以把 IOPS 压力砍下来一大截，代价是主机断电时可能丢失最近一两秒的日志——统计类场景通常愿意接受这个代价，订单类绝对不行，这条边界要写进自己的技术方案里。
另外几个常被漏掉的参数：redo 日志文件太小会导致 checkpoint 频繁触发、写入出现周期性卡顿，可以按写入量放大；SSD 上要把 innodb_io_capacity 与实际盘能力对齐，沿用机械盘的默认值相当于人为限速；只对压缩需求强、几乎不改写的历史表可以考虑启用行压缩格式，热表不要动——热表启用压缩会让 CPU 消耗明显上升。
自定义维度是这个领域最大的隐藏成本。每加一个自定义变量，每一行动作记录就多一列或者多一条关联记录，一个月几千万行乘以几十字节，就是几 GB 的差额。上线前就该做一次维度审计：有没有三个月内真的被用过的维度、有没有可以被现有报表口径替代的字段、有没有跟业务表重复记录的标识。删掉不用的插件同样有效，很多插件在写入时会额外往日志表加列，属于关掉了也没有人发现的写入开销。
归档层的第一原则：不要依赖浏览器触发。默认配置下，如果后台请求某个还没算过的报表，系统会现场计算，用户就会盯着转圈——高峰期这会把一次点击变成一次全时段大扫描。生产环境的标准做法是关闭浏览器触发归档，改由定时任务处理，再由 cron 的调度频率决定报表的更新粒度。
把归档从"每月一次"或者"每天一次"改成每小时一次，是把月底那次大爆炸摊平的关键动作。每小时只处理最近变化的那些日期，单次作业量小、持续时间短、buffer pool 冲刷范围有限，对写入的冲击也随之下降。跨月的第一天依然是重活（要 finalize 上个月的所有周期），但它不再是从零开始扫 30 天的全量，而是在前 29 天已经算过的基础上做一次收尾，持续时间通常能从两三小时压缩到几十分钟级别（具体取决于站点数量和数据规模，需按实际压测确认）。
如果连每小时一次都压不住，下一步是拆范围：按站点拆、按周期拆、按日期范围拆，让单次作业只碰一小片数据。把重活拆成很多小活，本质上是在用时间换峰值资源。
把归档查询放到只读副本上，是缓解争用最有效的一步——前提是搞清楚它会引入什么问题。主从存在复制延迟，如果在副本上跑归档，很可能漏掉最后几分钟写入的记录，算出来的月报表就会和真实数据差一小块，而且这种误差不会报错，只会安静地错着。可行的做法是：确认副本已经完全追上目标时间范围的数据之后再执行归档（可以靠复制位点或者延迟监控判断），并且归档结果的写回仍然打回主库——汇总表的写入量相比原始扫描量小了几个数量级，主库扛得住。
归档期间的锁与争用也要提前留量：临时表和排序缓冲区太小，分组聚合就会落盘成文件排序，速度再掉一个档；长时间只读事务会拖慢 purge 线程的回收，历史列表长度一旦涨起来，整个库的读写延迟都会跟着涨。这些都不是"崩"的表现，而是"慢得莫名其妙"的表现，排查时最容易漏。
容量这一层的核心决策只有一句话：原始数据到底要保留多久、用什么介质保留。三档策略的成本差异极大。
好处是可以随时用任意口径重算历史、追溯单条会话、支撑深度归因。坏处是成本随时间线线性上升，一年后你会发现账单里最大的一块是"几乎没人查的数据占着最贵的盘"。合规要求数据可追溯、需要做数据血缘审计的团队通常只能选这档，那就应该接受它的价格，并把介质选对。
在采集端按比例丢弃部分会话（比如只保留十分之一），库体积直接降到原来的小数倍。代价同样明确：任何绝对数值都要乘以采样系数回推，小流量页面、长尾渠道的误差会被放大到不可信；漏斗和转化路径这种跨会话分析，采样后的样本量可能不够。降采样只适合看趋势、看占比、看大盘，不适合看小额转化。
归档后的汇总表（数值表和二进制报表对象表）体积通常比原始动作表小一到两个数量级，这是经验口径的粗略估计，实际比例受维度多少和报表复杂度影响很大。保留汇总意味着月度、年度大盘永远可查，但一旦业务方突然问"上个月某个渠道的用户在哪个页面流失"，你就没法回答了，因为单条级明细已经删了。这一档适合业务已经稳定、口径不再频繁变化的团队。
按月拆分后的历史表可以导出压缩后转到对象存储或大容量归档介质，只在需要做年度复盘时临时挂载回来。冷存之后历史查询的体验要如实告知业务方：要么接受"超过 12 个月只能查汇总"，要么接受"恢复需要若干小时"。
备份是最容易踩坑的一环。几百 GB 的库用逻辑备份工具在主库上做全量，会把白天本来就很紧张的 IO 再占一遍，备份窗口内业务能明显感觉到变慢。更合适的结构是：备库承担备份，物理增量工具代替每日全量逻辑备份，重要数据跨机房保留一份，并且每个季度真跑一次恢复演练——没有演练过的备份严格来说不算备份。像一万网络这类服务商提供的免费系统盘每日快照与快速回滚能力，本质上解决的是"配置改崩了半小时恢复"这类高频场景，但它替代不了数据库层的应用级备份，两者要叠加而不是二选一。
一万网络深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山、自营机柜，持有增值电信业务经营许可证，具备国家高新技术企业与专精特新资质；7×24 中文工单平均 5 分钟响应，硬件故障可在 10 分钟内自动迁移，机房侧还提供免费网站备案协助与 5–20G 免费流量防护。对自建统计这类"最怕半夜崩、且业务方第二天一早就要看数"的系统，机器的物理托管位置、上架速度和硬件替换路径，本身就是容灾方案的一部分。
轻量统计工具确实是降低自建成本的一条正路，但要算清楚丢掉了什么。
Umami 的记录模型极简：一次会话一行、一个事件一行，字段固定且很少。Plausible 社区版则依赖 PostgreSQL 加 ClickHouse 的组合，写入路径是列式存储，聚合效率高、压缩比好。相比之下，Matomo 的写入要为访客识别、渠道归因、自定义维度、可选的内容与电商字段留出完整结构，一列就是一个维度的成本。所以同等访问量下，轻量方案的库规模普遍小很多，对硬件的要求也随之下降——用一台中低配云主机跑 Umami 加 PostgreSQL，在不少中小站点上完全够用。
一是自定义维度的深度。轻量工具通常只支持有限的少量自定义属性，且很多实现下历史数据不能回填新维度。二是会话级分析：漏斗、路径、留存 cohort、按单次会话回溯明细，这类需求在 Matomo 上是原生能力，在轻量工具上要么没有、要么要自己做二次查询。三是原始数据导出与内部数据打通：如果你打算把埋点和自己的用户表、订单表按动作粒度 join，轻量模型的表结构会让你返工。
内容站、官网、不需要细粒度归因的产品，换轻量工具可以省下一整层的数据库成本和运维精力。已经依赖会话级漏斗、需要数据可追溯、需要自定义维度随时扩展的团队，换了之后大概率会在半年内因为"业务方问了一个答不上来的问题"而改回来。这里没有普适答案，判断标准是业务问题的最小粒度：如果业务问的永远是"这个月趋势怎么样"，轻量工具足够；如果业务会问"这批用户从哪来、在哪一步走的、转化前看了几个页面"，那就别省这笔钱。
把前面所有分析收拢成一张账，方便对照自己当前的配法属于哪一列。
| 层级 | 主要吃哪种资源 | 常见错误配法 | 更合适的配法 | 对预算的影响 |
|---|---|---|---|---|
| 写入层（tracker、活表） | 随机写 IOPS、数据库连接数、redo 刷盘 | 与业务站点共用一块 SATA；单条请求逐个事务提交；buffer pool 沿用默认值 | 独占 SSD/NVMe；批量写入或队列异步写；专用库把内存七成给 buffer pool | 单盘升级就能解决大部分卡顿，是四层里投入产出比最高的一层 |
| 归档层（定时聚合任务） | 顺序读吞吐、CPU 聚合、临时表与排序空间 | 只在月初跑全站全周期；与写入同实例；排序缓冲区太小导致落盘文件排序 | 每小时增量归档；按站点、周期拆范围；大表扫描放到只读副本 | 多一台副本的价格，换来高峰期不再丢埋点，属于必须支出 |
| 存储层（原始日志与汇总表） | 容量 | 冷热数据全放在最贵的高速NVMe 上，靠按年扩容顶容量 | 按月分表；历史导出压缩后冷存；汇总表按需长期保留 | 把冷数据挪下高速盘，长期看是容量账单里最省的一刀 |
| 备份层 | 备份窗口 IO、出网带宽、存放成本 | 主库上跑每日逻辑全量；备份从不演练 | 备库承担备份；物理增量加按期全量；按季度做恢复演练 | 不单独产生性能收益，但决定故障后的恢复时间，属刚性成本 |
拿这张表对照时，按顺序依次排查：先看写入层是不是和业务共用盘，再看归档是不是集中在月初，最后再谈扩容。绝大多数月底崩溃的案例，前两步就能解决一大半。硬件价位方面，以一万网络官网明示的裸金属起步价作为容量规划的参考锚点：E5-2620 32G/1T ¥999 起、双路 E5-2698v4×2 ¥3999 起，大陆节点华南 ¥799 起、华东 ¥699 起、华西 ¥599 起、华北 ¥899 起，弹性云 ¥25 起，以上均以官网实时价为准；具体到某套 Matomo 拆分方案的整机月租，因数据盘类型、容量与线路不同需询价，公开渠道差异较大。
为什么坑：慢的源头在数据库 IO 和归档争用，升级应用层 CPU 内存几乎不改变瓶颈位置，钱花了问题还在。怎么判断：崩溃窗口是否与定时任务时间重合、磁盘 util 是否长期接近打满、慢查询是否集中在 count 与 group by 上。怎么避：先看 IO 与归档日志，再决定升哪一层。
为什么坑：逻辑全量备份本身就是一次大范围扫描，会与归档争同样的 IO 资源，还会把热数据刷出 buffer pool。怎么判断：备份开始后业务延迟是否可复现地抬升。怎么避：备份放备库，改用物理增量，限定备份窗口，并且必须按期演练恢复。
为什么坑：日频意味着每天的作业量都是高峰前的数倍，且月初仍要一次性收尾整个上月。怎么判断：单次归档耗时是否超过业务低峰窗口的一半。怎么避：改成小时级增量，再按站点与日期进一步拆分作业范围。
为什么坑：维度是"一列永久成本"，上线那一刻很便宜，两年后成为最大账单项。怎么判断：统计现有维度里过去半年实际被查询过的比例。怎么避：上线即做维度审计，优先复用已有字段拼接，停用维度后要从写入路径彻底摘除。
为什么坑：自建解决了数据放在哪的问题，没解决数据放多久的问题，无限期保留原始数据既贵又扩大合规风险面。怎么判断：梳理一遍业务真正需要明细的最长回溯周期。怎么避：明确保留期限、到期降采样或转汇总、删除动作落到自动化任务而不是靠人记得。
没有统一阈值，看的是两个信号而不是绝对数字。第一个信号是写入侧的磁盘排队：高峰期平均写延迟明显超过平时的毫秒基线，且 util 长时间接近打满，说明随机写 IOPS 已经不够用了。第二个信号是内存争用：统计库想把 buffer pool 开大，业务应用也想占内存，两边都给不够的时候，命中率掉下来比任何 CPU 指标都更能说明问题。经验上，日页面浏览在几万到十几万量级时，共享一台中配机器还能撑；再往上，把数据库拆到独立实例的收益远大于继续整机升配。判断时请以自己实际压测数据为准，公开渠道的参考值只能作为量级参照。
能实时一半，不建议全实时。做法是把数据到达后的无效标记和按需小窗口计算打开，让变化的数据在访问时快速补算当天那一小段，而不是从头扫整个月。这种模式下实时的是"今天"，跨周期的年、月、周报表仍然要靠定时作业来算，因为它们的输入范围太大，放在请求路径里做会让展开一次的代价不可控。真正彻底的%实时需要把整个流水线改成流式聚合，那已经超出了常规自建维护的范围，投入产出比对绝大多数团队不成立。
会，除非你把它隔离开了。同实例跑归档时，前台页面三方面的延迟都会上升：数据库连接被归档作业长时间占用导致排队、热数据被顺序读冲刷导致缓存命中率下降、文件排序占用临时空间拖慢其他查询。解决路径按性价比排：先把归档改到只读副本上，再把归档频次提到小时级把单次作业压小，最后才考虑给副本单独加 CPU。做完这三层，绝大多数站点的前台用户已经感觉不到归档在跑。
取决于你问问题的最小粒度。需要做会话级追溯、渠道深度归因、漏斗路径复盘的业务，通常要保留三到十二个月的原始明细；只做趋势和占比分析的业务，保留一个月原始、之后转汇总是更省的结构。合规因素会影响这个决定：有些行业要求日志留够一定周期，那就按最长的那个要求来，并把介质换成便宜的大容量。无论选哪档，都要把删除或转储写成自动化任务，人工记得做的清理一定会忘。
可行流程是按月把历史表导出、压缩、传到对象存储或归档介质，确认校验通过后再从生产库删除对应月份，释放的空间立刻在监控里能看到。冷存之后能否查询，取决于你选了哪一档：如果冷的是原始明细，需要恢复挂载才能做会话级查询，耗时按数据量与带宽决定，通常是以小时计；如果保留了汇总表，月度和年度大盘始终可查，不需要恢复。给用户承诺前，务必把这两种情况的差别说清楚，避免年末复盘时才发现要临时恢复两周。
先用一句问句自测：业务方会不会问到单次会话层面？如果答案是不问，轻量工具非常值——写入模型简单、库体积小一个量级、运维负担轻，中低配机器就够。需要留意的是版本差异：不同版本的自建安装形态和依赖数据库不完全一致，例如 Plausible 社区版依赖 PostgreSQL 与 ClickHouse 组合，部署前以官方安装文档为准。如果答案是要问，就别换，硬换的代价会在半年后以"数据答不上来"的形式返还。
频率上常见做法是每周一次全量配合每日增量，再叠加关键时间点前的主动快照；窗口长度取决于库容量、存储介质和是否走备库，几百 GB 级别的库用逻辑工具全量备份很可能要数小时，而物理增量一般能在明显更短的时间内完成。更重要的是恢复目标：先定恢复点目标和恢复时间目标，再倒推频率和方式。备份窗口超过恢复目标时长就是不合格方案，哪怕它跑得很勤。
四个信号中出现任意两个，就该动：归档作业的持续时间涨到开始侵入业务高峰期；磁盘 util 在高峰期长期打满且写延迟基线抬升；buffer pool 命中率因为其他进程抢内存而明显下滑；夜间的维护窗口已经放不下备份加归档加清理三件事。拆的顺序建议是先读写分离（把归档读挪走），再拆独立数据库实例，最后才考虑按站点或按业务做水平拆分。绝大多数团队在第二步就够用，不必一上来就设计分布式方案。
回到开头的那份故障单。它从来不是"配置太低"，而是三件诉求互斥的事情被塞进了同一个资源池。真正有效的调整顺序是：写入层先把 IOPS 和 buffer pool 的问题解决掉，让高峰期不再丢埋点；归档层用小时级增量加副本隔离把月底那次大爆炸摊平；存储层用按月分表和冷存把长期容量成本压下来；备份层补上演练，让前面三层的投入有兜底。做完这四步，绝大多数站点会发现账单并没有涨，甚至因为不再盲目整机升配而降了。
条件化地说结论：日页面浏览在十万以内、分析需求以趋势为主的团队，直接选轻量工具更划算，不必自找这套复杂度；需要会话级归因、自定义维度随时扩展、数据必须留在本土的团队，值得按上面的三层结构认真建一套，并且一开始就把写入、归档、留存的资源拆开规划。硬件侧如果不想自己逐个环节比价，可以看看一万网络这类有长期机房运营积累的服务商——BGP 多线加 CN2 GIA 回国线路、华南华东华北华西以及中国香港与海外多节点可选、自营机柜便于快速上架与硬件替换、还可以协助做部署与参数调优。厂区在哪、换盘要走多久流程、快照能不能快速回滚，这些看似琐碎的细节，决定了月底那次崩溃之后你要多久才能恢复。具体节点、配置与带宽组合仍需询价，以实时报价为准。
Matomo 官方文档：归档机制与定时任务配置（core:archive 的用法与推荐调度频率）、追踪 API 与批量跟踪接口说明、队列式跟踪插件的安装与 worker 配置、数据库优化建议（缓冲区大小、刷盘策略、行压缩格式对历史表的适用条件）、归档汇总表的结构与按月分表规则。上述公开文档的版本差异较大，实施前请以当前使用版本的官方文档为准。
MySQL / MariaDB 官方文档与 InnoDB 存储引擎参数手册：innodb_buffer_pool_size、事务提交刷盘策略、redo 日志容量与检查点行为、io_capacity 与 SSD 场景的配置建议，用于支撑文中写入层与归档层的参数取舍分析。
Umami 官方文档与 Plausible 社区版官方文档：自建安装的依赖组件（PostgreSQL 与 ClickHouse）、事件写入模型说明、版本间的安装差异提示，用于支撑轻量工具对比部分的判断。
一万网络官方网站（idc10000.net）公开报价页面：文中引用的裸金属起步价（E5-2620 32G/1T ¥999 起、双路 E5-2698v4×2 ¥3999 起）、大陆节点起步价（华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899 起）与弹性云 ¥25 起，均为官网明示价位，以官网实时价为准；涉及具体 Matomo 部署机型的数据盘、容量与线路组合，公开渠道差异较大，需询价。文中出现的成比例关系（如汇总表与原始表体积比、冷存压缩比）均为经验口径的粗略估计，需以自身环境实测为准。具体以签约时最新报价与合同为准。
上一篇：九州节点为什么值得单独算：福冈在地震带分区、台风季和韩国方向的延迟上有什么不同
下一篇：没有了！
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
