1. нужно ли держать 2 коннекта читающий ид-ы и пишущий отметку о посылке, с учетом того, что второй поток произвольно пишет ответы или лучше в первом потоке выгружать, например, все в std::vector и потом в другой транзакции последовательно записывать запросы?

Весь вопрос в быстродействии

таблица подвергающаяся модификации одна?

Вы там update что ли делаете?

количество записей в секунду?

pastor писал(а) Fri, 19 January 2024 09:45

количество записей в секунду?

приблизительно оценил в >100 записей в секунду )
не каждую секунду конечно, волнами нагрузка приходит, но оказалось в многопоток опрашивать железки достаточно "быстро" получается.

. препарированный запрос может жить и после коммита

на препарированных запросах на 2.5 получается до 40 000/сек по 4кб на запись

pastor писал(а) Mon, 22 January 2024 12:17

на препарированных запросах на 2.5 получается до 40 000/сек по 4кб на запись

вопрос же не в количестве записей в секунду (что определяется вообщем то железом), а в количестве транзакций, вы оформите каждую запись в транзакцию и тогда сколько будет?
повторюсь - 2 конкурирующих потока делают update одной и той же таблицы.
сейчас просто первую статистику получил на 150 железках, когда 2 потока складывают в 3ий и уже только он пишет пачкой.

повторюсь - 2 конкурирующих потока делают update одной и той же таблицы.

Они что, одну и ту же запись апдейтят ?

если потоки не пересекаются по устройствам - то откуда дедлоки?

pastor писал(а) Mon, 22 January 2024 13:50

если потоки не пересекаются по устройствам - то откуда дедлоки?

запрос может пересечься с ответом и они попытаются обновить одну и ту же строку.
пробовал поштучно опрашивать с ожиданием ответа, так cron успевает еще 2-3 раза начать задания крутить из за значительного времени ожидания ответа с медленных железок.
предметно говоря - отправляю я mqtt сообщение на железку, а она мне должна прислать снимок с камеры как получится

hvlad писал(а) Mon, 22 January 2024 14:18

Они что, одну и ту же запись апдейтят ?

да, столбцы только разные )

пока никакая "правильная" структура в голову не приходит.

id     integer
field1 integer
field2 integer
field3 integer

id       integer
id_field integer
value    integer

тогда придется каждый раз пересчитывать 100500 железок * на количество записей и удалять все бесполезное позже какого то периода другим потоком с каким то интервалом, а так получается всегда записана текущее значение "уровня сигнала" на железке - т.е. нагрузка существенно возрастет.

тогда придется каждый раз пересчитывать 100500 железок * на количество записей и удалять все бесполезное позже какого то периода другим потоком с каким то интервалом, а так получается всегда записана текущее значение "уровня сигнала" на железке - т.е. нагрузка существенно возрастет.

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