Тестируем DB2 ESE 8.1 на двух однопроцессорных машинах под linux.
Больше 20-40 INSERT'ов в секунду никак не получается.
Нет, я понимаю, что динамический SQL, SMS, IDE диски, сеть 100МБит... Но всё равно-не маловато ли, учитывая то, что на табличке из 7 столбцов всего один индекс? И я понимаю, если б загрузка процессоров была > 50%, или в диски упиралось, так нет же, idle 95-98%, I/O несколько сот блоков в секунду.

Что я делаю неправильно и куда копать?

gardenmanЕсли не трудно, выложите скрипт, которым пользуетесь для тестирования.
В данный момент не могу.
Но ничего особо интересного там нет-просто скрипт на Perl'e, который в цикле делает INSERT, используя динамический SQL.
Почему так? Хочется оценить возможность переноса приложения, которое в 99% случаев использует динамический SQL и крайне критично к времени ответа INSERT'a.

gardenmanа вот это -
get dbm cfg ?
get db cfg for <you db>?
а сделать вставку хранимой процедурой из perl можно?
Сделаю вечером, когда дома буду-сейчас нет доступа к тем машинам.
Хранимой процедурой не знаю, думаю, что если сделать prepare statement-ничем от ХП отличаться не должно-перекомпиляция должна отсутствовать?
Кстати, как посмотреть, сколько % времени (или в секундах) было потрачено на парсинг/компиляцию (сами мы не местные, в основном на Oracle) ?

Кстати, ещё я обратил внимание, что IMPORT работает тоже не слишком быстро, симптомы те же-загрузки CPU и I/O никакой нет.

ggvgardenman прав по поводу скрипта.
Я видел просто очень талантливый перл скрипт который делал в цикле
CONNECT
INSERT
COMMIT
DISCONNECT
не примите за личный наезд, но факт имел место быть.

Не, тогда, имхо, и 20-40 INSERT'ов не получалось бы :)

gardenmanИ еще такой вопрос, а на одиночной машине, того же класса (ну типа - диски IDE и оперативки столько же) та же самая задача как работает?

В разы быстрее, в том-то и дело. Точной цифры сейчас не помню-был так озадачен разницей, что забыл записать. Минимум в 5-7 раз быстрее.

gardenmanс удовольствием бы покапался в ваших проблемах... самому потому что интересно (еще никогда с DPF не работал). Еще одна мысль - включать мониторинг полностью и смотреть что происходит. Интересно еще, загрузка сети между нодами большая?

Ну я повключал все свитчи снэпшота, но понимания это не добавило. FCM buffers всегда свободны-их 4096 и меньше 4000 никогда не падало.

Загрузка сети, что интересно, тоже небольшая- 300-800 кбит/с!
Может, проблема в latency? С другой стороны, я коннектюсь (коннекчусь?) к координатору (node 0), уж он-то должен знать, на какой узел кидать свежевставленную строку?

gardenman DB2 Integrated Cluster Environment Deployment
Guide - читал?
Посыпаю голову пеплом-не читал. Заломало почти 14 метров качать...

Кстати, там ничего особо полезного в ICE Guide нет.
Не описано, как посмотреть, на каких задержках в данный момент висит клиент, и чего он больше всего ждал за всю свою сессию.

Итак, параметры:
Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE

Discovery support for this database (DISCOVER_DB) = ENABLE

Default query optimization class (DFT_QUERYOPT) = 5
Degree of parallelism (DFT_DEGREE) = 1
Database heap (4KB) (DBHEAP) = 1200
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC
Catalog cache size (4KB) (CATALOGCACHE_SZ) = 260
Log buffer size (4KB) (LOGBUFSZ) = 159
Utilities heap size (4KB) (UTIL_HEAP_SZ) = 5000
Buffer pool size (pages) (BUFFPAGE) = 4000
Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000
Number of extended storage segments (NUM_ESTORE_SEGS) = 0
Max storage for lock list (4KB) (LOCKLIST) = 100

Max size of appl. group mem set (4KB) (APPGROUP_MEM_SZ) = 40000
Percent of mem for appl. group heap (GROUPHEAP_RATIO) = 70
Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 512

Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = (SHEAPTHRES)
Sort list heap (4KB) (SORTHEAP) = 192
SQL statement heap (4KB) (STMTHEAP) = 2048
Default application heap (4KB) (APPLHEAPSZ) = 64
Package cache size (4KB) (PCKCACHESZ) = 859
Statistics heap size (4KB) (STAT_HEAP_SZ) = 4384

Interval for checking deadlock (ms) (DLCHKTIME) = 10000
Percent. of lock lists per application (MAXLOCKS) = 60
Lock timeout (sec) (LOCKTIMEOUT) = -1

Changed pages threshold (CHNGPGS_THRESH) = 60
Number of asynchronous page cleaners (NUM_IOCLEANERS) = 2
Number of I/O servers (NUM_IOSERVERS) = 4
Index sort flag (INDEXSORT) = YES
Sequential detect flag (SEQDETECT) = YES
Default prefetch size (pages) (DFT_PREFETCH_SZ) = 32

Track modified pages (TRACKMOD) = OFF

Default number of containers = 1
Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32

Max number of active applications (MAXAPPLS) = 40
Average number of active applications (AVG_APPLS) = 1
Max DB files open per application (MAXFILOP) = 64

Log file size (4KB) (LOGFILSIZ) = 4096
Number of primary log files (LOGPRIMARY) = 3
Number of secondary log files (LOGSECOND) = 1
Changed path to log files (NEWLOGPATH) =
Path to log files = /home/db2inst1/test1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
Overflow log path (OVERFLOWLOGPATH) =
Mirror log path (MIRRORLOGPATH) =
First active log file =
Block log on disk full (BLK_LOG_DSK_FUL) = NO
Percent of max active log space by transaction(MAX_LOG) = 0
Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0

Group commit count (MINCOMMIT) = 2
Percent log file reclaimed before soft chckpt (SOFTMAX) = 120
Log retain for recovery enabled (LOGRETAIN) = OFF
User exit for logging enabled (USEREXIT) = OFF

Auto restart enabled (AUTORESTART) = ON
Index re-creation time (INDEXREC) = SYSTEM (RESTART)
Default number of loadrec sessions (DFT_LOADREC_SES) = 1
Number of database backups to retain (NUM_DB_BACKUPS) = 12
Recovery history retention (days) (REC_HIS_RETENTN) = 366


DBM CFG:
Database monitor heap size (4KB) (MON_HEAP_SZ) = 200
Java Virtual Machine heap size (4KB) (JAVA_HEAP_SZ) = 2048
Audit buffer size (4KB) (AUDIT_BUF_SZ) = 0
Size of instance shared memory (4KB) (INSTANCE_MEMORY) = AUTOMATIC
Backup buffer default size (4KB) (BACKBUFSZ) = 1024
Restore buffer default size (4KB) (RESTBUFSZ) = 1024

Sort heap threshold (4KB) (SHEAPTHRES) = 2471

Directory cache support (DIR_CACHE) = YES

Application support layer heap size (4KB) (ASLHEAPSZ) = 15
Max requester I/O block size (bytes) (RQRIOBLK) = 32767
Query heap size (4KB) (QUERY_HEAP_SZ) = 1000
DRDA services heap size (4KB) (DRDA_HEAP_SZ) = 128
Maximum query degree of parallelism (MAX_QUERYDEGREE) = 1
Enable intra-partition parallelism (INTRA_PARALLEL) = YES

No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = 4096
Node connection elapse time (sec) (CONN_ELAPSE) = 10
Max number of node connection retries (MAX_CONNRETRIES) = 5
Max time difference between nodes (min) (MAX_TIME_DIFF) = 1440

И всё-таки... Какие есть средства мониторинга производительности DPF, кроме снэпшота FCM (он всегда кажет, кто буферов полно)?
Сетевой трафик небольшой, меньше 1МБ/с, а INSERT работает в разы медленнее, чем на одиночной машине.
DBArtisan показывает статус приложения-waiting for remote node.
Как понять, в чём bottleneck?
Может, конечно, дело в том, что сеть 100Мбит, но вроде ведь она вообще не загружена... Процессоры на 90% в idle, диски тоже.

ggvдля получения хорошей производительности OLTP надо писать приложение с учетом именно распределенной базы.
Это первое.
И второе - можно сказать что пока нет OLTP задачи, которые бы не решались одним SMP сервером.
Последнее время производительность серверов растет опаережающими темпами по сравнению с потребностью заказчиков.
Как вывод - дешевле OLTP будет гонять на одном SMP сервере. Просто возьми и посчитай. И случай выхода ноды из строя тоже просчитай.
Ну если все-таки вынужден гонять на кластере - то и начинать надо сначала, с постановки задачи и пересмотра логики приложения. Самое простое - два перл скрипта, работающих с разными нодами, и данные разбиты на уровне логической модели. Тогда точно будет большой прирост.
Как я понял, это основная причина, почему DPF ставят в подавляющем большинстве случаев под OLAP
Вот я и пытаюсь найти guidelines - КАК писать под EEE/DPF. Ничего толком нету.
Да и как переписать простой insert?

Большой SMP сервер не решает задачи небольших начальных вложений, масштабируемости и доступности компонентов, например. Ну и держать в стэндбае пару 2-4х-процессорных нодов гораздо дешевле, чем держать где-то запасной Sun 6800, например.

Главное-похоже, что невозможно понять _почему_ тормозит... То ли интерконнект, то ли ещё что... В Оракле с этим гораздо лучше.

Меня терзают смутные сомнения (с)

Опять же, ничем не подкреплённые, потому что не знаю, как это проверить.
Может быть, причина медленного INSERT'a в наличии primary key? Это ж полчается, что DB2 должно при вставке во всех разделах проверить, не нарушит ли новая строка уникальности?

Э, ну вот как раз в статейках приводится пример плохого partitioning key.
1) low cardinality
2) Из какого-нибудь Гондураса будет 5 строк данных, а из Нью-Йорка-5млн.

Да и не хотелось бы при получении строки для INSERTa вычислять, на какую ноду цепляться и отсоединяться-подключаться снова.

Ну и всё же хотелось бы понять, в чём конкретно проблема. Может, есть какие-то event monitors или я не знаю?

ggvDPF в OLTP хорош там, где данные можно легко разбить логически. И приложения соответсвенно тоже.
Ну предлагаю перейти к мысленному эксперименту :)

Есть таблицы, условно назовём их Customer, Product, History.
Соответственно, в Customer и Product вставки идут не очень часто, в основном чтения по первичному ключу(он же и partitioning) - выборки работают отлично, клиент в восторге.
А вот с History хуже-в неё постоянно идёт большое число вставок и "тяжёлые" SELECTы (без указания primary key, естессно).
Так вот со вставкой и есть проблема :(
И особо-то логически не разобьёшь...