Не за что! :-) Размер настраивается автоматически. Пока идет текущий fsync, все следующее копится в буфере. fsync прошел — тут же начинается запись буфера на диск и последующий fsync, а тем временем уже копится новый буфер. Все параллельно как в сказке моего детства: "— Одну ягодку беру, на другую смотрю, третью замечаю, а четвёртая
мерещится. " — skazki.org.ru/tales/dudochka-i-kuvshinchik
Резонный вопрос — почему нет настроек? Рассмотрим два варианта настроек:
1. Что если записывать буфер на диск не сразу после завершения предыдущего fsync, а еще подкопить его некоторый интервал времени? Это очевидно, ухудшит latency — клиенты будут ждать дольше ответ. Но никак не улучшит потолок throughput — просто потому, что все что не записалось сейчас, запишется в следующем fsync, который автоматом возьмет на себя больше записей, которые в этот раз не успели записаться.
2. Что если записывать буфер на диск не полностью. Это, очевидно, ухудшит потолок throughput, т.к. сделает fsync более частым, но почти никак не повлияет на latency, т.к. основное время будет уходить не на сискол write, даже если их много, а на сискол fsync.
P.S.
Ну и давайте уже к практике переходить. Обычно Тарантул обеспечивает такие скорости и с таким запасом, что подобного рода настройки излишне. С другой стороны, если Тарантул тормозит, то и настройки такие не помогут — обычно проблема или в зациклившийся луашке или в десятках индексах на таблицу :-)
Вы слишком плохого мнения о Tarantool и неверно представляете себе как работает Тарантул :) Пакеты группируются из параллельных запросов, которые летят из разных файберов. Ответ клиенту приходит только после записи ВСЕГО пакета на диск и выполнения fsync. Учите матчасть: habrahabr.ru/company/mailru/blog/317274
Вы имеете в виду пройтись по логу, понять, какие таблицы затронуты, далее считать эти таблицы из снэпшота, применить к каждой из них лог? Ну или распишите ваш алгоритм подробнее. Пока мне кажется, что ваш вариант будет в худшем случае O(N) по памяти, что есть явное ухудшение текущей ситуации, поэтому ответ на ваше «почему нельзя» такой — потому что это потребляет больше памяти.
«либо как вариант процессу шарить конкретно по диску и писать в необходимые файлы пришедшие данные» — это не понял вообще, сорри.
«Интересная задача, у меня вопрос, почему нельзя использовать отдельный процесс, который бы работал с копией базы на диске и применял к ней лог транзакций?» — применять как? Загрузить всю базу еще раз в память, удвоив количество необходимой памяти, применив логи и сохранив в новый файл? Поделитесь алгоритмом применения, если не сложно, чтобы он был линейный по времени исполнения и меньше чем линейный по дополнительной памяти. Заранее спасибо.
Запилите то же самое через Message Queues, выложите в продакшн, пустите нагрузку от реальных пользователей. И дальше мы с удовольствием почитаем на Хабре про ваш опыт.
Ну это же не запись в свой родной лог транзакций, это запись в другую СУБД. Что тут же делает работу игнайта на запись не быстрее чем эта СУБД. Плюс, в случае разрыва сети возможны повторные записи (в СУБД запись прошла, сеть порвалась, игнайт про это не узнал — сделал ритрай, получили повторную запись
мерещится. " — skazki.org.ru/tales/dudochka-i-kuvshinchik
Резонный вопрос — почему нет настроек? Рассмотрим два варианта настроек:
1. Что если записывать буфер на диск не сразу после завершения предыдущего fsync, а еще подкопить его некоторый интервал времени? Это очевидно, ухудшит latency — клиенты будут ждать дольше ответ. Но никак не улучшит потолок throughput — просто потому, что все что не записалось сейчас, запишется в следующем fsync, который автоматом возьмет на себя больше записей, которые в этот раз не успели записаться.
2. Что если записывать буфер на диск не полностью. Это, очевидно, ухудшит потолок throughput, т.к. сделает fsync более частым, но почти никак не повлияет на latency, т.к. основное время будет уходить не на сискол write, даже если их много, а на сискол fsync.
P.S.
Ну и давайте уже к практике переходить. Обычно Тарантул обеспечивает такие скорости и с таким запасом, что подобного рода настройки излишне. С другой стороны, если Тарантул тормозит, то и настройки такие не помогут — обычно проблема или в зациклившийся луашке или в десятках индексах на таблицу :-)
«либо как вариант процессу шарить конкретно по диску и писать в необходимые файлы пришедшие данные» — это не понял вообще, сорри.