Он то запустился, но требует много настроек

SetMaxIdleConns и SetMaxOpenConns попробуй. Это не много.

Окей, попробую

я по дефолту и для MySQL так указываю. все коннекты нужно контролить.

В общем проблема решилась (я надеюсь) установкой следующих параметров dbConnection.SetConnMaxLifetime(5 * time.Minute) dbConnection.SetMaxOpenConns(5) dbConnection.SetMaxIdleConns(0) Но я реально не понял ПОЧЕМУ это решило проблему. Кто нибудь может обьяснить? ?

Например, если увеличить макс кол-во открытых соединений, то проблема возвращается

Как это работает вообще

Видимо ты где-то не закрываешь подключения, и выставив lifetime, ты стал их закрывать

Остаётся только один вопрос

Насколько это хорошее решение

Lifetime роли не играет

Я проверил

Если его убрать или увеличить, все также ок

и вообще желательно юзать pgbouncer

С ним , кажется, потеряете prepared statements, а они скорости помогают неплохо

С ним , кажется, потеряете prepared statements, а они скорости помогают неплохо

Вроде как Prepared Statements в Го работают не так, как ожидается, и для каждого запроса создаётся новое соединение

Но я могу ошибаться

Но я могу ошибаться

Нормально работают подготовленные запросы.

Вроде как Prepared Statements в Го работают не так, как ожидается, и для каждого запроса создаётся новое соединение

Просто нужно держать пул prepared statement

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

https://github.com/nadoo/glider

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

Самое простое закешировать в редисе.

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

Если вы у бд один клиент, то вполне нормально. Это фактически и получается кэш. Хэш может давать коллизию и надо будет сравнивать запросы в любом случае. Можно мапу использовать или key/value хранилище.

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

А если по умному то делать unity of work

Самое простое закешировать в редисе.

Лишняя прослойка получается

Лишняя прослойка получается

В случае если у вас одно приложение. Но такое редко бывает. Вы же будете масштабироваться) Общий кеш на шаренной памяти же не будете делать)

Насчет редко загнул наверно

В случае если у вас одно приложение. Но такое редко бывает. Вы же будете масштабироваться) Общий кеш на шаренной памяти же не будете делать)

Рассчитываю все, что нужно любым другим потребителям, отдавать по апи

Но и рсубд + кеш та еще мудянка

Но и рсубд + кеш та еще мудянка

Оо почему?)

Рассчитываю все, что нужно любым другим потребителям, отдавать по апи

Это разумно

Оо почему?)

Или кеш работает синхронно с базой, и запись идет с ее скоростью

Или ты не знаешь, все ли записалось

Оо почему?)

От целей зависит Например, прилетает мне лог от неизвестно кого Смотрю в кеш: нет такого устройства, лезу в бд - там его тоже нет, дропаю Если таких пакетов от неизвестных источников будет много - от кеша толку ноль

Т.е. в моем случае надо иметь однозначный список объектов либо в бд, либо еще где

Рассчитываю все, что нужно любым другим потребителям, отдавать по апи

Мы не много о разном говорим, источник данных один. А приложений которые предоставляет апи может быть много отдельных. Например сервера в разных стойках для резервации. 3 бд инстанса мастер слейв для чтения + слейв без лага для того чтобы в критичной ситуации стать мастером. Плюс три application сервера(контейнера) чтобы при падении хоста у вас ничего не упало. В таком случае кешировать в памяти приложения не получится. Нужен общедоступный кеш)

Но если вам не нужна отказоустойчивая конфигураци то можно и памяти)

Мы не много о разном говорим, источник данных один. А приложений которые предоставляет апи может быть много отдельных. Например сервера в разных стойках для резервации. 3 бд инстанса мастер слейв для чтения + слейв без лага для того чтобы в критичной ситуации стать мастером. Плюс три application сервера(контейнера) чтобы при падении хоста у вас ничего не упало. В таком случае кешировать в памяти приложения не получится. Нужен общедоступный кеш)

Как спорный вариант - отдельный микросервис с об'ектами ))

Да вы извращенец))

А в нем уже они в Памяти)

Ну я гипотетически )

Ну а чем тот же редис кластер не нравится?)

Он же тоже самое делает)

Хранит в памяти, при желании может быть и персистентным) Единственно немного времени на сериализацию будете тратить

Когда последний раз имел дело с редисом лет 5 назад, он был дико падучим и рассыпчатым

Хз как сейчас, но осадок остался)

Когда последний раз имел дело с редисом лет 5 назад, он был дико падучим и рассыпчатым

Ого

Мб не 5, а 6..7

Не помню уже

Кластер вот относительно недавно у них появился был не стабилен какое-то время. Сейчас более менее. По крайней мере 6(3 master 3 slave) инстансов на одном из микросервисов уже год работают без падений) А не кластерное решение давно вроде работает стабильно, это штука древняя как г мамонта) И нагрузки хорошие держит и масштабируется на раз два)

Или кеш работает синхронно с базой, и запись идет с ее скоростью

Ну кеш нужен для объектов которые реже обновляются чем читаются, тут ты получаешь профит, а если ты часто пишешь и обязательно персистентно, то это уже не задача кеша, правильно же?)

ребят, а как можно как-нибудь так сделать? var params = make(map[string]interface{}) params["abc"] = struct{ a int b int }потом взять и сделать так params[abs].a = 212есть, конечно, идеи сделать это всё через getParam / setParam(path ...string) но вдруг есть что-то более правильное

и я бы хотел, чтобы была такая либа, чтобы

Так ты описал практически qt

ребят, а как можно как-нибудь так сделать? var params = make(map[string]interface{}) params["abc"] = struct{ a int b int }потом взять и сделать так params[abs].a = 212есть, конечно, идеи сделать это всё через getParam / setParam(path ...string) но вдруг есть что-то более правильное

у тебя ошибка как минимум в вопросе. params.a у тебя nil (должно быть params.abc.a). Вообще да, лучше через функцию сделать

Кластер вот относительно недавно у них появился был не стабилен какое-то время. Сейчас более менее. По крайней мере 6(3 master 3 slave) инстансов на одном из микросервисов уже год работают без падений) А не кластерное решение давно вроде работает стабильно, это штука древняя как г мамонта) И нагрузки хорошие держит и масштабируется на раз два)

Масштабируется вертикально?) А что будет если одна из 6 нод ляжет?

Масштабируется вертикально?) А что будет если одна из 6 нод ляжет?

В случае с кластером - ничего)

В случае с кластером - ничего)

Чтобы построить кластер нужно минимум 6 нод?

Чтобы построить кластер нужно минимум 6 нод?

3 мастера как я помню минимум) Но от такого толку нет. Хватит наводящих вопросов, давай колись где подколоть хочешь)

3 мастера как я помню минимум) Но от такого толку нет. Хватит наводящих вопросов, давай колись где подколоть хочешь)

Да не, просто интересуюсь) слышал, что эта портянка ляжет, если хоть одна нода отвалится.

у тебя ошибка как минимум в вопросе. params.a у тебя nil (должно быть params.abc.a). Вообще да, лучше через функцию сделать

эх(( ладно, спс

Да не, просто интересуюсь) слышал, что эта портянка ляжет, если хоть одна нода отвалится.

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

По крайней мере раньше так было, может с тех пор что-то изменилось в лучшую сторону)

Да не, просто интересуюсь) слышал, что эта портянка ляжет, если хоть одна нода отвалится.

Прочитал сейчас вот тут https://habrahabr.ru/post/320902/ что можно и без куска кластера выживать с помощью cluster-require-full-coverage no, не знаю на практике как это, не я инфру поднимаю)

Всем привет. А ещё конференции есть? )

Всем привет. А ещё конференции есть? )

пользуясь случаем. я заснял влог https://www.youtube.com/watch?v=lHqLtTetgUA

есть митапы

да я имею ввиду предстоящие мероприятия чтоб сходить

https://t.me/itiviru

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

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

Спасибо, загляну

задумался =\ Есть некие объекты и у них есть различные профили (профиль авторизации, профиль настроек, и т.д.) Объекты хранятся в памяти. Сначала хотел также хранить профили в памяти и к каждому объекту цеплять _указатель_ на нужные профили: таким образом при каком-либо изменении профилей объекты трогать не нужно, всё "само обновится" А потом подумал, что программа будет постоянно и непрерывно дёргать и лочить мьютексы одних и тех же профилей (объектов очень много, с ними постоянно что-то делается, а инстансов профилей мало: при каждом действии с каждым из тысяч объектов будут по нескольку раз лочиться-анлочиться мьютексы его профилей) что правильнее в такой ситуации делать?

можно использовать RWMutex, тогда хотя бы постоянного рид-локов не будет, но всё равно постоянное и очень высокочастотное дёргание мьютексов одних и тех же обьектов - это нормально? :)

задумался =\ Есть некие объекты и у них есть различные профили (профиль авторизации, профиль настроек, и т.д.) Объекты хранятся в памяти. Сначала хотел также хранить профили в памяти и к каждому объекту цеплять _указатель_ на нужные профили: таким образом при каком-либо изменении профилей объекты трогать не нужно, всё "само обновится" А потом подумал, что программа будет постоянно и непрерывно дёргать и лочить мьютексы одних и тех же профилей (объектов очень много, с ними постоянно что-то делается, а инстансов профилей мало: при каждом действии с каждым из тысяч объектов будут по нескольку раз лочиться-анлочиться мьютексы его профилей) что правильнее в такой ситуации делать?

Использовать реляционную СУБД

Использовать реляционную СУБД

Ну блин :)

Про это я уже выше спрашивал %)

Насколько правильно хранить объекты (персистентно хранящиеся в бд) и работать с ними - в памяти, в бд только записывая обновления? Суть: куча объектов (оборудования), постоянно опрашивающегося на предмет кучи параметров. Это уже куча постоянных одинаковых запросов (на один объект - от пары десятков до сотен дочерних объектов) - но это хрен с ним, достаточно безболезненно для бд. Еще это оборудование будет слать логи на сислог и снмп-трапы; какие-то события на оборудовании происходят постоянно, сейчас по нескольку сотен в секунду прилетает - и вот это уже похоже на бессмысленное дрочево БД: гораздо продуктивные было бы держать все в памяти Сейчас еще в голову пришел вариант - простая обёртка над бд, кеширующая в памяти на энное время именно результат запросов (с ключем = мд5 строки запроса, например) Кто как похожие кейсы решает?

Примерно тут

Примерно тут

Имхо кэшами нужно обманываться только когда вы упретесь в производительность базы

До этого момента это лишь добавит невероятно много геморроя

задумался =\ Есть некие объекты и у них есть различные профили (профиль авторизации, профиль настроек, и т.д.) Объекты хранятся в памяти. Сначала хотел также хранить профили в памяти и к каждому объекту цеплять _указатель_ на нужные профили: таким образом при каком-либо изменении профилей объекты трогать не нужно, всё "само обновится" А потом подумал, что программа будет постоянно и непрерывно дёргать и лочить мьютексы одних и тех же профилей (объектов очень много, с ними постоянно что-то делается, а инстансов профилей мало: при каждом действии с каждым из тысяч объектов будут по нескольку раз лочиться-анлочиться мьютексы его профилей) что правильнее в такой ситуации делать?

Так можешь иметь пул воркеров и по хэшу от каких нибудь полей давать владение объектами

Имхо кэшами нужно обманываться только когда вы упретесь в производительность базы

Почти гарантированно упрусь сразу, как дам полную нагрузку: если в лоб - то тысячи запросов/сек будут

Почти гарантированно упрусь сразу, как дам полную нагрузку: если в лоб - то тысячи запросов/сек будут

Слова и предположения — ничто, бенчмарки и метрики — всё

Слова и предположения — ничто, бенчмарки и метрики — всё

Я не предполагаю, я знаю поток сообщений, который нужно будет обрабатывать)

Если на каждый дергать бд без Кеша, будут тыщи qps

Это не обязательно "убьет" БД, т.к. там тоже есть кэш запросов. Но даже если и будет проблема с бд, то по крайней мере это будет некой baseline для дальнейших улучшений

Могу только еще раз подтвердить слова Мерль - без бенчмарков нечего оптимизировать

А если кешировать именно запросы в какой-нибудь обертке над бд? И хранить в мапе с ключем "хеш запроса" минут по 5? Тоже не оч вариант?

Могу только еще раз подтвердить слова Мерль - без бенчмарков нечего оптимизировать

Ну, хотелось сразу спроектировать с меньшей нагрузкой на бд) Проще ведь это сделать сразу и просто держать нужное в Памяти, чем потом где то сбоку синей изолентой кеш прикручивать)

СтОит сначала проверить, что может сделать сама бд для такого кэша. В mysql он точно есть. И проблема инвалидации там решена

Ну, хотелось сразу спроектировать с меньшей нагрузкой на бд) Проще ведь это сделать сразу и просто держать нужное в Памяти, чем потом где то сбоку синей изолентой кеш прикручивать)

Хотя в go и не приветствуются многочисленные абстракции, но здесь напрашивается repository pattern. Чтоб можно было добавить кэш или вообще заменить сторадж на что-то другое

Make it work, make it right, make it fast

СтОит сначала проверить, что может сделать сама бд для такого кэша. В mysql он точно есть. И проблема инвалидации там решена

Раз за разом вижу отсылки к кэшу MySQL. Но это вообще-то кардинально другая субстанция, не могущая заменить кэш приложения, и не для того сделанная

Да и депрекейтед с 8.0

и вообще у меня пг %)