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

2.0.29

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

Гость

Нов. | Гор. | Избр.

Действия ...

Доб. в избранное
Игнор. тему
Прикреп. тему
Пометить прочит. / непрочит.
Фильтр:
Сообщения автора темы
Сообщение содержит вложения
Сообщение содержит картинки
Сообщение содержит видеоклипы
Сообщение содержит аудиоклипы
Сообщение содержит картинки или видео 18+

Форумы / Informix [игнор отключен] [закрыт для гостей] / CREATE DATABASE может занимать несколько минут / 25 сообщений из 52, страница 1 из 3

все

09.04.2015, 22:47

#38932515

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

Гость

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

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

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

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

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

10.04.2015, 13:46

#38933047

victor16

Гость

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

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

...

Рейтинг:

0 / 0

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

10.04.2015, 21:37

#38933483

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

Гость

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

Уточнения
- забыл уточнить что "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:40

#38933486

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

Гость

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

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

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

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

...

Рейтинг:

0 / 0

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

10.04.2015, 22:04

#38933498

GVF112GVF

Гость

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

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

Такое впечатдение, что дисковая подсистема нагружена - 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:46

#38933537

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

Гость

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

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

Прикольно.

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

...

Рейтинг:

0 / 0

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

10.04.2015, 23:14

#38933546

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

Гость

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

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

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

11.04.2015, 10:58

#38933705

victor16

Гость

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

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

...

Рейтинг:

0 / 0

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

11.04.2015, 20:32

#38933932

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

Гость

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

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

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

...

Рейтинг:

0 / 0

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

11.04.2015, 20:42

#38933937

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

Гость

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

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

...

Рейтинг:

0 / 0

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

12.04.2015, 00:35

#38934006

victor16

Гость

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

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

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

...

Рейтинг:

0 / 0

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

12.04.2015, 12:37

#38934093

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

Гость

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

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

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

13.04.2015, 14:04

#38934882

GVF112GVF

Гость

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

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

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

Брасается в глаза общая нагруженность 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, 18:01

#38935212

victor16

Гость

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

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

Код: 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, 22:14

#38935326

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

Гость

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

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:28

#38935331

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

Гость

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

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

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

14.04.2015, 08:53

#38935510

DrGonzo

Участник

Откуда: ex-IBM
Сообщения: 176
Рейтинг: 0 / 0

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

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

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

При удалении по большому счету мы отмечаем свободное место в 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, 10:15

#38935590

АнатоЛой

Участник

Откуда: Киев, Украина
Сообщения: 2 910
Рейтинг: 0 / 0

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

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

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

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

...

Рейтинг:

0 / 0

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

14.04.2015, 13:00

#38935816

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

Гость

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

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

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

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

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

...

Рейтинг:

0 / 0

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

14.04.2015, 13:34

#38935868

АнатоЛой

Участник

Откуда: Киев, Украина
Сообщения: 2 910
Рейтинг: 0 / 0

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

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

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

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

...

Рейтинг:

0 / 0

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

14.04.2015, 15:25

#38936066

victor16

Гость

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

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, 19:30

#38936421

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

Гость

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

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:42

#38936434

victor16

Гость

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

Яковлев Павел
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:46

#38936438

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

Гость

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

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

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

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

...

Рейтинг:

0 / 0

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

14.04.2015, 20:02

#38936458

victor16

Гость

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

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

...

Рейтинг:

0 / 0

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

все

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

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

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

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

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

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

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

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

start [/forum/topic.php?fid=44&tablet=1&tid=1606877]:	0ms
get settings:	18ms
get forum list:	5ms
check forum access:	1ms
check topic access:	1ms
track hit:	37ms
get topic data:	3ms
get forum data:	1ms
get page messages:	652ms
get tp. blocked users:	1ms
others:	6ms

total:	725ms