FB 1.5.2, Intel C++ и кеш Windows

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
Andrew Sagulin
Сообщения: 53
Зарегистрирован: 11 мар 2005, 15:44

FB 1.5.2, Intel C++ и кеш Windows

Сообщение Andrew Sagulin » 28 дек 2005, 16:18

Может быть для разработчиков FB всё нижеизложенное и очевидно, но мне всё равно захотелось рассказать о своих экспериментах на форуме - вдруг кому-нибудь пригодится. :?:
В двух словах: есть у меня большая таблица (15 гигабайт, 200 млн. записей), слабый комп (P4 2.4, 1GB), и задачи, которые требуют сканирования значительной части таблицы (от 40 мегабайт до 1.5 гигабайт) практически в однопользовательском режиме. (Я на форуме уже пару раз плакался о своей беде, так что подробности моей задачи здесь уже фигурировали).
Установлен официальный билд 1.5.2 для Windows. Скачаны соответствующие им исходники.
Была цель сделать так, чтобы FB не использовал файловый кеш операционки, потому что при сканировании таблицы он раздувается так, что мама не горюй, а толку при этом - ноль, так как фактически доступ всё равно последовательный, и хранить уже прочитанное в кеше не за чем.
Спасибо http://www.ibphoenix.com/main.nfs?a=ibp ... urce_guide за то, что помогли разобраться в структуре исходников FB. В результате поисков, где именно можно отключить кеширование, я вышел на winnt.cpp, где и находился интересующий меня код:

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

static const DWORD g_dwExtraFlags = FILE_FLAG_RANDOM_ACCESS;
Заменив эту строчку на

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

static const DWORD g_dwExtraFlags = FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_NO_BUFFERING;
запустил компиляцию. Так случилось, что для msvc6 по умолчанию у меня был установлен компилятор Intel C++ 8.1. Так что FB-сервер скомпилировался им (с массой предупреждений, но без ошибок). В конце концов я сделал два варианта интеловским компилятором (с включенным кешем ОС и без него), и ещё один из официальной поставки, путём правки констант для CreateFile непосредственно в бинарнике.
Сделал несколько экспериментов по индексному скану таблицы (примерно 1.5 гигабайта): с дополнительным условием по полю без индексна и без дополнительного условия.
В результате: варинт сервера, не использующий кеш ОС был примерно на 3-5% быстрее варианта с кешем (размер buffers в обоих случаях был выбран небольшим, чтобы не пересекаться с кешем ОС). Скомпилированный интелом fbserver.exe работал на 25-30% быстрее того, что идёт в официальном билде.
Затем я сделал fullscan таблицы. Там разница между вариантами с кешем ОС и без него была примерно 3%, а "интеловский" fbserver оказался примерно на 8% быстрее "официального".
Естественно, на основании столь специфичного и однобокого теста делать выводы неразумно, но себе, тем не менее, в качестве рабочего варианта я скорее всего оставлю интеловский с запретом кеша ОС", а там видно будет. :roll:

P.S: Сделав размер кеша сервера FB 300 Мегабайт (я теперь могу это себе позволить, так как операционка не съедает память под кеш) и выполнив добавление данных за день (500 тыс. записей, ~ 35 мегабайт), не без удовольствия обнаружил, что "интел, ноу ОС кэш" отработал почти на 40% быстрее, чем "официальный" вариант.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 28 дек 2005, 17:09

это не секрет, Yaffil имеет такой флаг в конфиге.
Но. Производительность при отключенном файловом кэше ОС может сильно "гулять" в зависимости от размера страницы БД и размера кластера, особенно при записи. Мои тесты (года 4 назад) показали, что такой режим надо использовать осторожно, путем последовательного экспериментирования. Что мы тут и наблюдаем.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 28 дек 2005, 18:00

Насчёт разницы в компиляторах - сравни с MSVC7.1 (компилятор FB2)
Насколько я знаю, были попытки использовать интеловские компилеры, но 3-5% прироста скорости не могли компенсировать многократное увеличение р-ра бинарников :)

Насчёт разницы в кеше - без кеша ОС буду тормозить операции над относительно небольшими наборами данных, т.е. те, для которых кеш ОС помагал. ИМХО

Ответить