Решение проблемы «EMFILE, too many open files»

[friday]

Эм… а чем syslog не устроил?

[Keenest]

Только тем, что не попался мне на глаза раньше. Ну а теперь и смысла в нём нет.

[friday]

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

[kekekeks]

Механизм прост: задаём константе MAX_OPEN_FILES разумное число, меньшее чем максимально допустимое количество открытых файловых дескрипторов (например 256)

ulimit поднимать не пробовали? Говорят, помогает.

[Keenest]

И до каких пор поднимать? Предпочитаю прогрессивные решения.

[erlyvideo]

до 2,5 миллионов, очевидно =)

[jcmvbkbc]

Внезапно лёгкое deja vu: habrahabr.ru/qa/27509/

[mn3m0n1c_3n3m1]

Мне кажеться проблема изначально была в том, что используеться синхронная версия fs.close ведь она блокирует всё приложение, что бы просто закрыть файл.
Поскольку статус операции всё-равно не проверяеться (да и каким он, в принципе может быть?), думаю, использование асинхронной функции закрытия файла решило бы проблему без необходимости использования сторонних библиотек.

Для чего использовалась именно синхронная версия функции fs.close?

[Keenest]

Нет, дело не в этом — если бы я использовал асинхронную версию close, то ф-ию callback приходилось бы вызывать всё равно в её коллбеке:

// синхронная версия
fs.closeSync(file_handle);
callback();

// асинхронная версия
fs.close(file_handle, function () {
    callback();
});

Так что по сути разницы никакой — в обоих случаях сначала закрываем файл, и только потом рапортуем о том что можно открывать следующий.

[mn3m0n1c_3n3m1]

Разница в том, что:
1) В момент вызова fs.closeSync вся программа ждёт её завершения, и новые файлы не открываються, и сервер ничего не обрабатывает, полное замирание, в случае же с ассинхронной версией, файл закроеться когда закроеться, это не так важно, на самом деле, за то новые файлы смогут открываться и закрываться и новые соединения будут работать, всё будет заметно быстрее работать.

2) callback можно вызывать сразу и ничего страшного не произойдёт, дожидаться закрытия файла не обязательно, НО, если это ВАЖНО, то это всё таки будет лучше асинхронная версия поскольку программа не будет «замирать» ожидая пока файл закроеться.
habrahabr.ru/post/150788/
nodemanual.org/latest/nodejs_dev_guide/writing_asynchronous_code.html
habrahabr.ru/post/128772/
Райан Дал очень хорошо рассказывает о разнице между блокирующими и не блокирующими операцияи в каждом интервью, а особенно в этом ролике www.youtube.com/watch?v=jo_B4LTHi3I

[Keenest]

Да, пожалуй, правильнее действительно использовать асинхронную версию.

Однако на практике это вряд ли даст сколько-нибудь заметный прирост в производительности — всё-таки закрытие файла — операция шустрая.

Сейчас подредактирую пост. Дьявол кроется в мелочах.
Спасибо.

[mn3m0n1c_3n3m1]

Вам спасибо за интересную статью о Javascript и Node js, в последнее время очень редко что-то новое по-теме появляеться…

[jcmvbkbc]

Поскольку статус операции всё-равно не проверяеться (да и каким он, в принципе может быть?)

Цитата из man 2 close:

Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

[mn3m0n1c_3n3m1]

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

// синхронная версия
fs.closeSync(file_handle);
callback();

программа просто упадет, а во второй

// асинхронная версия
fs.close(file_handle, function () {
    callback();
});

стоит проверить результат операции закрытия файла.

[Keenest]

В первоначальной версии программа упадёт только если ни открытие, ни запись в файл не вернули ошибку, а закрытие внезапно ДА.