Как я могу уменьшить ЦП в операции SORT

Несколько комментариев по улучшению производительности ввода-вывода, которые должны улучшить общее затраченное время.

1. В своем заявлении SORTIN и SORTOUT DD добавьте следующее в свой DCB.

Из Руководства MVS JCL IBM на стр. 143.

//SORTIN   DD DSN=FILEONE(0),                           
//            DISP=SHR<b>,DCB=BUFNO=192</b>                                            
//SORTOUT  DD DSN=&&TEMP,                                       
//            DISP=(NEW,PASS,DELETE),                          
//            DCB=(RECFM=FB,LRECL=30050,BLKSIZE=0,BUFNO=192),
//            UNIT=TAPE

Я выбрал 192, так как в наши дни он относительно дешев с точки зрения памяти. Отрегулируйте для вашей среды. По сути, это сообщает системе, сколько блоков нужно прочитать с каждым вводом-выводом, что сокращает время, связанное с операциями ввода-вывода. Вы можете играть с этим числом, чтобы получить оптимальный результат. По умолчанию 5.

BUFNO=buffers
Указывает количество буферов, которые должны быть назначены DCB. Обычно максимальное значение равно 255, но может быть меньше из-за размера области. Примечание. Не кодируйте подпараметр BUFNO с подпараметрами DCB BUFIN, BUFOUT или параметром DD QNAME.

2. Вы можете рассмотреть размер блока. Размер блока на выходе кажется странным. Убедитесь, что он оптимизирован для устройства, которое вы собираетесь использовать. Для устройств TAPE это значение должно быть как можно больше. Для устройств 3480 или 3490 это может быть до 65535. Вы не указываете LRECL, но указываете, что это 30050, тогда вы можете указать BLKZIE 60100, что будет двумя записями на блок. Лучшая эффективность ввода-вывода.

Вот дополнительная информация о Выбор BLKSIZE для лент.

3490 Emulation (VTS)    262144 (256 KB)
3590                    262144 (256 KB) (note: on some older models the limit is  
                                               229376 (224 KB) 262144 (256 KB)

3. Последний быстрый совет, если вы действительно используете TAPE, это указать несколько устройств TAPE. Это позволит записывать одну ленту во время монтажа следующей. Я также включил здесь пример BUFNO:

//SORTOUT DD DSN=&&TEMP, // DISP=(NEW,PASS,DELETE), // DCB=(RECFM=FB,LRECL=30050,BLKSIZE=0,BUFNO=192), // UNIT=(TAPE,2)

Конечно, эти оптимизации зависят от вашей физической среды и настройки DFSMS.

Я люблю диагностировать такие проблемы...

80 М записей по 30 КБ каждая — это около 2,5 ТБ, и, поскольку вы читаете и записываете эти данные, вы обрабатываете как минимум 5 ТБ (не включая ввод-вывод для рабочих файлов). Если я правильно рассчитываю, это в среднем 500 МБ/с за три часа.

Первое, что нужно сделать, это понять, действительно ли DFSORT активно работает в течение 3 часов, или есть источники времени ожидания. Например, если ваши ленты представляют собой многотомные наборы данных, может потребоваться некоторое время для подключения ленты. Ищите это в сообщениях журнала заданий — может быть, 20 минут из ваших 3 часов просто ждут, пока будут смонтированы нужные ленты.

У вас также может возникнуть проблема с использованием ЦП, увеличивающая время ожидания. В зависимости от того, как настроена ваша система, ваша работа может заключаться в том, чтобы получать только небольшой кусок процессорного времени и ждать остальное время. Вы можете определить это, посмотрев на потребляемое время ЦП (оно также указано в сообщениях журнала заданий) и сравнив его с истекшим временем... например, если ваше задание получает 1000 секунд ЦП (TCB + SRB) в течение 3 часов, вы средняя загрузка ЦП за это время составила 9%. Может случиться так, что отправка вашей работы в другой класс работы имеет значение - спросите у местного системного программиста.

Конечно, 9% процессорного времени не может быть проблемой — ваша работа, вероятно, сильно связана с вводом-выводом, поэтому большая часть времени ожидания приходится на ожидание завершения ввода-вывода, а не на ожидание дополнительного времени процессора. Что вы действительно хотите знать, так это то, связано ли ваше время ожидания с доступом к ЦП, ожиданием ввода-вывода или по какой-либо другой причине. Опять же, ваш местный системный программист должен помочь вам ответить на этот вопрос, если он знает, как читать отчеты RMF.

Следующее, что нужно сделать, — это немного лучше понять ваш ввод-вывод, чтобы уменьшить общее количество физических операций ввода-вывода, которые необходимо выполнить, и/или сделать каждый ввод-вывод немного быстрее.

Подумайте об этом так: каждый физический ввод-вывод будет занимать как минимум 2-3 миллисекунды. В худшем случае, если каждая из этих 160 миллионов записей, которые вы читаете/записываете, занимает 3 мс, истекшее время составит 160 000 000 X 0,003 = 480 000 секунд, или пять с половиной дней!

Как упоминает другой респондент, размер блока и буферизация — ваши друзья. Поскольку большая часть времени в операции ввода-вывода сводится к срабатыванию ввода-вывода и ожиданию ответа, «большой ввод-вывод» не занимает намного больше времени, чем «малый ввод-вывод». Как правило, вы хотите выполнять как можно меньше и как можно больше физических операций ввода-вывода, чтобы сократить истекшее время.

В зависимости от типа используемого лентопротяжного устройства, вы сможете получить на ленте до 256 КБ блоков — это 7 записей на ввод-вывод. Ваш BLKSIZE=0 может уже дать вам это, в зависимости от того, как настроена ваша система. Однако обратите внимание, что это зависит от устройства, и следите за тем, чтобы ваш сайт не использовал один из виртуальных ленточных продуктов, которые отображают «настоящие» ленточные накопители на диск... здесь размеры блоков, превышающие определенный предел (32 КБ), имеют тенденцию работать медленнее.

Буферизация, к сожалению, более сложна, чем предлагался в предыдущем ответе ... оказывается, BUFNO предназначен для относительно простых приложений, использующих метод доступа IBM QSAM, и это не то, что делает DFSORT. Действительно, DFSORT довольно умно выполняет операции ввода-вывода и динамически создает буферы на основе доступной памяти. Тем не менее, вы можете попробовать выполнить задание в более крупном регионе (например, REGION=0 в вашем JCL), и вы можете найти параметры DFSORT, такие как справка MAINSIZE=MAX — см. эта ссылка для получения дополнительной информации.

Что касается вашего дискового ввода-вывода (который включает в себя эти наборы данных SORTWK), здесь тоже есть много вариантов. Ваш 30K LRECL в значительной степени ограничивает то, что вы можете сделать для блокировки, но есть всевозможные упражнения по настройке диска, которые вы можете выполнить, от использования наборов данных VIO до PAV (томов с параллельным доступом). Дело в том, что многое из этого также зависит от конфигурации, поэтому правильный ответ будет зависеть от того, что есть на вашем сайте и как все это настроено.

Но, возможно, самое важное заключается в том, что вы не хотите заниматься методом проб и ошибок, пока не наткнетесь на правильный ответ. Если вы хотите учиться, ознакомьтесь с RMF или любыми другими инструментами управления производительностью, которые есть на вашем сайте (или найдите системного программиста, который готов работать с вами) и копайте. Спросите себя, в чем узкое место - почему эта работа не выполняется быстрее. ? Затем найти узкое место, исправить его и перейти к следующему. Это потрясающие навыки, и как только вы освоите основы, это перестанет казаться черным искусством и больше походит на систематический процесс, которому вы можете следовать с чем угодно.

Поскольку вы пишете

... на выполнение уходит 3 часа...

Я предполагаю, что вы действительно хотите сократить прошедшее время, а не процессорное время. Прошедшее время зависит от многих факторов, таких как конфигурация машины, скорость машины, общая загрузка системы, приоритет вашей работы и т. д. Без дополнительной информации о среде трудно давать советы.

Однако я вижу, что вы записываете вывод сортировки во временный набор данных. Я заключаю, что есть еще один шаг для чтения этих данных. Почему вы записываете эти данные на ленту? Диск, безусловно, будет быстрее и уменьшит затраченное время.

Питер