|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Andron АлексанRA_PAGES оставил бы 64, RA_THRESHOLD - в 60 Почему так мало? Думаю что можно параметры RA на время импорта (для быстрого построения индексов на больших таблицах) ставить еще выше, поскольку данные лежат рядом, эффективность Read Ahead должна быть очень высокой. Предлагаю увеличить параметры RA согласно документации: Use the following formulas to calculate values for RA_PAGES and RA_THRESHOLD: RA_PAGES = ((BUFFERS * bp_fract) / (2 * large_queries)) + 2 RA_THRESHOLD = ((BUFFERS * bp_fract) / (2 * large_queries)) - 2 bp_fract is the portion of data buffers to use for large scans that require read-ahead. If you want to allow large scans to take up to 75 percent of buffers, bp_fract would be 0.75. large_queries is the number of concurrent queries that require read-ahead that you intend to support. Т.е. например RA_PAGES = 10000 и RA_THRESHOLD = 9998 это далеко не предел для построения индексов и статистики по большим таблицам. попробую сегодня ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:05 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
vasilis Журавлев Денис SkSergeyAА основное время уходит на вставку данных, есть несколько таблиц по 10 млн. записей и соответственно на построение индексов по этим табличкам.в принципе должно вставляться 200-500 тыс в минуту, т.е. 10млн это 50-20 минут. Если имеется ввиду только чистая вставка строк в таблицу без индексов, то вполне нормальна и скорость в 2 млн. строк в минуту, по крайней мере я это видел пару лет назад на сервере OS : Win2003+SP1 Informix: 10.0.FC4 CPU : 2 x Xeon 3,6 GHz Memory : 5GB RAM Disk : RAID 10 (4x70GB SCSI 15000) как добиться такой скорости? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:07 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
SkSergeyA vasilis - обратить внимание на параметры локализации исходного и целевого серверов - выливать данные dbexport-ом сразу на целевой сервер (чтобы потом не копировать с сервера на сервер и не перекодировать из вин в юникс формат) - разделить SQL на отдельные части - проверить названия ДБ-пространств и размеры экстентов, а также возможные ссылки на другие таблицы и БД - отключить первичные индексы на больших таблицах - заливать данные в несколько потоков параллельно (или хотя бы большие таблицы) т.е. можно запустить несколько dbimport или это можно делать из нескольких sqleditor ? "несколько dbimport" запускать нельзя. И sqleditor тут не нужен (и откуда такая любовь к GUI ?) Просто последний раз предлагаю ВНИМАТЕЛЬНО и ДО КОНЦА прочитать рекомендованные ссылки с опытом людей, которые эти задачи уже решали. Это сэкономит вам намного больше времени, которое вы потратите на чтение. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:14 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
AndronТ.е. например RA_PAGES = 10000 и RA_THRESHOLD = 9998 это далеко не предел для построения индексов и статистики по большим таблицам. Почему то именно такие значения вызывают у меня глубокий пессимизм. Возможно, я неправ и что то не понимаю в современной архитектуре Информикс. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:18 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
SkSergeyA vasilis Журавлев Денис SkSergeyAА основное время уходит на вставку данных, есть несколько таблиц по 10 млн. записей и соответственно на построение индексов по этим табличкам.в принципе должно вставляться 200-500 тыс в минуту, т.е. 10млн это 50-20 минут. Если имеется ввиду только чистая вставка строк в таблицу без индексов, то вполне нормальна и скорость в 2 млн. строк в минуту, по крайней мере я это видел пару лет назад на сервере OS : Win2003+SP1 Informix: 10.0.FC4 CPU : 2 x Xeon 3,6 GHz Memory : 5GB RAM Disk : RAID 10 (4x70GB SCSI 15000) как добиться такой скорости? Только упорным трудом :) А я не знаю, в особенности на вашем сервере и в ваших условиях. Вот еще нашел результаты для Линукса Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
- в каждую из 4-х таблиц грузилось по 1 млн.строк - таблицы от 3 до 4 полей, обязательно есть varchar(80), date, decimal - уникальные строки генерируются и вставляются процедурой блоками (возможно поэтому высокая скорость) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:37 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
vasilis AndronТ.е. например RA_PAGES = 10000 и RA_THRESHOLD = 9998 это далеко не предел для построения индексов и статистики по большим таблицам. Почему то именно такие значения вызывают у меня глубокий пессимизм. Возможно, я неправ и что то не понимаю в современной архитектуре Информикс. Я бы стал рассматривать такие значения, если бы загружались террабайты, и вопрос был бы в секундах. Кроме того, я не понимаю, как балансировать размер пула буферов, куда считываются данные, и размер виртуального сегмента, в котором будут строиться индексы. Но тесты могут меня убедить :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 14:56 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Ну что-ж! Всем спасибо за участие! Начинаю переваривать полученную информацию и готовиться к бессонной ночи ! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 15:35 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
SkSergeyA vasilis а также сделайте, по возможности, временные пространства на отдельных дисках - существенно поможет при индексировании. Это невозможно :-(( +1 к vasilis. ...а через "невозможно"? В сервере наверняка есть SATA-канал для DVD-ROM'a. К нему можно _временно_ подрубить шустренький винт. На нем сделать чанки под половину темповых дбспейсов. Возможно (смотрим по счетчикам onstat -D после тестовой загрузки), и PHYS_DBS туда же переносим (тоже временно, на период загрузки, переселяем с пом. "onparams -p"). ИМХО, самый действенный метод в вашей ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 18:27 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
vasilis AndronТ.е. например RA_PAGES = 10000 и RA_THRESHOLD = 9998 это далеко не предел для построения индексов и статистики по большим таблицам. Почему то именно такие значения вызывают у меня глубокий пессимизм. Возможно, я неправ и что то не понимаю в современной архитектуре Информикс. Я уж не помню, но кажется RA_PAGES обрубалось до 64 или даже до 32. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 21:53 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
SkSergeyAДоброе время суток ! Имею поставленную задачу - максимально быстро (ночь) перенести данные между двумя серверами. Сервер1 - Windows2000AS,2x2Intel Xeon, 3 Gb-ОЗУ, RAID-5, Informix IDS 10.00.TC7, ~объем данных 100 Гб Сервер2 - CentOS5.1, 2x4 IntelXeon, 8 Gb, RAID-10, Informix IDS 11.50.FC1 А зачем что-то выгружать и загружать назад ? Реальный путь провереный на практике у нас. Версии, правда, были одинаковые (но не думаю, что 10.0->11.5 будет проблемой) и операционки тоже (тут возможно хуже) На принимающей машине настраивается Информикс с _такими_же_ по размерам и именам (мммм у вас с виндов на линукс, тогда скорее всего увы) dbscpace и структурой чанков. Принимающий информикс гасится. Чанки экспортируются (nfs,nb,gnb... ) на отдающую машину и подключаются там как _миррорные_ Всё. Мирорные чанки заполняются данными без прекращений работы отдающей системой. После чего она гасится и поднимается принимающая. Время простоя - минимальное. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2008, 22:44 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Яковлев ПавелБлин совсем не мой день - три неполных поста Мои извинения ;( SkSergeyAДоброе время суток ! Имею поставленную задачу - максимально быстро (ночь) перенести данные между двумя серверами. Сервер1 - Windows2000AS,2x2Intel Xeon, 3 Gb-ОЗУ, RAID-5, Informix IDS 10.00.TC7, ~объем данных 100 Гб Сервер2 - CentOS5.1, 2x4 IntelXeon, 8 Gb, RAID-10, Informix IDS 11.50.FC1 А зачем что-то выгружать и загружать назад ? Реальный путь провереный на практике у нас. Версии, правда, были одинаковые (но не думаю, что 10.0->11.5 будет проблемой) и операционки тоже (тут возможно хуже) На принимающей машине настраивается Информикс с _такими_же_ по размерам и именам (мммм у вас с виндов на линукс, тогда скорее всего увы) dbscpace и структурой чанков. Принимающий информикс гасится. Чанки экспортируются (nfs,nb,gnb... ) на отдающую машину и подключаются там как _миррорные_ Всё. Мирорные чанки заполняются данными без прекращений работы отдающей системой. После чего она гасится и поднимается принимающая. Время простоя - минимальное. Вы таким образом предлагаете перетаскивать данные между версиями 10 TC и 11.5 FC ? :-))) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2008, 00:25 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
SkSergeyAДоброе время суток ! Имею поставленную задачу - максимально быстро (ночь) перенести данные между двумя серверами. Сервер1 - Windows2000AS,2x2Intel Xeon, 3 Gb-ОЗУ, RAID-5, Informix IDS 10.00.TC7, ~объем данных 100 Гб Сервер2 - CentOS5.1, 2x4 IntelXeon, 8 Gb, RAID-10, Informix IDS 11.50.FC1 Времени на исследования дали неделю, которая заканчивается завтра :-(( я считаю, для таких целей самое подходящее - Enterprise Replication. с настройкой повозиться придется, но если очень надо, за неделю можно успеть. причем все можно делать постепенно, без спешки, по одной табличке. и время простоя при переходе будет минимальное. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2008, 08:57 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
svat2 +1 к vasilis. ...а через "невозможно"? В сервере наверняка есть SATA-канал для DVD-ROM'a. К нему можно _временно_ подрубить шустренький винт. На нем сделать чанки под половину темповых дбспейсов. Возможно (смотрим по счетчикам onstat -D после тестовой загрузки), и PHYS_DBS туда же переносим (тоже временно, на период загрузки, переселяем с пом. "onparams -p"). ИМХО, самый действенный метод в вашей ситуации. Сегодня попробую и этот вариант ! Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2008, 15:06 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Выбегалло Яковлев ПавелБлин совсем не мой день - три неполных поста Реальный путь провереный на практике у нас. Версии, правда, были одинаковые (но не думаю, что 10.0->11.5 будет проблемой) и операционки тоже (тут возможно хуже) Вы таким образом предлагаете перетаскивать данные между версиями 10 TC и 11.5 FC ? :-))) Я таким образом описываю то, что реально работало, сразу оговорившись, что: - у нас была одна и таже версия - у нас было одно и тоже семействой ОС - Linux 32 бит - и обращаю внимание на то, где может не сработать в обсуждаемом случае Таким же образом я буду скоро _проверять_ переход Linux-32 => Linux-64 c повышением версии. И _пока_ проблема не вижу, так как 10.00 на 11.50 пройдёт, а для конвертации базы от 32 к 64 есть отдельная опция в преобразовании старых баз. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2008, 21:04 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Яковлев Павел Выбегалло Яковлев ПавелБлин совсем не мой день - три неполных поста Реальный путь провереный на практике у нас. Версии, правда, были одинаковые (но не думаю, что 10.0->11.5 будет проблемой) и операционки тоже (тут возможно хуже) Вы таким образом предлагаете перетаскивать данные между версиями 10 TC и 11.5 FC ? :-))) Я таким образом описываю то, что реально работало, сразу оговорившись, что: - у нас была одна и таже версия - у нас было одно и тоже семействой ОС - Linux 32 бит - и обращаю внимание на то, где может не сработать в обсуждаемом случае Таким же образом я буду скоро _проверять_ переход Linux-32 => Linux-64 c повышением версии. И _пока_ проблема не вижу, так как 10.00 на 11.50 пройдёт, а для конвертации базы от 32 к 64 есть отдельная опция в преобразовании старых баз. Ну, в данном случае не то что "может" не сработать - а не сработает совершенно точно, уж будьте уверены. Хотя бы потому, что в Win размер страницы 4K, а в Linux - 2. Насчет перетаскивания с 10 на 11.50 - ну да, должно сработать, но это будет банальный апдейт версии на копии данных. Как попробуете Lin32->Lin64 - держите нас в курсе. Куча системных псевдотаблиц имеют полями адреса в памяти, так что будет интересно посмотреть результаты. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2008, 03:43 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
vasilisЕсли имеется ввиду только чистая вставка строк в таблицу без индексов, то вполне нормальна и скорость в 2 млн. строк в минуту, по крайней мере я это видел пару лет назад на сервере Попробовал на домашнем коредуо. create table testint(a int); insert into testint(a) values (0); prepare; execute в цикле. итераций сек10000 .579100000 5.6881000000 55.485 из dbaccess load from 'test.unl' insert into testint 1000000 row(s) loaded. 6 sec Вот она магическая сила Insert Cursor, поэтому да, в минуту можно и 10 миллионов наинсертить. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2008, 21:48 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Журавлев ДенисВот она магическая сила Insert Cursor, поэтому да, в минуту можно и 10 миллионов наинсертить. Insert Cursor нервно курит в сторонке против HPL-я. Вчера перечитал по ссылке из соседнего треда свою рассказку в факе 6-летней давности. 70млн записей за 10 минут (в таблице 6 полей, row size=25). Отмечу, что железо тогда было попроще. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2008, 10:13 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
DaugavaInsert Cursor нервно курит в сторонке против HPL-я.Это понятно, но у hpl свои ограничения. Интересно чем можно буфер подкрутить для курсора, BIG_FET_BUF_SIZE FET_BUF_SIZE ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2008, 10:55 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Журавлев ДенисИнтересно чем можно буфер подкрутить для курсора, BIG_FET_BUF_SIZE FET_BUF_SIZEЭто переменные окружения на клиенте ( про JDBC ) и про ESQL/C . Нужно только на сервере, в $INFORMIXSQLHOSTS, настроить такой же размер буфера, как описано в разделе "Поле опций" тут . Только мне кажется, что выигрыш в производительности достигается за счёт увеличения размера сетевых пакетов (и, как следствие, за счёт уменьшения их числа), а у IP-протокола есть свой размер пакета, который по-умолчанию не очень велик, хотя и настраивается - 1,5 Кб, кажется. Прихожу к тому, что большой пакет клиента Информикса всё равно будет порезан на меньшие сетевые пакеты, и значительного прироста производительности не будет. ИМХО. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2008, 12:45 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Выбегалло Яковлев Павел Реальный путь провереный на практике у нас. Версии, правда, были одинаковые (но не думаю, что 10.0->11.5 будет проблемой) и операционки тоже (тут возможно хуже) Таким же образом я буду скоро _проверять_ переход Linux-32 => Linux-64 c повышением версии. И _пока_ проблема не вижу, так как 10.00 на 11.50 пройдёт, а для конвертации базы от 32 к 64 есть отдельная опция в преобразовании старых баз. Как попробуете Lin32->Lin64 - держите нас в курсе. Куча системных псевдотаблиц имеют полями адреса в памяти, так что будет интересно посмотреть результаты. ну как-то так :) http://www.sql.ru/forum/actualthread.aspx?tid=591463 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 22:35 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Интересно, кто-нибудь использовал следующую утилиту: load2 - utility for loading/unloading data to/from Informix database http://robsosno.googlepages.com/downloads С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2008, 21:41 |
|
Скорость загрузки данных
|
|||
---|---|---|---|
#18+
Daugava Журавлев ДенисВот она магическая сила Insert Cursor, поэтому да, в минуту можно и 10 миллионов наинсертить. Insert Cursor нервно курит в сторонке против HPL-я. Вчера перечитал по ссылке из соседнего треда свою рассказку в факе 6-летней давности. 70млн записей за 10 минут (в таблице 6 полей, row size=25). Отмечу, что железо тогда было попроще. ну если лить сразу страницы, минуя SQL level с его индексами, констрейнами, триггерами и пр. - то конечно :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2008, 18:54 |
|
|
start [/forum/topic.php?fid=44&msg=35397808&tid=1608024]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 177ms |
0 / 0 |