Вот на этом: tx := db.MustBegin()

Mo, вот о том я и говорил. panic: pq: sorry, too many clients already Делай все в одной транзакции тогда и коммить периодически, или по времени последнего коммита, или по количеству звыполненных запросов, по ситуации

Слава, код вот такой https://github.com/aadz/gopp Куча мютексов, просто хотя бы чтобы акуратно считать статистичку. И, вроде, работает для моих нужд. Но отцы ругают

panic: pq: sorry, too many clients already goroutine 583 [running]: panic(0x4188c0, 0xc420493680) /usr/local/go/src/runtime/panic.go:500 +0x1a1 github.com/jmoiron/sqlx.(*DB).MustBegin(0xc4201ae0c0, 0x0) /Users/ko/Desktop/gocode/src/github.com/jmoiron/sqlx/sqlx.go:316 +0x83 github.com/ko/sample/grpc/model.StorePayment(0xc4201ae0c0, 0xc4205a55a0, 0x0, 0x0, 0x0) /Users/ko/Desktop/gocode/src/github.com/ko/sample/grpc/model/payment.go:37 +0x67 вот че кинуло

К сожалению, библиотечка SQL думает что коннект к базе и транзакция - это одно и то же :( Подумай об том, хотя библиотечка и не права, конечно.

В соседней группе такое решение посоветовали, буду тестить

funct dbwriter(db DB) { for data := range datachan { db.Insert(data) } } func main() { go func() { for { datachan <- data } }() go func() { for { datachan <- data } }() go func() { for { datachan <- data } }() }

Mo, я то же самое посоветовал, по сути. Ты просто не услышал.

но я бы не стал ТАК это делать.

Слава, код вот такой https://github.com/aadz/gopp Куча мютексов, просто хотя бы чтобы акуратно считать статистичку. И, вроде, работает для моих нужд. Но отцы ругают

Кстати, можно вместо Mutex использовать RWMutex и при чтении делать RLock, при одновременном чтении эти области не будут лочиться

https://www.reddit.com/r/golang/comments/5uj13w/chrome_extension_that_replaces_occurrences_of/

Неплохое да

Но зачем скрывать боль если ей можно упиваться

Но зачем скрывать боль если ей можно упиваться

Хорошо сказано

I'm да не. Мне надо их лочить при записи, чтобы никто не читал. Читают дико редко, а пишут - часто. Но я тормозов что-то не заметил, если честно. А Сишники сказали - тормозной код с такими мютексами

Хотя, мютексы - это не про Go, это про UNIX в общем. Но, они работабают, что не может не радовать. :)

Mo, вот о том я и говорил. panic: pq: sorry, too many clients already Делай все в одной транзакции тогда и коммить периодически, или по времени последнего коммита, или по количеству звыполненных запросов, по ситуации

очень странная идея

К сожалению, библиотечка SQL думает что коннект к базе и транзакция - это одно и то же :( Подумай об том, хотя библиотечка и не права, конечно.

библиотека, к сожалению, права - именно так думает сервер

Это идея распараллелить коннекты. Но все равно, каждом коннекте все придется делать в рамках транзакции.

а у нас есть средства регулировать размер пула коннектов в sql?

впрочем - тут пул устроен иначе, чем в java

там ты явно забираешь соединение, и явно отдаешь

Библиотека не права и не не неправа. Она просто предоставляет сервис слишком низкого уровня. А это не сразу все программисты на PHP могут понять.

а у нас есть средства регулировать размер пула коннектов в sql?

https://godoc.org/database/sql#DB.SetMaxOpenConns

впрочем, тут ты тоже явно забираешь соединение, когда открываешь транзакцию

И, кажется,некоторые вещи в SQL-библиотечке называются слишком многообещающе, что как раз неправильно

можно на атомиках и sleep устроить блокирование и лимитирование числа коннектов

https://godoc.org/database/sql#DB.SetMaxOpenConns

а, так надо его покрутить до разумного ограничения, и та паника исчезнет

мне вот так и не удалось что-то сдеать так, чтобы запросы по доступным коннектам распределялись, а если доступных нет - ждали. Кажется, SQL-библиотека этого как раз и не умеет.

Она умееет открыть столько коннектов, сколько сможет, а потом подохнуть :(

ммм

как-то так получилось, что меня это не коснулось

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

но тогда - атомик и слип

или даже нет

канал же!

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

Например через n секунд или m запросов комитим

А никакого бесконечного количества рутин и не надо. Она сама наоткрывает тебе столько, сколько обработать потом сама же и не сможет. Просто это не pool, на самом деле, а просто список коннектов.

А никакого бесконечного количества рутин и не надо. Она сама наоткрывает тебе столько, сколько обработать потом сама же и не сможет. Просто это не pool, на самом деле, а просто список коннектов.

обычно запросы обрабатываются быстрее, чем поступают

И есть тупо метод не делать так много коннектов. Держать все в пределах транзакции. На транзакцию будет один коннект хотя бы :(

если это не так - у нас все равно проблемы

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

но именно в случае с транзакциями возможны блокировки и всплески

поэтому, если уж возникла проблема, нао как-то буферизовать запросы

Если тебе надо программным (сложным) образом поменять значение какого-то поля в табличке со 15 миллионами записсей, и ты не делаешь это в транзакции - да, в Go это у тебя проблема... :(

Даниэль, не о буферизации речь. Буферизация там как раз есть. И открытие рутины не по делу с новым коннектом к базе. Речь о том, что работает это не так, как ожидалось

И это, кажется миллион раз уже обсуждалось везде... Дизайн не самый удачный у этой библиотеки, в общем

ну - он просто низкоуровневый

проблему не заметают под ковер

но возникает проблема не в либе, а в дизайне снаружи

низкоуровневый дизайн? хм... хорошо сказано. :)

/voteban

sudo voteban

Не работеат, похоже нужно сначала сделать sudo apt-get install voteban

...форумы...а они разве живы где-то кроме даркнета? )

Дык этот форум косит под даркнет

форумы - нет, а спамеры со своими "лучшими форумами" - все еще да :(

Андрю туда даже зашел, видимо. И что там? Пипиську обещают, как обычно, увеличивать на 15 сантиметров в месяц? Интересно, как эта пиписька будет смотреться хотя бы через полгода...

Андрю туда даже зашел, видимо. И что там? Пипиську обещают, как обычно, увеличивать на 15 сантиметров в месяц? Интересно, как эта пиписька будет смотреться хотя бы через полгода...

Разочарование там. Форум не про Go, и даже написан не на Go ?

нет.

+

> go call admin

Я гофер, ничего не понял.

Похоже на то

https://www.facebook.com/permalink.php?story_fbid=722477891241449&id=100004377340065 Подскажите, пожалуйста, как в Go, прочитать читать UDP-пакет вместе с адресом отправителя без выделения памяти? (*UDPConn) Read() - читает без выделения памяти, но не возвращает адрес. (*UDPConn) ReadFrom() и (*UDPConn) ReadFromUDP() возвращают адрес, но при его создании в (c *UDPConn) readFrom() выделяется память для создания объекта адреса и в syscall.(*RawSockaddrAny).Sockaddr() выделяется память при создании сокета, из которого потом достаётся адрес. Т.е. два совершенно лишних копирования с аллокацией памяти. И это основные источники аллокаций в коде. Можно достать файловый дескриптор через (c *UDPConn) File() и что-то самому делать, не опускаясь до уровня сисколов. Но как достучаться до нужных методов?

Прочитать без выделения памяти? Прямо целый UDP-пакет?

Тогда возникает закономерный вопрос "прочитать КУДА?"

"читает без выделения памяти, но не возвращает адрес" — адрес чего?

Для начала возникает вопрос о том, что такое "прочитать"

Slash, что уже ты таки имел в виду сказать?

(если ты умеешь читать, конечно)

он читает наши сообщения без выделения памяти

и потому не может ответить

печалька кокая :(

коллеги

ну вы это

ядро выделяет буфер, и читает данные в него

а... как написать UDP-пакет без выделения памяти?

дальше можно этот буфер без копирования передавать туда-сюда, и даже ответ в него положить, и снова передать ядру для отправки

ну не кажется ли тебе, что общение с ядром с одной строны и желание не трогать сисколлы с другой несколько противоречат друг другу?

Да хрен с ними с сисколами и ядром. Главное, как память-то не выделять на каждое заходящее UDP, но читать его и долго потом думоть?

Да в чем поблема-то?