Nodeload2: Механизм загрузок — Перезагрузка

[@erlyvideo]

Потребовались усилия более 4 (!) программистов, что бы найти такую примитивную вещь, как утечку файловых дескрипторов и после этого мы видим «Node.js работает просто великолепно»

[@akzhan]

Хватило бы и одного, знающего, где искать. Проблема с неуправляемыми ресурсами (unmanaged resources) достаточно общая и не касается конкретной среды разработки.

[@brutaler]

Ладно бы, если бы это баг Node.js был. Тут же просто не до конца продуманная деталь реализации, только Чак Норрис всегда пишет код без ошибок.

[@AlexTikhonov]

Ух ты!

Побольше бы success stories с node.js в главной роли :)

Сейчас активно рассматриваю варианты реализации некоторых звеньев на node.js, по этому очень интересны какие грабли есть, чтоб на них не наступить.

[@si14]

Интересно, почему я ни разу не слышал о текущей памяти и тем более дескрипторах в Erlang'е?

[@akzhan]

может, просто никогда не искали про это в Google?

навскидку — erlang.2086793.n4.nabble.com/cover-fix-file-descriptor-leak-td3482992.html
erlang.org/pipermail/erlang-patches/2011-February/001926.html

[@si14]

Т.е. ребята захотели нафигачить простейший сервис, сразу же наткнулись на серьёзную проблему, потребовавшую участия большого количества людей — это равнозначно ситуации, когда подавляющее большинство пользователей даже не встречало таких проблем в Erlang'е и их надо искать в Гугле? Ок.

[@akzhan]

Я ответил на ваш вопрос вообще-то. Уверен, что проблемы бывают везде и у всех. Это нормально.

Я вот, к примеру, тоже ни разу пока не встречался с проблемами в Node.JS, и прочитал об этой проблеме только в этой статье.

[@si14]

Вопрос в том, насколько эти проблемы серьёзны. Что-то мне говорит, что проблемы, для решения которых понадобилось 4 человека, весьма серьёзны. В это же время люди типа практически в одиночку делают лучший существующий опенсорцный стриминговый сервер, ок.

[@akzhan]

Да ладно вам. Просто надо было найти проблему быстро (production). Разбили поиски на 4 человек.

Думаю, в любом проекте в случае проблемы с production вся команда помогает найти и устранить проблему, если не удалось её найти мгновенно.

Проблема была описана выше, — отсутствие написанного обработчика на обрыв соединения. При должном тестировании нашли бы её раньше еще на staging и решили бы не в таком авральном режиме.

[@orcy]

Потому что эрланг мало кому интересен :)

[@si14]

Зато node.js много кому. gaynode.org/

[@seriyPS]

а сборщик мусора не умеет файловые дескрипторы закрывать? Или они не только дескриптор проворонили но и сам объект подключения? Чудно как-то…

[@akzhan]

Сборщик мусора отвечает только за управляемые ресурсы. Но это не проблема, ибо мы всегда работаем с управляемыми объектами-обертками.

Тут проблема в том, что они проворонили объект потока.

[@akzhan]

Тут: sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_buffering

Суть в том, что если апстрим умеет сам управлять потоками (типа node.js streams или ruby rainbows), то надо эту опцию отключать. Ибо перед перед передачей клиента ответ накапливается в буфере (и скидывается на диск, если не вмещается в буфера).