KA
хотя... 1 row. винил не используете?
Не, только в памяти
Size: a a a
2020 July 09
KA
не пишите пачками и будет гарантированная низкая задержка
Тут меня интересует какие архитектурные решения приняты внутри тарантула, грубо говоря latency vs throughput
MA
Когда я сказал, что пришла пачка, я имел в виду не батч на уровне протокола, а перекос по нагрузке в данный момент времени
"пачку" обрабатываете длинными циклами?
MA
чего-то принятого нет, каждый выбирает себе под задачу
KA
"пачку" обрабатываете длинными циклами?
в луашке есть цикл, в котором собирается кортеж а потом за один replace записывается. по размеру кортежа не могу сказать, пока не смотрели
KA
чего-то принятого нет, каждый выбирает себе под задачу
это как? буферизация есть уже наверняка хотя бы на уровне чтения из сокета, я могу там что то покрутить?
MA
это как? буферизация есть уже наверняка хотя бы на уровне чтения из сокета, я могу там что то покрутить?
на сокете есть io_collect_interval
но он по дефолт у в 0. затуп где-то при обновлении происходит.
после этого апдейта есть что-то, что занимает врем на почти секунду.
но он по дефолт у в 0. затуп где-то при обновлении происходит.
после этого апдейта есть что-то, что занимает врем на почти секунду.
KA
ого, круто! не знал что тарантул позволяет такой микротюнинг
KA
в строчке лога написано, что затуп именно на записи в WAL. я правильно понимаю, что долгое выполнение луашки можно исключить и блокировка происходит уже где то после вызова replace?
MA
в строчке лога написано, что затуп именно на записи в WAL. я правильно понимаю, что долгое выполнение луашки можно исключить и блокировка происходит уже где то после вызова replace?
насколько я помню, замер происходит в tx треде между "мы записали в memtx" и "получили ответ от wal"
соответственно если мы приложим tx какой-то работой после записи, то запись произойдёт быстро, но об этом мы узнаем поздно, тем самым сгенерируем too long
соответственно если мы приложим tx какой-то работой после записи, то запись произойдёт быстро, но об этом мы узнаем поздно, тем самым сгенерируем too long
DS
в строчке лога написано, что затуп именно на записи в WAL. я правильно понимаю, что долгое выполнение луашки можно исключить и блокировка происходит уже где то после вызова replace?
нельзя, может это гц например
DS
монс правильно описал
MA
нельзя, может это гц например
> "теоретически это ещё может быть gc".
^^^ буквально не успел Enter нажать :)
^^^ буквально не успел Enter нажать :)
DS
у дураков мысли сходятся
DS
MA
@gibsn а что по CPU usage (вообще и в момент too long)?
и что по различным метрикам?
и что по различным метрикам?
KA
@gibsn а что по CPU usage (вообще и в момент too long)?
и что по различным метрикам?
и что по различным метрикам?
другие метрики, к сожалению, у нас с частотой раз в несколько минут 🙁 таск на админов уже поставлен
KA
по системным: диски ок, памяти ок, цпу на всей тачке нагружен не сильно, потоков хватает. сейчас прикину сколько цпу жрет один шард в среднем
MA
другие метрики, к сожалению, у нас с частотой раз в несколько минут 🙁 таск на админов уже поставлен
эх, monit'а на вас нет, с частотой в 1s ;)
OK
в луашке есть цикл, в котором собирается кортеж а потом за один replace записывается. по размеру кортежа не могу сказать, пока не смотрели
А луашная логика у вас в транзакции?