worker_rlimit_nofile

[drmarker]

> > А реализация кеша в linux умеет думать "отсюда я уже читал N раз,
> > подержим это в кеше подольше"? По факту данные из кеша очень быстро
> > "вымываются".
>
> Вообще любые реализации кешей что-то такое умеют. То есть при
> определении страниц, которые надо выкинуть из кеша, учитывается и
> время последнего использования, и "температура" - частота обращений.

Про LRU и прочие алгоритмы, основанные на частотном анализе, все понятно.

Вопрос в том, что делает linux, когда ему нужно считать с диска кусок
данных, равный 10% кеша, а в кеше места нет. Думаю, определяется самый
"бесмысленный объект" в кеше, его удаляют, на его место пишут новый.
При интенсивном чтении и маленьком кеше нет шансов кому-то задержаться
в кеше надолго.

Тем самым, кеш малополезен в данном случае.

> > > Queueing есть и в дешевых вариантах. Во-первых операционная система
> > > запросы, поступающие в очередь, переупорядочивает (и это тоже
> > > настраивается все, deadline iosched например можно настроить на
> > > максимальную пропускную способность, сильно повредив времени отклика,
> > > он будет сотни запросов в секунду "объединять"), во-вторых SATA на
> > > современных чипсетах NCQ умеет.
> >
> > А где почитать про переупорядочивание?
>
> Про SATA - это вот тут http://linux-ata.org/ , пример как пользовать
> есть тут: http://blog.kovyrin.net/2006/08/11/turn-on-ncq-on-ich-linux/lang/ru/
> Про io schedulers - в гугле можно  описания поискать, и в доке которая
> в исходниках ядра (/Documentation/block/..)

Спасибо. Кстати, в ядрах, начиная с 2.6.18, лежит новый libata,
который умеет NCQ, то есть для поддержки NCQ не надо патчить ядро.