а! я неоднократно пробовал показывать. не понимают-с. дикари-с.

чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд

Можете проверить :)

а! я неоднократно пробовал показывать. не понимают-с. дикари-с.

Ну вроде понял. К тому же я вроде бы не далек от истины в своих спекуляциях

Можете проверить :)

я бы глянул на код без prepare для начала

чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд

Там два запроса, один выполняется по количеству строк, второй количество строк умноженное на количество параметров

я бы глянул на код без prepare для начала

https://github.com/Supme/gonder/commit/74c333a1e3373bc254a557248b965a1ff5898e61#diff-26c6a333209552b6b6f6cef1dc42fe8e

Первая версия

В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения? Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?

так у вас транзакции не было

?

В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения? Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?

Ну, или смотреть в сторону master/slave архитектуры

так у вас транзакции не было

именно. я думаю, дело не в prepare, а в транзакции

Ну, или смотреть в сторону master/slave архитектуры

А как это решит проблему невозможности слушать на том же порту?

чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд

Тут дело такое: простое query это тоже подготовка запроса и потом запуск с переданными параметрами. База при подготовке запроса интерпритирует его себе, готовит план выполнения, потом мы просто передаём данные э этому

В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения? Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?

предполагается, что у вас веб сервисы за лоадбалансером. Процедура такая 1) Поднимаете новый сервис, ЛБ начинает передавать трафик на него и продолжает передавать на старый 2) Отдаёте команду shutdown старому, он перестаёт принимать новые соединения и ЛБ шлёт трафик только на новый 3) старый до обрабатывает старые соединения и завершается

именно. я думаю, дело не в prepare, а в транзакции

Да там потом и транзакции были

> Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения? такого нет

предполагается, что у вас веб сервисы за лоадбалансером. Процедура такая 1) Поднимаете новый сервис, ЛБ начинает передавать трафик на него и продолжает передавать на старый 2) Отдаёте команду shutdown старому, он перестаёт принимать новые соединения и ЛБ шлёт трафик только на новый 3) старый до обрабатывает старые соединения и завершается

@MichaelMonashev ^^

В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения? Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?

см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте

см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте

там и tcp порты можно передавать?

см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте

Спасибо, это то что надо. А то я сделал свой аналог https://github.com/rcrowley/goagain/ , но оно не пашет. И хрен знает почему.

там сокеты по их дескриптору передаются наверное.

а вот скажите - как вы собираетесь graceful утилизировать в век keepalive

а вот скажите - как вы собираетесь graceful утилизировать в век keepalive

а что не так? ?

так не закроется же соединение никогда

Вообще-то они закрываются.

откуда ты знаешь?

проверял ?

я вот не проверял, но письма от страдальцев, у которых на reload nginx висит часами, читал

часами != никогда.

по мне, так часами === никогда

за время жизни вселенной точно закроется

при релоаде nginx-у SIGHUP посылается и всё. так что управление возвращается в консоль, если что.

спасибо, кэп

но от этого только хуже

В реальности это юзеры, которые активно использую сайт. Как уйдут, так соединение и закроется.

а вот скажите - как вы собираетесь graceful утилизировать в век keepalive

терпеть же.

но от этого только хуже

а что именно плохо?

В реальности это юзеры, которые активно использую сайт. Как уйдут, так соединение и закроется.

или прокси

а что именно плохо?

ты реально понять не можешь, с хера ли новая конфигурация не применилась

ну прибивай воркеров через час.

почему не сразу?

сразу плохо: может прилететь пол страницы юзеру.

и так может, только ты еще час ждал

спор из области, что курить вредно, но я же курю и жив.

не, я не спорю

я вопрос задаю

и пока ответы все какие-то невнятные :)

http://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout

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

ответ: чтобы юзер, качающий 100500 мегабайтный файл мог не нажимать на его перезакачку в браузере.

а недогруженный css или js или картинка делают сайт некрасивым.

и браузер не пытается из докачать, кстати.

ответ: чтобы юзер, качающий 100500 мегабайтный файл мог не нажимать на его перезакачку в браузере.

но нет же способа оборвать соединение ровно тогда, когда он его докачает.

раньше он сам бы соединение закрыл по окончании

но сегодня-то - нет, не закроет

браузер закроет соединени.

как докачает и подождёт 10 минут вроде

keepalive соединение не живёт бесконечно. Обычно закрывается в течение минуты после последней передачи.

как докачает и подождёт 10 минут вроде

если новый запрос в него не отправит

Всё верно.

keepalive соединение не живёт бесконечно. Обычно закрывается в течение минуты после последней передачи.

а если передача каждые 10 секунд?

Тогда плохо. Но это не тот вариант, что со скачиваеним файла в 100500 мегабайт.

И вообще такое надо на вебсокетах делать :)

с вебсокетами та же херня

ERROR: S client not available

в вебсокетах хотя бы можно на уровне протокола сказать - restart

со стороны сервера

да. Используйте load balancer'ы для переключения на живую и авто-восстановление вебсокетов для кикнутых клиентов

это да, но уже далеко от graceful

можно еще keepalive поддерживать только на балансере, а на бекендах обойтись без него

тогда на бекендах будет работать graceful

но это расход сокетов втрое и лейтенси повышенная

Коллеги, посоветуйте. Нужно запустить через конвейер от трёх и более программ. Если самому соединять их через io.Pipe, получается уж очень громоздко. Есть ли либа или способ упростить данный процесс?

type cmd ... func (* cmd) Exec ... commands := []cmd{"ls", "grep .txt", "sort"} for i, _ := range commands[:len(commands)-1] { r, w := io.Pipe() commands[i].Stdout = w commands[i+1].Stdin = r commands[i].Exec() } commands[len(commands)-1].Exec()

вроде не очень громоздко

cmd - псевдотип, для наглядности

Написал смену юзера и группы, но что-то как был процесс под рутом, так и остался. Что я делаю не так? func setUserAndGroup(u, g string) error { if u != "" { uid, err := strconv.Atoi(u) if err == nil { return err } err = syscall.Setuid(uid) if err == nil { return err } } if g != "" { gid, err := strconv.Atoi(g) if err == nil { return err } err = syscall.Setgid(gid) if err == nil { return err } } return nil }

скажи - ты забыл, что смена юзера нормально не работает в go?

я и не знал

к тому моменту, ак ты его менять пытаешься, несколько тредов уже запущены

и им никто ничего не сменит

был уверен, что оно к процессу относится, а не к тредам...

а есть какие-то варианты обхода этого?

а тред на линуксе - это процесс

нет

запускаться сразу от нужного пользователя - вот и все

или под рутом в докере

ох... Ну почему опять надо что-то городить... устал уже. ?

https://github.com/golang/go/issues/1435 - ссылка про это

ох... Ну почему опять надо что-то городить... устал уже. ?

Страдай )

https://github.com/golang/go/issues/1435 - ссылка про это

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

а как это сделать?

Я был уверен, что на старте, пока я не сделал go func у меня один тред

тред то основной, но горутина всегда может перескочить в другой тред.

а другого треда то и не существует

он пока один