Привет всем! Скачал UDF с сайта Ibase.ru библиотеку с данной функцией (спасибо KDV). Функции зарегистрировал, все работает. Но!
Имеем два сервера:
Сервер 1:
Intel(R) Xeon(R) CPUE31240 3.3GHz, 8 ядер
16Гб, рэйд 1
Вин-сервер 2008, 64 бита.

Сервер 2 (по сути и не сервер, обычный рабочий комп).
Intel(R) Core(TM) I5-3470 3.2GHz, 4 ядра.
8Гб, система Win7, 64 бита на SSD, сервер FB на обычном диске.

Везде FB2.5.7, 32 бита, только что выкачанный с официального сайта.

На сервере 1 функция работает гораздо медленнее. Сравнивался запрос из описания к библиотеке вида





Это для одного файла в 42Мб. Аналогичный файл на сервере 2 затягивается в базу за 2с.
Обычные файловые операции - копирование, чтение и т.п. на сервере 1 выполняются нормально, процессор не загружен.
Обычным образом (через IBExpert, вьювер блобов) блобы подгружаются практически мгновенно.
Пробовал на всех версиях сервера - 32 бита, классик, суперклассик, суперсервер. Разницы нет - все одинаково долго выполняется. На сервере 2 все одинаково быстро. Все тесты выполнялись локально, так что сеть ни при чем. Но при тестах по сети (например, от сервера 1 запрос к серверу 2 и, наоборот - от сервера 2 к серверу 1, все естественно тоже самое - первый случай долго выполняется, второй очень быстро - сеть загружается почти на все 100Мбит).
К базам во время теста никто не подключен кроме SYSDBA.
Вроде в UDF функции тормозить-то нечему, но и на железо грешить тоже не получается. Кривые руки тоже просто некуда приложить было.
Куда надо копать? какую статистику смотреть почему так получается? Заранее спасибо.

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


Лучше под базу ставить SSD получается?

Спасибо всем.
hvladSSD лучше, но и raid нужно настроить.
Да нашему серверу уже 7 лет, контроллер там sata2, диски эти ещё родные, вряд ли там что настроишь. Там ещё один рэйд на новых sata3 дисках, так там цифры в 1.5 раза лучше показывает, тоже не фонтан - контроллер тот же.
Просто кроме этой проблемы, других проблем с базой нет, сама база маленькая, транзакций мало, большинство только читают. Да и файл-то насквозь через базу передаётся, то есть блоб временный, не думал что при этом влияние дисков такое будет.

Ivan_PisarevskyНасколько временный? если его можно загнать в ГТТ и достаточно ОЗУ, то влияние дисков можно нивелировать.
Вообще временный. Это (та что реальная, но на основе udf Дмитрия) процедура передачи файлов насквозь через базу, чтобы не использовать отдельный протокол параллельно базе, которая знает о полномочиях пользователей на файлы.
Получил файл с сервера в блоб являющийся параметром процедуры, выдал его как результат клиенту. В таблицы он вообще не пишется.
ОЗУ достаточно, использую классик, 50 клиента по 50мб на коннект. То есть 16гб за глаза.

Dimitry Sibiryakov,

Пишется, я понимаю, и тут же уничтожается и место освобождается, туда тут же пишется следующий блоб. Мы каждый день 10гб передаём, а база распухла на 8гб за 3года, что не делали рестор рабочей базы. По сути размер базы увеличивается один раз на размер самого большого передаваемого файла. Может ещё чуть чуть. Эти "чуть-чуть" и составили 6-7 гб за 3 года. Я не знаю, "я же не настоящий сварщик".

Ivan_Pisarevsky на старте сервера создавать пустую базу на RAM диске и гнать блобы через нее?
Да смысла особого нет - даже с обычным hdd моего компа ака сервер2 уже сеть 100мбит загружается на 80-90%. А с ssd вообще хорошо должно все стать. Тем более что этот способ в основном для передачи через интернет используется, а там и 50мбит будет достаточно - больше канал не пропустит. А разносить по разным базам полномочия на файлы и их передачу более геморойно. Но если когда-то объёмы передачи сильно вырастут, почему бы и нет.

Попробовал еще погонять загрузку из файла в блоб. То что проблема связана с диском это понятно стало. Но как-то она неправильно коррелирует с данными, которые выдает crystal. На сервере два рэйда - C:\ и E:\. Для них Crystal выдает данные отличающиеся в 1,5 раза - C:\ привел выше (слева), E:\ в 1,5 раза лучше характеристики. Но скорость загрузки через них почти одинаково плохая.
Зато есть внешний диск, подключенный через USB (F:\), для которого характеристики Crystal показывает в несколько раз хуже, но если база лежит на нем, то загрузка выполняется в 5 раз быстрее. Прикладываю график загрузки сети - пики это передача блоба от базы на клиента (клиент в локальной сети), провалы - загрузка файла в базу во временный блоб.
График загрузки сети База во всех 3-х случаях одинаковая, отресторенная рабочая и раскопированная на 3 диска.
Результат теста внешнего диска, подключенного через USB Подключен к другому компу, поэтому буква диска другая, не F:\.
График загрузки сети при загрузке через RAM-диск
Попробовал даже загружать через отдельную базу расположенную на RAM-диске, как посоветовал Иван - намного быстрее, но не ахти как, локальная сеть полностью не загрузилась даже - примерно на половину. При том, что при аналогичной загрузке с Сервера2 загрузка около 90%.
Понятно, что тест выполняемый Crystal копированием по 4кБ это не истина в последней инстанции для конкретной базы. Но все же - можно что-то сделать на том железе что есть? Поставить SSD на сервер пока нет возможности - все места под диски заняты, подключить мимо штатного контроллера HP не дает.

Ivan_Pisarevsky,
Подключил двух клиентов, правда с одного и того же компа. Разницы никакой. Т.е. скорость между ними делится. Потом попробую с двух компов одновременно подключиться, но не думаю что это что-то изменит.
Сетевая конечно на 1Гбит, но свитч на 100МБит.

Тоже самое, но клиенты подключаются к разным базам на одном сервере - одна на RAM-диске, другая на внешнем HDD.

Тоже что в первом тесте - два клиента к одной базе, но база лежит на внешнем HDD

Тоже что в тесте №2 - подключение к разным базам, но расположенных на одном RAM-диске