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

0) Бысто вытащить все только незакомментаренные параметры конфига, без "#-мусора":

1) Про LockHashSlots , http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=993274&msg=13688627
kdvпо LockMemSize еще запомните формулу (автор - dimitr)

LockMemSize >= Cache_pages * max_connections_count * 100

А насчет LockHashSlots Пешков давно заявлял, что уже можно ставить 10007, фактически в качестве "дефолтного" значения. 2) Опять про LockHashSlots , http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1075167&msg=15519745
dimitrТаблоидНа стр. 10 по-прежнему торчит старое LockHashSlots = 1009.
Этот дефолт - он действительно устарел (так считает Алекс, если смотреть на ссылку от kdv) или нет ?"старое" - это 101 слот, а 1009 слотов являются дефолтом не так и давно, последние 5 лет. Насчет "устаревшего" - все зависит от числа коннектов, давай посчитаем вместе: 1009 слотов в среднем по 10 коллизий это 10К страниц (остальные типы локов для простоты игнорируем). Дефолтный размер кеша SC/CS - 75 страниц в 2.х и 256 страниц в 3.0. Получается, что дефолт рассчитан на ~130 коннектов в 2.х и ~40 коннектов в 3.0. На самом деле несколько меньше. Мое личное мнение - в 3.0 можно и увеличить, а в 2.5 число слотов вполне адекватно размеру кеша.3) Про LockMemSize , http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1092754&msg=15971603
dimitrв первом приближении: число страниц кеша * число коннектов в пике * 100 байт. А проще мониторить параметр Used лок-таблицы в течении дня и устанавливать LockMemSize в значение раза в два (чтобы с запасом) более найденного.4) Про TempBlockSize, TempCacheLimit , а также их "влияние" на GTT:
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1099687&msg=16152458 dimitrэти параметры (TempBlockSize и TempCacheLimit) на GTT никак не влияют :-) А TempBlockSize я бы советовал выставлять не более 5% от TempCacheLimit и не менее 1МБ (дефолтное значение).
Плюс добавить "мантру" (DS'a, кажется): размер страничного кеша д.б. равен примерно половине объема физ. памяти.
Плюс добавить инфу о том, что если в CS/SC команда fb_lock_print -c -d <database> | grep -i "hash lengths" выдаёт для "min/avg/max" значения больше, чем M1 / M2 / M3, то надо делать "то-то и то-то" (M1, M2, M3 - не помню точно их; но max был меньше 15-20).

ЗЫ. Еще неплохо бы скопипастить туда (с разрешения автора, ес-сно) статью про настройку keep-alive'ов в nix/win. Эти параметры влияют на время отвала мертвяков, их дефолтные значения могут приводить к "недоразумениям".

Alexey KovyazinРазмер страничного кэша до 2.5 включительно на SuperServer (речь то про него?) ставить надо в 10000. Якобы есть процедуры разогрева кэша и прочая-прочая для больших значений, но эффект от такого тюнинга минимальный, а вот геморроя и тестов выше крыши .А это не устаревшие страшилки ? Какой там гемор, в чём он ?
Я вот помню, что Главный Источник Света сказал, что это давно уже пофиксено, с 2.0 вроде. Не могу найти сиё, но точно помню разговор на эту тему.

Alexey KovyazinДля Classic и SuperClassic совет тем более не годится - намедни ребята из Австралии обратились с БД в 5Гб и 128Гб ОЗУ, с 80 коннектами. По этой логике, надо каждому коннекту воткнуть по 50 тысяч буферов? :)
И у россиян такое видели, в Инфоклинике.Гм... ну, а какой тогда верхний лимит-то для CS/SC ? 10 тыс страниц ?

Alexey KovyazinНа 3.0 в твоем тесте и вообще ситуация с кэшем более интересная, и эффект от разогрева виден невооруженным взглядом, но с 3.0 мы только начинаем набирать практический оптимизационный опыт - т.к. коллективных разум юзеров в плане создания проблем куда как мощнее силы предвидения разработчиков :)Эффект от разогрева в 3.0 начинает проявляться только при большом числе коннектов (больше 175), а на 2.5 - сразу (скрин - с презентухи к конфе-2014)