Потребление памяти при использовании vinyl

[Eldar Kononov]

Всем привет!

Смотрим сейчас tarantool для наших задачек. В данный момент используем редис. По размеру данных подходим к пределам одного сервера.

В тарантул нравится понятная (внешне) master-master репликация с приемлемым резолвом конфликтов и заявленное наличие on-disk хранилища.

Шардированием заниматься лень, т.к. нагрузка на базу вполне исполнима на дисковом хранилище (порядка 1000 записей в сек, и 100 чтений). А шарды увеличивают энтропию сервиса :)

Среда:

ОС: FreeBSD 10.3-RELEASE-p5 #0 r301414

Tarantool из портов.

Tarantool 1.7.3-99-gca4b9c0

Target: FreeBSD-amd64-Rel

Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_BACKTRACE=OFF

Compiler: /usr/bin/cc /usr/bin/c++

C_FLAGS:-O2 -pipe  -fstack-protector -fno-strict-aliasing -Wno-unknown-pragmas -fexceptions -funwind-tables -fno-common -std=c11 -Wall -Wextra -Wno-strict-aliasing -Wno-unused-value

CXX_FLAGS:-O2 -pipe -fstack-protector -fno-strict-aliasing -Wno-unknown-pragmas -fexceptions -funwind-tables -fno-common -std=c++11 -Wall -Wextra -Wno-strict-aliasing -Wno-unused-value

Создаем space:

box.schema.create_space('private_disk2', {engine = 'vinyl'})

Создаем индекс:

box.space.private_disk2:create_index('primary', {parts = {1, 'unsigned'}})

Конфигурация такая:

# echo "box.cfg" | tarantoolctl eval private_disk

---

- snapshot_count: 3

  too_long_threshold: 0.5

  slab_alloc_factor: 1.06

  slab_alloc_minimal: 16

  background: true

  logger: /var/log/tarantool/private_disk.log

  readahead: 16320

  wal_dir: /var/db/tarantool/private_disk

  listen: public_addr:3301

  vinyl:

    page_size: 8192

    memory_limit: 1

    compact_wm: 2

    threads: 1

    range_size: 1073741824

  logger_nonblock: true

  vinyl_dir: /var/db/tarantool/private_disk

  snap_dir: /var/db/tarantool/private_disk

  coredump: false

  read_only: false

  log_level: 5

  slab_alloc_maximal: 52428800

  wal_mode: write

  hot_standby: false

  panic_on_snap_error: true

  panic_on_wal_error: true

  slab_alloc_arena: 5

  snapshot_period: 86400

  pid_file: /var/run/tarantool/private_disk.pid

  username: tarantool

  rows_per_wal: 5000000

  wal_dir_rescan_delay: 2

Когда я смотрел memtx, то полный набор моих данных из порядка 120 миллионов умещался в 60Гб.

Пытаюсь заливать свои данные в vinyl.

Где-то на 28 миллионах вставленных записей процесс tarantool потребляет 50Гб оперативной памяти. Дальше тест проводить смысла нет.

По ходу заливки и выделения памяти, было видно, что SIZE примерно равен RES + slab_alloc_maximal, откуда можно сделать вывод, что память выделяется отдельно от арены.

Увидел волшебный параметр vinyl.memory_limit. Пошел на github искать, как он используется.

Но либо я плохо искал, либо он только в vy_conf зачитывается в vinyl.c, но дальше никак не используется.

Искал так:

https://github.com/tarantool/tarantool/search?utf8=%E2%9C%93&q=memory_limit

Собственно, вопросы:

1. Как так получается, что потребление памяти при vinyl выше, чем при использовании memtx?

2. На что vinyl потребляет память?

3. Почему он потребляет существенно больше фактического объема данных?

4. Как ограничить потребление оперативной памяти vinyl?

5. Учитывая то, что затык произошел в самом начале просто на первичном заливании данных, может быть я что-то сделал не так? Как понять? Ведь оно же как-то проходило тестирование перед релизом? :)

Заранее спасибо за ответы.

Эльдар Ко.

[Konstantin Osipov]

* Eldar Kononov <ekon...@gmail.com> [17/03/09 17:04]:

Обновитесь. Мы в винил коммитим по 3-5 патчей в день.

Попали на версию с мемликом.

> ОС: FreeBSD 10.3-RELEASE-p5 #0 r301414
>
> Tarantool из портов.
>
> Tarantool 1.7.3-99-gca4b9c0
> Target: FreeBSD-amd64-Rel

>

> https://github.com/tarantool/tarantool/search?utf8=%E2%9C%93&q=memory_limit

Теперь эта ручка по-другому зовётся. Сейсас допишу письмо и катну
rename. Приходите в чат, мы всё расскажем.

> Собственно, вопросы:
>
> 1. Как так получается, что потребление памяти при vinyl выше, чем при
> использовании memtx?

Утёк.

> 2. На что vinyl потребляет память?

1) На l0 lsm дерева
2) на page index
3) на tuple cache

1) и 3) регулируются явно, 2) через 5 ручек: page_size,
range_size, run_count_per_level, level_size_ratio, bloom_fpr

> 3. Почему он потребляет существенно больше фактического объема данных?

Утёк!

> 4. Как ограничить потребление оперативной памяти vinyl?

Да у вас по ходу один вопрос-то на самом деле: ГДЕ БЛИН МОЯ
ПАМЯТЬ? :)))
Спасибо что приличными словами хоть пишете :-)))

> 5. Учитывая то, что затык произошел в самом начале просто на первичном
> заливании данных, может быть я что-то сделал не так? Как понять? Ведь оно
> же как-то проходило тестирование перед релизом? :)
>
> Заранее спасибо за ответы.
>
> Эльдар Ко.

В Винил ещё будем катить несколько важных патчей. После этого
только мороз, только багфиксы.

--
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.org - www.twitter.com/kostja_osipov

[Eldar Kononov]

Константин, спасибо за ответы.

Ситуация понятна.

А насколько стабильно работала sophia?

Мой ход мыслей под этим вопросом таков: очевидно, винил делался для предельных нагрузок. Это, несомненно, хорошее начинание, но предельные нагрузки - это более сложный код. А значит и большее число багов.

С моими нагрузками (100Гб данных, 1000 write/update rps + 100read rps) можно справится и без особых финтов. Так может быть вместо пока еще явно нестабильного винила взять что-то проще, медленнее, но стабильнее?

Выше вы пишете, что "В Винил ещё будем катить несколько важных патчей". Когда эта "looks good" версия примерно планируется к релизу?

Спасибо.

четверг, 9 марта 2017 г., 23:39:08 UTC+1 пользователь Konstantin Osipov написал:

[Veniamin Gvozdikov]

On Friday, March 10, 2017 at 12:04:24 PM UTC+3, Eldar Kononov wrote:

Константин, спасибо за ответы.

Ситуация понятна.

А насколько стабильно работала sophia?

Sophia больше нет, доработанная sophia это vinyl .

Выше вы пишете, что "В Винил ещё будем катить несколько важных патчей". Когда эта "looks good" версия примерно планируется к релизу?

Ребята обещали что в 1.7.4, то есть скоро.

 

[Veniamin Gvozdikov]

Tarantool из портов.

Tarantool 1.7.3-99-gca4b9c0

В портах есть новей с вторника (последняя на тот день). 

[Eldar Kononov]

Вижу. Обновил. Заливаю. Спасибо.

пятница, 10 марта 2017 г., 10:49:03 UTC+1 пользователь Veniamin Gvozdikov написал:

[Konstantin Osipov]

* Eldar Kononov <ekon...@gmail.com> [17/03/10 12:05]:

> Константин, спасибо за ответы.
>
> Ситуация понятна.
>
> А насколько стабильно работала sophia?

Софии больше нет. Мы её удалили из 1.6

> Мой ход мыслей под этим вопросом таков: очевидно, винил делался для
> предельных нагрузок. Это, несомненно, хорошее начинание, но предельные
> нагрузки - это более сложный код. А значит и большее число багов.
> С моими нагрузками (100Гб данных, 1000 write/update rps + 100read rps)
> можно справится и без особых финтов. Так может быть вместо пока еще явно
> нестабильного винила взять что-то проще, медленнее, но стабильнее?
>
>
> Выше вы пишете, что "В Винил ещё будем катить несколько важных патчей".
> Когда эта "looks good" версия примерно планируется к релизу?

Вы хотя бы попробуйте текущую версию. Уверен, что впечатления уже
будут хорошие.
1.7.4-gamma планируем в ближайшие недели, более точно сказать не
могу.

[Eldar Kononov]

Попробовал последнюю версию из портов, про которую написал Вениамин.

1.7.3-318-gba3b221

Первые впечатления были хорошие. По крайней мере что-то куда-то загружалось без чрезмерного потребления памяти.

Где-то на 30 миллионах я решил параллельно посмотреть, а сколько точно записей в спэйсе. Ну, и вообще, что будет :)

Запустил вот такое:

echo "local cnt = 0; for k,v in box.space.private_disk:pairs() do cnt = cnt + 1 end; return cnt;" | tarantoolctl eval private_disk

Вместо ответа на заданный вопрос случилось такое:

2017-03-10 17:56:11.540 [70981] main/102/vinyl.scheduler I> 512/1: started dumping range (-inf..inf)

2017-03-10 17:56:15.094 [70981] main/102/vinyl.scheduler I> 512/1: completed dumping range (-inf..inf)

Segmentation fault

Current time: 1489158029

Please file a bug at http://github.com/tarantool/tarantool/issues

Я его перезапустил. Он долго и упорно восстанавливался из xlog файлов. 

Тут у меня вопрос есть: если vinyl хранит все на диске, то зачем ему восстанавливаться все с начала?

Где-то вроде было написано, что vinyl как бы сам себе снапшот (что логично). По идее, ему ведь и не нужно тогда воспроизводить все из xlog?

После перезапуска код по подсчету числа записей он выполнил:

# echo "local cnt = 0; for k,v in box.space.private_disk:pairs() do cnt = cnt + 1 end; return cnt;" | tarantoolctl eval private_disk

---

- 32319253

Дальше проверил 2 сценария:

1. Запуск команды на подсчет при параллельной заливке те данных, которые уже есть в базе.

2. Запуск команды на подсчет при параллельной заливке новых данных.

Для заливки использую replace.

В обоих случаях скрипт отработал нормально и выдал мне количество записей. Так что сабмитить в качестве issue нечего :)

пятница, 10 марта 2017 г., 15:56:24 UTC+1 пользователь Konstantin Osipov написал:

[Konstantin Osipov]

* Eldar Kononov <ekon...@gmail.com> [17/03/10 19:38]:

ОК, спасибо, крэш будем иметь ввиду.

По поводу скорости перезапуска: у вас какой сheckpoint interval?
Это ручка в конфиге.

> --
> Вы получили это сообщение, поскольку подписаны на группу tarantool-ru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Eldar Kononov]

пятница, 10 марта 2017 г., 18:13:07 UTC+1 пользователь Konstantin Osipov написал:

* Eldar Kononov <ekon...@gmail.com> [17/03/10 19:38]:

ОК, спасибо, крэш будем иметь ввиду.

По поводу скорости перезапуска: у вас какой сheckpoint interval?
Это ручка в конфиге.

checkpoint_interval - сутки. И сделано это осмысленно, чтобы в процессе загрузки он постоянно не сохранялся.

Я просто себе это как вижу...

В случае с in-memory, при запуске данные надо откуда-то взять. Мы их берем из последнего snap + накатываем xlog. Тут просто нет других вариантов.

Но в случае с on-disk хранилищем данные как бы уже лежат на диске в правильнопроиндексированном виде. Нужно только восстановить в память тот l0 lsm, о котором вы писали выше.

Видимо, я ошибаюсь и все сложнее.

[Konstantin Osipov]

* Eldar Kononov <ekon...@gmail.com> [17/03/10 20:19]:

> > По поводу скорости перезапуска: у вас какой сheckpoint interval?
> > Это ручка в конфиге.
> >
> >
> checkpoint_interval - сутки. И сделано это осмысленно, чтобы в процессе
> загрузки он постоянно не сохранялся.
>
> Я просто себе это как вижу...
> В случае с in-memory, при запуске данные надо откуда-то взять. Мы их берем
> из последнего snap + накатываем xlog. Тут просто нет других вариантов.
>
> Но в случае с on-disk хранилищем данные как бы уже лежат на диске в
> правильнопроиндексированном виде. Нужно только восстановить в память тот l0
> lsm, о котором вы писали выше.
>
> Видимо, я ошибаюсь и все сложнее.

Всё правильно. Бага заключается в том, что мы пока автоматически
не передвигаем текущий чекпоинт вперёд, когда данные винила
оказываются на диске. Ровно над этим мы сейчас и работаем.
В 1.7.4 появится новый файл, .xctl, похожий на Oracle control
file, в котором мы сможем хранить состояние последнего чекпоинта.
После этого появится собственно куда писать - потому что сейчас
состояние чекпоинта берётся из чекпоинта мемтикс.

Пока просто поставьте checkpoint_interval в 30-60 минут,
восстановление это должно ускорить, а нагрузку на диск увеличит
незначительно.