Не могу не поделиться результатами, это какой очень success story или все гениальное просто!
Писать таки пришлось в рамдиск, ибо диск конечно рвет на части, в час получается около 0.5М файлов. Входящий траф 25мегабит - это праздники, будет наверно 35. И сейчас это примерно 1.2M запросов в час. Все это стоит примерно... 5% ЦПУ двух старых E5410. ))
Простой скрипт все это разгребает раз в 10 минут и кладет в много. И сразу агрегирует все что необходимо. Все очень быстро и имеем целую гору статистики!
Это ЦПУ недельный, в середине - это я 4 дня пытался на php ловить на ходу и складывать в мемкеш для дальнейшей обработки. И это была 1/10 всего трафа - дальше все загибалось! http://my.jetscreenshot.com/2419/20121225-n76e-40kb.jpg
Я понимаю что при прочих равных писать в кучу файлов и без буферизации намного хуже чем в один и с буфером. Но если это будет работать, то получится весь поток сразу разобрать на сессии, что сильно облегчит обработку, под такое и рамдиск даже не жалко сделать.
On Saturday 22 December 2012 05:54:17 Anton Kuznetsov wrote:
> Спасибо, коллеги, меня точно заклинило на мемкеше. Прям смешно. :)
> И тут мысль снова начала развиваться... "В пути файла можно использовать
> переменные", а ведь нжинкс уже распарсил всю строчку на переменные? Т.е. я
> могу писать в кучу файлов с именами сессий которые есть в параметрах? Хотя
> что-то мне кажется что диск порвет. :( А так было бы хорошо все
> разложить...
>
Не нужно писать в кучу файлов. Логи, путь к которым известен на этапе чтения
конфигурации, nginx откроет на старте, и будет держать открытыми. Если путь
задан с переменными, то на каждую запись лога нужно открыть файл, записать,
закрыть. Кроме того, с динамическими логами нельзя использовать буферизацию, а
соответственно и нельзя будет использовать gzip-сжатие на лету, поддержка
которого ожидается в ближайшей версии.