Медленный экспорт в Firebird через ODBC

Страницы: 1
RSS
Медленный экспорт в Firebird через ODBC
 
Добрый день!

Экспорт из QUIK в FireBird через ODBC осуществляется с задержками.
К вечеру достигает опоздания 1-2 часа (!!!).

Экспорт осуществляется из 9 таблиц, самая большие - таблица параметров в 2 версиях:
1. Колонки: Код бумаги Бумага Бумага сокр. Баз.актив Код класса Класс Тип опциона Лот Точность Шаг цены Страйк Дата исп. Валюта Марж.
2. Колонки:  Код бумаги Спрос Предл. Теор. цена Цена послед. Волатильность БГОНП БГОП ГО покупателя ГО продавца Статус
Обычно по 300-700 строк. Опционы.
Экспорт одной таблицы в 700 строк осуществляется в течение 1-2 минут.

Проверялось с таблицам FB как с индексами, так и без них.

QUIK 6.17.1.17. Проблема была также и в предыдущих версиях (6.16.1.15, 6.16.0.42, 6.15.2.9, 6.15.1.17).
FireBird 2.5.3.26778.
FireBird ODBC Driver 2.0.3.154 (http://www.firebirdsql.org/en/odbc-driver), также проверял на 2.0.2.153, как на Windows xp, так и на Windows Server 2008 R2 Standard.

При этом, в той же сессии одновременно с FB экспорт осуществляется и в базу MS Access. Так же через ODBC. Мгновенно (700 строк за 1-2 сек), объемы данных - точно такие же.

Нашел на форуме подобную проблему в ветке http://forum-archive.quik.ru/forum/iwr/77235/
Но там проблема была решена обновлением версии QUIK'а.

Здесь, думаю, проблема в чем-то другом. Прошу помочь.

С уважением,
Сергей.
 
Здравствуйте.
Просьба произвести логирование экспорта:
- при закрытом QUIK в его папке необходимо создать пустой файл с именем quik_odbc.log
- запустить QUIK, зафиксировать факт задержек (примерное время)
- сделать архив файла quik_odbc.log и прислать нам для анализа на адрес quiksupport@arqatech.com , в теме письма обязательно укажите ссылку на эту ветку форума.
После этого необходимо удалить quik_odbc.log (при закрытом Quik), иначе он будет сильно разрастаться.
 
Добрый день, Сергей!

Логи отправил.
Спасибо.

С уважением,
Сергей.
 
Прошу прощения.
* Олег.
 
Здравствуйте.
Задержки экспорта возникают по причине накопления очереди при экспорте, которая, в свою очередь, возникает из-за недостаточного быстродействия СУБД.
Экспорт производится синхронно, т.е. следующий SQL запрос не будет отправлен  на исполнение до тех пор, пока не будет получен ответ по предыдущему. Для таблицы QUIKPRICES среднее время выполнения запроса составило 114.19 мс, для выполнения 99627 запросов понадобилось 11376 секунд (3 часа 9 минут 36 секунд), что Вы и наблюдаете: начало экспорта в 21:25:41, окончание - 00:41:53. Прошедшее время несколько больше расчётного, т.к. оно тратится ещё и на подготовку данных и иные промежуточные операции в QUIK, но расчёт подтверждает то, что основное время затрачивается на выполнение SQL запросов: 6 минут 36 секунд против 3 часов 9 минут 36 секунд.
В данной ситуации обычно существует два пути решения - повышение производительности СУБД и/или снижение объёмов потока данных. Если мы правильно понимаем, экспорт производится из таблицы текущих параметров. К примеру, существует возможность "прореживания" данных по этой таблице путём установки "Интервала обновления данных с текущим состоянием", количество обновлений сократится, соответственно, риск возникновения очереди будет снижен.
 
Добрый день, Олег!

По уменьшению интервала обновления - понятно. Увеличил. Спасибо.

Но остались вопросы:

1. Почему экспорт тех же данных в Access (тоже через тормозной ODBC) производится быстрее в 50-60 раз (1500 строк: 2 минуты в FB против 2 сек в Access)? Неужели он шустрее FB?

2. Как посоветуете повысить производительность FB? Может, проблема в драйвере? Какие есть альтернативы?


С уважением,
Сергей.
 
Здравствуйте.
К сожалению, мы не обладаем какой-либо достоверной статистикой по данным вопросам, поэтому затруднимся рекомендовать что-либо. В случае необходимости мы готовы помочь с оценкой производительности со стороны СУБД по приведённому ранее сценарию.
 
Добрый день, Олег!

Проблема решена. По крайней мере, устранены сильные тормоза и скорость работы доведена хотя бы до скорости Access'а.

Как выяснилось, мой виртуальный хостер предоставляет SSD-диски только для системного раздела. А доп.раздел - SATA.
Сам FB, БД и каталог для временных файлов перенесены на SSD-диск. Теперь экспорт тех же данных занимает не 120 сек, а только 3-4 сек. Что в целом уже почти устраивает.

+ немного подкрутил настройки firebird.conf.
Осталось еще памяти добавить.

Помогла статья http://www.ibase.ru/devinfo/optimize.htm.

С уважением,
Сергей.
 
Цитата
Сергей пишет:
Как выяснилось, мой виртуальный хостер предоставляет SSD-диски только для системного раздела. А доп.раздел - SATA.
Сам FB, БД и каталог для временных файлов перенесены на SSD-диск. Теперь экспорт тех же данных занимает не 120 сек, а только 3-4 сек. Что в целом уже почти устраивает.
Спасибо за ценное наблюдение.

Сам часто замечал когда банальный запуск chckdisk и последующее обслуживание могут в разы увеличить скорость доступа к диску.
Страницы: 1
Читают тему (гостей: 3)
Наверх