New z14 mainfraime family.

[mskmel]

Давайте будем уважать друг друга. Если Вы пишите мэйнфрэймщику что "нормальную производительность дискового массива на МФ не получить без извращений" то Вы обязаны дать аргументированные объяснения. Где они?

Я просто не вижу повода для печали.

Давайте будем уважать друг друга. Если мы говорим об аргументации производительности массива не доступного на МФ, то не надо переходить на хакеров, доступность, "нам хватает и меньше" и "другие и без этого живут".
Да живут, да дирижируют джобами, да создают реплики, да допускают извращения по 30 2х портовых FC HBA (популярно было одно время) не достигая и 1/4 того что уже дал прогресс.

[zVlad]

... что уже дал прогресс.

Мы с нетерпением ждем рассказа про прогресс. На чем и как он достигнут.

[mskmel]

Мы с нетерпением ждем рассказа про прогресс. На чем и как он достигнут.

Ключевые слова Infiniband, NVMe, Linux
Вот один из примеров реализации https://www.flashgrid.io , в примере выше не это решение

[iDesperado]

Наши четыре кабеля в самый пик работы пользователя загружены не более чем на 10%. Их четыре для избыточности, а избыточность для отказоустойчивости. Чтение с дисков данных из базы данных во многих случаях идет асинхронно с выполнением запросов, всякие там разные prefetch существуют, считанные данные сохраняются в буферных пулах и в кэше дисковой системы. Мораль проста - живут как то люди и без 150GB/SEC.
Только не думайте пожалуйста что я не допускаю таких скоростей на МФ. Я просто не вижу повода для печали.

мы все когда-то жили на устаревшей технике и примитивных модемах, но теперь с таким отстоем живете только вы в мире МФ. и не надо вашу систему воспринимать как нечто серьезное, у вас все буферные кеши вместе взятые 3.3Gb, попадание в 87%, откуда там нагрузка на ио может взяться ? взгляните на современный мир, в мобильном телефоне samsung s8 сейчас 4Gb, у вас буферный кеш 3.3Gb.

[zVlad]

..... у вас все буферные кеши вместе взятые 3.3Gb, попадание в 87%, откуда там нагрузка на ио может взяться ? взгляните на современный мир, в мобильном телефоне samsung s8 сейчас 4Gb, у вас буферный кеш 3.3Gb.

Ты уже второй раз в этой теме приводишь какие-то числа безотносительно того что обсуждается. Придется удовлетворить твое упорство.
Во-первых, не кеши, а пулы. Это называется в DB2 Buffer Pool, и я тебе уже несколько раз говорил об этом.
Тот, один из буферных пулов (BP1 по видимому), про который ты говоришь, стал с тех пор несколько больше. А вообще можешь сам посчитать каков суммарный размер всех наших BP:

Code: Select all

+ Pool     VP       Pages    Pages    Getp       Read       Prefetch   Write
+ ID       Size     Alloc    In Use   Rate       I/O Rate   Req Rate   I/O Rate
+ ------   ------   ------   ------   --------   --------   --------   --------
+ BP0       25000    25000     1355     438.00        .00       1.33        .00
+ BP1      900000   900000     6474   13751.66      70.00      52.66        .00
+ BP2      800000   800000    13391   42536.66     232.66     541.00        .00
+ BP3        5000     5000        2      53.00        .00       3.00        .00
+ BP4       12000    12000        2    1395.00        .00      11.33        .00
+ BP5        9500     9500      278     178.66        .00        .33        .00
+ BP6      405000   405000     1268      42.33        .00        .00        .00
+ BP7      100000   100000    48240    2127.66        .00        .00        .00
+ BP10     150000   150000      285     107.33        .00       3.33        .00
+ BP11     600000   600000      624     844.66        .00      80.33        .00
+ BP13     300000   300000       21   16108.66        .00    2947.66        .00
+ BP14       1500     1500       11        .00        .00        .00        .00
+ BP32K     10000    10000       87      23.00        .33       3.00        .00
+ BP32K7    50000    50000    28922      19.33        .00        .00        .00
+ BP8K0     20000    20000        1     260.33       1.33       5.00        .00
+ BP16K0      500      500        0      71.00        .00        .66        .00

I/O - это главный киллер response time. Во всех применениях БД для OLTP (строго говоря, и это видимоо ввело некоторых в заблуждение, наше ERP приложение не чисто OLTP, который имеет дело с очень короткими транзакциями согласно теории. У нас весьма широкий спектр транзакций используется, есьть и такие что их можно смело отнести к OLAP) делаются попытки как можно больше данных поместить в память и мксимально сократить I/O. Мы не исключение.

Буфферные пулы, которые ты видишь выше, специальным образом формировались и настраивались, в большенстве их сидит по одной таблице (hit ratio в них 99% как правило, поскольку все данные находятся в пуле), в каких то по нескольку, а в BP1 все остальные таблицы (hit ratio здесь самый низкий 70-80%%) и в BP2 все индексы. Конечно все данные из БД мы в память загнать не можем - у нас всего в продакшн 24 GB RAM поэтому без ввода-вывода не обойтесь, но он сведен, намеренно, к минимуму. Я ни разу не видел чтобы наши каналы ввода-вывода были загружены больше чем на 10%. И в тоже время CPU в пиковые часы трогает планку в 100%, вот, специально для тебя - ты видно любишь анализировать данные мониторинга с МФ - позавчерашний сумарный отчет по CPU:

Code: Select all

                                               R M F   S U M M A R Y   R E P O R T

            z/OS  V1R13              SYSTEM ID ****             START 09/27/2017-07.00.00  INTERVAL 00.29.59
                                     RPT VERSION V1R13 RMF      END   09/27/2017-16.00.00  CYCLE 6.000 SECONDS

NUMBER OF INTERVALS 18            TOTAL LENGTH OF INTERVALS 08.59.50
DATE   TIME     INT   CPU   DASD  DASD   JOB   JOB   TSO   TSO   STC   STC  ASCH  ASCH  OMVS  OMVS SWAP DEMAND
MM/DD HH.MM.SS MM.SS  BUSY  RESP  RATE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE RATE PAGING
09/27 07.00.00 29.59  32.6   1.9 367.0     6     0     2     1   112   112     0     0     4     3 0.00  17.67
09/27 07.30.00 29.59  53.9   2.0 538.2     4     0     2     2   112   112     0     0     4     3 0.00   2.47
09/27 08.00.00 30.00  52.0   2.0 478.0     3     0     3     3   112   112     0     0     4     3 0.00   0.98
09/27 08.30.00 30.00  54.8   1.8 658.4     3     0     8     5   112   112     0     0     4     3 0.00   0.89
09/27 09.00.00 29.59  57.7   1.7 667.2     4     0     8     8   112   112     0     0     4     3 0.00   5.70
09/27 09.30.00 30.00  77.8   1.9 590.9     7     1    10     8   113   111     0     0     5     3 0.00   0.39
09/27 10.00.00 29.59  70.8   2.1 656.0     7     1    10     9   113   112     0     0     5     3 0.00   0.20
09/27 10.30.00 30.00  66.5   1.8 788.5     5     0    10     9   113   112     0     0     4     3 0.00  25.55
09/27 11.00.00 29.59  64.4   2.0 635.1     4     0    10     8   112   112     0     0     5     3 0.00   6.45
09/27 11.30.00 29.59  50.2   2.0 569.6     4     0    10     8   112   112     0     0     4     3 0.00   3.92
09/27 12.00.00 30.00  36.9   2.3 404.1     4     0    10     7   112   112     0     0     5     3 0.00   2.77
09/27 12.30.00 29.59  43.7   2.4 453.4     4     0     7     6   112   112     0     0     4     3 0.00   1.40
09/27 13.00.00 29.59  56.6   2.2 528.8     4     0     9     8   112   112     0     0     4     3 0.00   1.93
09/27 13.30.00 29.59  67.9   2.1 671.6     5     1    11     9   112   111     0     0     4     3 0.00   0.37
09/27 14.00.00 29.59  59.2   2.6 576.5     5     0    12     9   112   112     0     0     5     3 0.00  10.68
09/27 14.30.00 30.00  53.9   1.9 550.7     3     0     6     5   112   112     0     0     5     3 0.00   0.85
09/27 15.00.00 30.00  52.7   2.3 496.4     2     0     9     7   112   112     0     0     4     3 0.00   1.58
09/27 15.30.00 30.00  33.2   3.4 426.2     3     0    11     9   113   112     0     0     4     3 0.00   0.38
TOTAL/AVERAGE         54.7   2.1 558.7     7     0    12     7   113   112     0     0     5     3 0.00   4.68

[Dmitry67]

I/O - это главный киллер response time. Во всех применениях БД для OLTP (строго говоря, и это видимоо ввело некоторых в заблуждение, наше ERP приложение не чисто OLTP, который имеет дело с очень короткими транзакциями согласно теории. У нас весьма широкий спектр транзакций используется, есьть и такие что их можно смело отнести к OLAP) делаются попытки как можно больше данных поместить в память и мксимально сократить I/O. Мы не исключение.

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

[zVlad]

I/O - это главный киллер response time. Во всех применениях БД для OLTP (строго говоря, и это видимоо ввело некоторых в заблуждение, наше ERP приложение не чисто OLTP, который имеет дело с очень короткими транзакциями согласно теории. У нас весьма широкий спектр транзакций используется, есьть и такие что их можно смело отнести к OLAP) делаются попытки как можно больше данных поместить в память и мксимально сократить I/O. Мы не исключение.

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

Дима, какие проблемы? Нет у меня никаких проблем. SLA выполняется строго, пользователь доволен. Зачем мне терабайт памяти?

[zVlad]

...

Возьмем 1ТБ таблицу для экспериментов.

Code: Select all

SQL>select sum(bytes)/1024/1024 from dba_segments where owner='XX' and segment_name='YYYY';
        GB
----------
1115.62714

И прочитаем весь 1ТБ.

Code: Select all

SQL>select /*+ full(a) parallel(a,64) */ count(*) from XX.YYYY a;
  COUNT(*)
----------
5,XXX,XXX,XXX

Elapsed: 00:00:07.46
...
146025908  physical reads
...
--149GBs
--19,574,518 reads\sec

А можно Вас попросить прогнать другой запрос? Не с count(*) v SELECT, а что нибудь чтобы обрабатывались данные в строкax, например, сложение числовых данных, или сложение по столбцам, ну или еще чего-нибудь такое на Ваше усмотрение. Вы меня поняли конечно.
Спасибо.

[mskmel]

А можно Вас попросить прогнать другой запрос? Не с count(*) v SELECT, а что нибудь чтобы обрабатывались данные в строкax

В общем то и не ожидалось, что простые мат операции над данными - будут медленнее чтения этих данных с диска.

Code: Select all

SQL>select /*+ full(a) parallel(a,64) */ sum(F1-F2) as ddd from YYYY a ;

DDD
-------------------------
               8.12345E+17

1 row selected.

Elapsed: 00:00:07.96

[zVlad]

А можно Вас попросить прогнать другой запрос? Не с count(*) v SELECT, а что нибудь чтобы обрабатывались данные в строкax

В общем то и не ожидалось, что простые мат операции над данными - будут медленнее чтения этих данных с диска.

Code: Select all

SQL>select /*+ full(a) parallel(a,64) */ sum(F1-F2) as ddd from YYYY a ;

DDD
-------------------------
               8.12345E+17

1 row selected.

Elapsed: 00:00:07.96

Небольшой рост времени (совсем небольшой) просматривается. Я правильно понимаю что на Вашем сервере нет больше никаких других работ?

Ну, и почему ж Вы упорно не делитесь конфигурацией Вашего сервера? Что в этом страшного может быть? Тут все свои, все понимают.

Подтвердите (или опровергните) что Вы имеете локальные диски, да еще поди SSD да еще поди с кэшем. Infiniband Вы сами называли, но это локальный интерфэйс, а в реальной жизни что на МФ что на серверах других архитектур широко используют все таки SAN-ы, NAS-ы там разные и у них нет таких скоростных каналов как Infiniband. Это внешнее подключение дисков.

Для Вашего сведения, ни для чего больше, официально задокументированная сумарная пропускная способность ввода-вывода z13 составляет 832 GBs. Там еще звездочка стоит и в сноске написано: No server can fully exploit its maximum I/O bandwidth.

Такиe вот дела. Спасибо еще раз. Надеюсь мы закончили меряться и можем перейти к обсуждению более интересных вопросов. Например CPL, command ring's, GP.

[mskmel]

Подтвердите (или опровергните) что Вы имеете локальные диски, да еще поди SSD да еще поди с кэшем.

Диски не локальные, они могут быть доступны нескольким серверам.

Infiniband Вы сами называли, но это локальный интерфэйс, а в реальной жизни что на МФ что на серверах других архитектур широко используют все таки SAN-ы, NAS-ы там разные и у них нет таких скоростных каналов как Infiniband.

"Наши на луну высадились!"
2005ый год, IBM подключает диски для DB2 через IB switches http://www.tpc.org/tpch/results/tpch_re ... =105051901

Надеюсь мы закончили меряться и можем перейти к обсуждению более интересных вопросов. Например CPL, command ring's, GP.

OK

[iDesperado]

Ты уже второй раз в этой теме приводишь какие-то числа безотносительно того что обсуждается. Придется удовлетворить твое упорство.
Во-первых, не кеши, а пулы. Это называется в DB2 Buffer Pool, и я тебе уже несколько раз говорил об этом.
Тот, один из буферных пулов (BP1 по видимому), про который ты говоришь, стал с тех пор несколько больше.

во первых Buffer Pool это название конкретного кеша. во вторых я говорил именно о сумме всех Buffer Pools из этого поста viewtopic.php?p=5993902#p5993902
еще не давно у вас вся "ERP" умещалась в 3.3Gb кеша, теперь подросло до 12Gb, все равно меньше моего ноутбука. если база действительно размером с 1ТБ, это просто архивные данные, в которые никто никогда не заглядывает. на моем лаптопе с 16Gb RAM и я не вижу абсолютно никаких препятствий гонять такую ерп на лаптопе с которого пишу.

Code: Select all

                                               R M F   S U M M A R Y   R E P O R T

            z/OS  V1R13              SYSTEM ID ****             START 09/27/2017-07.00.00  INTERVAL 00.29.59
                                     RPT VERSION V1R13 RMF      END   09/27/2017-16.00.00  CYCLE 6.000 SECONDS

NUMBER OF INTERVALS 18            TOTAL LENGTH OF INTERVALS 08.59.50
DATE   TIME     INT   CPU   DASD  DASD   JOB   JOB   TSO   TSO   STC   STC  ASCH  ASCH  OMVS  OMVS SWAP DEMAND
MM/DD HH.MM.SS MM.SS  BUSY  RESP  RATE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE   MAX   AVE RATE PAGING
09/27 07.00.00 29.59  32.6   1.9 367.0     6     0     2     1   112   112     0     0     4     3 0.00  17.67
09/27 07.30.00 29.59  53.9   2.0 538.2     4     0     2     2   112   112     0     0     4     3 0.00   2.47
09/27 08.00.00 30.00  52.0   2.0 478.0     3     0     3     3   112   112     0     0     4     3 0.00   0.98
09/27 08.30.00 30.00  54.8   1.8 658.4     3     0     8     5   112   112     0     0     4     3 0.00   0.89
09/27 09.00.00 29.59  57.7   1.7 667.2     4     0     8     8   112   112     0     0     4     3 0.00   5.70
09/27 09.30.00 30.00  77.8   1.9 590.9     7     1    10     8   113   111     0     0     5     3 0.00   0.39
09/27 10.00.00 29.59  70.8   2.1 656.0     7     1    10     9   113   112     0     0     5     3 0.00   0.20
09/27 10.30.00 30.00  66.5   1.8 788.5     5     0    10     9   113   112     0     0     4     3 0.00  25.55
09/27 11.00.00 29.59  64.4   2.0 635.1     4     0    10     8   112   112     0     0     5     3 0.00   6.45
09/27 11.30.00 29.59  50.2   2.0 569.6     4     0    10     8   112   112     0     0     4     3 0.00   3.92
09/27 12.00.00 30.00  36.9   2.3 404.1     4     0    10     7   112   112     0     0     5     3 0.00   2.77
09/27 12.30.00 29.59  43.7   2.4 453.4     4     0     7     6   112   112     0     0     4     3 0.00   1.40
09/27 13.00.00 29.59  56.6   2.2 528.8     4     0     9     8   112   112     0     0     4     3 0.00   1.93
09/27 13.30.00 29.59  67.9   2.1 671.6     5     1    11     9   112   111     0     0     4     3 0.00   0.37
09/27 14.00.00 29.59  59.2   2.6 576.5     5     0    12     9   112   112     0     0     5     3 0.00  10.68
09/27 14.30.00 30.00  53.9   1.9 550.7     3     0     6     5   112   112     0     0     5     3 0.00   0.85
09/27 15.00.00 30.00  52.7   2.3 496.4     2     0     9     7   112   112     0     0     4     3 0.00   1.58
09/27 15.30.00 30.00  33.2   3.4 426.2     3     0    11     9   113   112     0     0     4     3 0.00   0.38
TOTAL/AVERAGE         54.7   2.1 558.7     7     0    12     7   113   112     0     0     5     3 0.00   4.68

DASD RATE The activity per second for all direct access storage devices included in the report. The value reported corresponds to an accumulation of each DEVICE ACTIVITY RATE field in the Direct Access Device Activity report.

https://www.ibm.com/support/knowledgece ... 500513.htm

как я понимаю это IOPs на весь майнфрейм, в пике 788.5 IOPs. мой SSD диск в лаптопе способен давать тысячи IOPs, т.е. ио система лаптопа справиться с задачей, памяти 16Gb в лаптопе хватает на эту задачу, 12Gb под кеш выделить можно легко. в лаптопе 4 ядра i5, тоже с головой хватит. ваша "ERP" лупит миллионами DML по данным лежащим в 12Gb Buffer Pool, до ио доходит лишь пара сотен IOPs. такая "ERP" игрушка даже для моего лаптопа, на моем десктопе 32Gb, на нем вообще такую "ERP" inmemory можно гонять.

[zVlad]

.....

Infiniband Вы сами называли, но это локальный интерфэйс, а в реальной жизни что на МФ что на серверах других архитектур широко используют все таки SAN-ы, NAS-ы там разные и у них нет таких скоростных каналов как Infiniband.

"Наши на луну высадились!"
2005ый год, IBM подключает диски для DB2 через IB switches http://www.tpc.org/tpch/results/tpch_re ... =105051901

Вы все таки продолжаете меряться, неуклюже правда как то, из Вашего линка:

System Configuration:

x346 servers, each server with:
Processor: 1 x 3.6GHz Intel Xeon with 2MB cache
on 1 processor, 1 core, 2 threads
Memory: Eight (8) 512MB PC-3200 ECC SDRAM RDIMMs
Cluster Interconnect: One Voltaire HCA400 Dual-Port InfiniBand Host Channel Adapter
Disk Controllers: One ServeRAID-7k Ultra320 SCSI controller
Disk Drives: Total Disk Storage:
Six (6) 73.4GB 15K Ultra 320 SCSI disk drives 26,249 GB

[flip_flop]

Infiniband Вы сами называли, но это локальный интерфэйс

Не вступая в дискуссию.

Когда я начал интересоваться Infiniband, лет 15 назад, мне казалось что он с самого начала позиционировался как сетевой интерфейс, в то время он был типа PCIe over network. Среднее расстояние по меди и дальнее по оптоволокну. Он мог применяться и локально, внутри компьютера, но его главное назначение было с самого начала именно сетевое. Сейчас внутри компьютера не применяется. Широко применялся и применяется в суперкомпьютерах между кластерами. Как здесь показано, для сетевых баз данных тоже.

Влад, откуда мнение о локальности? Оно ошибочно.

[zVlad]

Ты уже второй раз в этой теме приводишь какие-то числа безотносительно того что обсуждается. Придется удовлетворить твое упорство.
Во-первых, не кеши, а пулы. Это называется в DB2 Buffer Pool, и я тебе уже несколько раз говорил об этом.
Тот, один из буферных пулов (BP1 по видимому), про который ты говоришь, стал с тех пор несколько больше.

во первых Buffer Pool это название конкретного кеша. во вторых я говорил именно о сумме всех Buffer Pools из этого поста viewtopic.php?p=5993902#p5993902
еще не давно у вас вся "ERP" умещалась в 3.3Gb кеша, теперь подросло до 12Gb, все равно меньше моего ноутбука. если база действительно размером с 1ТБ, это просто архивные данные, в которые никто никогда не заглядывает. на моем лаптопе с 16Gb RAM и я не вижу абсолютно никаких препятствий гонять такую ерп на лаптопе с которого пишу.
....

Хочешь я тебе дам телефон нашего CIO и ты ему продашь идею гонять наше ERP приложение на твоем лаптопе? Какой ты мне процент дашь?

Да, ты прав, три года назад было 3.3 GB, тогда еще был z114 и в Prod был RAM 12 GB, уже в 2015 мы получили zBC12 и в Prod стало 24 GB и буферные пулы были увеличены, а как только наша DB2 DBA ушла в прошлом году на пенсию я еще их увеличил.

Что ж ты, уважаемый iDesperado, думаешь мы на месте стоим? Время идет, все меняется. Если бы ты прежде чем использовать данныe трех летней давности, уточнил у меня то мы бы не тратили зря время. Я и сам то уже позабыл о том что было три года назад и число 3.3 GB меня удивило, врет думаю как всегда , один буферный пул только озвучивает, наверное. Ан нет оказалось, точно говорит, но не о сейчас.

Tем не менее молодец ты, iDesperado, умеешь работать с материалом, хвалю. Молодежь, учитесь.