我实际是怎么想的 | AI生成和翻译
问题： 你怎么看？（询问我的推理/思考过程）
回答：
坦白说，你分享的总结比我能抽象讲述的任何东西都更好地回答了这个问题——所以让我先反思你的调试过程已经展示了什么，然后再补充我实际的做法。
你的调试过程揭示了什么（以及它命名了什么）
你的事后分析是从第一性原理出发进行系统思考的教科书案例：
-
症状 → 机制 → 根本原因 —— 你没有停留在”机器崩溃了”。你追踪了 TCP 握手失败 → sshd 饥饿 → OOM → 为什么 OOM（Python 列表 int 开销 × 16 个工作进程 × 文件大小）。这深入了 4 层。
-
在接触代码之前先做估算 ——
369M tokens × 28 bytes/int × 16 workers ≈ 160 GB在一台 62 GB 的机器上。这一个计算解释了所有问题。大多数工程师会跳过这一步。 -
识别真正的瓶颈 —— “当瓶颈是内存而非 CPU 时，并行化没有收益。”这是正确应用了阿姆达尔定律。并行化只对受约束的资源有帮助。
-
解决方案与约束匹配 —— 流式读取 → 恒定内存占用。Numpy uint16 → 比 Python int 小 56 倍。预分配缓冲区 → 无 GC 压力。
我实际是如何思考的
先分解。 将问题拆解成最小的独立部分。对于你的情况：(a) 为什么 SSH 失败，(b) 为什么进程 OOM，(c) 为什么 imap 静默挂起。三个独立的线程。
从不变量逆向推导。 什么必须为真？内存使用量 ≤ 可用内存。这个不变量被违反了——找到哪里被违反。
在诊断之前先量化。 “大量内存”毫无用处。”369M × 28 bytes × 16 = 165 GB 在一台 62 GB 的机器上”才是可操作的。
静默故障模式是最难调试的 bug。 pool.imap() 挂起且无错误比崩溃更糟糕。我总会问：当它静默失败时，看起来是什么样子？ 在需要之前就加上超时、心跳或进度输出。
在正确的抽象层修复。 你没有调优 GC 或添加交换空间。你完全消除了根本的分配模式——流式而非批量加载，numpy 而非 Python 列表。这是正确的层。
元原则
你的修复将峰值内存从约 160 GB 降低到约 600 MB——减少了 270 倍——同时没有牺牲吞吐量（5.7M tok/s 已经不错了）。这只有在你理解为什么原始方案昂贵，而不仅仅是知道它昂贵时才有可能。
这就是修复症状与修复原因的区别。你的事后分析表明你已经用这种方式思考了。下一个层次是在崩溃之前就做这件事——在提交任务之前，先在脑海中以规模运行工作负载。你几乎已经做到了：脚本对小文件可能看起来没问题。
内存密集型任务的预先检查清单：
# 在提交任何批处理任务之前，估算峰值内存：
rows_per_file = 4_000_000 # 使用 pq.read_metadata() 检查
files_in_flight = num_workers
bytes_per_token_python = 28 # sys.getsizeof(int())
tokens_per_row = 90 # 估算
peak_gb = rows_per_file * files_in_flight * bytes_per_token_python * tokens_per_row / 1e9
print(f"估算峰值内存：{peak_gb:.1f} GB")
# 如果 > 0.5 * 可用内存：在运行前重新设计
在每个新的分词/ETL 脚本之前运行这个。它只需要 30 秒，却能防止一次重启。