我已经使用这个脚本好几年了，当 7z 中 2 个以上核心是一个挑战时，我刚刚给自己提供了一个闪亮的 i7：
"C:\Program Files\7-Zip\7z.exe" u -m5=lzma2 -mmt=8 %1.7z %1
这样做的好处是可以使用 8 个内核、lzma2 压缩，并将 CPU 频率（通常处于某种 speedstep 降低状态）设置为 max + turbo。速度和便利性都很棒（在 Windows SendTo 中）。
最近我得到了一个惨痛的教训，超过 4GB 的文件在意外删除后很难恢复（NTFS）。我刚刚错误地擦除了一个备份卷...
吸取了教训后，我决定修改我的脚本，让档案跨越 2GB 的卷。
"C:\Program Files\7-Zip\7z.exe" a -m5=lzma2 -mmt=8 %1.7z %1 -v2g
在此过程中失去了更新的便利性。
让我感到不安的是，这也是我的问题主题，我听不到 CPU 和机箱风扇像以前一样启动的声音，而 xeon westmere 会变得更热。我以为我遇到了硬件问题……检查后发现，不仅 CPU 的繁忙程度约为 50%（在所有核心上），而且它还没有摆脱它所处的降低状态（22 的 12x）。这令人恼火：只有 25% 的可用处理能力被使用，而不是 100% 没有卷跨度。我估计归档时间乘以了 10 倍，而不是 4 倍。
错误还是功能？我是否遗漏了什么？这是 Windows 8.1/64，4 核 Westmere xeon，配备 24 GB RAM。7Z 9.20 /64。
我经常使用这个脚本，有时用于多个文件夹存档：
for %%i in (%*) do call "....\archive.cmd" %%i
在 Windows 中相当方便，没有它生活会变得更加困难:)
有人有办法解决这个问题吗？我在谷歌上搜索了好久，但没有任何结果...
谢谢您的意见。祝您有美好的一天。
答案1
7-zip 在 I/O 上花费的时间可能比压缩数据的时间要多。我的建议是使用 -mx9（超级模式）和 -md30（1 GB 字典大小）。
默认字典大小为 16MB。在超级模式下，默认字典大小为 64MB。Z-zip 使用 10.5 倍于字典大小的内存缓冲区（-md30 将总内存使用量提高到 11GB 左右）。当然，较大的字典大小意味着提取档案的计算机也必须分配该大字典。您也可以尝试 -d28。
增加线程数或使用 -v 开关会降低压缩率（根据命令行文档）。设置 -v4095m 是否仍应允许恢复丢失的文件？
-slp（设置大页面模式）选项可能会加速压缩。请查看 http://sevenzip.sourceforge.jp/chm/cmdline/switches/large_pages.htm
一般来说，有了这么多内存，您就不需要分页文件（除了保存崩溃转储）。如果您有一个很大的分页文件，Windows 将尝试将程序的大部分内存移至分页文件，并根据需要分页程序的部分内存。这也会大大降低程序的速度。