нужна наша помощь по логотипу, просьба потратить минутку на короткрий опрос: https://forms.yandex.ru/surveys/10022588.cef650836a35cf646d91bf2e532696e9660a2427/
две низкоуровневые вчера, давайте одну высокоуровневую - сегодня ))) https://github.com/ClickHouse/ClickHouse/issues/11722
кстати hugepages в оракл испольщуется для SGA (buffer cache - скешированные в память блоки, in-memory tables, процедуры/бд код). Т.е. в терминологии КХ - данные default пользователя (не ассоциированные с запросом). Но в КХ таких данных мало обычно - (кеш засечек, метаданные, словари наверно, и вроде все)... Наверно можно разрешить КХ использовать N HP страниц для словарей если их много с помощью параметра?
ораклу hugepages помогает именно для буфферного кеша и в режиме dedicated, экономит память в первую очередь. проблема именно в режиме dedicated, у каждого процесса свое адресное пространство, своя TLB 338 лет назад, у меня при SGA_TARGET 14G случилась PageTables > 2G , при 200 dedicated сессиях, т.е. фактически 2 ГБ ушло на TLB при 14GB полезных.
Режим dedicated/shared влияет на память процесса. Это PGA, он вообще не умеет HugePages использовать. SGA это именно системная память, ей пофиг на dedicated/shared mode. Это вообще не про это, либо мы терминологию используем по-разному.
buffer pool в sga. Но это не важно как называть. суть в том что кеш датаспейсов -- буфферный пул это shared memory. Но каждый процесс -- unix process видит ее в своем адресном пронстранстве и у них у всех собственная tlb.
Да, вы правы. В случае с КХ конечно ввиду однопроцессности в этом плане (полезное использование памяти) такой пользы не будет. Но все равно по скорости и % ТЛБ кеш попаданий будет на порядок лучше в условиях больших словарей/кешей.
Обсуждают сегодня