Тюнинг отдачи мелких картинок

[MZ]

В пт, 19/10/2007 в 16:13 +0400, Монашёв Михаил пишет:

> 
> Диски хоть и недогружены, но nginx-ы все в ожидании ввода-вывода.
А чем ему ещё заняться стоит ? Он мог бы курить табак, если бы все
данные были бы в кеше, и можно было бы сразу отдать их в сокет. А так он
становится в очередь ожидания результата дискового I/O, если нужных
данных в памяти нет.

> Я знаю, какие картинки запрашивают часто и хотел бы их положить в
ОС тоже знает. И ложит их в файловый кеш.

> свободную память. Файлуха сама почему-то заняла только 214 метров
> (214M Buf в top-е). Как можно увеличить размер этого буфера?
> Простаивает 3 Гига памяти ( 2936M Inact в top-е) :-(
Простаивает это когда 2396M Free. А так 2936M Inact хранят какие-то
данные, которые возможно кому-то когда-то пригодятся, а если и не
пригодятся, то не проблема самые ненужные страницы очистить и отдать
кому надо память.


> Или  куда  эффективнее  класть/обновлять/удалять  картинки  самому:  в
> мемкашед или в файловую систему в памяти?
А что, memcached распоряжается данными быстрее в user-level, чем ядро в
kernel-level ? Или ядро умеет к memcached данным делать sendfile(), чтоб
не переключать контекст лишний раз ? Это ж надо придумать - сделать
запрос к memcached, создать сокет, подождать пока memcached скопирует
данные в его буфер сокета, скопировать данные из буфера сокета memcached
к себе и сразу скопировать в буфер сокета браузера. Вместо того чтоб
сделать sendfile и ядро само замаппит (если использовать zero-copy)
данные из кеша фс в буфер сокета браузера и отдаст, без переключения
контекста.
И кто вообще придумал использовать ФС в памяти - данные лежат и в самой
фс, и в системном кеше, то есть памяти расходуется до двух раз больше,
чем если бы ОС просто закешировала данные исходя из частоты их
использования. Я понимаю если много операций на запись с файлами,
которые (результат операций, а также atime данные) не надо flush-ать на
диск - тогда RAM-FS сохраняет нам прилично дискового I/O.