перенос индексов в другие пространста альтер фрагментом / Informix

ReSQL.ru

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

Гость

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

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

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

Цитировать

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

Вложение:

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

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

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

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

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

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

25 сообщений из 50, страница 2 из 2

все

перенос индексов в другие пространста альтер фрагментом

#35735975

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

cpr
подскажите где посмотреть размер ключа?

Это размерность записи( записей) которые индексируются.

cpr
iostat показывает что с диска чтение происходит примерно 130 метров в секунду.

Подозреваю, что в Вашем случае основную массу составляет ввод вывод temp.
Параметр DS_TOTAL_MEMORY 6553600 позволит Вам уменьшить
обьем ввода вывода в temp минимум на порядок.

cpr
sar -ud это что?
у меня такой утилиты нет т.к. соляра. у меня iostat

вот нагуглил.

...

Рейтинг:

0 / 0

25.12.2008, 20:41

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

перенос индексов в другие пространста альтер фрагментом

#35735980

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

onstat-cpr
подскажите где посмотреть размер ключа?

Это размерность записи( записей) которые индексируются.

Прошу прощения , не записи а поля( полей в случае сложного индекса) ,
Видимо устал уже , домой пора.

...

Рейтинг:

0 / 0

25.12.2008, 20:43

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

перенос индексов в другие пространста альтер фрагментом

#35735983

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

И еще одни совет, когда закончите с постройкой индексов
поставьте
MAX_PDQPRIORITY 1
DS_TOTAL_MEMORY > 20 Mb,

Это позволит ускорить работу всяческий репортов, данные по которым
лежат в более чем 1 фрагменте.

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

...

Рейтинг:

0 / 0

25.12.2008, 20:59

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

перенос индексов в другие пространста альтер фрагментом

#35736348

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

onstat-Да забыл , переменную окружения проверить и поставить
PSORT_NPROCS =16,
и перестратовать базу.Эта переменная действует и из окружения клиента, на сессию действует.

...

Рейтинг:

0 / 0

26.12.2008, 08:22

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

перенос индексов в другие пространста альтер фрагментом

#35736549

cpr

Гость

подскажите плиз, это не ошибка?

давал команду onmod -M 10000000
в логе вылезло сообщение

mgm_reinit: memory 10000000 K < minimum (128 K) times queries (307200)

...

Рейтинг:

0 / 0

26.12.2008, 10:33

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

перенос индексов в другие пространста альтер фрагментом

#35736612

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

cprподскажите плиз, это не ошибка?

давал команду onmod -M 10000000
в логе вылезло сообщение

mgm_reinit: memory 10000000 K < minimum (128 K) times queries (307200)

Попробуйте уменьшить, сначала до 4095 Mb если не поможет, то до 2047.

...

Рейтинг:

0 / 0

26.12.2008, 10:59

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

перенос индексов в другие пространста альтер фрагментом

#35736615

cpr

Гость

onstat-
Подозреваю, что в Вашем случае основную массу составляет ввод вывод temp.

Это не так.

Вот вывод onstat -D
======================================================================
Chunks
address chk/dbs offset page Rd page Wr pathname
5513622a8 1 1 0 0 3046 /dev/md/rdsk/d66
552c2f108 2 2 0 0 107 /dev/md/rdsk/d50
552c2f450 5 4 0 0 26 /dev/md/rdsk/d52
552c2f568 6 4 0 0 4 /dev/md/rdsk/d53
552d20028 58 13 0 18 3 /dev/md/rdsk/d140
552d20488 62 13 0 0 1 /dev/md/rdsk/d144
552d205a0 63 13 0 0 1 /dev/md/rdsk/d145
552d206b8 64 13 0 0 1 /dev/md/rdsk/d146
552d207d0 65 13 0 0 1 /dev/md/rdsk/d147
552d208e8 66 13 0 0 1 /dev/md/rdsk/d148
552d20a00 67 13 0 0 1 /dev/md/rdsk/d149
552d20b18 68 3 0 1747098 1752677 /opt/informix/dbs/chunk_tempdbs_01.dbs
552d20f78 72 14 0 3104116 0 /dev/md/rdsk/d155
552d21090 73 14 0 8186000 0 /dev/md/rdsk/d156
552d211a8 74 14 0 11040284 0 /dev/md/rdsk/d157
552d212c0 75 14 0 13894568 0 /dev/md/rdsk/d158
552d213d8 76 14 0 16748852 0 /dev/md/rdsk/d159
552d214f0 77 14 0 19603136 0 /dev/md/rdsk/d160
552d21608 78 14 0 22457420 0 /dev/md/rdsk/d161
552d21720 79 14 0 25311704 0 /dev/md/rdsk/d162
552d21838 80 14 0 28165988 0 /dev/md/rdsk/d163
552d21950 81 14 0 31020272 0 /dev/md/rdsk/d164
552d21a68 82 14 0 33874556 0 /dev/md/rdsk/d165
552d21b80 83 14 0 36728840 0 /dev/md/rdsk/d166
552d21c98 84 14 0 39583124 0 /dev/md/rdsk/d167
552d21db0 85 14 0 42437408 0 /dev/md/rdsk/d168
552d21ec8 86 14 0 45291692 0 /dev/md/rdsk/d169
552d28028 87 14 0 50331716 0 /dev/md/rdsk/d170
552d33c98 171 19 0 3145827 0 /dev/md/rdsk/d256
552d33db0 172 19 0 8186000 0 /dev/md/rdsk/d257
552d33ec8 173 19 0 11040284 0 /dev/md/rdsk/d258
552d34028 174 19 0 13894568 0 /dev/md/rdsk/d259
552d34140 175 19 0 16748852 0 /dev/md/rdsk/d260
552d34258 176 19 0 19603136 0 /dev/md/rdsk/d261
552d34370 177 19 0 22457420 0 /dev/md/rdsk/d262
552d34488 178 19 0 25311704 0 /dev/md/rdsk/d263
552d345a0 179 19 0 28165988 0 /dev/md/rdsk/d264
552d346b8 180 19 0 31020272 0 /dev/md/rdsk/d265
552d347d0 181 19 0 33874556 0 /dev/md/rdsk/d266
552d348e8 182 19 0 36728840 0 /dev/md/rdsk/d267
552d34a00 183 19 0 39583124 0 /dev/md/rdsk/d268
552d34b18 184 19 0 42437408 0 /dev/md/rdsk/d269
552d34c30 185 19 0 45291692 0 /dev/md/rdsk/d270
552d34d48 186 19 0 50331716 0 /dev/md/rdsk/d271
552d3f838 254 23 0 1769638 1775224 /opt/informix/dbs/chunk_tempdbs1_01.dbs
552d3f950 255 24 0 1635322 1640891 /opt/informix/dbs/chunk_tempdbs2_01.dbs
552d3fa68 256 25 0 1742758 1748340 /opt/informix/dbs/chunk_tempdbs3_01.dbs
552d44028 261 26 0 0 161 /opt/informix/dbs/chunk_l_logdbs_02.dbs
552d445a0 266 27 0 3000249 0 /dev/md/rdsk/d339
552d446b8 267 27 0 3000248 0 /dev/md/rdsk/d340
552d447d0 268 27 0 3000248 0 /dev/md/rdsk/d341
552d448e8 269 27 0 3000248 0 /dev/md/rdsk/d342
552d44a00 270 27 0 3000248 0 /dev/md/rdsk/d343
552d44b18 271 27 0 3000248 0 /dev/md/rdsk/d344
552d44c30 272 27 0 3000248 0 /dev/md/rdsk/d345
552d44d48 273 27 0 3000248 0 /dev/md/rdsk/d346
552d44e60 274 27 0 3000248 0 /dev/md/rdsk/d347
552d44f78 275 27 0 3000248 0 /dev/md/rdsk/d348
552d45090 276 27 0 622275 0 /dev/md/rdsk/d349
552d45720 282 28 0 3000249 0 /dev/md/rdsk/d355
552d45838 283 28 0 3000248 0 /dev/md/rdsk/d356
552d45950 284 28 0 3000248 0 /dev/md/rdsk/d357
552d45a68 285 28 0 3000248 0 /dev/md/rdsk/d358
552d45b80 286 28 0 3000248 0 /dev/md/rdsk/d359
552d45c98 287 28 0 3000248 0 /dev/md/rdsk/d360
552d45db0 288 28 0 3000248 0 /dev/md/rdsk/d361
552d45ec8 289 28 0 3000248 0 /dev/md/rdsk/d362
552d46028 290 28 0 1920944 0 /dev/md/rdsk/d363
552d468e8 298 13 0 0 1 /dev/md/rdsk/d371
552d46a00 299 13 0 0 1 /dev/md/rdsk/d372
552d46b18 300 13 0 0 1 /dev/md/rdsk/d373
552d46c30 301 13 0 0 1 /dev/md/rdsk/d374
552d46d48 302 13 0 0 1 /dev/md/rdsk/d375
552d46e60 303 13 0 0 1 /dev/md/rdsk/d376
552d59b80 373 33 0 9 51922 /dev/md/rdsk/d446
552d59c98 374 33 0 119 475757 /dev/md/rdsk/d447
392 active, 2047 maximum
================================================================

пространства 14, 19 это фрагменты по 16 чанков, заполненные полностью.
пространства 27, 29 это фрагмены заполненные примерно напополоам
пространства 3, 23-25 - темповые.
основной ввод вывод это чтение полных фрагментов. наблюдение iostat это полностью подтвердило.

За подсказки спасибо, все варианты попробую. Но мне кажется причина все же в другом. Очень похоже что количество чанков с данными играет основную роль т.к. фрагменты имеющие 16 чанков с данными сканились намного больше, чем те в которых данных меньше.
Надо попробовать все варианты. Если подсказки по тюнингу PDQ не помогут надо будет пробовать таблицу перегружать в большее количество фрагментов и переиндексировать.

...

Рейтинг:

0 / 0

26.12.2008, 11:00

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

перенос индексов в другие пространста альтер фрагментом

#35736707

vasilis

Участник

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

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

Рейтинг: 0 / 0

cprподскажите плиз, это не ошибка?
давал команду onmod -M 10000000
в логе вылезло сообщение
mgm_reinit: memory 10000000 K < minimum (128 K) times queries (307200)
Это потому, что у вас неправильно были настроены и другие параметры PDQ, в частности
DS_MAX_QUERIES = 307200 а это абсолютно неправильно (разве такое кол-во PDQ запросов потянет какая-то система ?). Смысл в том, чтобы на каждый PDQ запрос выделить одномоментно хорошую порцию памяти, а не просить 200 раз по 128К.
Т.е. минимальный размер порции определяется, как DS_TOTAL_MEMORY разделить на DS_MAX_QUERIES.
В вашем случае необходимо установить в onconfig (или через onmode)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES 4 # Maximum number of decision support queries
DS_TOTAL_MEMORY 128000 (или больше, если есть доступная память) # Decision support memory (Kbytes)
DS_MAX_SCANS 16 # Maximum number of decision support scans

и установить затем при выполнении запроса на постройку индекса
set pdqpriority 100 (переменной окружения или SQL-оператором).
и не забыть потом выключить.

Если все правильно включите, то, поддержу onstat- - "Думаю результаты Вас очень удивят ( в хорошем смысле)."
И , опять таки, почитайте на тему PDQ-запросов (они же DS Query) - для вашей системы с большими объемами грамотное применение может дать иногда очень хорошие результаты (но применять очень осторожно, вдумчиво, с пониманием где это может помочь, а где навредить - особенно при оптимизации планов процедур :)).

...

Рейтинг:

0 / 0

26.12.2008, 11:35

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

перенос индексов в другие пространста альтер фрагментом

#35736726

cpr

Гость

vasilis,

спасибо, будем попробовать.

...

Рейтинг:

0 / 0

26.12.2008, 11:41

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

перенос индексов в другие пространста альтер фрагментом

#35737780

cpr

Гость

Всем спасиобо за наводки!

Окончательно удалось победить сырость после того как были определены еще переменные окружения

PDQPRIORITY=100
PSORT_DBTEMP= каталог на файловой системе

скорость чтения с дискового массива возросла в пике до почти 200 метров в секунду,
а загрузка цпу выростала в пике до 64% т.е. практически до 10 ядер из 16-и имеющихся.

...

Рейтинг:

0 / 0

26.12.2008, 18:22

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

перенос индексов в другие пространста альтер фрагментом

#35737816

АнатоЛой

Участник

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

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

Рейтинг: 0 / 0

Ну и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

...

Рейтинг:

0 / 0

26.12.2008, 18:54

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

перенос индексов в другие пространста альтер фрагментом

#35737885

cpr

Гость

АнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

с этой таблицей еще не закончил экспериментировать, но похоже, что большое количество чанков порождает проблемы. По этой таблице отпишу позже.

Сегодня проводил такой эксперимент.
Взял таблицу (которую собираюсь фрагментированть на каникулах) размер 23 гига с индексами, примерно 78 млн записей. Загрузил ее в 6 фрагментов.
До настройки PDQ один индекс строился в районе часа, после настройки все 11 индексов были построены за 34 минуты. Так что PDQ работает как положено.

С моей самой большой таблицей не так все хорошо.
Пока наблюдаю следующее:
при запуске create index 4 фрагмента сканятся одновременно в 4 руки.
Незаполненные 2 фрагмента были просканены один раз. Заполненные 2 фрагмента (16 чанков по 2 гига) сканятся очень долго с повторным чтением чанков. Такое ощущение, что есть какая то магическая граница, количество чанков в фрагменте больше которой приводит к очень длительному проходу фрагмента. Буду экспериментировать дальше, проблема только одна - потртребуется очень много времени на перевыгрузку большой таблицы в большее количество фрагментов.

...

Рейтинг:

0 / 0

26.12.2008, 20:21

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

перенос индексов в другие пространста альтер фрагментом

#35737913

cpr

Гость

АнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

там где было 256 минут стало 56 минут. Тоже неплохо.

...

Рейтинг:

0 / 0

26.12.2008, 21:02

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

перенос индексов в другие пространста альтер фрагментом

#35739193

cpr

Гость

cprАнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

там где было 256 минут стало 56 минут. Тоже неплохо.

Как я и предполагал, после загрузки таблицы в 10 фрагментов (в каждом фрагменте получилось 5 с копейками чанков по 2 гига) один индекс построился за 10минут 34 секунды.
Итого операция ускорилась в 23 раза :-)

...

Рейтинг:

0 / 0

29.12.2008, 10:05

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

перенос индексов в другие пространста альтер фрагментом

#35739394

cpr

Гость

cpr,

И все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Данные естественно одни и те же.
Вопрос сугубо практический т.к. таблица очень активно растет.
До сих пор у меня была простая стратегия: по мере заполнения текущих фрагментов подсоединять по два максимального для 7.31 размера т.е. по 32 Гига.

...

Рейтинг:

0 / 0

29.12.2008, 11:46

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

перенос индексов в другие пространста альтер фрагментом

#35739659

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

cprcpr,
Вопрос сугубо практический т.к. таблица очень активно растет.
До сих пор у меня была простая стратегия: по мере заполнения текущих фрагментов подсоединять по два максимального для 7.31 размера т.е. по 32 Гига.

Из практических соображений, если это не система 24/7/365, и ее можно безболезненно
останавливать на не некоторый период, то практика показывает, что фрагмент
должен содержать тот объем который Вам потом нужно будет удалять.
То есть например если история в системе расчитана на 3 года, в фрагменты создаются например поквартально.
По прошествии 3 лет , система останавливается 1 раз в квартал, и самому первому кварталу
делается alter fragnent detach, Если все индексы индексы фрагментированы
также как и таблица, то это происходить практически моментально, от секунды до минуты.
Тут возникают проблемы с уникальными индексами и PK , в большенстве случаев их
нельзя фрагментировать также как и таблицу, эти индексы и все на них завязанные перед alter fragment удаляются и после отключения строятся заново.
Если условие фрагментации индекса не соответствует условию фргментации таблицы, то detach
работает достаточно медленно.

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

Что касается скорости постройки индексов , то фрагментов должно быть больше чем CPUVP.

...

Рейтинг:

0 / 0

29.12.2008, 13:23

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

перенос индексов в другие пространста альтер фрагментом

#35739973

vasilis

Участник

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

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

Рейтинг: 0 / 0

cprИ все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Думаю, что основное ускорение получено за счет параметров PDQ и увеличения параллельности при основных времяпотребляющих операций (сканирование и сортировка).

...

Рейтинг:

0 / 0

29.12.2008, 15:16

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

перенос индексов в другие пространста альтер фрагментом

#35739974

vasilis

Участник

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

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

Рейтинг: 0 / 0

onstat-Что касается скорости постройки индексов , то фрагментов должно быть больше чем CPUVP.
Зачем ? И на сколько больше?

...

Рейтинг:

0 / 0

29.12.2008, 15:17

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

перенос индексов в другие пространста альтер фрагментом

#35740032

cpr

Гость

onstat-,

система практически 24x7x365

таблица фрагментирована по round robin. детачить фрагменты в архив мне не грозит.

...

Рейтинг:

0 / 0

29.12.2008, 15:44

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

перенос индексов в другие пространста альтер фрагментом

#35740162

cpr

Гость

vasiliscprИ все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Думаю, что основное ускорение получено за счет параметров PDQ и увеличения параллельности при основных времяпотребляющих операций (сканирование и сортировка).

Основное время это именно сканирование, тут у меня вопросов нет.
В том почему в больших фрагментах сканирование происходло много кратно. Так первый чанк сканился один раз, второй чанк два раза, третий -три и т.д. Таким образом два больших фрагмента сканились многократно, что и составило основное время.
При большем количестве фрагменто и соответственно меньших их размерах чанки сканились в каждом фрагменте последовательно один раз. Все фрагменты сканились параллельно, суммарное количество чтений намного меньше.
Вопрос именно почему так происходит, действительно ли есть связь с количеством чанков в фрагменте?

...

Рейтинг:

0 / 0

29.12.2008, 16:30

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

перенос индексов в другие пространста альтер фрагментом

#35740170

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

vasilisonstat-Что касается скорости постройки индексов , то фрагментов должно быть больше чем CPUVP.
Зачем ? И на сколько больше?

Моя практика так показывает
и здесь написано:
http://docs.rinet.ru/InforSmes/ch19/ch19.htm
автор
Informix starts one scan thread for every fragment.

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

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

Что касается пратиций внутри фрагментов, не знаю, возможно одни скан пускается на каждую партицию, или даже на екстент. В топике версия 7.31 там партиций точно нет.

з.ы. Я не претендую на абсолютную правоту.

...

Рейтинг:

0 / 0

29.12.2008, 16:34

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

перенос индексов в другие пространста альтер фрагментом

#35740401

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

cpronstat-,

система практически 24x7x365

таблица фрагментирована по round robin. детачить фрагменты в архив мне не грозит.

Досотаточно хорошо показала себя следующая практика.

Таблица и индексы делятся на фрагметы по условию c mod
по дням или месяцам.

http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.ddi.doc/ddi92.htm
автор
You can use the MOD function in a FRAGMENT BY EXPRESSION clause to map each row in a table to a set of integers (hash values). The database server uses these values to determine in which fragment it will store a given row. The following example shows how you might use the MOD function in an expression-based distribution scheme:

FRAGMENT BY EXPRESSION
MOD(id_num, 3) = 0 IN dbsp1,
MOD(id_num, 3) = 1 IN dbsp2,
MOD(id_num, 3) = 2 IN dbsp3

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

Получается практически тот же round-robin только вручную фрагментирован по периоду времени.
При этом удаление практически не мешает текущей работе по дисковому вводу выводу.

Едиственный недостаток этого подхода, тяжело исключить сканирование всех фрагментов, если данные лежат в извесном фрагменте.
Что бы этого добиться в запрос нужно включать условие в соответствии с результатом mod.

...

Рейтинг:

0 / 0

29.12.2008, 18:02

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

перенос индексов в другие пространста альтер фрагментом

#35741220

vasilis

Участник

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

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

Рейтинг: 0 / 0

cprvasiliscprИ все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Думаю, что основное ускорение получено за счет параметров PDQ и увеличения параллельности при основных времяпотребляющих операций (сканирование и сортировка).

Основное время это именно сканирование, тут у меня вопросов нет.
В том почему в больших фрагментах сканирование происходло много кратно. Так первый чанк сканился один раз, второй чанк два раза, третий -три и т.д. Таким образом два больших фрагмента сканились многократно, что и составило основное время.
При большем количестве фрагменто и соответственно меньших их размерах чанки сканились в каждом фрагменте последовательно один раз. Все фрагменты сканились параллельно, суммарное количество чтений намного меньше.
Вопрос именно почему так происходит, действительно ли есть связь с количеством чанков в фрагменте?
Думаю, да. Связь есть, но если уточнить, то не с кол-вом чанков, а с общим объемом информации в фрагменте. Ведь сканируя фрагмент считанную информацию надо куда то положить. а затем еще и отсортировать, а потом еще и отсортированные куски слить в одно целое. Поетому за один раз данный объем работы было трудно выполнить. Пришлось делать в несколько проходов. А почему некоторые чанки многократно читались ? Думаю, что еще причиной был и round robin (или недостаток алгоритма :)

...

Рейтинг:

0 / 0

30.12.2008, 12:11

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

перенос индексов в другие пространста альтер фрагментом

#35741264

vasilis

Участник

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

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

Рейтинг: 0 / 0

onstat-vasilisonstat-Что касается скорости постройки индексов , то фрагментов должно быть больше чем CPUVP.
Зачем ? И на сколько больше?
Моя практика так показывает и здесь написано:
http://docs.rinet.ru/InforSmes/ch19/ch19.htm
автор
Informix starts one scan thread for every fragment.

Если фрагментов меньше, то процессоры могут оказаться недогружены.
Этот топик тоже на практике показывает , что если теже данные разложить по большему количеству фрагментов, то скорость постройки индексов увеличивается.
У onstat- было 16 CPUVP поэтому здесь все понятно. Фрагментов все равно меньше , чем CPUVP.
Поэтому ответа на свой вопрос "зачем фрагментов должно быть больше, чем CPUVP ?" я как бы и не увидел. Понятно, что речь идет о тех фрагментах, которые могут читаться одновременно (параллельно).
Для старых процов почти всегда работало правило (и это рекомендовалось в доках), что CPUVP = кол-во физических процессоров минус один. Соответственно, и кол-во фрагментов логично делать не более этого числа. Для более производительных систем (процов и каналов вв/выв) и для OLTP я сам уже давно рекомендовал устанавливать CPUVP из расчета 2 CPUVP на один физический проц.
Но не для DSS/OLAP систем - там будет тяжеловато (но, как обычно, зависит от местных условий).
И если сканировать фрагменты в двойном кол-ве (т.е. по два скана на VP)) я еще могу понять, то ведь потом с этими данными что-то еще надо и делать - сортировать, сливать, фильтровать - и вот тогда, мне кажется, физическим процам будет уже очень трудно, т.е. процессы постообработки, скорее всего, будут идти последовательно.

onstat-На сколько больше , тяжело сказать , нужно смотреть на сбалансированность ввода вывода и нагрузки на CPU.
Что касается пратиций внутри фрагментов, не знаю, возможно одни скан пускается на каждую партицию, или даже на екстент. В топике версия 7.31 там партиций точно нет.
раньше был один скан на фрагмент (даже не на чанк).
onstat-з.ы. Я не претендую на абсолютную правоту.
да я тоже. Просто высказал сввою логику и свое понимание.

...

Рейтинг:

0 / 0

30.12.2008, 12:34

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

перенос индексов в другие пространста альтер фрагментом

#35741386

cpr

Гость

vasilis
Думаю, да. Связь есть, но если уточнить, то не с кол-вом чанков, а с общим объемом информации в фрагменте. Ведь сканируя фрагмент считанную информацию надо куда то положить. а затем еще и отсортировать, а потом еще и отсортированные куски слить в одно целое. Поетому за один раз данный объем работы было трудно выполнить. Пришлось делать в несколько проходов. А почему некоторые чанки многократно читались ? Думаю, что еще причиной был и round robin (или недостаток алгоритма :)

Все логично, знать бы это магическое число чанков или записей :-)

Что касается round robin, то думаю что дело не в нем.

...

Рейтинг:

0 / 0

30.12.2008, 13:21

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

25 сообщений из 50, страница 2 из 2

все

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

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

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

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

start [/forum/topic.php?fid=44&msg=35735980&tid=1607923]:	0ms
get settings:	10ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	61ms
get topic data:	11ms
get forum data:	3ms
get page messages:	56ms
get tp. blocked users:	1ms
others:	342ms

total:	506ms