Симонов Денис,

GCPolicy = background - не убираю т.к. иногда запускаю в тесте супер, а т.к. на классик не влияет получается висит всегда
DefaultDbCachePages = 38192 - на классике сильно провисают запросы на базе более 4Гб выставили оптимальное значение методом тыка. Хотя после скольки то Гб требовалось больше, но были проблемы с блобами. Поэтому оставили пока эо значение.
Супер 3-ки не удалось запустить в работу т.к. 32 бит не дает нам возможность запустить более 3 - 4 подключений к разным базам данных т.к. боле 2Гб оперативки это придел.
А хочется еще больше, 9Гб базу поместить в память. Но тогда надо ставить 64 бит сервер, а значит и УДФ надо будет 64 бит протестировать сначала.

Вчера пришлось обновиться до Windows 10.
Сегодня выдалось глянуть конференцию и ответить.
Странно было после первого запуска и решил все перезапустить.

Т.к. тесты все равно были сделаны их выкладываю. Напоминаю ориентироваться на них сильно не советую т.к. в реальных запросах более сложные скрипты. Также мы все не все параметры используем в конфиге к примеру TempCacheLimit. Я его не использую но он дает прирост 25-30%. Под разные задачи разные параметры.
Показатели update остались на прежнем уровне. Все остальное на разъехалось.
Все расхождения на несколько секунд. Это можно пока пережить т.к. есть другие более сложные проблемы. Баги прошлых лет которые приходиться перетестить и рапортовать т.к. получить 3-ку было важней, чем их тогда править. Дальше будет проще разработчики будут оптимизировать по ходу дела и продукт будет крепчать.

Создание индекса
FB 3.0.1.3224
Если кеширование и данные на одном диске то
TempCacheLimit = default
18:10:00-18:17:26=7:26
TempCacheLimit = 364M
17:45:00-17:50:37=5:37

Если кеш и данные на разных дисках
TempCacheLimit = default
18:50:00-18:54:13=4:13
TempCacheLimit = 364M
19:12:00-19:16:12=4:12
TempCacheLimit = 640M
19:38:00-19:41:40=3:40

FB2 2.5.6.26979
Если кэш и данные на разных дисках
TempCacheLimit = 671088640
20:24:00-20:27:45=3:45

Да прирост есть, но после 640M быстрей не становится, пробовал ставить 1536M.
Но это только в этом тесте. И на это можно смотреть так для ознакомления.

Все тесты проводились с одним лишь изменением в конфиге
для FB 3.0.1.32524
TempCacheLimit = 640M
TempCacheLimit = default
для Fb 2.5.6.26979
TempCacheLimit = 671088640

select first(100000) skip(20000000) * from TEST
where ID > 0
order by ID, STR_80, DAT;
FB 3.0.1.32524
Время подготовки "00:00:00.004", выполнения "00:00:40.706"
Время подготовки "00:00:00.028", выполнения "00:00:50.507"
Fb 2.5.6.26979
Время подготовки "00:00:00.127", выполнения "00:00:47.414"

было в Fb 3.0.1.32510
Время подготовки "00:00:00.009", выполнения "00:00:43.030"
Fb 2.5.6.26979
Время подготовки "00:00:00.005", выполнения "00:00:44.069"


select first(100000) skip(20000000) * from TEST
where ID > 30000000
order by ID, STR_80, DAT;
FB 3.0.1.32524
Время подготовки "00:00:00.005", выполнения "00:00:39.055"
Время подготовки "00:00:00.018", выполнения "00:00:44.455"
Fb 2.5.6.26979
Время подготовки "00:00:00.013", выполнения "00:00:44.173"

было в Fb 3.0.1.32510
Время подготовки "00:00:00.005", выполнения "00:00:54.328"
Fb 2.5.6.26979
Время подготовки "00:00:00.008", выполнения "00:00:45.121"


select first(100000) skip(20000000) * from TEST
where ID > 79000000
order by ID, STR_80, DAT;
FB 3.0.1.32524
Время подготовки "00:00:00.006", выполнения "00:00:45.159"
Время подготовки "00:00:00.008", выполнения "00:00:43.372"
Fb 2.5.6.26979
Время подготовки "00:00:00.017", выполнения "00:00:42.217"

было в Fb 3.0.1.32510
Время подготовки "00:00:00.004", выполнения "00:00:54.452"
Fb 2.5.6.26979
Время подготовки "00:00:00.009", выполнения "00:00:43.058"


update TEST set STR_2000 = STR_2000 || STR_2000
where ID between 45000001 and 55000000;
FB 3.0.1.32524
Время подготовки "00:00:00.016", выполнения "00:02:10.409"
Fb 2.5.6.26979
Время подготовки "00:00:00.016", выполнения "00:01:53.789"

было в Fb 3.0.1.32510
Время подготовки "00:00:00.007", выполнения "00:02:10.892"
Fb 2.5.6.26979
Время подготовки "00:00:00.008", выполнения "00:01:53.063"

Симонов ДенисЕвгений Болтик,

на последний тест это изменение TempCacheLimit не может повлиять.
TempCacheLimit помогает для внешних сортировок (создание индекса, ORDER BY с планом SORT, GROUP BY с планом SORT, DISTINCT) и для HASH/MERGE JOIN.
Огромное СП за совет. Это я сразу понял. Судя по тому какие базу у меня мелкие это так не значительно. Поэтому он у меня закомментированный с моими тестовыми значениями. До этих тестов я не видел разницы в этом параметре. Я всегда обходился DefaultDbCachePages.


Черт дернул подергать эту же тестовую базу
DefaultDbCachePages = 1024
FileSystemCacheThreshold = 264K
GCPolicy = background
RemoteAuxPort = 3051
ServerMode = Classic
TempDirectories = f:\

select first(100000) skip(20000000) * from TEST
where ID > 0
order by ID, STR_80, DAT;
Время подготовки "00:00:00.020", выполнения "00:00:32.929"

DefaultDbCachePages = 38192
FileSystemCacheThreshold = 264K
GCPolicy = background
RemoteAuxPort = 3051
ServerMode = Classic
TempDirectories = f:\
TempCacheLimit = 640M
Время подготовки "00:00:00.018", выполнения "00:00:33.216"

Вот это уже фигня какая то. То 40, то 50, то 33 секунды выполняется запрос.
Такое поведение стало после коммита этого
update TEST set STR_2000 = STR_2000 || STR_2000
where ID between 45000001 and 55000000;
Складывается впечатление мусор помогает быстрей работать. Все спать, спать....