CREATE DATABASE может занимать несколько минут / Informix

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / CREATE DATABASE может занимать несколько минут

52 сообщений из 52, показаны все 3 страниц

все

CREATE DATABASE может занимать несколько минут

#38932515

Яковлев Павел

Гость

Здраствуйте товарищи !

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

Informix 11.50FC8W2 на CentOS 5.11

С некоторых пор, время создания новой базы данных стало практически не предсказуемым - от 0 до практически бесконечности (минуты). Создание же структуры свежесозданой базы - моментом.

CREATE DATABASE XXX IN yyy;

Общее количество баз на инстансе - несколько тысяч. И ежедневно их количество увеличивается на несколько десятков.
(до лимита 22 миллиона далеко :).

Корневой TBLSPACE TBLSPACE (0x100001) не разбух (15 экстенов, все в одном чанке).

DBSPACE TBLSPACE (0x100002) тоже не сказать что бы фрагментирован (20 экстентов, все в одном чанке)

TBLSPACE TBLSPACE для дбспейса yyy ваще новый и создан с первичным экстентом 500МБ.

Чекпоинты короткие - 0-1 секунды.

Общая производительность системы и нагрузки - без изменений.

Параллельно базы не создаются.

Что это заразе надо ? Что держит создание базы ?

...

Рейтинг:

0 / 0

09.04.2015, 22:47

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933047

victor16

Гость

Яковлев ПавелЧто держит создание базы ?
А что рассказывает onstat об этой сессии ?

...

Рейтинг:

0 / 0

10.04.2015, 13:46

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933483

Яковлев Павел

Гость

Уточнения
- забыл уточнить что "with bufferres log" (но это не влияет)

- rename database - моментом

- drop database - моментом

А вот и сессия - ввода-вывода ждёт

session effective #RSAM total used dynamic
id user user tty pid hostname threads memory memory explain
8571147 xxxx - 4 19045 xxxx 270336 177496 off

tid name rstcb flags curstk status
8578836 sqlexec 636f516c0 --BP--- 10288 IO Wait-

Memory pools count 2
name class addr totalsize freesize #allocfrag #freefrag
8571147 V 5cee87040 266240 92032 250 55
8571147*O0 V 5a38ec040 4096 808 1 1

name free used name free used
overhead 0 6576 scb 0 144
opentable 0 4312 filetable 0 1416
ru 0 600 misc 0 168
log 0 16536 temprec 0 21664
keys 0 920 ralloc 0 65816
gentcb 0 1592 ostcb 0 2920
sqscb 0 31328 sql 0 72
rdahead 0 1120 hashfiletab 0 552
osenv 0 2832 sqtcb 0 6912
fragman 0 216 udr 0 11800

sqscb info
scb sqscb optofc pdqpriority optcompind directives
5516b9028 63bbe8028 0 0 2 1

Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
8571147 CREATE DATABAS xxxxxx CR Not Wait 0 0 9.24 Off

Current SQL statement :
create database xxxxxx in xxxxxx with buffered log

Last parsed SQL statement :
create database xxxxxx in xxxxxx with buffered log

...

Рейтинг:

0 / 0

10.04.2015, 21:37

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933486

Яковлев Павел

Гость

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

Но это трэш, угар и содомия.

Надо гадость удушить.

...

Рейтинг:

0 / 0

10.04.2015, 21:40

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933498

GVF112GVF

Гость

Яковлев Павел,

Такое впечатдение, что дисковая подсистема нагружена - Wait I/O.

Что показывает вывод onstat:
1. onstat -a:
2. onstat -g iof, onstat -g ioq, and onstat -g iov
3. onstat -FR

Disk I/O на уровне LINUX:
1. top
2. iostat -x 2 5
3. sar, vmstat

С уважением,
Вадим.

...

Рейтинг:

0 / 0

10.04.2015, 22:04

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933537

Яковлев Павел

Гость

Нашёл транзакцию этой сессии в логах - технически она длится до сих пор, хотя всё уже отработало и база доступна.

Прикольно.

Или я пропустил COMMIT в логах. Хотя grep навряд ли такой кривой :)

...

Рейтинг:

0 / 0

10.04.2015, 22:46

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933546

Яковлев Павел

Гость

GVF112GVFТакое впечатдение, что дисковая подсистема нагружена - Wait I/O.

Сильно навряд ли - всё вооще бы колом стояло и сервис бы лежал. А тормозит только одна операция.

База живёт на Adaptec 5405Z c RAID 10 из пар HDD(sas 15k) + SSD
(я про такое как-то тут уже писал: чтения - только с SSD, запись - на оба)

Статистика в файле.

41.2%us, 3.0%sy, 0.0%ni, 36.4%id, 17.4%wa, 0.1%hi, 1.9%si, 0.0%st

dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
2075938411 9912027217 327016654736 99.37 66568028 228772570 1245219533 95.03

...

Рейтинг:

0 / 0

10.04.2015, 23:14

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933705

victor16

Гость

[quot Яковлев Павел]GVF112GVFТСтатистика в файле.
Неплохо было бы онулить статистику onstat -z непосредственно перед выполнением SQL

...

Рейтинг:

0 / 0

11.04.2015, 10:58

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933932

Яковлев Павел

Гость

C обнулённой статистикой.

Загрузка обычная + шло удаление ~500К записей с блобами из одной таблицы (порциями по 5К)

...

Рейтинг:

0 / 0

11.04.2015, 20:32

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38933937

Яковлев Павел

Гость

Физический лог и логические логи из рута разумеется вынесены и тмп отдельно нарезаны

...

Рейтинг:

0 / 0

11.04.2015, 20:42

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38934006

victor16

Гость

Яковлев ПавелC обнулённой статистикой
Стоит обратить внимание на высокие цифры maxlen из onstat -ioq.
Для KAIO не желательно превышать 32.

Яковлев Павелшло удаление ~500К записей с блобами из одной таблицы (порциями по 5К)
Вопрос: блобы журналируются?
Что происходит с контрольной точкой, особенно в момент выполнения CREATE DATABASE
(onstat -g ckp, onstat -F)
Как насчет фрагментированности пространств, где создаются базы данных ?

...

Рейтинг:

0 / 0

12.04.2015, 00:35

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38934093

Яковлев Павел

Гость

victor16Яковлев Павелшло удаление ~500К записей с блобами из одной таблицы (порциями по 5К)
Вопрос: блобы журналируются?
Что происходит с контрольной точкой, особенно в момент выполнения CREATE DATABASE
(onstat -g ckp, onstat -F)
Как насчет фрагментированности пространств, где создаются базы данных ?

Блобы хранятся в том же TBLSPACE что и таблица. И их удаление было упомянуто для полноты картины - это был разовый процесс, а создание баз тормозит и без этого

Ничего с чекпоинтами "такого" не происходит - вызываются после бэкапа каждого лога (с чего так - ранее тут уже описывалось), или вызываются от RTO.

Состояние корневого пространства и пространства данный - без изменений по сравнении с тем то описано в начале - не фрагментировано.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

AUTO_CKPTS=Off   RTO_SERVER_RESTART=180 seconds   Estimated recovery time 27 seconds

                                                                    Critical Sections                          Physical Log    Logical Log    
           Clock                                  Total Flush Block #      Ckpt  Wait  Long  # Dirty   Dskflu  Total    Avg    Total    Avg   
Interval   Time      Trigger    LSN               Time  Time  Time  Waits  Time  Time  Time  Buffers   /Sec    Pages    /Sec   Pages    /Sec  
7081846    11:36:47 *User       2902853:0x7557c   0.2   0.0   0.0   15     0.0   0.2   0.3   2160      2160    25094    125    8990     44    
7081847    11:40:17 *User       2902854:0x3d4508  0.2   0.1   0.0   4      0.0   0.1   0.2   1991      1991    27306    129    10863    51    
7081848    11:43:13 *User       2902855:0x57d1cc  0.9   0.8   0.0   14     0.0   0.9   0.9   21221     21221   22239    127    10425    59    
7081849    11:46:17 *User       2902856:0x352610  1.0   0.9   0.0   9      0.0   1.0   1.0   23079     23079   28573    155    9445     51    
7081850    11:48:25 *User       2902857:0x1520c8  0.2   0.1   0.0   12     0.0   0.2   0.2   3438      3438    25034    195    9488     74    
7081851    11:51:13 *User       2902858:0x8e67b8  0.6   0.5   0.0   13     0.0   0.6   0.6   14678     14678   24843    147    11941    71    
7081852    11:54:01 *User       2902859:0xaa234   0.5   0.4   0.0   4      0.0   0.5   0.5   3235      3235    22161    131    7891     46    
7081853    11:57:19 *User       2902860:0x56262c  0.2   0.1   0.0   7      0.0   0.2   0.2   1926      1926    25103    126    11208    56    
7081854    12:00:32 *User       2902861:0x223550  0.6   0.4   0.0   14     0.1   0.6   0.6   12968     12968   27394    142    9169     47    
7081855    12:02:35 *User       2902862:0x2bb050  0.3   0.1   0.0   13     0.0   0.2   0.3   2363      2363    20619    166    10152    81    
7081856    12:04:18 *User       2902863:0x296510  0.4   0.3   0.0   3      0.0   0.4   0.5   1535      1535    26682    259    9963     96    
7081857    12:06:51 *User       2902864:0x20e0b4  0.4   0.3   0.0   11     0.0   0.4   0.4   2575      2575    30113    196    9864     64    
7081858    12:09:25 *User       2902865:0x13141c  0.6   0.3   0.0   10     0.0   0.5   0.6   6545      6545    25378    165    9779     63    
7081859    12:11:17 *User       2902866:0xab67b8  0.4   0.3   0.0   5      0.0   0.4   0.4   13673     13673   17384    155    12437    111   
7081860    12:13:27 *User       2902867:0x5f704   0.8   0.6   0.0   11     0.1   0.8   0.8   12505     12505   17053    131    7353     56    
7081861    12:17:16 *User       2902868:0x5ba0ac  1.0   0.9   0.0   10     0.0   1.0   1.0   5363      5363    31620    138    11371    49    
7081862    12:20:18 *User       2902869:0x30f524  0.7   0.5   0.0   4      0.0   0.7   0.7   17585     17585   21439    117    9317     50    
7081863    12:22:36 *User       2902870:0x56674   0.8   0.7   0.0   9      0.0   0.7   0.8   15860     15860   18249    132    9303     67    
7081864    12:25:18 *User       2902871:0x6ec7c8  0.3   0.1   0.0   7      0.0   0.2   0.3   3320      3320    25449    158    11687    72    
7081865    12:27:22 *User       2902872:0x1f7060  0.4   0.3   0.0   7      0.0   0.4   0.4   17142     17142   28613    230    8730     70    

Max Plog       Max Llog       Max Dskflush   Avg Dskflush   Avg Dirty      Blocked      
pages/sec      pages/sec      Time           pages/sec      pages/sec      Time         
44085          7315           54             731            1              0

...

Рейтинг:

0 / 0

12.04.2015, 12:37

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38934882

GVF112GVF

Гость

Яковлев Павел,

Спасибо за предоставленную информацию.

Брасается в глаза общая нагруженность CPU-процессоров системы и ожидания операций I/O (чтения) с устройства на уровне OS (vmstat). На уровне Informix, наблюдается очередь на обслуживание I/O - maxlen (onstat -g ioq)

1. Нужно проверить пропускную систему I/O на уровне OS.
2. Хватает ли в системе выделенных CPU и RAM.
3. Распредедение ресурсов на уровне Inofmrix (performance tuning).

Рекомендую ознакомиться со следующим материалом - http://www.advancedatatools.com/TechInfo/G14_UnixMonitoringTools.pdf

Далле, на фоне всего происходящего - есть ли отличие (по врением) при создании базы данных -
CREATE DATABSE xxx ... WITH ...
и CREATE DATABSE xxx IN dbspace ... WITH ...???

С уважанием,
Вадим.

...

Рейтинг:

0 / 0

13.04.2015, 14:04

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935212

victor16

Гость

Яковлев ПавелСостояние корневого пространства и пространства данный - без изменений по сравнении с тем то описано в начале - не фрагментировано.
Проверьте общее количество экстентов по каждому пространству:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

select sysmaster:partdbsnum(a.partnum),
       count(ti_nextns)
  from sysmaster:systabnames a,  
       sysmaster:systabinfo i
 where partnum = ti_partnum 
   and a.tabname != 'TBLSpace'
group by 1
order by 2 desc

...

Рейтинг:

0 / 0

13.04.2015, 18:01

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935326

Яковлев Павел

Гость

victor16Яковлев ПавелСостояние корневого пространства и пространства данный - без изменений по сравнении с тем то описано в начале - не фрагментировано.
Проверьте общее количество экстентов по каждому пространству:

Ничего интересного - 38483 прекрасно согласуется с количеством баз уже созданых в 8 с учётом что таблица или индекс это один экстент и что на пустую таблицу экстент не выделяется.

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

          13           990191  (закончился TBLSPACE TBLSPACE)
           8            38483   (вот тут создаются базы, это новое пространство,
                                        но и в нём были тормоза даже когда оно было пустое свежесозданное)
           1              926
           5              808
           9              356
          16              230
          12               83
           6               68
           7               27
          17               27
          18               27
           3                8
          19                7
           4                6
          14                4
           2                4
          10                4

...

Рейтинг:

0 / 0

13.04.2015, 22:14

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935331

Яковлев Павел

Гость

GVF112GVFБрасается в глаза общая нагруженность CPU-процессоров системы и ожидания операций I/O (чтения) с устройства на уровне OS (vmstat). На уровне Informix, наблюдается очередь на обслуживание I/O - maxlen (onstat -g ioq)

1. Нужно проверить пропускную систему I/O на уровне OS.
2. Хватает ли в системе выделенных CPU и RAM.
3. Распредедение ресурсов на уровне Inofmrix (performance tuning).

Рекомендую ознакомиться со следующим материалом - http://www.advancedatatools.com/TechInfo/G14_UnixMonitoringTools.pdf

Эээээ может быть момент снятия статистики был не очень удачен (хммм может ночь попала - ночью pbzip динамически отжирает всё что idle (в итоге имеем загрузку 100%) когда бэкап жмёт), но загрузка CPU в разгар рабочего дня 50% и idle процентов 30%.

И при 99.4% кэширования информиксом записи я ошибаюсь или io-wait сильно без разницы ? главное что чекпоинт стабильно < 1 секунды.

GVF112GVFДалле, на фоне всего происходящего - есть ли отличие (по врением) при создании базы данных -
CREATE DATABSE xxx ... WITH ...
и CREATE DATABSE xxx IN dbspace ... WITH ...???

Нету. Что в рут создавай, что в новом пустом дбспейсе - минуты.

Если это блокировки, то они какие-то весёлые - напомню что переименование или удаление базы - моментом. Заполнение новой базы таблицами и индексами - моментом

При создании что, весь sysdatabases эксклюзивно лочится что ли ? А при переименовании нет ? Странно это.

А при удлении ? Действий явно требуется больше чем при создании - таблицы и индексы снести надо и место освободить. И ведь шустро так успевает...

...

Рейтинг:

0 / 0

13.04.2015, 22:28

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935510

DrGonzo

Участник

Откуда: ex-IBM

Сообщения: 176

Рейтинг: 0 / 0

> А при удлении ? Действий явно требуется больше чем при создании

Действий больше при создании. При создании базы создается набор таблиц системного каталога с индексами и тд. Для всего этого надо искать и выделять место. Выделение экстентов записывается в журнал, даже если создаваемая база не логируется. Если база с логом, то создание сис. каталога попадет в журнал в дополнение ко всему остальному.

При удалении по большому счету мы отмечаем свободное место в chunk free list page, обнуляются страницы tblspace tblspace (сами страницы таблиц и индексов на диске не меняются), потом удаляется запись из sysmaster:sysdatabases.

Если хотите понять, где теряется время у вас при создании базы, мониторьте статус нити sqlexec, выполняющей CREATE DATABASE.

При любом статусе, отличном от 'running' " onstat -g stk <tid> " должен показать стек нити.

Если нить большую часть времени проводит в статусе 'running', определите на каком CPU VP выполняется CREATE DATABASE. И пока оно крутится, соберите несколько стеков процесса одним из нижеследующих способов.

a) pstack <oninit_PID> (предпочтителен, т.к. бывали случаи, когда 'onmode -X' заваливал весь инстанс)
b) onmode -X stack <VP #>

...

Рейтинг:

0 / 0

14.04.2015, 08:53

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935590

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

Яковлев ПавелЕсли это блокировки, то они какие-то весёлые - напомню что переименование или удаление базы - моментом. Заполнение новой базы таблицами и индексами - моментом

При создании что, весь sysdatabases эксклюзивно лочится что ли ? А при переименовании нет ? Странно это.

Предположение про блокировку sysdatabases просто проверяется на практике.
1. Создали БД №1.
2. Запустили создание БД №2.
3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3.
Имхо - дело не в нём...

...

Рейтинг:

0 / 0

14.04.2015, 10:15

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935816

Яковлев Павел

Гость

АнатоЛойЯковлев ПавелЕсли это блокировки, то они какие-то весёлые - напомню что переименование или удаление базы - моментом. Заполнение новой базы таблицами и индексами - моментом

При создании что, весь sysdatabases эксклюзивно лочится что ли ? А при переименовании нет ? Странно это.

Предположение про блокировку sysdatabases просто проверяется на практике.
1. Создали БД №1.
2. Запустили создание БД №2.
3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3.
Имхо - дело не в нём...
На практике, с такими лагами как у меня, сложно определить когда пункт 2 схемы дорвётся до таблицы и залочит её (или её страницу - там страничная блокировка) .

Ну вот запустил я создание-2 и ? Оно может минуту висть, может две. Когда именно запускать п3 ?

...

Рейтинг:

0 / 0

14.04.2015, 13:00

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38935868

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

Яковлев ПавелАнатоЛойпропущено...

Предположение про блокировку sysdatabases просто проверяется на практике.
1. Создали БД №1.
2. Запустили создание БД №2.
3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3.
Имхо - дело не в нём...
На практике, с такими лагами как у меня, сложно определить когда пункт 2 схемы дорвётся до таблицы и залочит её (или её страницу - там страничная блокировка) .

Ну вот запустил я создание-2 и ? Оно может минуту висть, может две. Когда именно запускать п3 ?
П.3. можешь сразу запустить в цикле даже до запуска п.2.
И смотреть, какие отклонения у времени переименования до, во время и после п.2 .
Павел, это больше мозги размять... А-ля мозговой штурм. Моя идея может на самом деле и выеденного яйца (после Пасхи-то :)) не стоить...

...

Рейтинг:

0 / 0

14.04.2015, 13:34

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936066

victor16

Гость

DrGonzo > А при удлении ? Действий явно требуется больше чем при создании

Действий больше при создании. При создании базы создается набор таблиц системного каталога с индексами и тд. Для всего этого надо искать и выделять место. Выделение экстентов записывается в журнал, даже если создаваемая база не логируется. Если база с логом, то создание сис. каталога попадет в журнал в дополнение ко всему остальному.

При удалении по большому счету мы отмечаем свободное место в chunk free list page, обнуляются страницы tblspace tblspace (сами страницы таблиц и индексов на диске не меняются), потом удаляется запись из sysmaster:sysdatabases.

Если хотите понять, где теряется время у вас при создании базы, мониторьте статус нити sqlexec, выполняющей CREATE DATABASE.

При любом статусе, отличном от 'running' " onstat -g stk <tid> " должен показать стек нити.

Если нить большую часть времени проводит в статусе 'running', определите на каком CPU VP выполняется CREATE DATABASE. И пока оно крутится, соберите несколько стеков процесса одним из нижеследующих способов.

a) pstack <oninit_PID> (предпочтителен, т.к. бывали случаи, когда 'onmode -X' заваливал весь инстанс)
b) onmode -X stack <VP #>
+100500
Редко когда встретишь столько умных мыслей в одном сообщении. Я записал в свой блокнот на всякий случай.
ЗЫ:) Можно пойти дальше и подключить процесс к дебаггеру для его дальнейшего исследования... Но на продакшене я бы не рискнул.

...

Рейтинг:

0 / 0

14.04.2015, 15:25

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936421

Яковлев Павел

Гость

DrGonzoЕсли хотите понять, где теряется время у вас при создании базы, мониторьте статус нити sqlexec, выполняющей CREATE DATABASE.

При любом статусе, отличном от 'running' " onstat -g stk <tid> " должен показать стек нити.

Если нить большую часть времени проводит в статусе 'running', определите на каком CPU VP выполняется CREATE DATABASE. И пока оно крутится, соберите несколько стеков процесса одним из нижеследующих способов.

a) pstack <oninit_PID> (предпочтителен, т.к. бывали случаи, когда 'onmode -X' заваливал весь инстанс)
b) onmode -X stack <VP #>

сессия

Код: python

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.

session           effective                            #RSAM    total      used       dynamic 
id       user     user      tty      pid      hostname threads  memory     memory     explain 
24746236 xxx      -         4        10561    xxxx     1        155648     115440     off 

tid      name     rstcb            flags    curstk   status
24767513 sqlexec  636f35c88        --BP---  10288    IO Wait-

Memory pools    count 2
name         class addr              totalsize  freesize   #allocfrag #freefrag 
24746236     V     612660040        151552     39400      192        37        
24746236*O0  V     5ca9d5040        4096       808        1          1         

name           free       used           name           free       used      
overhead       0          6576           scb            0          144       
opentable      0          4312           filetable      0          1392      
ru             0          600            misc           0          168       
log            0          16536          temprec        0          21664     
keys           0          968            ralloc         0          12256     
gentcb         0          1592           ostcb          0          2920      
sqscb          0          27800          sql            0          72        
rdahead        0          1120           hashfiletab    0          552       
osenv          0          2896           sqtcb          0          6928      
fragman        0          216            udr            0          6728      

sqscb info
scb              sqscb            optofc   pdqpriority optcompind  directives
744319028        5f5a94028        0        0           2           1         

Sess       SQL            Current            Iso Lock       SQL  ISAM F.E. 
Id         Stmt type      Database           Lvl Mode       ERR  ERR  Vers  Explain    
24746236   CREATE DATABAS xxx             CR  Not Wait   0    0    9.24  Off        

Current SQL statement :
  create database xxx in xxx with buffered log 

Last parsed SQL statement :
  create database xxx in xxx with buffered log

onstat -g stk

Код: python

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

0x0000000001090cb9 (oninit) yield_processor_mvp
0x000000000109256d (oninit) mt_yield
0x00000000010ad8b7 (oninit) mt_aio_wait
0x00000000010afef3 (oninit) mt_aio_start
0x00000000010c815b (oninit) mt_aio_fread
0x000000000087b187 (oninit) scread
0x000000000087f206 (oninit) dbcreate
0x000000000062abd6 (oninit) aud_dbcreate
0x00000000009fcd4e (oninit) excommand
0x00000000008d0beb (oninit) sq_execute
0x000000000098c716 (oninit) sqmain
0x00000000011565b7 (oninit) spawn_thread
0x00000000010a38ca (oninit) startup

pstack

Код: python

1.
2.
3.
4.
5.

#0  0x000000325c8d6397 in semop () from /lib64/libc.so.6
#1  0x0000000001096993 in P ()
#2  0x0000000001097168 in idle_processor ()
#3  0x00000000010a38ca in startup ()
#4  0x0000000000000000 in ?? ()

onmode -X дало пусто. у него в хелпе даже ключа такого нет.

Спит оно пока ввода-вывода ждёт.

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

DrGonzo > А при удлении ? Действий явно требуется больше чем при создании

Действий больше при создании. При создании базы создается набор таблиц системного каталога с индексами и тд. Для всего этого надо искать и выделять место. Выделение экстентов записывается в журнал, даже если создаваемая база не логируется. Если база с логом, то создание сис. каталога попадет в журнал в дополнение ко всему остальному.

При удалении по большому счету мы отмечаем свободное место в chunk free list page, обнуляются страницы tblspace tblspace (сами страницы таблиц и индексов на диске не меняются), потом удаляется запись из sysmaster:sysdatabases.

Тоже логично.

Ещё что весело - в след за созданием базы идёт создание в ней пользовательских таблиц и индексов.

И это всё то же требует сравнимых действий как по составу так и по количеству

И даже хуже - база заполняется системными таблицами изнутри одного процесса, а на создание каждой пользовательской таблицы, индекса, констрейнта у меня отдельный вызов sql.

И ещё хуже - создание пользовательских объектов требует заполнения системных таблиц.

Но шаг создания пользовательских объектов проскакивает моментом. И даже в том же дбспейсе - системные таблицы базы они ж в её родном дбспейсе, не в корневом - т.е. экстенты ищутся там же.

...

Рейтинг:

0 / 0

14.04.2015, 19:30

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936434

victor16

Гость

Яковлев Павел
onstat -g stk

Код: python

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

0x0000000001090cb9 (oninit) yield_processor_mvp
0x000000000109256d (oninit) mt_yield
0x00000000010ad8b7 (oninit) mt_aio_wait
0x00000000010afef3 (oninit) mt_aio_start
0x00000000010c815b (oninit) mt_aio_fread
0x000000000087b187 (oninit) scread
0x000000000087f206 (oninit) dbcreate
0x000000000062abd6 (oninit) aud_dbcreate
0x00000000009fcd4e (oninit) excommand
0x00000000008d0beb (oninit) sq_execute
0x000000000098c716 (oninit) sqmain
0x00000000011565b7 (oninit) spawn_thread
0x00000000010a38ca (oninit) startup

Судя по стеку, сессия - не писатель, сессия - читатель ..

...

Рейтинг:

0 / 0

14.04.2015, 19:42

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936438

Яковлев Павел

Гость

victor16Судя по стеку, сессия - не писатель, сессия - читатель ..

Что в автолавку загрузили - тем и торгуем :)

Боюсь уже фантазировать что она такое у куда полезла читать что встала колом. Магнитной ленты в системе нет :)

...

Рейтинг:

0 / 0

14.04.2015, 19:46

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936458

victor16

Гость

Яковлев ПавелБоюсь уже фантазировать что она такое у куда полезла читать что встала колом.
Наверно, дальше сможет помочь $INFORMIXDIR/bin/xtrace

...

Рейтинг:

0 / 0

14.04.2015, 20:02

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936471

victor16

Гость

Кстати, что показывает onstat -u на эту сессию ?

...

Рейтинг:

0 / 0

14.04.2015, 20:17

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936509

Яковлев Павел

Гость

victor16Яковлев ПавелБоюсь уже фантазировать что она такое у куда полезла читать что встала колом.
Наверно, дальше сможет помочь $INFORMIXDIR/bin/xtrace
Сильно ночью остановив всё что можно.

Но сначала попробую как-нибудь вместо сна загнать в однопользовательский режим и попробовать создать базу из него (прада почти уверен что проблемы не будет)

...

Рейтинг:

0 / 0

14.04.2015, 21:28

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936514

Яковлев Павел

Гость

victor16Кстати, что показывает onstat -u на эту сессию ?

на "эту" я уже ни откуда не возьму, но вот на аналогичную

636f45f30 ---P--- 24840704 xxxx 4 0 0 0 0 0

...

Рейтинг:

0 / 0

14.04.2015, 21:38

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936515

Яковлев Павел

Гость

К сожалению я на несколько дней покину собственную тему в самом её разгаре.

Вернусть - обязательно всё прочту и продолжу свои собственные опыты над зверюшкой.

...

Рейтинг:

0 / 0

14.04.2015, 21:39

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936519

GVF112GVF

Гость

Яковлев Павел,

Если баз действительно так много ... могу предположить, что нужно посмотреть в сторону ожиданий I/O, STMT cache, VP CPU cache и
возможно некоторых проблем - IC73442: PERFORMANCE PROBLEM WHEN A TEMPORARY TABLE IS CREATED AND DROPPED WITHIN A LOOP AND WITHIN A TRANSACTION.

Да вот еще, редакция Cent OS и возможные параметры конфигурации на уровне OS (требуемые FixPack).

С уважением,
Вадим.

...

Рейтинг:

0 / 0

14.04.2015, 21:47

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38936636

DrGonzo

Участник

Откуда: ex-IBM

Сообщения: 176

Рейтинг: 0 / 0

pstack

Код: python

1.
2.
3.
4.
5.

#0  0x000000325c8d6397 in semop () from /lib64/libc.so.6
#1  0x0000000001096993 in P ()
#2  0x0000000001097168 in idle_processor ()
#3  0x00000000010a38ca in startup ()
#4  0x0000000000000000 in ?? ()

Т.к. нить не находится в состоянии running, использовать pstack или onmode -X не нужно.

onmode -X дало пусто. у него в хелпе даже ключа такого нет.

"onmode -X stack <номер VP>" сохраняет стек в файл - проверьте лог, там должно быть что-то типа:
stack trace for pid <PID> written to <имя файла>

Яковлев Павел
onstat -g stk

Код: python

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

0x0000000001090cb9 (oninit) yield_processor_mvp
0x000000000109256d (oninit) mt_yield
0x00000000010ad8b7 (oninit) mt_aio_wait
0x00000000010afef3 (oninit) mt_aio_start
0x00000000010c815b (oninit) mt_aio_fread
0x000000000087b187 (oninit) scread
0x000000000087f206 (oninit) dbcreate
0x000000000062abd6 (oninit) aud_dbcreate
0x00000000009fcd4e (oninit) excommand
0x00000000008d0beb (oninit) sq_execute
0x000000000098c716 (oninit) sqmain
0x00000000011565b7 (oninit) spawn_thread
0x00000000010a38ca (oninit) startup

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

Конкретно данный стек говорит о том, что нить занимается созданием системного каталога. А точнее, хочет прочитать $INFORMIXDIR/etc/boot*.sql файл - запрос на чтение ушел к AIO VP, и нить "отдыхает" в ожидании данных.

Теперь, посмотрите на это:

AIO I/O queues:
q name/id len maxlen totalops dskread dskwrite dskcopy
fifo 0 0 0 0 0 0 0
drda_dbg 0 0 0 0 0 0 0
sqli_dbg 0 0 0 0 0 0 0
kio 0 0 97 271415488 265771982 5643506 0
kio 1 0 96 227052370 221310410 5741960 0
kio 2 0 89 193821546 188481299 5340247 0
kio 3 0 96 230928080 225027325 5900755 0
kio 4 0 118 209941739 204116166 5825573 0
kio 5 0 92 175250252 169940212 5310040 0
kio 6 0 94 149339764 143989597 5350167 0
kio 7 0 91 175761296 170102731 5658565 0
kio 8 0 96 101813114 96709351 5103763 0
kio 9 0 95 149871490 144246592 5624898 0
kio 10 0 95 123926988 118749124 5177864 0
kio 11 0 94 125228875 119640898 5587977 0
adt 0 0 0 0 0 0 0
msc 0 0 58 42154126 0 0 0
aio 0 195 2315 34890959 9004434 2 0
<...>

Cтрочка для aio - текущая длина очереди 195, максимальная - 2315! Это дофига и явно указывает на проблему с AIO.

Если не совсем ясно, поясню. Для чанков у вас используется KAIO, что хорошо и правильно. Но при создании базы Informix читает некоторые файлы из $INFORMIXDIR/etc - чтение файлов происходит через AIO.

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

AUTO_AIOVPS у вас включено или нет?

...

Рейтинг:

0 / 0

15.04.2015, 04:06

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38937588

victor16

Гость

...

Рейтинг:

0 / 0

15.04.2015, 18:10

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38937850

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

victor16DrGonzoКонкретно данный стек говорит о том, что нить занимается созданием системного каталога. А точнее, хочет прочитать $INFORMIXDIR/etc/boot*.sql файл - запрос на чтение ушел к AIO VP, и нить "отдыхает" в ожидании данных.
А где можно поподробнее почитать про то, чем какая нить занимается?
сильно подозреваю, что в исходниках сервера :)

...

Рейтинг:

0 / 0

15.04.2015, 23:49

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38937871

DrGonzo

Участник

Откуда: ex-IBM

Сообщения: 176

Рейтинг: 0 / 0

АнатоЛойсильно подозреваю, что в исходниках сервера :)

Так точно! :)

...

Рейтинг:

0 / 0

16.04.2015, 01:33

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38937937

GVF112GVF

Гость

АнатоЛой,

Модно начать с onstat -g ath .... далее ... Advanced Informix Administration ... :-)

С уважаением,
Вадим.

...

Рейтинг:

0 / 0

16.04.2015, 09:03

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38938250

cpr

Гость

А нельзя на другой сервак съехать хотя бы временно?
Может дело именно в большом количестве БД?

...

Рейтинг:

0 / 0

16.04.2015, 13:28

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38938533

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

GVF112GVFАнатоЛой,

Модно начать с onstat -g ath .... далее ... Advanced Informix Administration ... :-)

С уважаением,
Вадим.
Вадим, мне намёк не совсем понятен.
"Advanced Informix Administration" - это курс?
И в "методичке" к которому есть "перечень" названий функций из исходников сервера? С пояснениями?
:)

...

Рейтинг:

0 / 0

16.04.2015, 17:35

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38939184

GVF112GVF

Гость

АнатоЛой,

> "Advanced Informix Administration" - это курс?

Да. Помню, был такой курс с детальным описанием форматов и бинарных структур INFORMIX (страниц) и т.д.

И в "методичке" к которому есть "перечень" названий функций из исходников сервера? С пояснениями?
Методичка у тебя всегда под рукой ... $INFORMIXDIR/etc/ ... что-то типа sym.out ... :-)

Если на ядро oninit с базового адреса натравить debugger .. о чудо ... можно многое узнать ... ;-)

С уважением,
Вадим.

...

Рейтинг:

0 / 0

17.04.2015, 13:39

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38939381

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

GVF112GVFМетодичка у тебя всегда под рукой ... $INFORMIXDIR/etc/ ... что-то типа sym.out ... :-)

GVF112GVFЕсли на ядро oninit с базового адреса натравить debugger .. о чудо ... можно многое узнать ... ;-)

Чёт меня улыбает.

1. А можно по-любому из этих двух методов (или их объединив) сделать однозначно логичный вывод, что это:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

0x0000000001090cb9 (oninit) yield_processor_mvp
0x000000000109256d (oninit) mt_yield
0x00000000010ad8b7 (oninit) mt_aio_wait
0x00000000010afef3 (oninit) mt_aio_start
0x00000000010c815b (oninit) mt_aio_fread
0x000000000087b187 (oninit) scread
0x000000000087f206 (oninit) dbcreate
0x000000000062abd6 (oninit) aud_dbcreate
0x00000000009fcd4e (oninit) excommand
0x00000000008d0beb (oninit) sq_execute
0x000000000098c716 (oninit) sqmain
0x00000000011565b7 (oninit) spawn_thread
0x00000000010a38ca (oninit) startup

обозначает вот это:
DrGonzo...что нить занимается созданием системного каталога. А точнее, хочет прочитать $INFORMIXDIR/etc/boot*.sql файл

2. Я точно не нарушу какое-нибудь лицензионное соглашение, натравив debugger на ядро oninit?

...

Рейтинг:

0 / 0

17.04.2015, 15:40

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38939407

victor16

Гость

АнатоЛойЯ точно не нарушу какое-нибудь лицензионное соглашение, натравив debugger на ядро oninit?
Более того, насколько я знаю, это рекомендуемый способ отладки С-функций. Еще рекомендуется создавать дополнительный виртуальный процессор для С-шных функций, но это для безопасности, можно отлаживать и на CPU.

...

Рейтинг:

0 / 0

17.04.2015, 15:48

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38941519

GVF112GVF

Гость

АнатоЛой,

> 2. Я точно не нарушу какое-нибудь лицензионное соглашение, натравив debugger на ядро oninit?

Хороший вопрос ... :-) ... если не вмешиваться в работу процесса (reverse engineering, patch and so on) ... смотри пункт 2)
Ведь - onstat (читает из памяти) или SQLIDEBUG ... вроде как не нарушают лицензионное соглашения и т.д. ... ;-)

Насколько мне известно :
----------------------------
Лицензиат не может 1) использовать, копировать, модифицировать или распространять Программу за исключением того, как явно разрешено в настоящем Соглашении, 2) осуществлять обратное ассемблирование, обратное компилирование или иное преобразование, либо вскрывать технологию Программы, кроме тех случаев, когда соответствующие действия прямо разрешены действующими законами, без возможности ограничения этих прав в условиях договора; 3) использовать какие-либо компоненты, файлы, модули, аудио-визуальное содержимое или связанные лицензионные материалы отдельно от Программы, 4) сублицензировать, предоставлять Программу на условиях аренды или лизинга ...

Более детально - http://www-03.ibm.com/software/sla/sladb.nsf/displaylis/95D8ACE31FE22B6285257D9000829EB4?OpenDocument

С уважением,
Вадим.

...

Рейтинг:

0 / 0

21.04.2015, 13:06

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38947954

Яковлев Павел

Гость

DrGonzoКонкретно данный стек говорит о том, что нить занимается созданием системного каталога. А точнее, хочет прочитать $INFORMIXDIR/etc/boot*.sql файл - запрос на чтение ушел к AIO VP, и нить "отдыхает" в ожидании данных.

Теперь, посмотрите на это:

AIO I/O queues:
q name/id len maxlen totalops dskread dskwrite dskcopy
aio 0 195 2315 34890959 9004434 2 0

Cтрочка для aio - текущая длина очереди 195, максимальная - 2315! Это дофига и явно указывает на проблему с AIO.

Если не совсем ясно, поясню. Для чанков у вас используется KAIO, что хорошо и правильно. Но при создании базы Informix читает некоторые файлы из $INFORMIXDIR/etc - чтение файлов происходит через AIO.

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

AUTO_AIOVPS у вас включено или нет?

lsof показывает что oninit лезет только в

etc/boot1110.sql
msg/en_us/0333/net.iem
msg/en_us/0333/netsrv.iem
msg/en_us/0333/olmsglog.iem
msg/en_us/0333/olserver.iem
tmp/online.con

AUTO_AIOVPS = 1

По onstat -g auth количество aio - 12 штук и все running

По iostat диск на котором живёт всё прочее куда может полезть Informix помимо чанков как-то почти и не задействован

Код: python

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.

sdd2                        2.00         0.00        16.00          0         16
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                       16.83         0.00        87.13          0         88
sdd2                        0.00         0.00         0.00          0          0
sdd2                        2.00         0.00        16.00          0         16
sdd2                       13.00        52.00        16.00         52         16
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        2.00         0.00        16.00          0         16
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        1.00        28.00         0.00         28          0
sdd2                        2.00         0.00        16.00          0         16
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        2.00         0.00        12.00          0         12
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        0.00         0.00         0.00          0          0
sdd2                        2.00         0.00        20.00          0         20
sdd2                        0.00         0.00         0.00          0          0

Так что чем заняты aio для меня пока загадка.

Логи бэкапятся на nfs через ontape, это не aio надеюсь ? А даже если и aio, то бэкапятся они "иногда" и при этом быстро.

...

Рейтинг:

0 / 0

28.04.2015, 22:59

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38947963

Яковлев Павел

Гость

А ткните носом в нормальную доку по xtrace, а то что-то поиск не помогает (или я переотдохнул и туплю)

...

Рейтинг:

0 / 0

28.04.2015, 23:04

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38951557

GVF112GVF

Гость

Яковлев ПавелА ткните носом в нормальную доку по xtrace, а то что-то поиск не помогает (или я переотдохнул и туплю)

Попробуй поискать на сайте IBM Support ...infromix xtrace:

http://www-01.ibm.com/support/docview.wss?uid=swg21413185
http://www-01.ibm.com/support/docview.wss?uid=swg21162482

Kind regards,
Vadim.

...

Рейтинг:

0 / 0

05.05.2015, 11:34

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38953079

Яковлев Павел

Гость

GVF112GVFЯковлев ПавелА ткните носом в нормальную доку по xtrace, а то что-то поиск не помогает (или я переотдохнул и туплю)

Попробуй поискать на сайте IBM Support ...infromix xtrace:

http://www-01.ibm.com/support/docview.wss?uid=swg21413185
http://www-01.ibm.com/support/docview.wss?uid=swg21162482

Спасибо, пробовал и "это" видел. Я несколько по другому трактую термин "нормальная документация".

...

Рейтинг:

0 / 0

06.05.2015, 21:48

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38953085

Яковлев Павел

Гость

Между тем тему можно закрывать без результата.

После "комплекса мероприятий" (мы же не сидели и не пялились на "это") проблема ушла.

В основном снижено количество одновременных коннектов (не путать с активно работающими коннектами).

Как побочный результат - коннекшен менеджер (oncmsm) окончательно выпилен, закидан ссаными тряпками и выкинут.

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

...

Рейтинг:

0 / 0

06.05.2015, 21:56

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38953265

яфшуеі

Гость

Если не секрет - каким образом и для чего вы использовали Connection Manager?

...

Рейтинг:

0 / 0

07.05.2015, 09:47

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38954090

Яковлев Павел

Гость

яфшуеіЕсли не секрет - каким образом и для чего вы использовали Connection Manager?

ну формально ни для чего - не пригодилось ни разу по "по прямому назначению" :)

Без отдельной лицензии можно держать HDR или RSS не выполняющий ни каких вычислительных задач, на который CM может вас прозрачно переключить в при отвале первичного сервера.

Informix зараза устойчив, так что данную функциональность можно реализовать на коленке хоть и с неким тормозом пока всё скрепит шестерёнками.

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

Делать так СМ имеет привычку при росте нагрузки раза в два от средней обычной (ну вот бывают моменты) или просто иногда в зависимости от фазы луны.

...

Рейтинг:

0 / 0

07.05.2015, 21:35

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38957368

cpr

Гость

Яковлев Павел,

А на последнии версии переходить не задумывались?

...

Рейтинг:

0 / 0

13.05.2015, 12:58

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38958061

Яковлев Павел

Гость

cprЯковлев Павел,

А на последнии версии переходить не задумывались?

Нет

...

Рейтинг:

0 / 0

13.05.2015, 21:50

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38958433

cpr

Гость

Яковлев ПавелcprЯковлев Павел,

А на последнии версии переходить не задумывались?

Нет

Зря, багов в 11.5 было много.
Хотя собственно у всех конечно свои обстоятельства, я тоже когда то не хотел с 7.31 на новую версии переходить. Не сам, конечно - так руководство считало. Теперь вот на 12.1 сидим и все проблемы решились.

...

Рейтинг:

0 / 0

14.05.2015, 11:40

| Ответить | Цитировать | Написать

CREATE DATABASE может занимать несколько минут

#38959256

Яковлев Павел

Гость

cprЯковлев Павелпропущено...

Нет

Зря, багов в 11.5 было много.
Хотя собственно у всех конечно свои обстоятельства, я тоже когда то не хотел с 7.31 на новую версии переходить. Не сам, конечно - так руководство считало. Теперь вот на 12.1 сидим и все проблемы решились.

Ну мне всё же немного виднее в моей ситуации ;)

...

Рейтинг:

0 / 0

14.05.2015, 22:12

| Ответить | Цитировать | Написать

52 сообщений из 52, показаны все 3 страниц

все

Форумы / Informix [игнор отключен] [закрыт для гостей] / CREATE DATABASE может занимать несколько минут

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=44&tid=1606877]:	0ms
get settings:	16ms
get forum list:	5ms
check forum access:	1ms
check topic access:	1ms
track hit:	35ms
get topic data:	3ms
get forum data:	1ms
get page messages:	1047ms
get tp. blocked users:	1ms
others:	5ms

total:	1115ms