Исходное сообщение
"В состав FreeBSD принята высокопроизводительная реализация s..." Отправлено Valentin V. Bartenev, 11-Янв-16 23:18
Мы в процессе экспериментов перепробовали очень много подходов. Так, например, в результате этих экспериментов во FreeBSD даже появился такой системный вызов как aio_mlock() (см. http://lists.freebsd.org/pipermail/svn-src-all/2013-June/069... ). И если бы проблема блокировки open() и stat() стояла остро, то усилия были бы направлены на её решение тем или иным способом, но нет. Замечу также, что в nginx есть механизм кэша открытых файловых дескрипторов (см. директиву open_file_cache), который для многих кейсов неплохо работает. В контексте пулов потоков, разумеется, если уж мы оффлоадим read() и sendfile() в отдельный пул потоков, то запихнуть туда в придачу еще open() и stat() было бы интересной оптимизацией. Но это требует некоторого дополнительного количества человеко-часов, которых пока не нашлось. Наибольший интерес тут именно сделать это вместе одним потоком, т.е. сразу открыть файл и начать его читать или отправлять, что несколько ломает существующую логику работы, где эти вызовы бывает довольно сильно разнесены по коду. Выгружать open() и stat() в пул как отдельные задачи не очень интересно, поскольку это добавляет накладных расходов и возможно пессимизирует частый случай, когда эти операции не требуют обращения к диску. Однако, замечу, что проблема блокировки указанных вызовов пока никак себя не проявила. На тестах с существующей реализацией, где в отдельные потоки выгружаются только read() и sendfile() на линуксе получаются хорошие результаты, заказчик функциональности остался очень доволен и о том, что кто-то на некотором кейсе уперся в open() и stat() я пока не слышал.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Мы в процессе экспериментов перепробовали очень много подходов. Так, например, в результате > этих экспериментов во FreeBSD даже появился такой системный вызов как aio_mlock() > (см. http://lists.freebsd.org/pipermail/svn-src-all/2013-June/069825.html ). И если > бы проблема блокировки open() и stat() стояла остро, то усилия были > бы направлены на её решение тем или иным способом, но нет. > Замечу также, что в nginx есть механизм кэша открытых файловых дескрипторов (см. > директиву open_file_cache), который для многих кейсов неплохо работает. > В контексте пулов потоков, разумеется, если уж мы оффлоадим read() и sendfile() > в отдельный пул потоков, то запихнуть туда в придачу еще open() > и stat() было бы интересной оптимизацией. Но это требует некоторого дополнительного > количества человеко-часов, которых пока не нашлось. Наибольший интерес тут именно сделать > это вместе одним потоком, т.е. сразу открыть файл и начать его > читать или отправлять, что несколько ломает существующую логику работы, где эти > вызовы бывает довольно сильно разнесены по коду. Выгружать open() и stat() > в пул как отдельные задачи не очень интересно, поскольку это добавляет > накладных расходов и возможно пессимизирует частый случай, когда эти операции не > требуют обращения к диску. > Однако, замечу, что проблема блокировки указанных вызовов пока никак себя не проявила. > На тестах с существующей реализацией, где в отдельные потоки выгружаются только > read() и sendfile() на линуксе получаются хорошие результаты, заказчик функциональности > остался очень доволен и о том, что кто-то на некотором кейсе > уперся в open() и stat() я пока не слышал.
	Введите код, изображенный на картинке: