iBase.ru Forum

имеется FB2.0, Win2003
парсим текстовый файл, упихиваем данные в предварительную таблицу (получаем порядка 50 000 записей), затем процедурой обрабатываем, которая в зависимости от соответствия данных в этой таблице и в справочных апдейтит поля предварительной таблицы.
при первом запуске процедуры:

Код: Выделить всё

------ Performance info ------
Prepare time = 0ms
Execute time = 9s 406ms
Current memory = 2 751 124
Max memory = 2 796 480
Memory buffers = 10 240
Reads from disk to cache = 0
Writes from cache to disk = 1
Fetches from cache = 2 430 492

при втором запуске

Код: Выделить всё

------ Performance info ------
Prepare time = 0ms
Execute time = 2m 20s 672ms
Current memory = 2 750 852
Max memory = 2 814 760
Memory buffers = 10 240
Reads from disk to cache = 0
Writes from cache to disk = 54 774
Fetches from cache = 2 762 600

при 3-м и последующих

Код: Выделить всё

------ Performance info ------
Prepare time = 0ms
Execute time = 1m 33s 906ms
Current memory = 2 760 508
Max memory = 2 814 760
Memory buffers = 10 240
Reads from disk to cache = 0
Writes from cache to disk = 54 593
Fetches from cache = 2 791 416

Чем вызваны такие изменения времени выполнения?
И как это можно побороть?

выполнения в одной транзакции или разделены коммитами?

если в одной, то см. сюда:
www.ibase.ru/devinfo/test3.htm

разъяснение по savepoints было в журнале ibdeveloper.com не то 3, не то 4-ый номер.

А разъяснение по сборке мусора в FB 2 - тут:
http://www.sql.ru/forum/actualthread.as ... =4#3577997

1. Writes from cache to disk = 1
2. Writes from cache to disk = 54 774

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

dimitr писал(а): выполнения в одной транзакции или разделены коммитами?

после каждого выполения процедуры - коммит

dimitr писал(а): если в одной, то см. сюда:
www.ibase.ru/devinfo/test3.htm

разъяснение по savepoints было в журнале ibdeveloper.com не то 3, не то 4-ый номер.

А разъяснение по сборке мусора в FB 2 - тут:
http://www.sql.ru/forum/actualthread.as ... =4#3577997

Спасибо, буду смотреть (правда с моей скоростью и-нета это будет напоминать участие одноногого в состязянии по ляганию задниц), но согласно IBAnalyst мусор стабильно растет, коли дело в нем, почему начиная с 3-го запуска процедуры время выполнения стабилизируется?

dimitr писал(а): 1. Writes from cache to disk = 1
2. Writes from cache to disk = 54 774

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

Возможно, но
3. Writes from cache to disk = 54 593 и время меньше, чем во втором запуске
По дискоковой ПС: имеется зеркало на IDE, и в ближайшее время ничего лучшего не предвидится

. Все что мог, вроде подкрутил.

stix-s писал(а):почему начиная с 3-го запуска процедуры время выполнения стабилизируется?

Скорее всего каждый последующий запуск чистит некоторый мусор от предыдущего запуска.

Dimitry Sibiryakov писал(а):
stix-s писал(а):почему начиная с 3-го запуска процедуры время выполнения стабилизируется?
Скорее всего каждый последующий запуск чистит некоторый мусор от предыдущего запуска.

Именно.
И нарывается на неприятный эффект от careful write, заставляющий записываться на диск каждую затронутую апдейтом запись не по коммиту, а в момент обновления

Как это обойти: FW = OFF или GCPolicy = background

hvlad писал(а): Как это обойти: FW = OFF или GCPolicy = background

выставил GCPolicy = background

Код: Выделить всё

1-й проход
------ Performance info ------
Prepare time = 0ms
Execute time = 9s 109ms
Current memory = 2 563 044
Max memory = 2 608 640
Memory buffers = 10 240
Reads from disk to cache = 93
Writes from cache to disk = 1
Fetches from cache = 2 034 976

коммит
очередь к диску при выполнении близка к 0
2-й проход

Код: Выделить всё

2-й проход
------ Performance info ------
Prepare time = 0ms
Execute time = 55s 985ms
Current memory = 2 487 052
Max memory = 2 608 640
Memory buffers = 10 240
Reads from disk to cache = 0
Writes from cache to disk = 21 056
Fetches from cache = 2 644 213

коммит
очередь к диску 80-90%
3-й проход

Код: Выделить всё

------ Performance info ------
Prepare time = 0ms
Execute time = 1m 46s 16ms
Current memory = 2 499 244
Max memory = 2 608 640
Memory buffers = 10 240
Reads from disk to cache = 0
Writes from cache to disk = 42 406
Fetches from cache = 2 343 368

коммит
очередь к диску 80-90%
LOG_TMP Записей: 48947, Версий: 48640, дл.зап.: 123.86, дл.верс. 9.00
Да, пардон FB2.0 - SS
Последующие попытки - 46 с, 24 с, 1 мин, 1 мин 27 с, 1мин 27с
согласно АйБиАналисту число версий стабильно порядка 4%
не улавливаю я закономерности

да и выигрыша в конечном итоге не вижу

Я не понял - это статистика при GCPolicy = background ? на FW = OFF не похоже.
Обязательно нужно апдейтить все 50К записей каждый раз ?
Паузы между выполнениями процедуры допустимы ?

Паузы между выполнениями процедуры допустимы ?

нет, процедура должна долбить постоянно

hvlad писал(а): Я не понял - это статистика при GCPolicy = background ? на FW = OFF не похоже.
Обязательно нужно апдейтить все 50К записей каждый раз ?
Паузы между выполнениями процедуры допустимы ?

1 - да, GCPolicy = background, FW = ОN
2 - нет, необязательно, если за один проход получим требуемый результат, если же косяки из-за парсера или же из-за справочных таблиц, то приходится повторять процедуру
3 - да, перерывы есть как таковые, поскольку необходимо будет результаты обработки проверять
В идеале данную процедуру хочу в дальнешем запихнуть в триггер на вставку, дабы не плодить мусор.
Впрочем в программе которая будет данную процедуру выполнять предусмотрена возможность просмотра результатов обработки по принципу select * from t (возможно и с предварительным select count(*).....), так что мусор должен быть изничтожен.
Я поведение сервера понять не могу -
1
полностью вытираем таблицу
парсим файл, запихиваем данные
очередь диска болтается возле 0%, только периодически впихивает пакеты.
версий после загрузки нет
2
первый проход
выполнение - порядка 10 сек
очередь диска болтается возле 0%
процент версий -5,48%
3
смотрим результаты обработки - в результате версий 0%
запускаем на 2-й проход
время выполнения 1 мин с хвостиком
очередь диска 80-90% (причем не того, где временная директория определена, а того, где база лежит)
TempDirectories = c:\temp\fb_swap - но там во время выполнения пусто
версий порядка 4%
4
опять смотрим результаты версий 0%
запускаем 3-й проход
время выполнения 1 мин с хвостиком
очередь диска 80-90%
версий порядка 4%
5
не смотрим результаты - версии оставляем
запускаем 4-й проход
время выполнения 1,5 мин
очередь диска 80-90%
версий порядка 4%

Что же мешает FB выполнитьпроцедуру при отсутствии версий как за первый проход? за секунды, а не за минуту
вчера гонял процедуру IBExperto-м
сегодня своей программулиной

параметры транзакций
на процедуру - короткая пишущая
write
nowait
concurrency

на просмотр
read
nowait
rec_version
read_committed

kdv писал(а): нет, процедура должна долбить постоянно

Издеваемся, да?

В идеале данную процедуру хочу в дальнешем запихнуть в триггер на вставку, дабы не плодить мусор.

что-что???

Что же мешает FB выполнитьпроцедуру при отсутствии версий как за первый проход?

ты же сам видишь - пишет оно на диск.

Издеваемся, да?

да. а как еще такую "технику" назвать?

kdv писал(а):
В идеале данную процедуру хочу в дальнешем запихнуть в триггер на вставку, дабы не плодить мусор.
что-что???

Тут он наверное не мусор, а "мусор" имел в виду, т.е. "лишние" процедуры свои.

какая разница. кусок кода, который временами выполняется до 1.5 минут, кидать в before/after insert ???

kdv писал(а): что-что???

версии не плодить

kdv писал(а): ты же сам видишь - пишет оно на диск.

а какого рожна ОНО при первой обработке тоже пишет, но не настолько, шоб диск затыкался, а при 2-3 и далее прогонах все упирается в диск, тотя версии по идее уже собраны?
или же здесь присутствует некий ньюанс?

kdv писал(а): да. а как еще такую "технику" назвать?

зер гуд, задача в том, что из совершенно разнокалиберных текстовых файлов надо получить нормальную таблицу, в которой в итоге работы парсера записей может быть от 10000 до сотен тысяч
поскольку справочники у меня уже на ФБ, совершенно нет желания. например гнать из парсера в дбф к примеру и затем гетерогенные запросы ваять FB-dbf
в конечном итоге эти данные уже препарированые падают в постоянную таблицу в FB и там практически не меняются
если есть предложения, как это сделать более эффективно чем у меня, то скажи, любые предложения приветствуются

(я вовсе не предлагаю решать задачу за меня

)

WildSery писал(а): Тут он наверное не мусор, а "мусор" имел в виду, т.е. "лишние" процедуры свои.

Вот всяк хотит художника обгадить, нет чтоб что-то существенное сказать

kdv писал(а): что-что???

ыт не совсем 1,5 мин загрузка энтого несчастного файла с 50000 записей с триггером увеличилась всего на 10 сек

stix-s писал(а):версии не плодить

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

stix-s писал(а):Вот всяк хотит художника обгадить, нет чтоб что-то существенное сказать

Есть такое. Недолюбливаю художников, они часто всякую мазню за произведение искусства выдают. Даже "общепризнанные", хотя я например их не признавал, значит, не "обще".

stix-s писал(а):а какого рожна ОНО при первой обработке тоже пишет, но не настолько, шоб диск затыкался, а при 2-3 и далее прогонах все упирается в диск, тотя версии по идее уже собраны?
или же здесь присутствует некий ньюанс?

Easy, easy

При втором и далее прогонах тормоза, как я уже писал выше, из-за параллельной сборки мусора и обновления одних и тех же записей.
Если разнести эти два процесса во времени, то всё будет ок.
Как это сделать
а) GCPolicy = background и дождаться окончания сборки мусора после каждого апдейта. Селекты тут не помогут ибо не собирают тмусор
б) GCPolicy != background + селект после апдейта. В другой тр-ции конечно
в) любой GCPolicy + FW=OFF

hvlad писал(а):
stix-s писал(а):а какого рожна ОНО при первой обработке тоже пишет, но не настолько, шоб диск затыкался, а при 2-3 и далее прогонах все упирается в диск, тотя версии по идее уже собраны?
или же здесь присутствует некий ньюанс?
Easy, easy
При втором и далее прогонах тормоза, как я уже писал выше, из-за параллельной сборки мусора и обновления одних и тех же записей.
Если разнести эти два процесса во времени, то всё будет ок.
Как это сделать
а) GCPolicy = background и дождаться окончания сборки мусора после каждого апдейта. Селекты тут не помогут ибо не собирают тмусор
б) GCPolicy != background + селект после апдейта. В другой тр-ции конечно
в) любой GCPolicy + FW=OFF

Либо тупо брутально купить рэйд контроллер с хотя бы 64 метрами набортного кэша и батарейкой и включить на нем райтбэк. Можно даже на САТА, тогда и диски менять не придется.

WildSery писал(а): Чтобы версии не плодить, надо не в триггер пихать, а логику процедуры менять, избавляться от апдейтов последовательных.

Как например?
есть разноформатные TXT из которых мне в конечном итоге надо сделать конфетку
в одном одного не хватат, в другом другого
а в итоге все должно быть однообразно
подготавливать мне файлы в нужном формате никто не будет - издержки так сказать производства.

WildSery писал(а): Есть такое. Недолюбливаю художников, они часто всякую мазню за произведение искусства выдают. Даже "общепризнанные", хотя я например их не признавал, значит, не "обще".

Эт у тебя взгляд на подлинное исскуство отличается от "общепризнанного"

hvlad писал(а): Как это сделать
а) GCPolicy = background и дождаться окончания сборки мусора после каждого апдейта. Селекты тут не помогут ибо не собирают тмусор
б) GCPolicy != background + селект после апдейта. В другой тр-ции конечно
в) любой GCPolicy + FW=OFF

ых. я же и пишу, шо:
а) GCPolicy = background
что значить дождаться?
IBA мне кажет, что версий нет, следовательно мусор собран
б) это и делаю - GCPolicy = background, апдейт в пишущей, соммит, селект в читающей
в) не, не хочу FW=OFF

stix-s писал(а):есть разноформатные TXT из которых мне в конечном итоге надо сделать конфетку
в одном одного не хватат, в другом другого
а в итоге все должно быть однообразно
подготавливать мне файлы в нужном формате никто не будет - издержки так сказать производства.

Стотыщ записей - не так уж много. Можно всосать все TXT суперконвертилкой, которая в памяти всё соберёт и выплюнет готовый к обработке тэйбл.

iBase.ru Forum

"Плавающее" время выполнения процедуры

"Плавающее" время выполнения процедуры