200GB超大文本文件排序去重及进度监控方案咨询

针对你200GB纯文本文件的排序去重需求，结合你之前遇到的sort进程无可见进度的问题，我整理了一套实用的解决方案，从进度监控到工具优化都覆盖到了：

一、先搞懂：为什么你的sort没在/tmp产生变化？ #

GNU sort默认会把临时文件放在$TMPDIR环境变量指定的目录，如果没设置这个变量才会用/tmp。你可以先通过echo $TMPDIR确认临时目录位置，说不定sort的临时文件都在别的地方（比如/var/tmp），导致你在/tmp看不到变化。

另外，sort在处理大文件时，前期会先把数据读入内存，当内存不够时才会生成临时排序块。如果你的机器内存足够大，可能前期一直在内存中处理，还没到生成临时文件的阶段，这也会导致/tmp没动静。

二、如何监控sort的运行进度？ #

如果已经启动了sort进程，你可以用这些方法确认它没停滞：

• 检查进程状态：用ps aux | grep sort查看CPU和内存占用，如果CPU一直在跑、内存有波动，说明进程还在工作。
• 追踪临时文件：先用pgrep sort拿到sort的PID，再用lsof -p <PID>查看它打开的文件，里面会列出正在使用的临时文件路径，去这个路径下看文件大小变化。
• 系统调用追踪：用strace -p <PID> -e trace=read,write，如果能看到持续的read/write调用，说明进程在读写数据，没有停滞。
• 用pv监控输入流量：如果还没启动sort，建议用pv来实时监控数据读取进度，命令如下：

  pv bigfile.txt | sort --parallel=8 -u --buffer-size=64G --temporary-directory=/mnt/ssd/tmp -o sorted_unique.txt
  

  pv会显示当前读取的字节数、速度、预计完成时间，能直观看到sort是否在处理数据。

三、优化排序去重的效率（让进程更快完成） #

针对200GB的大文件，单纯用默认参数的sort效率很低，这些优化能大幅缩短时间：

• 分配足够的内存缓冲区：用--buffer-size参数给sort分配更多内存，比如你的机器有128G内存，可以设--buffer-size=64G，这样sort能在内存中处理更多数据，减少磁盘IO。
• 用SSD做临时目录：机械盘的IO速度是瓶颈，把临时目录指定到SSD：--temporary-directory=/mnt/ssd/tmp，能大幅提升临时文件的读写速度。
• 先去重再排序（如果重复率高）：如果你的文件里重复单词很多，先用awk做O(n)时间复杂度的去重，再排序，能大幅减少数据量：

  awk '!seen[$0]++' bigfile.txt | pv | sort --parallel=8 --buffer-size=64G -o sorted_unique.txt
  

  awk去重只遍历一次文件，比sort先排序再去重（O(n log n)）快很多，后续排序的数据量也会小很多。
• 分块并行处理：如果机器有多个核心，可以把大文件拆分后并行处理，再合并：

  # 拆分文件为每个10GB的块
  split -b 10G bigfile.txt chunk_
  # 并行对每个块去重排序
  parallel --progress 'sort -u {} -o sorted_{}' ::: chunk_*
  # 合并所有已排序的块，最终去重
  sort -u -m sorted_* -o final_sorted_unique.txt
  

  parallel --progress会显示每个块的处理进度，你能清晰看到整体进展。

四、有没有专用工具？ #

其实GNU sort就是最适合这个场景的工具，只要参数优化到位就能高效处理。如果想找替代方案，datamash工具也支持排序去重，但效率不如优化后的sort。另外，上面提到的awk+sort组合，其实就是针对高重复率文件的最优组合。

最后提醒：处理大文件前，确保磁盘有足够的剩余空间（至少是原文件大小的1.5倍），避免中途因为磁盘满而失败。

内容的提问来源于stack exchange，提问作者GMX Rider