Go есть в продакшене, в том числе в «критичных» для продукта моментах.
Наличие проблем с GC сильно зависит от самого приложения, т.е. от того, что вы выбираете писать на Go.
Мы выбираем Go там, где есть существенные преимущества перед event based callback hell подходом, например в сетевых сервисах типа «сходи в 10 источников параллельно, обработай данные, сходи еще в 5 и выдай ответ клиенту» (в нашем случае клиент, чаще всего, php). Или там где есть достаточно сложная логика, которую муторно писать на C, но нехватает производительности php.
В качестве анекдота — написали свой sort --merge на Go и обгоняем его в ~5 раз на наших текстовых данных и объемах (за счет простой параллелизации обработки).
С другой стороны если нужен «контроль памяти» (a-la memcached — есть X гигабайт, надо их максимально эффективно использовать), или «нужно обрабатывать 200 миллионов сравнительно короткоживущих объектов» — имеет смысл аккуратно тестировать, прежде чем пускать это в продакшен.
У нас нет «серебрянной пули» борьбы с GC, стандартные вещи — поменьше указателей, иногда отказываемся от «красоты» взаимодействия через каналы (улучшения грядут в 1.4 правда) и профайлим, профайлим, профайлим.
Например gogoprotobuf вместо goprotobuf, linked lists «ручками», хотим попробовать что-то типа bouk.co/blog/idiomatic-generics-in-go/.
мускул, очевидно, синкает не в рандомном порядке, ну и плюс ядро сортирует страницы и пытается писать последовательно, а там дальше софт в самом диске, ncq всякое.
насчет редиса: упс случается, когда много пишут + запускается процесс снапшота или rewriteaof, особенно, если редис заполнен близко к общему размеру памяти на машине.
если повезет и настроена overcommit memory, то он сможет форкнуться без свопа, но т.к. записи много, и папке и дочке нужно еще памяти они оба вываливаются в своп и машина умирает. Предполагаю по этой причине народ извращается с 16 инстансами редиса на машину по 4 гига максимум каждый.
не исключительно, транзакция будет висеть открытой пока соединение не закроется или timeout или commit/rollback.
а вот умирание скрипта с этим пожалуй не связано дествительно, ибо в случае умирания скрипта разницы между persistent и обычным не будет, тут я не совсем по делу да :)
3. ага, а любое действие, которое нужно "не забыть" - это уже ошибка, ибо должно делаться автоматом.
и, самое главное, нельзя полагаться на то, что выполнение вообще дойдет до вашего "не забытого" закрытия(commit/rollback т.е.) транзакции, т.к. скрипт может быть убит или самоубиться по разным, часто не зависящим от него причинам, сильно надежнее все же без pconnect жить.
Наличие проблем с GC сильно зависит от самого приложения, т.е. от того, что вы выбираете писать на Go.
Мы выбираем Go там, где есть существенные преимущества перед event based callback hell подходом, например в сетевых сервисах типа «сходи в 10 источников параллельно, обработай данные, сходи еще в 5 и выдай ответ клиенту» (в нашем случае клиент, чаще всего, php). Или там где есть достаточно сложная логика, которую муторно писать на C, но нехватает производительности php.
В качестве анекдота — написали свой sort --merge на Go и обгоняем его в ~5 раз на наших текстовых данных и объемах (за счет простой параллелизации обработки).
С другой стороны если нужен «контроль памяти» (a-la memcached — есть X гигабайт, надо их максимально эффективно использовать), или «нужно обрабатывать 200 миллионов сравнительно короткоживущих объектов» — имеет смысл аккуратно тестировать, прежде чем пускать это в продакшен.
У нас нет «серебрянной пули» борьбы с GC, стандартные вещи — поменьше указателей, иногда отказываемся от «красоты» взаимодействия через каналы (улучшения грядут в 1.4 правда) и профайлим, профайлим, профайлим.
Например gogoprotobuf вместо goprotobuf, linked lists «ручками», хотим попробовать что-то типа bouk.co/blog/idiomatic-generics-in-go/.
А когда он появится? такие штуки происходят совсем нечасто, мы все-таки пока еще не гугл :)
насчет редиса: упс случается, когда много пишут + запускается процесс снапшота или rewriteaof, особенно, если редис заполнен близко к общему размеру памяти на машине.
если повезет и настроена overcommit memory, то он сможет форкнуться без свопа, но т.к. записи много, и папке и дочке нужно еще памяти они оба вываливаются в своп и машина умирает. Предполагаю по этой причине народ извращается с 16 инстансами редиса на машину по 4 гига максимум каждый.
проверить можно на Neuromancer — если не нужно лазить на каждый абзац по три раза в словарь :)
правда есть немножко разговорной практики
а вот умирание скрипта с этим пожалуй не связано дествительно, ибо в случае умирания скрипта разницы между persistent и обычным не будет, тут я не совсем по делу да :)
и, самое главное, нельзя полагаться на то, что выполнение вообще дойдет до вашего "не забытого" закрытия(commit/rollback т.е.) транзакции, т.к. скрипт может быть убит или самоубиться по разным, часто не зависящим от него причинам, сильно надежнее все же без pconnect жить.