我的网站的一个实践是当批处理循环开始时,我们在运行任何程序之前分配将在整个运行中使用的所有GDG的新一代.
这意味着我们现在有了在我们的流程开始之前分配超过500个文件的场景.我的任务是试图让这个大规模循环更有效率.我很想知道我应该为这些分配采取哪条路径:
多次连续多次呼叫IDCAMS是否有很多问题？
我有一种预感,将这些分解为更小的步骤可以提高整体性能,但我并没有明确的方法来测试它.我们的测试环境并不是运行指标的好地方,因为我们的工作通常在JES中以低优先级结束,因此我们会大量反弹,因此经过的时间实际上并不是实际发生的事情的良好指标,因为这些都是IDCAMS分配,无论如何,CPU统计数据总是很低.
TLDR; 有谁知道哪个更有效率,或者我怎么能找到哪个更有效？
事实是,如果正确完成,定义数百个数据集不应该强调大多数现代z/OS系统.每个分配都经历了可预测的系统服务序列 - 目录功能,分配功能,安全性,SMF日志记录等等 - 虽然确实存在细微差别,但无论您如何操作,每个都需要相当长的时间.
根据经验,在现代平均调整的大型机上,典型的新文件分配不应超过100毫秒.如果分配500个数据集需要花费超过一分钟的时间,那么您可能会遇到与使用IDCAMS无关的错误.
举个例子,你的工作可能属于一个低优先级的类,一旦消耗了一定数量的资源就会缺乏资源......在这种情况下,它可能只是等待而不是被调度(简单计算CPU时间划分)经过的时间会告诉你这是不是问题).如果这是你的问题,那么"欺骗"的一种常见方法是在JCL中定义GDG而不是通过IDCAMS ...你的JCL分配发生在批处理启动器的优先级上,这通常高于作业步骤本身.请记住,这意味着错误将导致JCL错误,而不是您可能从IDCAMS中的错误中获得的非零返回代码.
您可能还想检查GDG基本定义 - 保持大量的代数往往会减慢速度......也许您可以提出一个更好的方案来存储更少的总代.
要做的一件事是确保您的系统程序员在正确调整事物方面做得很好,特别是目录环境......有许多参数可以控制缓存,缓冲等等,并且如果有正确调整的目录,则必须使用你想要好的表现.这份IBM文档中有很多好的信息.大多数任务需要特殊授权,因此这可能是您无法自行处理的.
如果您实际为新数据集分配磁盘空间,则还需要确保分配参数良好.例如,如果您在同一磁盘卷上放置大量数据集,这将是一件坏事.分配在卷级别执行大量序列化,因此这意味着您可以越多地跨多个磁盘卷传播数据集,争用的可能性就越小.您可以使用RMF(或您的站点可能具有的任何供应商产品)等工具来监控入队延迟等等 - 这通常是缓慢分配性能的罪魁祸首.
这是一个迭代过程,如果你真的想对它有条不紊,那就创建一个测试作业,分配一堆GDG文件并收集它的性能统计数据.不同的分配参数和系统设置将为您提供不同的吞吐量,并且您希望获得最佳组合而不是猜测.无论您经过多长时间,您都可以获得CPU和I/O的服务单元数,这些是您确定最佳效果的最佳指南.
一旦你说服自己系统正确调整并且没有不必要的延迟,下一个选择是你是否想通过并行技术来交换CPU利用率以获得更好的经过时间.您正在做的主要是I/O绑定工作,所以假设您的系统调整得很好,将您的单个作业拆分为具有一部分文件的多个作业将使用稍多的处理器资源,但是从经过的时间开始运行得更快观点看法.最好的情况是,当您使用处理器引擎时,或者当您将目录或磁盘驱动到高利用率时.
只是将分配分成多个作业是一个简单的并行路径,假设您的站点允许它们并行运行(即,有足够的批处理启动器等等).如果你这样做并且经过的时间并不比运行一个大型工作好,那么现在是时候深入挖掘并研究争用的地方,正如我在上面解释的那样.
如果您想要进行一些冒险,那么并行执行大量分配的一种方法是使用UNIX Services shell和BPXWDYN而不是IDCAMS(确保为BPXWDYN指定GDGNT标志).如果操作正确,您可以编写一个shell脚本来启动任意数量的子流程,每个子流程都执行一个子集分配.正确配置,这具有在一个大地址空间中运行的优势,而不是需要多个地址空间来实现并行性的批处理作业.
| 归档时间： |
|
| 查看次数： |
432 次 |
| 最近记录： |