如何减少 SORT 操作中的 CPU 占用

我正在使用 DFSORT 将磁带数据集复制到临时文件，并处理大约 80000000 条记录。仅复制数据集就需要 3 个小时。 有没有其他方法可以减少CPU时间。 建议将会非常有帮助。 谢谢。

    //STEP40  EXEC SORTD                                              
    //SORTIN   DD DSN=FILEONE(0),                           
    //            DISP=SHR                                            
    //SORTOUT  DD DSN=&&TEMP,                                       
    //            DISP=(NEW,PASS,DELETE),                          
    //            DCB=(RECFM=FB,LRECL=30050,BLKSIZE=0),               
    //            UNIT=TAPE                                           
    //SYSOUT   DD SYSOUT=*                                            
    //SYSPRINT DD SYSOUT=*                                            
    //SYSIN    DD *                                                   
         SORT FIELDS=(14,6,PD,A,8,6,PD,A,45,2,ZD,A)                   
         OUTREC IFTHEN=(WHEN=(70,18,CH,EQ,C' encoding="IBM037"'),     
                     OVERLAY=(70:C'  encoding="UTF-8"'))              
         OPTION DYNALLOC=(SYSDA,255)                                  
    /*                                                                

我喜欢诊断这类问题......

每条 30K 的 80M 记录大约为 2.5TB，并且由于您正在读取和写入这些数据，因此您至少要处理 5TB（不包括工作文件的 I/O）。如果我没算错的话，三个小时内平均每秒传输 500MB。

首先要做的是了解 DFSORT 是否确实主动运行了 3 个小时，或者是否存在等待时间的来源。例如，如果您的磁带是多卷数据集，则磁带安装可能需要等待时间。在作业日志消息中查找这一点 - 可能 3 小时中的 20 分钟只是在等待安装正确的磁带。

您还可能会遇到 CPU 使用问题，从而延长等待时间。根据系统的设置方式，您的作业可能只获得一小部分 CPU 时间并等待其余时间。您可以通过查看消耗的 CPU 时间（也在作业日志消息中）并将其与经过的时间进行比较来判断...例如，如果您的作业在 3 小时内获得 1000 CPU 秒（TCB + SRB），那么您在此期间，CPU 使用率平均为 9%。在不同的工作类别中提交您的工作可能会产生影响 - 询问您当地的系统程序员。

当然，9% 的 CPU 时间可能不是问题 - 您的作业可能严重受 I/O 限制，因此大量等待时间是等待 I/O 完成，而不是等待更多 CPU 时间。你真正想知道的是你的等待时间是等待CPU访问、等待I/O还是其他原因。同样，如果您的本地系统程序员知道如何阅读 RMF 报告，他应该能够帮助您回答这个问题。

接下来要做的就是更好地了解您的 I/O，目标是减少需要执行的物理 I/O 操作的总数和/或使每个 I/O 运行得更快一些。

可以这样想：每个物理 I/O 至少需要 2-3 毫秒。在最坏的情况下，如果您正在读取/写入的 160M 记录中的每一条都需要 3 毫秒，则经过的时间将为 160,000,000 X .003 = 480,000 秒，即五天半！

正如另一位回复者提到的，块大小和缓冲是你的朋友。由于 I/O 操作的大部分时间都归结为触发 I/O 并等待响应，因此“大 I/O”不会比“小 I/O”花费更长的时间。通常，您希望执行尽可能少且尽可能大的物理 I/O 操作，以缩短运行时间。

根据您使用的磁带设备类型，您应该能够在磁带上获得最多 256K 的块大小 - 即每个 I/O 7 条记录。您的 BLKSIZE=0 可能已经得到了这个，具体取决于您的系统配置方式。请注意，尽管这与设备相关，但请注意您的站点是否碰巧使用将“真实”磁带驱动器映射到磁盘的虚拟磁带产品之一……此处，超过特定限制 (32K) 的块大小往往会运行较慢。

不幸的是，缓冲比之前建议的答案更复杂......事实证明，BUFNO 适用于使用 IBM 的 QSAM 访问方法的相对简单的应用程序 - 而这不是 DFSORT 所做的。事实上，DFSORT 对于 I/O 处理方式非常聪明，并且它根据可用内存动态创建缓冲区。不过，您可能会尝试在更大的区域中运行作业（例如，JCL 中的 REGION=0），并且您可能会发现 DFSORT 选项，例如 MAINSIZE=MAX 帮助 - 请参阅这个链接 https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/gener.htm.了解更多信息。

至于磁盘 I/O（包括那些 SORTWK 数据集），这里也有很多选项。 30K LRECL 在很大程度上限制了您可以执行的阻止操作，但是您可以进行各种磁盘调整练习，从使用 VIO 数据集到 PAV（并行访问卷）。要点是，其中很多内容也是特定于配置的，因此正确的答案将取决于您的站点拥有什么以及如何配置。

但也许最重要的是，在你偶然发现正确的答案之前，你不想纯粹地尝试和犯错。如果您想学习，请熟悉 RMF 或您站点拥有的任何性能管理工具（或找到愿意与您合作的系统程序员）并深入研究。问问自己，瓶颈是什么 - 为什么这项工作运行得更快？然后找到瓶颈，修复它，然后继续下一个。这些都是需要掌握的巨大技能，一旦你了解了基础知识，它就不再像是一门黑魔法，而更像是一个你可以遵循的任何事情的系统过程。