Использование памяти ArangoDB

Я пытаюсь понять, каковы пределы Arangodb и что такое идеальная установка. Из того, что я понял, arango хранит все данные коллекции в виртуальной памяти, и в идеале вы хотите, чтобы это было вместимо в ОЗУ. Если коллекция растет и не может поместиться в ОЗУ, она будет заменена на диск.

Итак, мой первый вопрос. Если мой db будет расти, мне нужно будет отрегулировать раздел/файл подкачки для размещения db?

Поскольку arango также синхронизирует данные с диском, означает ли это, что данные всегда будут находиться в ОЗУ и диске? Итак, если у меня есть db, что 1,5 ГБ, а моя оперативная память - 1 ГБ, мне нужно будет по крайней мере иметь 0,5 ГБ дискового пространства и 1,5 ГБ свободного места на диске?

Я немного смущен тем, как arango использует виртуальную память. Сейчас у меня есть 7 коллекций, которые практически пусты. У меня 1 ГБ оперативной памяти и 1 ГБ диска подкачки. Администратор сообщает, что arango использует 4,5 ГБ виртуальной памяти. Как это возможно, если обменный диск равен 1 ГБ? В настоящее время он использует 80 МБ ОЗУ. Разве это не должно быть 224 МБ, если размер журнала составляет 32 МБ для каждой коллекции?

Какова рекомендация по размеру журнала и размеру коллекции? Можно ли это динамически корректировать по мере роста коллекции?

Какая производительность ожидается, если диск подкачки используется много, когда диск является SSD? Если диск подкачки используется много, производительность будет похожа на использование более традиционного db, такого как mysql?

Ответ 1

ArangoDB сохраняет все данные в файлах с отображением памяти. Каждая коллекция может содержать от 0 до n файлов данных с размером файлов по умолчанию по 32 МБ (обратите внимание, что этот размер файла можно настроить глобально или на уровне сбора). У пустой коллекции (у которой никогда не было данных) нет файла данных. Первая запись в коллекцию создаст файл данных, и всякий раз, когда файл данных будет заполнен, новый будет создан автоматически.

Коллекции выделяют файлы данных в кусках по 32 МБ по умолчанию. Если у вас есть много небольших коллекций, это может привести к некоторой памяти. Если у вас много, но больших коллекций, потенциальные отходы (свободное пространство в конце файла данных), вероятно, не имеют большого значения.

Всякий раз, когда любая операция ArangoDB считывает данные или записывает данные в файл данных с отображением памяти, операционная система сначала переводит смещение в файл на номер страницы. Это связано с тем, что каждый файл данных неявно разбивается на страницы определенного размера. Насколько велика страница, зависит от платформы, но пусть предполагают, что страницы имеют размер 4 КБ. Таким образом, файл данных с размером файла по умолчанию будет иметь 8192 страниц.

После того, как ОС переведет смещение в файл на номер страницы, он будет убедиться, что данные запрашиваемой страницы присутствуют в физической ОЗУ. Если страница еще не находится в физической ОЗУ, операционная система выдаст ошибку страницы, чтобы вызвать загрузку запрошенной страницы с диска или обменять ее на физическую ОЗУ. Это, в конечном счете, сделает всю страницу доступной в ОЗУ, и после этого могут произойти любые чтения или записи данных страницы.

Все это выполняется диспетчером виртуальной памяти операционной системы. Операционная система может отображать как можно больше страниц из файла данных в ОЗУ, поскольку это хорошо. Например, при обращении к файлу с отображением памяти последовательно, операционная система, вероятно, будет умной и прочитанной на многие страницы, поэтому они уже находятся в физической ОЗУ при фактическом доступе.

ОС также может свободно менять некоторые или все страницы файла данных. Скорее всего, он будет заменять страницы, если недостаточно физической физической памяти для одновременного хранения всех страниц из всех файлов данных в ОЗУ. Он также может менять страницы, которые не использовались какое-то время, чтобы сделать RAM доступной для других операций. Вероятно, для этого будет использоваться некоторый алгоритм LRU.

То, как ведет себя виртуальная диспетчер виртуальной памяти, сильно отличается от разных платформ и реализаций. Большинство систем также позволяют настраивать подсистему VM. Например, вот некоторые параметры подсистемы Linux VM.

Поэтому трудно сказать, сколько физической памяти ArangoDB фактически будет использовать для определенного количества коллекций и их файлов данных. Если коллекции не имеют доступа вообще, если отображение данных в файлах данных может использоваться почти без ОЗУ, так как ОС, вероятно, полностью или частично поменяла коллекцию. Если коллекции сильно используются, операционная система, скорее всего, будет полностью отображать свои файлы данных в ОЗУ. Но в обоих случаях память рассчитывается как отображаемая память. Это вы можете использовать гораздо более высокую виртуальную память, чем у вас есть физическая оперативная память.

Как упоминалось ранее, ОС должна выполнять большую работу при доступе к страницам, которые не находятся в ОЗУ, и вы хотите избежать этого, если это возможно. Если общий размер ваших часто используемых коллекций превышает размер физической ОЗУ, у ОС нет альтернативы, кроме как поменять местами страницы и много, когда вы обращаетесь к этим коллекциям. Использование SSD для свопа, скорее всего, будет лучше, чем использование вращающегося жесткого диска, но все еще намного медленнее, чем доступ к ОЗУ. Короче говоря: данные ваших активных коллекций (datafiles plus index) должны поместиться в физическую RAM, если это возможно, или вы увидите много активности на диске.

Кроме того, ArangoDB не только выделяет виртуальную память для файлов данных коллекции, но также запускает несколько потоков V8 (V8 - это механизм JavaScript в ArangoDB), который также использует виртуальную память. Эта виртуальная память не поддерживает файлы.

В пустой ArangoDB V8 учитывается большая часть использования виртуальной памяти. Например, на моем 64-битном компьютере потоки V8 потребляют около 5 ГБ виртуальной памяти (но ArangoDB в общей сложности использует только 140 МБ ОЗУ), тогда как на моем 32-битном компьютере с меньшей оперативной памятью потоки V8 используют около 600 - 700 МБ виртуальная память. В вашем случае, при использовании виртуальной машины на 4,5 ГБ, я подозреваю, что причина V8 тоже.

Использование виртуальной памяти для потоков V8, очевидно, коррелирует с количеством запущенных потоков V8. Например, увеличение значения параметра запуска --server.threads начнет больше потоков и будет использовать больше виртуальной памяти для V8, а при снижении значения начнется меньше потоков и будет меньше виртуальной памяти.