Воскресенье, 19.11.2017, 02:14
Приветствую Вас Гость | RSS
Главная | IDCAMS - Форум | Регистрация | Вход
Форма входа
Логин:
Пароль:
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 11
Форум » Технические форумы » MVS (OS/390, zOS) » IDCAMS (Вопрос по распределению памяти при создании кластера)
IDCAMS
yakigorДата: Пятница, 11.03.2016, 09:58 | Сообщение # 1
Рядовой
Группа: Доверенные
Сообщений: 5
Репутация: 0
Статус: Offline
Столкнулся со следующей ситуацией при создании кластера в IDCAMS.
Создаю VSAM н.д., указав распределение кластера с параметром KILOBYTES (0002200275)
Задание генерируется следующее:
 DEFINE  -                                      
    CLUSTER  -                                  
      (NAME (FASPILOT.DATA.FIORUDBD.FIORU080)  -
      DATACLAS(FASPILOT)                       -
      NONINDEXED                        -       
      KILOBYTES (0002200275)            -       
      CONTROLINTERVALSIZE (00512)       -       
      RECORDSIZE (00505,00505)          -       
      SPEED)                            -       
    CATALOG (CATALOG.FASPILOT)                  
DATACLAS ссылается на storage group, содержащую диски 3390-9.

Согласно геометрии диска 3390-9 (56664 байт на дорожку или 849960 байт на цилиндр)
ожидалось распределение 2 GB на примерно 2600 cyl.
По факту же распределилось порядка 5600 cyl. Почти в два раза больше.

Если указываю в цилиндрах, то распределение в цилиндрах происходит согласно параметру:
CYLINDERS (0000003000), 
3000 cyl.

Вопрос: почему такое распределение, если указан параметр KILOBYTES?
IDCAMS пересчитывает в дорожки и цилиндры, учитывая какую-нибудь другую геометрию дисков?
 
AKonevДата: Пятница, 11.03.2016, 10:31 | Сообщение # 2
Лейтенант
Группа: Проверенные
Сообщений: 46
Репутация: 4
Статус: Offline
Особенно не вдаваясь в теорию.
Если вы указываете в CYL, то и распределяется в них и ничего не пересчитывается
Килобайты распределяются с учетом длины записи, а для длины 505 байт коэффициент утилизации дорожки будет как раз примерно 50 процентов.
Оптимальная длина записи около 27000, как раз две записи на дорожку и утилизация порядка 98 процентов
 
yakigorДата: Пятница, 11.03.2016, 11:05 | Сообщение # 3
Рядовой
Группа: Доверенные
Сообщений: 5
Репутация: 0
Статус: Offline
Подозревал, что именно так, как вы написали.
Спасибо.
 
ggvДата: Пятница, 11.03.2016, 12:49 | Сообщение # 4
Лейтенант
Группа: Доверенные
Сообщений: 54
Репутация: 2
Статус: Offline
Дык просто так 27999 мы взять не можем - это VSAM под базу IMS, CI 512, 7 байт на заголовок, запись 505 - под этот размер записи баи расчитаны вся иерархическая структура, размер root segment и его дочерних сегментов.
То есть просто увеличив размер CI и соответственно record size мы получим опять же потерю места - не наберётся столько сегментов, чтобы заполнить CI.
Если только тогда две иерархические структуры класть в один CI. Что потребует соответсвенного отражения в randomizer, чтобы он правильно распределял... То есть два root segment в один CI.
Мда, задачка.
Оно то возможно.
Наверное, так и придётся, не терять же 50% дискового пространства - не поймут-с.
Спасибо за ответ, помогли нащупать путь движения.


Сообщение отредактировал ggv - Пятница, 11.03.2016, 12:50
 
AKonevДата: Пятница, 11.03.2016, 14:02 | Сообщение # 5
Лейтенант
Группа: Проверенные
Сообщений: 46
Репутация: 4
Статус: Offline
sad не увидел, что CONTROLINTERVALSIZE задан
Не для случая IMS...
Я бы его совсем убрал, пусть VSAM сам примет решение о его размере, так как файл не индексированный, могу предположить, что  доступ будет не по ключу.
Следовательно для лучшего чтения - больший CI лучше.
А за счет оптимального размера и память дисковую можно сэкономить (для вашего случая CISIZE будет 18432) почти 100% утилизация дорожки
А как IMS-у лучше - это у IMS-а надо спросить tongue
 
ggvДата: Пятница, 11.03.2016, 15:00 | Сообщение # 6
Лейтенант
Группа: Доверенные
Сообщений: 54
Репутация: 2
Статус: Offline
Для IMS в DBDGEN задаётся именно что Control Interval, это мы изменить не можем, потом после генерации DBDGEN мы получаем в sysout рекомендуемые параметры DEFINE CLUSTER, но да ладно, не в этом суть  - мы должны указать CI size, должны знать его.
Для рандомного доступа слишком большой CI нам тоже не очень нужно, много лишнего будет прочитываться при доступе по отдельным случайным записям.
Тут можно только одним способом повысить утилизацию - увеличить размер CI в некотором допустимом пределе, и писать в него не одну, а больше записей IMS, они тогда по рутовым сегментам в цепочку выстрятся.
Теряем на чём - при операции I/O читаем лишние (не нужные нам) записи, ну, не знаю, можно на это не обращать внимание, не думаю, что это критично, и немного теряем уже на проходе по цепочке рутовых сегментов до нужного сегмента, но это не операции ввода/вывода, это уже инструкции процессорные, совсем другой уровень.
Можно, в принципе, попробовать - терять 50% пространства никто не разрешит.
 
ggvДата: Пятница, 11.03.2016, 21:51 | Сообщение # 7
Лейтенант
Группа: Доверенные
Сообщений: 54
Репутация: 2
Статус: Offline
Мда, компромис между утилизацией и производительностью.
Выбирай, но осторожно, вот жешь.
Но можно будет поиграть параметрами и посмотреть, даже интересно будет сравнить, пока тестируем, есть возможность.
 
ggvДата: Суббота, 12.03.2016, 18:31 | Сообщение # 8
Лейтенант
Группа: Доверенные
Сообщений: 54
Репутация: 2
Статус: Offline
Посмотрел на тетирование IMS V13,где был достигнут рекорд.
Там IBM поступилро двояко - основная база, счетов банковских карт, имеет CI 2048, и по 12 записей IMS в CI
А другие две базы, заблокированных карт и ещё какая-то, так там CI по 512 байт, и тоже по нескольку записей в CI, по шесть, что ли.
То есть с базой акаунтов увеличило размер CI,а с остальными оставили с неэфективным CI, но там и размеры несопоставимы - база аккаунтов 4400 цилиндров, а остальные две 84 и 60 цилиндра, так что плюнули на такую мелкую потерю пространства.
Ну, вот, в принципе, и алгоритм действий - пример, как действовать.
 
Форум » Технические форумы » MVS (OS/390, zOS) » IDCAMS (Вопрос по распределению памяти при создании кластера)
Страница 1 из 11
Поиск: