Senfile + Threads + mincore in Linux?

[Andrey Istochkin]

Насколько я понимаю, mincore оперирует адресами из виртуального адресного
пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы
как-то применить его к файлу, нужно через mmap отображать файл в то самое
адресное пространство, что, видимо, не является приемлемым решением. В
http://habrahabr.ru/post/260669/ указано, что были попытки по созданию
системного вызова fincore(https://lwn.net/Articles/371538/), который
работал бы как раз с файловыми дескрипторами, но как-то не срослось.

28 июня 2015 г., 22:10 пользователь Gelun, Artem <a at gelun.ru> написал:

> Добрый день всем.
>
> Возможно, идея/вопрос не новы, но:
>
> Сейчас (с версии 1.7.11, если не ошибаюсь) sendfile может быть как
> блокирующим, так и неблокирующим *основной поток*, вызываясь в отдельном
> треде.
>
> При этом пул тредов фиксирован и если, например, я выделил 10 тредов,
> которые заняты чтением с диска (заблокированы), то другие "читатели" будут
> ожидать их даже если данные уже находятся в page cache, что не рационально,
> имхо. Т.е. мы можем иметь нагрузку, при которой 90% трафика будет
> отдаваться из PageCache, 10% с диска и эти 10% могут заблокировать
> кэшированные, "популярные" ответы.
>
> Вопрос: можно ли добавить в эту логику вызов mincore (в linux) для того,
> чтобы определить сколько данных есть в page cache, отправке этого объема
> данных и, если они отправились (возврат == NGX_OK) вызывать остаток
> sendfile в треде? Есть ли какие-то потенциальные проблемы за пределами
> ngx_linux_sendfile_chain.c строк 182-203 внутри #if (NGX_THREADS) ?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150629/2d73ff4d/attachment.html>