- Сколько ОЗУ использует каждый из этих процессов по умолчанию?
По умолчанию:
- Процесс yb-tserver предполагает, что 85% ОЗУ узла составляетдоступны для его использования.и
- Процесс yb-master предполагает, что 10% ОЗУ узла доступно для его использования.
Они определяются настройками по умолчанию gflag --default_memory_limit_to_ram_ratio (0,85 и 0,1 соответственно дляYB-tserver / Yb-мастер).
Есть ли способ явно контролировать это?
Да, есть 2 различных варианта для контроля того, сколько памяти выделено процессам yb-master и yb-tserver:
Вариант A) Вы можете установить --default_memory_limit_to_ram_ratio, чтобы контролировать, какой процент ОЗУ узла должен использовать процесс.
Вариант B) Вы также можете указать абсолютное значение, используя --memory_limit_hard_bytes.Например, чтобы получить 32 ГБ оперативной памяти для yb-tserver, используйте:
--memory_limit_hard_bytes 34359738368
Поскольку эти два процесса запускаются независимо, вы можете использовать любую из опций для yb-master или yb-tserver,Просто убедитесь, что вы не переподписываете общий объем памяти компьютера, поскольку процессы yb-master и yb-tserver могут присутствовать на одной виртуальной машине.
Предположительно, память используется для кеширования, создания таблиц памяти и т. Д. Как измеряются эти компоненты?
Да, основными потребителями памяти являются блочный кеш, memstores и память, необходимые для запросов / RPCв полете.
Кэш блока: --db_block_cache_size_percentage=50 (default)
Общее количество хранилищ - минимум этих двух ручек: --global_memstore_size_mb_max=2048 --global_memstore_size_percentage=10
Могут ли определенные таблицы быть закреплены в памяти (или, скажем, с более высоким приоритетом в кэшах)?
В настоящее время (по состоянию на 1.1) пока нет подсказок для закрепления таблицы.Тем не менее, кеш блоков уже отлично справляется с хранением горячих блоков в кеше.Мы улучшили блочный кеш RocksDB, чтобы обеспечить его устойчивость к сканированию.Мотивация состояла в том, чтобы предотвратить такие операции, как длительные сканирования (например, из-за случайного большого запроса или фоновых заданий Spark), от загрязнения всего кэша низкокачественными данными и удаления полезных / горячих данных.