USD-M archiver memory baseline ~4.7GB vs 5000M limit

[proerror77]

2026-08-15 观察到 binance-lob-archiver-production@usdm RSS 达 63.9%（~4.7GB，MemoryMax=5000M）。#881 修复了 recover_parts 的一次性分配，但正常运行基线仍接近上限。需要容量评估：symbol 数/深度档位/6h 轮换时的峰值，必要时调 limit 或降内存。

[proerror77]

Capacity gate remains open — 2026-08-17

Fresh runtime readback on i-6we6afeqsvv8uo1ixmyo:

• Host RAM is ~7.4 GiB. Spot production is active on artifact abeb35cc…008e1 and has recorded MemoryPeak=3,223,310,336 bytes.
• USD-M is currently inactive after an OOM and has recorded MemoryPeak=6,262,824,960 bytes. The immediate OOM is explained by the pre-fix(collector): stream recover_parts to survive multi-GB interrupted parts (#869) #881 recursive recovery of a preserved 6.2 GB .jsonl.part.
• Installed production configuration is asymmetric by design: Spot SYMBOLS=ALL, USD-M a recorded Top-50 list.
• Post-fix(collector): stream recover_parts to survive multi-GB interrupted parts (#869) #881 artifact 93407923…67beb (source 3da03f45…1601, deployment bundle 6247b302…e4123) is installed only as the inactive Shadow candidate. Its committed production env would restore USD-M to SYMBOLS=ALL, and the governed Gate/cutover transitions Spot and USD-M together.

Decision: no formal Gate/cutover from the Top-50 runtime to the ALL-symbol bundle under this incident. Streaming recovery fixes the multi-GB startup allocation but does not prove the combined steady-state/rotation memory budget. Issue #738 records the bounded recovery: preserve the three old recovery inputs outside the canonical spool and restart only the unchanged Top-50 USD-M unit.

This issue still needs one changed capacity input and evidence before the candidate can cross the collector boundary: either a host/memory budget that safely covers concurrent Spot+USD-M ALL catalogs and rotation peaks, or a separately reviewed production contract whose Gate and deployment bundle intentionally pin the reduced USD-M catalog. Raising the cgroup cap alone on a 7.4 GiB host is not sufficient evidence.