|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Здраствуйте товарищи ! Завелся тут у меня вынос мозга разобраться с которым пока не получается. 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 секунды. Общая производительность системы и нагрузки - без изменений. Параллельно базы не создаются. Что это заразе надо ? Что держит создание базы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2015, 22:47 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев ПавелЧто держит создание базы ? А что рассказывает onstat об этой сессии ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 13:46 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Уточнения - забыл уточнить что "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 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 21:37 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Собственно костыль уже с утра работает - при нужде в новой базе она не создаётся, а получается переименованием одной из заранее созданых, коих запас регулярно пополняется. Но это трэш, угар и содомия. Надо гадость удушить. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 21:40 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев Павел, Такое впечатдение, что дисковая подсистема нагружена - 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 С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 22:04 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Нашёл транзакцию этой сессии в логах - технически она длится до сих пор, хотя всё уже отработало и база доступна. Прикольно. Или я пропустил COMMIT в логах. Хотя grep навряд ли такой кривой :) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 22:46 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 23:14 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
[quot Яковлев Павел]GVF112GVFТСтатистика в файле. Неплохо было бы онулить статистику onstat -z непосредственно перед выполнением SQL ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2015, 10:58 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
C обнулённой статистикой. Загрузка обычная + шло удаление ~500К записей с блобами из одной таблицы (порциями по 5К) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2015, 20:32 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Физический лог и логические логи из рута разумеется вынесены и тмп отдельно нарезаны ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2015, 20:42 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев ПавелC обнулённой статистикой Стоит обратить внимание на высокие цифры maxlen из onstat -ioq. Для KAIO не желательно превышать 32. Яковлев Павелшло удаление ~500К записей с блобами из одной таблицы (порциями по 5К) Вопрос: блобы журналируются? Что происходит с контрольной точкой, особенно в момент выполнения CREATE DATABASE (onstat -g ckp, onstat -F) Как насчет фрагментированности пространств, где создаются базы данных ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2015, 00:35 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2015, 12:37 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев Павел, Спасибо за предоставленную информацию. Брасается в глаза общая нагруженность 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 ...??? С уважанием, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2015, 14:04 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев ПавелСостояние корневого пространства и пространства данный - без изменений по сравнении с тем то описано в начале - не фрагментировано. Проверьте общее количество экстентов по каждому пространству: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2015, 18:01 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
victor16Яковлев ПавелСостояние корневого пространства и пространства данный - без изменений по сравнении с тем то описано в начале - не фрагментировано. Проверьте общее количество экстентов по каждому пространству: Ничего интересного - 38483 прекрасно согласуется с количеством баз уже созданых в 8 с учётом что таблица или индекс это один экстент и что на пустую таблицу экстент не выделяется. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2015, 22:14 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
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 эксклюзивно лочится что ли ? А при переименовании нет ? Странно это. А при удлении ? Действий явно требуется больше чем при создании - таблицы и индексы снести надо и место освободить. И ведь шустро так успевает... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2015, 22:28 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
> А при удлении ? Действий явно требуется больше чем при создании Действий больше при создании. При создании базы создается набор таблиц системного каталога с индексами и тд. Для всего этого надо искать и выделять место. Выделение экстентов записывается в журнал, даже если создаваемая база не логируется. Если база с логом, то создание сис. каталога попадет в журнал в дополнение ко всему остальному. При удалении по большому счету мы отмечаем свободное место в 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 #> ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 08:53 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев ПавелЕсли это блокировки, то они какие-то весёлые - напомню что переименование или удаление базы - моментом. Заполнение новой базы таблицами и индексами - моментом При создании что, весь sysdatabases эксклюзивно лочится что ли ? А при переименовании нет ? Странно это. Предположение про блокировку sysdatabases просто проверяется на практике. 1. Создали БД №1. 2. Запустили создание БД №2. 3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3. Имхо - дело не в нём... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 10:15 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
АнатоЛойЯковлев ПавелЕсли это блокировки, то они какие-то весёлые - напомню что переименование или удаление базы - моментом. Заполнение новой базы таблицами и индексами - моментом При создании что, весь sysdatabases эксклюзивно лочится что ли ? А при переименовании нет ? Странно это. Предположение про блокировку sysdatabases просто проверяется на практике. 1. Создали БД №1. 2. Запустили создание БД №2. 3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3. Имхо - дело не в нём... На практике, с такими лагами как у меня, сложно определить когда пункт 2 схемы дорвётся до таблицы и залочит её (или её страницу - там страничная блокировка) . Ну вот запустил я создание-2 и ? Оно может минуту висть, может две. Когда именно запускать п3 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 13:00 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев ПавелАнатоЛойпропущено... Предположение про блокировку sysdatabases просто проверяется на практике. 1. Создали БД №1. 2. Запустили создание БД №2. 3. Пока длится п.2, запустили переименование БД №1 в какой-нить БД №3. Имхо - дело не в нём... На практике, с такими лагами как у меня, сложно определить когда пункт 2 схемы дорвётся до таблицы и залочит её (или её страницу - там страничная блокировка) . Ну вот запустил я создание-2 и ? Оно может минуту висть, может две. Когда именно запускать п3 ? П.3. можешь сразу запустить в цикле даже до запуска п.2. И смотреть, какие отклонения у времени переименования до, во время и после п.2 . Павел, это больше мозги размять... А-ля мозговой штурм. Моя идея может на самом деле и выеденного яйца (после Пасхи-то :)) не стоить... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 13:34 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
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 Редко когда встретишь столько умных мыслей в одном сообщении. Я записал в свой блокнот на всякий случай. ЗЫ:) Можно пойти дальше и подключить процесс к дебаггеру для его дальнейшего исследования... Но на продакшене я бы не рискнул. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 15:25 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
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.
onstat -g stk Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
pstack Код: python 1. 2. 3. 4. 5.
onmode -X дало пусто. у него в хелпе даже ключа такого нет. Спит оно пока ввода-вывода ждёт. Вопрос чего именно ей так от ввода-вывода надо - остальные задачи работают и не жалуются... DrGonzo > А при удлении ? Действий явно требуется больше чем при создании Действий больше при создании. При создании базы создается набор таблиц системного каталога с индексами и тд. Для всего этого надо искать и выделять место. Выделение экстентов записывается в журнал, даже если создаваемая база не логируется. Если база с логом, то создание сис. каталога попадет в журнал в дополнение ко всему остальному. При удалении по большому счету мы отмечаем свободное место в chunk free list page, обнуляются страницы tblspace tblspace (сами страницы таблиц и индексов на диске не меняются), потом удаляется запись из sysmaster:sysdatabases. Тоже логично. Ещё что весело - в след за созданием базы идёт создание в ней пользовательских таблиц и индексов. И это всё то же требует сравнимых действий как по составу так и по количеству И даже хуже - база заполняется системными таблицами изнутри одного процесса, а на создание каждой пользовательской таблицы, индекса, констрейнта у меня отдельный вызов sql. И ещё хуже - создание пользовательских объектов требует заполнения системных таблиц. Но шаг создания пользовательских объектов проскакивает моментом. И даже в том же дбспейсе - системные таблицы базы они ж в её родном дбспейсе, не в корневом - т.е. экстенты ищутся там же. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 19:30 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
Яковлев Павел onstat -g stk Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Судя по стеку, сессия - не писатель, сессия - читатель .. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 19:42 |
|
CREATE DATABASE может занимать несколько минут
|
|||
---|---|---|---|
#18+
victor16Судя по стеку, сессия - не писатель, сессия - читатель .. Что в автолавку загрузили - тем и торгуем :) Боюсь уже фантазировать что она такое у куда полезла читать что встала колом. Магнитной ленты в системе нет :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2015, 19:46 |
|
|
start [/forum/topic.php?fid=44&msg=38933047&tid=1606877]: |
0ms |
get settings: |
26ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
632ms |
get tp. blocked users: |
1ms |
others: | 286ms |
total: | 1015ms |
0 / 0 |