Вопросы истории ИТ и ОС

[iDesperado]

сколько проигрывает МФ на конкретных тестах можно посмотреть в тестах peoplesoft, которые проводит оракл совместно с IBM. вот тут я разбирал идентичную нагрузку на МФ и писюк
viewtopic.php?p=5499327#p5499327" onclick="window.open(this.href);return false;

за счет большей памяти писюк в двое больше транзакций обработал.

[Dmitry67]

32 GB Карл... (бьется в истерике)

[Easbayguy]

32 GB Карл... (бьется в истерике)

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

[mskmel]

писюк
viewtopic.php?p=5499327#p5499327" onclick="window.open(this.href);return false;

Это совсем не писюк, а вполне так "популярная" по своим временам (~2002) железка. Популярная в смысле их массово мигрировали любители HPUX на Itanium, другие на pSeries\Sun .
Там 8x875MHz PA-RISC ~= 2x3200MHz Intel Xeon DP

Я не думаю что бенчмарки 10ти+ летней давности могут говорить о текущей ситуации. Что у МФ несколько поколений прошло, что у остальных...

ЗЫЖ оказывается тут эти споры уже не прервый год идут

[zVlad]

32 GB Карл... (бьется в истерике)

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

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

Добавление 4GB к имевшимся 12 GB в нашей Production вылилось в уменьшее среднего времени транзаксий в несколько милисекунд. Те 4 GB у нас были неиспользуемыми, но они должны были быть на случай DR. Изучив возможность динамически увеличивать и уменьшать память в LPAR, и сконфигурировав все правильно, мы смогли подключить эти 4GB к Production, оставив возможность их забрать в случае необходимость без остановки Production. Чем мы и воспользовались в прошлое воскресение когда после изменения мироринг нужно было сделать то что мы называем mini-DR test. Т.е. убедиться что с мирора системы (3 штуки) будут грузиться в случае DR. Память для отого была освобождена в Production динамически, и использована для mini-DR test и.... нет, не возвращена, забылось, один GB все еще не возвращен (это ответ двух DISPLAY command MVS):
Движок справа для прокрутки не забудьте

Code: Select all

 IEE174I 09.10.44 DISPLAY M 710
 REAL STORAGE ELEMENT STATUS
 0: OWNED STORAGE=12288M UNASSIGNED STORAGE=0M STATUS=ONLINE
 1: OWNED STORAGE=4096M UNASSIGNED STORAGE=1024MB STATUS=ONLINE
.....
IEE174I 09.05.47 DISPLAY M 536
REAL STORAGE STATUS
ONLINE-NOT RECONFIGURABLE
    0M-12288M
ONLINE-RECONFIGURABLE
    12288M-14976M
    16000M-16384M
PENDING OFFLINE
    NONE
 0M IN OFFLINE STORAGE ELEMENT(S)
 1024M UNASSIGNED STORAGE
STORAGE INCREMENT SIZE IS 128M

Это Продуцтион и я делаю этот 1 GB доступным динамически с помощью комманды CONFIG:

Code: Select all

CF STOR(1024M),ONLINE
IEE524I REAL STORAGE LOCATIONS 14976M TO 16000M ONLINE
IEE712I CONFIG   PROCESSING COMPLETE

Теперь мы имеем, на Production:
Движок справа для прокрутки не забудьте

Code: Select all

IEE174I 09.15.28 DISPLAY M 046
REAL STORAGE ELEMENT STATUS
0: OWNED STORAGE=12288M UNASSIGNED STORAGE=0M STATUS=ONLINE
1: OWNED STORAGE=4096M UNASSIGNED STORAGE=0M STATUS=ONLINE
.....
D M=STOR
...
IEE174I 09.15.33 DISPLAY M 053
REAL STORAGE STATUS
ONLINE-NOT RECONFIGURABLE
    0M-12288M
ONLINE-RECONFIGURABLE
    12288M-16384M
    PENDING OFFLINE
    NONE
 0M IN OFFLINE STORAGE ELEMENT(S)
 0M UNASSIGNED STORAGE
STORAGE INCREMENT SIZE IS 128M

Все сделано на ваших глазах, на реально Production системе.

[zVlad]

....
ЗЫЖ оказывается тут эти споры уже не прервый год идут

Не первый год это мягко сказано. Много лет уже.

[iDesperado]

Это совсем не писюк, а вполне так "популярная" по своим временам (~2002) железка. Популярная в смысле их массово мигрировали любители HPUX на Itanium, другие на pSeries\Sun .

меня в школе учили все, что не МФ то писюк (personal computer). на сколько я знаю с тех пор терминология не менялась.
update: наверно personal не верно, всякие PDP и VAX наверно mini computer назывались

[Easbayguy]

Добавление 4GB к имевшимся 12 GB в нашей Production вылилось в уменьшее среднего времени транзаксий в несколько милисекунд. Те 4 GB у нас были неиспользуемыми, но они должны были быть на случай DR. Изучив возможность динамически увеличивать и уменьшать память в LPAR, и сконфигурировав все правильно, мы смогли подключить эти 4GB к Production, оставив возможность их забрать в случае необходимость без остановки Production.

Звучит как детский сад с 4ГБ и "уменьшение времени транзакций" , нормально бы было сказать что добавление 4ГБ памяти привело к снижению Physical reads, например вот легкая нагрузка на базе:

Было:
Buffer Hit %: 95.92

Load Profile Per Second Per Transaction
~~~~~~~~~~~~ ------------------ ---------------------

Logical reads: 325,190.8 358.4
Block changes: 8,341.4 9.2
Physical reads: 13,310.5 14.7
Physical writes: 296.6 0.3


Стало:
Buffer Hit %: 97.12

Load Profile Per Second Per Transaction
~~~~~~~~~~~~ ------------------ ---------------------
Logical reads: 469,656.1 295.7
Block changes: 14,609.7 9.2
Physical reads: 13,538.5 8.5
Physical writes: 502.9 0.3

[flip_flop]

Это совсем не писюк, а вполне так "популярная" по своим временам (~2002) железка. Популярная в смысле их массово мигрировали любители HPUX на Itanium, другие на pSeries\Sun .

меня в школе учили все, что не МФ то писюк (personal computer). на сколько я знаю с тех пор терминология не менялась.
update: наверно personal не верно, всякие PDP и VAX наверно mini computer назывались

Кроме PDP & VAX были и есть всякие RISC/SPARC/POWER серверы, были но сплыли им подобные Itanium и сейчас доминируют XEON based servers. Последние, хотя и основаны на х86, выравниваются по степени RAS с МФ ( по memory и по IO/Network card превосходят МФ, хотя фаны МФ и отвергают очевидное, хе-хе ). Неправильные учителя у Вас были в школе.

[zVlad]

....
Звучит как детский сад с 4ГБ и "уменьшение времени транзакций" , нормально бы было сказать что добавление 4ГБ памяти привело к снижению Physical reads, .............

Так можно было бы сказать если бы мы имели некий повторяемый тест и прогнали бы его до и после. А в данном случае, и об этом было сообщено, это Production система в которой каждый раз выполняется уникальный набор транзакций, а в таких условиях единствено на чем можно обнаружить влияние изменения того или иного ресурса будет "среднее время транзакции". Да и то на него надо смотреть в продолжительном отрезке времени, а не типа "вчера было так, а сегодня так".

Земляк, не засоряй свою речь не нужными восклицаниями. Думай прежде чем ляпать что в голову приходит.

P.S. Мониторинг на вашей БД слабый (детский сад). Вот что дает DB2 for zOS для каждого buffer pool (в данном случае BP1):

Code: Select all

>                            BUFFER POOL DETAIL

 BP    1
+ Collection Interval:  REALTIME                         Start:  11/04 13:24:38
+ Report Interval:       4 sec                             End:  11/04 13:24:42
+
+ Virtual Buffer Pool Size=    750000
+ VPOOL Buffers Allocated =    750000
+ VPOOL Buffers in Use    =      2777
+ VPOOL Buffers to be Del =         0    Auto Size                   =       N
+ Use Count               =      2548    Page Fix                    =       N
+ VP Sequential Thresh    =       80%
+ Deferred Write Thresh   =       30%    Vert Deferred Write Thresh  =      5%
+ VP Parallel Seq Thresh  =       50%    Sysplex Parallel Thresh     =      0%
+
+ Getpages per Sync I/O   =     24.71    Pages Written per Write I/O =    5.79
+ Prefetch per I/O        =     74.75    Pages Read per Prefetch     =     .58
+ Seq Prefetch per I/O    =      1.42    Pages Read per Seq Prefetch =   73.65
+ List Prefetch per I/O   =      3.29    Pages Read per List Prefetch=     .60
+ Dyn Prefetch per I/O    =    163.85    Pages Read per Dyn Prefetch =     .14
+ Max Concur Prefetch     =         5    Workfile Maximum            =       0
+ BP Hit % - Random       =     93.3%    Virtual Page Steal Method   =     LRU
+ BP Hit % - Sequential   =     82.7%
+
+                                    TOTAL  INTERVAL  /SECOND  /THREAD  /COMMIT
+                                 QUANTITY  QUANTITY  (    4)  (   52)  (   49)
+                                 --------  --------  -------  -------  -------
+ Getpage Requests                6403589K    412640  103.16K  7935.38  8421.22
+ Getpage Requests - Sequential   2532077K    188724   47.18K  3629.30  3851.51
+ Getpage Requests - Random       3871512K    223916   55.98K  4306.07  4569.71
+ Getpage Failed - VPOOL Full            0         0      .00      .00      .00
+ Getpage Failed - Cond Request          0         0      .00      .00      .00
+ Getpage Failed - Cond SeqReq           0         0      .00      .00      .00
+
+ Sync Read I/O Operations         259182K        66    16.50     1.26     1.34
+ Sync Read I/Os - Sequential        77861         1      .25      .01      .02
+ Sync Read I/Os - Random          259104K        65    16.25     1.25     1.32
+ Page-in Required for Read I/O     769287         0      .00      .00      .00
+ Pages Read via Seq Prefetch      325082K       197    49.25     3.78     4.02
+ Seq Prefetch I/O Operations      3106309        10     2.50      .19      .20
+ Sequential Prefetch Requests     4413636      1732   433.00    33.30    35.34
+ Pages Read via List Prefetch     4744418         8     2.00      .15      .16
+ List Prefetch I/O Operations     2390022         3      .75      .05      .06
+ List Prefetch Requests           7858667        95    23.75     1.82     1.93
+ Pages Read via Dyn Prefetch      105835K        32     8.00      .61      .65
+ Dyn Prefetch I/O Operations      4472903         1      .25      .01      .02
+ Dyn Prefetch Requests            732890K     21896  5474.00   421.07   446.85
+ Prefetch Failed - No Buffer            0         0      .00      .00      .00
+ Prefetch Failed - No Engine            0         0      .00      .00      .00
+
+ Parallel Group Requests               15         0      .00      .00      .00
+ Prefetch I/O Streams Reduced           0         0      .00      .00      .00
+ Parallelism Downgraded                 0         0      .00      .00      .00
+ Prefetch Quan Reduced to 1/2           0         0      .00      .00      .00
+ Prefetch Quan Reduced to 1/4           0         0      .00      .00      .00
+
+ Pages Updated                   45725188        40    10.00      .76      .81
+ Pages Written                    9760739         0      .00      .00      .00
+ Page-in Required for Write I/O     73301         0      .00      .00      .00
+ Write I/O Operations             1586029         0      .00      .00      .00
+ Immediate (Sync) Writes            99639         0      .00      .00      .00
+
+ Vert Defer Wrt Thresh Reached        690         0      .00      .00      .00
+ Deferred Write Thresh Reached        269         0      .00      .00      .00
+ Data Manager Thresh Reached            0         0      .00      .00      .00
+
+ Successful VPOOL Expand/Contr          0         0      .00      .00      .00
+ VPOOL or HPOOL Expand Failed           0         0      .00      .00      .00
+
+ Successful Dataset Opens            2572         0      .00      .00      .00
+ DFHSM Recall                           0         0      .00      .00      .00
+ DFHSM Recall Timeouts                  0         0      .00      .00      .00
+
+ Sort Merge Passes                      0         0      .00      .00      .00
+ Sort/Merge Workfile Requests           0         0      .00      .00      .00
+ Sort/Merge Workfile Req Denied         0         0      .00      .00      .00
+ Sort Merge Pass - Buff Short           0         0      .00      .00      .00
+ Workfile Prefetch Disabled             0         0      .00      .00      .00
+ Workfile Create Failed-No Buff         0         0      .00      .00      .00
+ Destructive Read Requests              0         0      .00      .00      .00
+ Destructive Read Page Dequeue          0         0      .00      .00      .00

[Dmitry67]

Именно поэтому есть tpc тесты
)))

[iDesperado]

Кроме PDP & VAX были и есть всякие RISC/SPARC/POWER серверы, были но сплыли им подобные Itanium и сейчас доминируют XEON based servers.

спасибо кэп !

2Влад
Virtual Buffer Pool Size= 750000 ~3Gb в которые уместилось "BP Hit % - Random = 93.3%".
на компе нашей секретарши все активные данные вашей задачи уместились бы в памяти. 49 commit за 4 секунды тоже намекают на то, что задача совершенно не серьезная

P.S. кому интересно уже пережевывали таблички от Влада viewtopic.php?p=5993928#p5993928" onclick="window.open(this.href);return false;

[Easbayguy]

на самом деле нагрузка больших рабочих систем всегда предсказуема и повторяется. Banks/etrade/amazon/ и так далее.
Исключение это DWH с большим количеством ad-hoc. Ну или банально системой практически не пользуются, с небольшим количеством пользователей.

[Easbayguy]

Кроме PDP & VAX были и есть всякие RISC/SPARC/POWER серверы, были но сплыли им подобные Itanium и сейчас доминируют XEON based servers.

спасибо кэп !

2Влад
Virtual Buffer Pool Size= 750000 ~3Gb в которые уместилось "BP Hit % - Random = 93.3%".
на компе нашей секретарши все активные данные вашей задачи уместились бы в памяти. 49 commit за 4 секунды тоже намекают на то, что задача совершенно не серьезная

P.S. кому интересно уже пережевывали таблички от Влада viewtopic.php?p=5993928#p5993928" onclick="window.open(this.href);return false;

Влад нас тонко троллит с 49 коммитами в секунду и 4мб/сец по чтению. Молодец!

[zVlad]

Вы что ребята подумали что это единственный buffer pool у нашей DB2? Нет серьезно, ответьте.

[mskmel]

Вы что ребята подумали что это единственный buffer pool у нашей DB2? Нет серьезно, ответьте.

Даже у Оракла их не один, так что нет, не подумал.
Но по этим табличкам уже ведь ездили пару лет назад, эта песня хороша - начинай сначала?

ЗЫЖ статистика там не совсем детская, 127 параметров только по cache. То что выше это Load Profile from Report Summary.

[oshibka_residenta]

Влад нас тонко троллит с 49 коммитами в секунду и 4мб/сец по чтению. Молодец!

Зато IBM делает эти 49 коммитс с достоинством недоступным другим.

[zVlad]

Вы что ребята подумали что это единственный buffer pool у нашей DB2? Нет серьезно, ответьте.

Даже у Оракла их не один, так что нет, не подумал.
Но по этим табличкам уже ведь ездили пару лет назад, эта песня хороша - начинай сначала?

ЗЫЖ статистика там не совсем детская, 127 параметров только по cache. То что выше это Load Profile from Report Summary.

Спасибо за пояснения. Только вот я не говорил что у Оракла лишь один кэш. Количеством параметром я тоже не размахивал (мне даже в голову не пришло их считать), а просто привел принт скрин из Omegamon for DB2, а Вы ничего такого не привели просто сказали что их 127.

По табличкам, которые я привожу время от времани, никогда и никто всерьез не ездил. В том то и беда что от настоящих разборов данных с реальных продакшн систем публика здешняя шарахается как черт от ладана. И Вы тоже не исключение похоже. Поясню. Я в этой теме, в ответ на Ваши вопрошания предоставить материал для сравнения Мф с другими платформами, рассказал о том что несколько лет назад один из наших кастомеров ушел с МФ (одна штука) на IBM Power сервера (больше одной штуки) с AIX и Оракл. Уникальность того перехода состояла в том что софт как для МФ так и для Юникс/Оракл был написан одинаково буквально. Точнее он писался на Юникс/Оракл, и портировался на МФ (zOS/CICS/DB2). Иными словами мы имеем яблоки в обоих случаях. Объем данных тоже одинаков - это данные одного и того же кастомера. Стиль работы с системой одинаков. Все одинаково только платформы разные. это гораздо лучше чем любые искуственные тесты, согласитесь.

Повторять параметры МФ с которого уходили и параметры ИБМ Power я не стал их есть несколько в предыдущих темах. Подробных причем, с реальных документов, которые я сам читал (а МФ тот сам саппортал).

От Вас по поводу это не поступило ни звука. Вы поленились найти те данные? Вам помочь?

Что хочу здесь добавить, кастомер тот по первоначалу имел массу проблем с надежностью и с дизастер рековери. Первый набор AIX серверов не давал приемлемой производительности и через пару лет был заменен на гораздо более мощные сервера. Данные о них я тоже приводил здесь на форуме. Кастомер тот - атомная станция, для них цены на компьютеры не интересны вообще (хотя мотивом ухода с МФ было в том числе цена МФ, но не только). Затраты на одно обслуживание реактора больше многолетних затрат на их ИТ. Но вот что для них действительно важно так это надежность и доступность, а также DR. И вот этого всего они сразу лишились уйдя с МФ. Да и по деньгам ничего они не сэкономили, наоборот потратили кучу денег как на перевод так и на сервера (мы общаемся регулярно с ИБМ представителями и я помню их круглые глаза когда мы спрашивали ну и за сколько вы продали ваши Power этому кастомеру, ну и сколько они сэкономили по сравнению с МФ. Конечно я не могут привести чисел, эти числа не публикуют в газетах их держат в секрете, но то что в данном случае у меня есть из первых рук красноречивей чисел. Словами было сказано что кастомер в деньгах явно не ограничен).

Где Ваши комментарии или вопросы по этому примеру из жизни? Их нет и я почему знаю что их и не будет. Возможно Вы скажете что те сервера Power в исполнении дешевых х86 стоили бы $ххх ххх, или даже $хх ххх. Часто в жизни экономить не надо на самом деле. Вот я делаю кухню реновэйшн. купили дешевых смеситель за $129, поставили, вода конечно течет, но через пару дней я этот смеситель выбросил и купил другой за $359. Вот теперь это более менее смеситель. А есть и смесители за $1000 и боле. Как Вы думаете почему? А Вы какой смеситель имеете на кухне? Сколько он стоит?

[iDesperado]

От Вас по поводу это не поступило ни звука. Вы поленились найти те данные? Вам помочь?

вы никогда не давали данные, вы всю дорогу выдавали лишь свои, явно неадекватные, интерпретации. как только вы показываете аутпут команд, 16 процессорные махины усыхают до LPAR на половинку процессора, которые и нагрузить то у вас нечем. вот тут вас сбили с толку 32 cpu. страшно подумать, что вы в этой байке напутали.

[mskmel]

а Вы ничего такого не привели просто сказали что их 127.

NDA, не собираюсь с продакшенов публиковать в паблике статистику ради того чтобы просто померяться размером линейки.
Easbayguy выше приводил стастику с легконагруженных БД.
Logical reads это ваши Getpage Requests , blocks=pages. Такое часто тихо в виртуалке живёт.

Точнее он писался на Юникс/Оракл, и портировался на МФ (zOS/CICS/DB2). Иными словами мы имеем яблоки в обоих случаях.

Не совсем, задача переписывания с БД на БД чего-то более менее большого это задача не из тривиальных. Очень много что зависит от степени кривизны рук начальных писателей и последующих переписывателей. Я наблюдал решение почти одной и той же задачи ETL на Java и на Cobol. То что слепили на Java работало раз в 100 медленнее Cobol, Java медленее? Возможно, но не настолько. Уровень писателей был сильно разный, ребята на коболе заделиверили код, который у нас заработал сразу же. Читатели "Java для чайников" несколько месяцев баги правили, попутно тюнили и скулили, что тюнить это не к ним, их этому не учили.

это гораздо лучше чем любые искуственные тесты, согласитесь.

Для сравнения нужна одинаковая сравнимая нагрузка, её делает стандартизованный тест (SAP benchmark один из лучших). В нём великой разницы между Oracle\MSSQL\DB2 нет Linux\Windows тоже, тестов z-Series правда там нет.

Где Ваши комментарии или вопросы по этому примеру из жизни? Их нет и я почему знаю что их и не будет.

Конечно же не будет, мирграций между БД - не видел. Продукты которые работают на нескольких БД видел, но это как правило мелкое что-то. SAP один из немногих кто таки запилил свой продукт под несколько БД, но у них на то есть ресурсы.

Поверьте, если бы Вам предстояло решить задачку побольше, например в день только добавляется столько же данных сколько у вас есть всего (допустим ваша контора, купила всех энергопроизводителей Северной Америки ), то на производителя именно сервера вы бы смотрели в последнюю очередь.

[mskmel]

Статистика за час с нагруженной системы на маленьком 2х сокетном сервере, синеньким на что по идее надо смотреть во вторую очередь. Угадайте что в первую?

[zVlad]

...

Точнее он писался на Юникс/Оракл, и портировался на МФ (zOS/CICS/DB2). Иными словами мы имеем яблоки в обоих случаях.

Не совсем, задача переписывания с БД на БД чего-то более менее большого это задача не из тривиальных. Очень много что зависит от степени кривизны рук начальных писателей и последующих переписывателей. Я наблюдал решение почти одной и той же задачи ETL на Java и на Cobol. То что слепили на Java работало раз в 100 медленнее Cobol, Java медленее? Возможно, но не настолько. Уровень писателей был сильно разный, ребята на коболе заделиверили код, который у нас заработал сразу же. Читатели "Java для чайников" несколько месяцев баги правили, попутно тюнили и скулили, что тюнить это не к ним, их этому не учили.

это гораздо лучше чем любые искуственные тесты, согласитесь.

Для сравнения нужна одинаковая сравнимая нагрузка, её делает стандартизованный тест (SAP benchmark один из лучших). В нём великой разницы между Oracle\MSSQL\DB2 нет Linux\Windows тоже, тестов z-Series правда там нет.

....

Вы не поняли. Никакого переписывания с БД на БД не было. Использовался такой набор SQL который проходит и в DB2 и в Oracle.
Степень кривизны рук одинакова - это были одни и те же руки. В обоих случаях это Cobol и только Cobol. И SQL.
То что Вы видели или наблюдали этоо не то чем идет речь. Зачем отвлекаться от того что есть к тому что Вам приходит в голову?

Мне кажется я достаточно пояснил что во всех отношениях все сравнило. И по нагрузке тоже. Клиент был и остался тот же с теми же потребностями в системе и теми же процедурами и графиками работы с ней.

Разница в параметрах МФ и RISC огромная получилась. Качество ухудшилось. Если Вы смогли найти те параметры (я приводил), Вы не могли этого не увидеть.

[mskmel]

Использовался такой набор SQL который проходит и в DB2 и в Oracle. Степень кривизны рук одинакова - это были одни и те же руки.

Степень кривизны может отличаться от используемого инструментария.

И тут мы приходим к 101 варианту, как не меняя текста запроса и данных, сделать так чтобы он на порядки отличаться во времени выполнения на в одной и той же Oracle БД.

А уж один в один запросы DB2<->Oracle не удивительно.

[zVlad]

Статистика за час с нагруженной системы на маленьком 2х сокетном сервере, синеньким на что по идее надо смотреть во вторую очередь. Угадайте что в первую?

Угадывать я оставляю Вам. Я попросил нашего Oracle DBA посмотреть на Ваш случай и дать ответ на Ваш вопрос. "Угадать" чт надо смотреть в первую очередь он не смог (или не стал гадать), но ему не понравилась значение в строке "gc buffer buzy aquired" и он сказал что у Вас (точнее у Вашего сервера) не хватает памяти. С этим и я согласился на основании соотношения "Logical IO/Physical IO". Примерно 2/1. Это очень мало. Каждое второе обращение к страницам сопровождаестся IO. В приведенных мною данных (лишь по одному BP) на 25 Getpages приходится одна Sync I/O. И в одной I/O в среднем считыцается 75 pages. Это в случайно выбранном 4 секундном интервал и только по одному Buffer Pool.

Теперь o Buffer Pools и о терминологии. Опять же со слов нашего Oracle DBA, Oracle имеет несколько разнотипных кэшей, но кэш данных один и в нем парятся все табличные пространства. Есть еще кэши процедур, планов доступа и, наверное, еще какие-нибудь.
В DB2, то что называется Buffer Pools, это памаыть для данных. Другие системные данные находятся в EDM pool (планы доступа динамических запросов, etc...). Каждое табличное пространство приписано к тому или иному BP. Их может быть от одного в BP до много. Индексы хранятся в памяти в своих BP, но могут и в тех же что и таблицы. Что это дает? Это дает возможность выделения BP для hot-tables(или индексов) и гарантировать их наличие в памяти (не всей БД, а тех таблиц которые наиболее востребованны). Есть и большие таблицы среди таких и они в памяти находятся в сжатом виде. Разжимаются страницы по необходимости с помощью аппаратной поддержки разжатия. Вот некоторые параметры одного такого БП, в котором сидит одна сжатая таблица (кстати, всего таблиц в БД >1250. С данными >600):

Code: Select all

BP    11
 Collection Interval:  REALTIME                         Start:  11/05 16:23:12
 Report Interval:       9 sec                             End:  11/05 16:23:21

 Virtual Buffer Pool Size=    500000
 VPOOL Buffers Allocated =    500000
.....
 Getpages per Sync I/O   =    224.49    Pages Written per Write I/O =    1.79
 Prefetch per I/O        =     25.78    Pages Read per Prefetch     =     .71
 Seq Prefetch per I/O    =      1.26    Pages Read per Seq Prefetch =   32.49
 List Prefetch per I/O   =      4.55    Pages Read per List Prefetch=    2.70
 Dyn Prefetch per I/O    =     30.30    Pages Read per Dyn Prefetch =     .51
 Max Concur Prefetch     =         0    Workfile Maximum            =       0
 BP Hit % - Random       =     99.5%    Virtual Page Steal Method   =     LRU
 BP Hit % - Sequential   =       .0%

Кстати buffer, как мне сказали, это страница, а кэш это совокупность всех buffers. Block, уже я гадаю, это block на диске.

Я привел статистику только по одному BP. Вот все они (исключая EDM pool):

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        5000     5000      138     681.50       2.50      15.50        .00
BP1      750000   750000     2848    365.16K     662.50   20825.00      14.50
BP2      750000   750000     3591   20121.50     172.00     376.00      39.00
BP3        5000     5000        1      56.50        .00       1.00        .00
BP4       12000    12000       14     130.00        .00        .50        .00
BP5        9500     9500      442     153.00        .00        .50        .00
BP7       50000    50000    32477    2317.50        .00        .00        .00
BP10     220000   220000      231       6.00        .00        .00        .00
BP11     500000   500000      357    5417.00        .00     778.50        .00
BP13     370000   370000       66        .00        .00        .00        .00
BP14       5000     5000       86      20.00        .00        .00        .00
BP32K     10000    10000       50      93.50        .50       3.00       2.00
BP32K7    50000    50000    25787      23.00        .00        .00        .00
BP8K0     20000    20000        0    1013.50       9.50     127.00        .00
BP16K0      500      500        0      18.00        .00        .00        .00

Опять же, это значения за интервал, а интервал это время между нажитиями на "enter". Так что не надо комментировать числа (сообственно они и так относительные все), нажимал я "enter" довольно быстро, да и время сейчас уже не пиковое. Это я к тому что меня позабавил Ваш репорт за час работы.Я привожу данные с REALTIME monitors.

Кстати, а зачем Вы установили кластер na "маленький 2х сокетный сервер". Чисто из любопытства, или был какой-то резон?

[mskmel]

у Вас (точнее у Вашего сервера) не хватает памяти.

Сервер не мой Тут несчастных 80к physical reads

С этим и я согласился на основании соотношения "Logical IO/Physical IO". Примерно 2/1.

О! А о чем я талдычу уже которую страницу Что памяти надо много.
Ваше утверждение несколько не верно, не всё Physical IO для удовлетворения нужд Logical IO, но это уже другая история, в неё лучше вообще не лезть.

Теперь o Buffer Pools и о терминологии. Опять же со слов нашего Oracle DBA, Oracle имеет несколько разнотипных кэшей, но кэш данных один и в нем парятся все табличные пространства.

А это кому уже лет 10+ как?

Code: Select all

db_16k_cache_size     
db_2k_cache_size                 
db_32k_cache_size               
db_4k_cache_size                 
db_8k_cache_size                 
db_cache_size                       
db_keep_cache_size             
db_recycle_cache_size         

Configuring Multiple Buffer Pools

Кстати, а зачем Вы установили кластер na "маленький 2х сокетный сервер". Чисто из любопытства, или был какой-то резон?

HA одна из причин.