добрый день
есть одномоментное обновление нескольких миллионов записей, по логам заходит где-то 30-40тыс записей в секунду (меняется 1 int, 3 остальных int - ключ в hash)
memtx, 1 мастер + реплики. обновление идет через роутер и дальнейший vshard.router.call(функция) на мастер, на мастере функция перебирает массив и делает 1000(или меньше) upsert.

через некоторое время получается куча предупреждений на мастере, потом на репликах
main txn.c:487 W> too long WAL write: 1 rows at LSN 180557302: 0.789 sec
далее
main/104/lua I> Could not reach node: 10.0.2.2:3319 - suspect
main/104/lua I> Node timed out: 10.0.2.3:3319 - dead

main/316/lua utils.c:1007 E> LuajitError: not enough memory

main txn.c:487 W> too long WAL write: 1 rows at LSN 181886605: 0.839 sec
main txn.c:487 W> 111116 messages suppressed

и заканчивается
main/105/lua C> not enough memory
SegFaultом и поеданием всей оперативки на сервере (до 10гигов на инстанс, кто сколько успеет) при ограничении на 1.5гига/инстанс и 350мб данных. дальше уже ничего не работает вообще

вопрос - а можно ли что-то с этим сделать, чтобы оно не падало и как понять, чего ему не хватает вообще? ssd не вывозит? код приложения хреновый? надо в индексацию слипов добавить?

Уж не pairs ли это часом

А что за функция?

мониторить луа память и гц метрики

нет, pairs тут нет (есть в другом месте, в получении данных). весь код выглядит схематично так

php

$tarantool->call('api.update', [[1,2,3,4] x 1000раз])

роутер

defaultRouter = cartridge.service_get('vshard-router').get()
defaultRouter:callrw(1, 'storage.update', { params }, { timeout = 1800 })

хранилище

function update(records)
    for i = 1, #records do
        update_item(records[i].product_id, records[i].type, records[i].location, records[i].days)
    end
end

///update_item
local record = {
        productId,
        location,
        0, 
        days, 
    }
    box.space.aaa:upsert(record, { { '=', 4, days } })

кто нить пробовал https://plugins.jetbrains.com/plugin/14780-tarantool-database ?

Можно добавить агрессивную сборку мусора

а где можно глянуть, какие выводы на основе этих метрик делать? много это или мало и можно ли на это повлиять..

если там пила - то можно попробовать агрессивный гц

если он просто не успевает

по описанному - похоже

Там ENOMEM. Очень похоже на кучу несобранного мусора

И ещё цикл с апдейтом заверните в транзакцию

ну то есть два варианта - либо просто не успевает в пике, либо где-то копится

не помню, как влияли транзакции именно в этом наборе апдейтов, но в целом в первой версии были транзакции и было совсем печально(  но возможно не в этом апдейте, попробую еще раз

а агрессивность сборщика это какие настройки крутятся?

это не настройки, это можно фоновый файбер воткнуть

который его будем сам дергать

Вообще по хорошему нужно измерять скорость апдейтов
если скорость апдейтов больше, чем входящая нагрузка, то проблема где-то в Lua/GC
если скорость апдейтов меньше, то идёт просто лавинообразное накопление запросов

я бы порекомендовал просто прогнать такую нагрузку на апдейт в простом цикле и посмотрел сколько апдейтов в секунду оно даст

Есть клиент для Go (https://github.com/tarantool/go-tarantool)
Он использует пакет (gopkg.in/vmihailenco/msgpack.v2) для msgpack.
Для быстрого распаковки и упаковки msgpack предлагается реализовать методы EncodeMsgpack и DecodeMsgpack.
Вопрос: есть ли готовый пакет для кодогенерации методов `EncodeMsgpack` и `DecodeMsgpack` на основе структуры с анотациями?
Например, как это реализовано в easyjson