буфера логов apache

[schors]

Был не прав http://schors.livejournal.com/652594.html
awind был более прав. На сотнях логов соль либо заметного эффекта нет. На одном-двух по идее должно работать. Но не проверял.

Comments

[checat]

И на одном-двух не должно. Из описания awind следует, что ты делаешь более редкими, но крупными операции копирования из буфера апача в кэш ФС, без fsync. На современных процессорах эти операции оптимизированы по самое нехочу. Последний использованный блок кэша не сбрасывается (IMHO) на диск, пока он обновляется достаточно часто. То есть количество дисковых операций не будет уменьшаться.

Остался неясным для меня вопрос, за счёт чего при сбросе лога получается атомарность. Это специальный вызов ядра, который блокирует конкурентные операции записи в тот же дескриптор?

[schors]

Он просто весь буфер записывает за один раз.

Это... поставь эксперимент - ну сообери например инфу по всем NS'ам доменов зоны .ru. Задача простая. И пиши на диск. Сначала построчно, а потом по 1000 строчно. Удивишься.

[schors]

Я просто пробовал.

[jekel]

Что получилось? можно какие-то цифры показать?

[schors]

20 минут против часа выполнения скрипта собирания NS'ов зоны .ru.

[jekel]

Пачками по 1к строк оказалось соответственно быстрее?

[schors]

Да

[checat]

Записывает за 1 раз куда? Смысл в том, как я понял, чтобы в операцию записи одного процесса не вклинился другой процесс, сброс кэша на диск не обязателен.
Значит, потеря производительности может быть только на ожидании получения блокировки для записи "за 1 раз".
С обычным каким-нибудь fwrite, я уверен, не будет разницы между 100000 раз по 100 байт и 100 раз по 100000 байт. (Что и демонстрирует ниже awind.) В мане вообще сказано, что fwrite делается последовательным вызовом fputc.

Вполне возможно, что с pipe ситуация будет несколько другая, поскольку для небуферизованного вывода на каждый байт будет делаться context switch. Так?