Comments 105
UFO just landed and posted this here
Публикуюсь тут впервые. Буду знать как правильно выкладывать сырцы. Спасибо ;)
stream_set_blocking($in, );
…
$processors_states = array_fill(, PROCESSORS_TO_SPAWN, true);
Куда-то потерялись парочка аргументов. При раскраске или так и было?
…
$processors_states = array_fill(, PROCESSORS_TO_SPAWN, true);
Куда-то потерялись парочка аргументов. При раскраске или так и было?
$proc_data_pipes[] = $pipes[];
Эта строка вообще приведет к ошибке. Ясное дело, что причина все та же — habrahabr.ru/blogs/server_side_optimization/54140/#comment_1444927
Эта строка вообще приведет к ошибке. Ясное дело, что причина все та же — habrahabr.ru/blogs/server_side_optimization/54140/#comment_1444927
Поддержите отечественного производителя, ставьте nginx! ;)
Почему нельзя было писать данные в файл, периодически считывая с него данные другим процессом?
Во-первых, это лишняя операция и диск куда более медленное устройство чем память. Во-вторых, при описанной мной в топике нагрузке, файл будет очень быстро расти и его надо будет регулярно чистить. Все это лишние операции которые сильно усложнят схему работы.
Вы не подумайте, я не то, чтобы ради критики — мне статья очень понравилась, необычный подход к решению задачи.
Просто со временем начинаешь тяготеть к более простым вещам. В общем-то, небезосновательно.
Просто со временем начинаешь тяготеть к более простым вещам. В общем-то, небезосновательно.
ну файл можно располагать в памяти.
UFO just landed and posted this here
4) асинхронная работа с дисками, насколько я знаю, до сих пор не очень хорошо реализована — простого неблокирующегося write(2), насколько я знаю, нет. Возможно, я сильно ошибаюсь, но хотелось бы тогда услышать кейворды.
Про aio_{read,write,...} слышал, но не в самом лестном свете.
Про aio_{read,write,...} слышал, но не в самом лестном свете.
Можно её вручную организовать. Через fork'и. Не так уж и накладно в итоге получается, потому что пишушие/читающие процессы будут сидеть в ядре, и не будут расходовать много ресурсов на переключение контекстов.
А вот POSIX aio действительно штука шибко неудачная из-за необходимости насиловать программу обработкой сигналов. Но вот в Linux есть eventfd, например, что упрощает работу с aio. Вобщем, жить можно.
А вот POSIX aio действительно штука шибко неудачная из-за необходимости насиловать программу обработкой сигналов. Но вот в Linux есть eventfd, например, что упрощает работу с aio. Вобщем, жить можно.
Процессы в ядре? С этого момента по подробнее :)
Ну в линуксах времен 2.4.х aio тредами (на уровне glibc) собственно и реализовывался, треды даже полегче форков будут в контексте переключений контекста, про другие юниксы вообще ничего не знаю.
Про сидящий в ядре форкнувшийся процесс, на который не нужно переключение контекста — вообще понял плохо. Переключение mm-контекста всё равно будет происходить в добавок к переключению контекста cpu (по сравнению с тредами).
Про сидящий в ядре форкнувшийся процесс, на который не нужно переключение контекста — вообще понял плохо. Переключение mm-контекста всё равно будет происходить в добавок к переключению контекста cpu (по сравнению с тредами).
Вот как раз переключения mm и не будет — зачем, если процесс в ядре? Доступ к user-space данным организовывается изнутри ядра по 'физическим' адресам.
Пройдусь по пунктам :)
1) Вы забыли про буферизацию записи, а значит ваше умозаключение о равенстве частоты записей в секунду на диск будут ограничивать частоту записей в файл лога. Это ваше первое упущение. Но тем не менее, запись лога в файл не подходит для реализованной мной системы.
2) Учет данных в БД был мною описан как довольно простой. Могу сказать больше — осуществляется вставка записей в таблицу с одним первичным ключом. Что касается куска кода — то приведен он мной тут как раз по теме статьи, т.к. писал я о способе избавления от минусов однопоточного сервера. И код мой, как показала практика, справляется с задачей на ура. Напомню — топик мой о примере решения проблемы, а не обсуждение построенной мной системы.
3) Решение с СУБД отлажено и работает уже не первый год. И еще раз предлагаю почитать название топика — речь идет о решении проблем сложного логирования однопоточного сервера, а не обсуждение работы СУБД.
4) Напомню еще раз — писать в моей задаче нужно не в файл, а в БД. Т.к. необходим живой анализ и учет трафика. Если писать в файл (неважно какой, физический файл, mmap или еще что), а потом вычитывать оттуда данные и писать в БД — то это ничем не отличается от приведенного мною решения с записью данных в буфер памяти PHP. Разве что только PHP скрипт — это drop-in решение и не требует абсолютно никаких дополнительных действий при развертывании.
5) Вопрос отслеживания обработчиков и поднятия их после падения мною решен, просто я не стал это приводить в этом топике и оставил этот вопрос на решение тому, кто решит воспользоваться. Напомню — код никогда в статьях не приводится как конечный результат, а как подсказка и руководство к дальнейшим изысканиям. Готовые решения на SourceForge
И вот что добавлю. Не все записи что отдает сервер должны попадать в лог, и агрегатор с этим справляется — он отбрасывает ненужные записи до того как они попадают в обработчик и дополнительного ожидания обработки со стороны сервера н таких записях не происходит. Ну и про производительность решения в СУБД — если писатьв один поток данные в БД — то конечно буффер будет расти и система не будет успевать отправлять данные на хранение. Но если писать в несколько потоков — то мы получим многократное увеличение производительности, т.к. будут получены все плюсы concurent inserts в MySQL, а так же мы победим overhead от обработки запроса и подготовки его выполнения в СУБД.
И подведу итог: самомнение и высокомерие некоторых мешает им даже прочитать и осознать что писал их собеседник. Вы решили сразу написать пять увесистых параграфов, вместо того, чтоб просто хорошенько задуматься. Вы начали искать способ сказать что я не прав, вместо того чтоб понять о чем я писал. А вы так и не поняли.
А насчет ваших прогнозов о моем росте как специалиста — спасибо. Правда ваше высокомерие опять заставило вас ошибиться. Я уже являюсь разработчиком со стажем и руковожу весьма большим региональным проектом. Будьте сдержанней в высказываниях и заочной оценке собеседника.
1) Вы забыли про буферизацию записи, а значит ваше умозаключение о равенстве частоты записей в секунду на диск будут ограничивать частоту записей в файл лога. Это ваше первое упущение. Но тем не менее, запись лога в файл не подходит для реализованной мной системы.
2) Учет данных в БД был мною описан как довольно простой. Могу сказать больше — осуществляется вставка записей в таблицу с одним первичным ключом. Что касается куска кода — то приведен он мной тут как раз по теме статьи, т.к. писал я о способе избавления от минусов однопоточного сервера. И код мой, как показала практика, справляется с задачей на ура. Напомню — топик мой о примере решения проблемы, а не обсуждение построенной мной системы.
3) Решение с СУБД отлажено и работает уже не первый год. И еще раз предлагаю почитать название топика — речь идет о решении проблем сложного логирования однопоточного сервера, а не обсуждение работы СУБД.
4) Напомню еще раз — писать в моей задаче нужно не в файл, а в БД. Т.к. необходим живой анализ и учет трафика. Если писать в файл (неважно какой, физический файл, mmap или еще что), а потом вычитывать оттуда данные и писать в БД — то это ничем не отличается от приведенного мною решения с записью данных в буфер памяти PHP. Разве что только PHP скрипт — это drop-in решение и не требует абсолютно никаких дополнительных действий при развертывании.
5) Вопрос отслеживания обработчиков и поднятия их после падения мною решен, просто я не стал это приводить в этом топике и оставил этот вопрос на решение тому, кто решит воспользоваться. Напомню — код никогда в статьях не приводится как конечный результат, а как подсказка и руководство к дальнейшим изысканиям. Готовые решения на SourceForge
И вот что добавлю. Не все записи что отдает сервер должны попадать в лог, и агрегатор с этим справляется — он отбрасывает ненужные записи до того как они попадают в обработчик и дополнительного ожидания обработки со стороны сервера н таких записях не происходит. Ну и про производительность решения в СУБД — если писатьв один поток данные в БД — то конечно буффер будет расти и система не будет успевать отправлять данные на хранение. Но если писать в несколько потоков — то мы получим многократное увеличение производительности, т.к. будут получены все плюсы concurent inserts в MySQL, а так же мы победим overhead от обработки запроса и подготовки его выполнения в СУБД.
И подведу итог: самомнение и высокомерие некоторых мешает им даже прочитать и осознать что писал их собеседник. Вы решили сразу написать пять увесистых параграфов, вместо того, чтоб просто хорошенько задуматься. Вы начали искать способ сказать что я не прав, вместо того чтоб понять о чем я писал. А вы так и не поняли.
А насчет ваших прогнозов о моем росте как специалиста — спасибо. Правда ваше высокомерие опять заставило вас ошибиться. Я уже являюсь разработчиком со стажем и руковожу весьма большим региональным проектом. Будьте сдержанней в высказываниях и заочной оценке собеседника.
UFO just landed and posted this here
не буду с вами спорить, просто приведу пример.
Oracle (знаете такую СУБД?) _все_ операции логирует. И пишет это все, знаете куда? угу, в файл :)
и чистит эти логи, и использует их для восстановления после сбоев.
так что вы еще раз подтвердили мое мнение по поводу программирования на php.
Oracle (знаете такую СУБД?) _все_ операции логирует. И пишет это все, знаете куда? угу, в файл :)
и чистит эти логи, и использует их для восстановления после сбоев.
так что вы еще раз подтвердили мое мнение по поводу программирования на php.
К чему все это было сказано? Суть комментария в констатации фактов?
суть комментария показать то, как вашу задачу решают в промышленном программировании
Нет, ваш комментарий имел суть указание того, что вы знаете что такое Oracle, и то что вы сомневаетесь в том, что я знаю о такой СУБД. Далее вы сказали что Oracle пишет лог транзакций. Более ничего вы не сказали и мысль свою никак не обозначили. Будьте конкретней.
эм…
конкретней: вы реализовали глупость.
это делается более привычными средствами.
для меня Oracle — это система, на реализации которой можно учиться, потому я привел пример реализации такой же функционаьлности, как доказательство своей правоты.
конкретней: вы реализовали глупость.
это делается более привычными средствами.
для меня Oracle — это система, на реализации которой можно учиться, потому я привел пример реализации такой же функционаьлности, как доказательство своей правоты.
Вы опять ничего не сказали. Если вам непоянта суть моего текст — поясню в двух словах — избавиться от нелостатков однопоточности лайти при логировании в пайп. То что вы написали — не несет никакого смысла. Разверните мысль.
Разворачиваю. Вот как нужно было делать:
1) Реализуем логирование в файлы
2) Реальзуем мониторинг файлов отдельным потоком и делаем с этими данными что хотим. кидайте их в базу, отправляйте по почте, все что душе угодно.
результат: меньше зависимостей -> повышение надежности, упрощение
что вас не устраивает в таком решении?
1) Реализуем логирование в файлы
2) Реальзуем мониторинг файлов отдельным потоком и делаем с этими данными что хотим. кидайте их в базу, отправляйте по почте, все что душе угодно.
результат: меньше зависимостей -> повышение надежности, упрощение
что вас не устраивает в таком решении?
Как раз наоборот — больше зависимостей и больше ненужных операций. Зачем писать в файл когда можно писать в память?
сорри, я заканчиваю на сегодня эту дискуссию.
спасибо. вы подняли мне настроение. я понимаю, что работа у меня будет всегда.
спасибо. вы подняли мне настроение. я понимаю, что работа у меня будет всегда.
Если так страшны дисковые операции, что мешает смонтировать tmpfs и писать в лог как в файл?
Неужели, за 30 секунд у Вас скопится столько логов, что это забьет всю память? А пропарсить файл легче, чем городить систему из пайпов и двух пхпшных программ.
Неужели, за 30 секунд у Вас скопится столько логов, что это забьет всю память? А пропарсить файл легче, чем городить систему из пайпов и двух пхпшных программ.
А кто сказал легче. Вот ради того чтоб прекратить все эти «а если» — напишите аналогичную систему с использованием промежуточных файлов и приведите ее код. А еще расскажите сколько времни уходит на ее развертывание и настройку.
Для сравнения — мое решение достаточно скопировать на целевой сервер и прописать как цель ведения логов в конфиге вэб-сервера.
PS и почему «городить систему из пайпов и двух пхпшных программ»?? Пайпы создаются автоматически при запуске любого процесса. Да и сами программы сложно назвать программами. Это два коротеньких и предельно простых скрипта.
Для сравнения — мое решение достаточно скопировать на целевой сервер и прописать как цель ведения логов в конфиге вэб-сервера.
PS и почему «городить систему из пайпов и двух пхпшных программ»?? Пайпы создаются автоматически при запуске любого процесса. Да и сами программы сложно назвать программами. Это два коротеньких и предельно простых скрипта.
1. Реализация на файлах не потребует агрегатора вообще, достаточно раз в Н времени запускать скрипт парсинга и делать truncate/ftruncate/переименовывать файл. По поводу lighthttpd не могу, честно говоря, ничего сказать, так как в основном используют nginx, который умеет по сигналу переоткрывать логи. Думаю, при грамотном использовании truncate, с лайтом проблем не возникнет, если он открывает логи с O_APPEND. А если нет — можно будет переписать и сделать так, чтобы открывал :)
2. Странно, ниже Вы писали, что Ваше решение как раз не готовое и его не надо копипастить в продакшн.
3.1. Про пайпы при создании каждого процесса, пожалуйста, поподробнее.
3.2. С простотой первого еще можно согласиться, но никак не с простотой второго. В то время, как вся система работы с файлами будет на 2 строчки длиннее первого скрипта.
2. Странно, ниже Вы писали, что Ваше решение как раз не готовое и его не надо копипастить в продакшн.
3.1. Про пайпы при создании каждого процесса, пожалуйста, поподробнее.
3.2. С простотой первого еще можно согласиться, но никак не с простотой второго. В то время, как вся система работы с файлами будет на 2 строчки длиннее первого скрипта.
1) все слова это. Покажите решение. На написание моего у меня ушло 40 минут. Если ваша задумка проще — приведите все что необходимо для релизации.
2) Код приведенный выше — это код который нужно еще доработать в некоторых местах. Я же говорю про решение в целом, а не про пример кода. Решение простое и его достаточно просто поместить на сервер и казать как цель логирования.
3.1) Посмотрите в код мой. Пайпы создаются простым указанием на то что их нужно создать. Это никак не соответствует тому что вы написали «городить систему из пайпов». Что в этом сложного?
3.2) Код второго файла прост до неприличия. Если этот код вам кажется сложным значит в ыне умеете читать чужой код.
И еще раз повторюсь — хватит пустых слов, покажите пример организации с файлами. С вычиткой файла, с защитой от непредвиденного завершения. По вашим словам написание этого займет у вас не более 20-ти минут.
2) Код приведенный выше — это код который нужно еще доработать в некоторых местах. Я же говорю про решение в целом, а не про пример кода. Решение простое и его достаточно просто поместить на сервер и казать как цель логирования.
3.1) Посмотрите в код мой. Пайпы создаются простым указанием на то что их нужно создать. Это никак не соответствует тому что вы написали «городить систему из пайпов». Что в этом сложного?
3.2) Код второго файла прост до неприличия. Если этот код вам кажется сложным значит в ыне умеете читать чужой код.
И еще раз повторюсь — хватит пустых слов, покажите пример организации с файлами. С вычиткой файла, с защитой от непредвиденного завершения. По вашим словам написание этого займет у вас не более 20-ти минут.
2. Решение — абстрактное понятие. Его нельзя скопировать и использовать.
3.1. Пайпы мало создать, их еще использовать надо.
3.2. Все относительно (с) не я.
1,4: Вот Вам решение.
3.1. Пайпы мало создать, их еще использовать надо.
3.2. Все относительно (с) не я.
1,4: Вот Вам решение.
Copy Source | Copy HTML
- #!/usr/bin/php
- <?php
- $log = '/dev/shm/mylog';
- $db = mysql_connect();
- $in = fopen($log, 'r');
- while ($in_str = fgets($in))
- {
- mysql_query('тут происходит передача $in_str в БД'); // обрабатываем строку в БД
- }
- // ifdef SUPPORT_SIG
- fclose($in);
- unlink($log);
- posix_kill($master_pid, SIGUSR1);
- // else
- ftruncate($in, 0);
- fclose($in);
- // endif
- }
1) упала софтина — откуда узнаем где остановились в прошлый раз при обработке?
2) мы пстоянно читаем, а чистим файл только когда все прочитали. Мы так можем никогда до чистки не дойти
Исправьте эти два допущения и получите код такой же длинны как и в моем варианте.
2) мы пстоянно читаем, а чистим файл только когда все прочитали. Мы так можем никогда до чистки не дойти
Исправьте эти два допущения и получите код такой же длинны как и в моем варианте.
1. Не понял. Что упало? Этот скрипт надо запускать по крону раз в Н времени. Падать при обработке она не должна. Если упал сам сервер — вариант с пайпом этого недостатка отнюдь не лишен.
2. Если у Вас логи генерируются быстрее, чем их можно парсить, надо задумываться над масштабированием на кластер/кластер больше/другую архитектуру.
2. Если у Вас логи генерируются быстрее, чем их можно парсить, надо задумываться над масштабированием на кластер/кластер больше/другую архитектуру.
Так это по крону? Тогда это не подходит к моему условию. Мне необходимо вносить записи лога с минимальными задержками.
30секундная задержка — это много?
И, все-таки, любопытно, назовите задачу, требующую такого странного логгирования.
И, все-таки, любопытно, назовите задачу, требующую такого странного логгирования.
Я же писал — файлхостинг. Причем с очень жесткими требованиями по учету трафика (требования эти не я выдвигал, но следовать им должен).
Если задача такая — то я вообще не понимаю, где тут проблема.
Считайте не после скачки, а до: пускай пользователю дается не прямая ссылка на файл, а ссылка на php-скрипт, пишущий заветную строку в базу и отдающий X-Accel-Redirect.
Считайте не после скачки, а до: пускай пользователю дается не прямая ссылка на файл, а ссылка на php-скрипт, пишущий заветную строку в базу и отдающий X-Accel-Redirect.
Опять же внимательное чтение топика избавит от необходимости задавать этот вопрос. Я написал что одно из значений, которое необходимо для учета — фактическое кол-во байт переданное за соединение. Эти данные доступны только после завершения соединения.
Ну так и парсите еррор-лог на предмет разорванных до передачи всего файла соединений.
А вот это уже мягко говоря бред. Во-первых в errorlog не попадают данные о предварительно разорванных соединениях, т.к. это вовсе не ошибки а нормальное поведение http соединения (клиент может выкачать часть файла). Во-вторых, даже если бы данные о разрыве соединения писались бы в какой то лог — то это довольно сильное усложнение парсинга, т.к. данные из этого лога необходимо было бы сопоставлять с данными от скрипта.
Вы зачем-то прицепились к идее записи лога в файл и парсинга его, хотя это вовсе и не просто, да и не имеет никаких преимуществ по сравнению с моей реализацией.
Опять же спор ради спора.
Вы зачем-то прицепились к идее записи лога в файл и парсинга его, хотя это вовсе и не просто, да и не имеет никаких преимуществ по сравнению с моей реализацией.
Опять же спор ради спора.
На деле всё сложнее. Диск, конечно, устройство медленное, только в современных ОС файл — это не просто данные на диске. Эти данные ещё кэшируются в RAM (при чём кэшируются весьма агрессивно), что уже делает файлы не такими-уж-и-медленными, а работа с закэшированными данными осуществляется с хитрыми оптимизациями, вроде zero-copy. Поэтому не так уж и страшно активно использовать файлы. Чистить же их не нужно будет. Существует известная техника logrotate.
При том размере логов которые накапливаются за полчаса работы на моем ресурсе — говорить о кешировании уже не приходится.
Про logrotate уже написано в комментариях (их нужно читать, чтоб не задавать одинаковые вопросы), так что основная проблема с файлами как раз в их чистке.
Про logrotate уже написано в комментариях (их нужно читать, чтоб не задавать одинаковые вопросы), так что основная проблема с файлами как раз в их чистке.
Дело не в общем размере лога, а в объёме одной записи. Вы что, по сотне мегабайт за один write скидываете? А когда вы скидываете помаленьку, то происходит как раз асинхронная работа с диском. Ядро системы записывает старые данные на диск, а новые небольшие порции складывает в кэш. И это всё происходит параллельно. При этом кэш — это весьма нетривиальная штука, она собирает статистику, подстраивается под профиль работы ваших программ, чтобы действовать эффективнее.
Вот если бы вы записывали по гигабайту за раз, тогда да. Кэш не помог бы. Но это же не ваш случай. А с logrotate я так и не понял, в чём вы видите проблему.
Вот если бы вы записывали по гигабайту за раз, тогда да. Кэш не помог бы. Но это же не ваш случай. А с logrotate я так и не понял, в чём вы видите проблему.
Повторю в сто десятый раз — а кто чистить будет все это? Вопрос не в том сколько за раз пишется, а в том что за час накопится много записей. Зачем писать в файл и дополнительно организовывать себе геморрой с чисткой из него отработанных данных, если можно писать в память и раскидывать данные оттуда.
А какие проблемы с чисткой? Вы организуете лог в виде набора файлов с номерами log_{1,2,3,...}, когда ваш анализатор логов очередной том парсит и загружает в базу данных, вы удалаете log с этим номером. В качестве номера можно использовать дату. А в логи писать только те данные, которые вы хотите загрузить в БД. Примерно такая схема.
IMHO, ваше решение точно так же работает, только оно вместо файлов складывает всё в память. Но в этом случае вы в своём приложении делаете повторно ту же самую работу, что может сделать за вас и OS. Да ещё при этом теряете часть гибкости, которая была бы, если бы вы работали с файлами. Например, можно было бы кроме аплоадера в базу данных прикрутить к анализу файлов процесс, который выявлял бы какие-нибудь атаки на сайт и высылал бы письмо админу.
IMHO, ваше решение точно так же работает, только оно вместо файлов складывает всё в память. Но в этом случае вы в своём приложении делаете повторно ту же самую работу, что может сделать за вас и OS. Да ещё при этом теряете часть гибкости, которая была бы, если бы вы работали с файлами. Например, можно было бы кроме аплоадера в базу данных прикрутить к анализу файлов процесс, который выявлял бы какие-нибудь атаки на сайт и высылал бы письмо админу.
Отвечаю в стоодиннадцатый — вы рассматривали вариант с ftruncate() лога?
А как очистка файла лога скажется на записи данных в этот файл сервером? Подумайте.
А как? Нормально скажется — файл очистится и сервер будет писать с начала файла.
В худшем случае можно потерять несколько записей которые будут записаны между моментом вычитки лога аггрегатором и truncate — но и этот race можно обойти, насколько я знаю.
Hint: inode не меняется а логи открываются обычно с O_APPEND.
В худшем случае можно потерять несколько записей которые будут записаны между моментом вычитки лога аггрегатором и truncate — но и этот race можно обойти, насколько я знаю.
Hint: inode не меняется а логи открываются обычно с O_APPEND.
Лайти очень сильно глючит с записью логов если их вручную обрезать. Пробовал этот вариант — абсолютно не годится.
Гм… судя по коду, глючить особо не должен, хотя могу ошибаться.
А как именно глючит и как обрезали? Можете развернуть мысль?
А как именно глючит и как обрезали? Можете развернуть мысль?
После truncate теряется около 10 записей, что в моем случае абсолютно неприемлемо.
А mandatory lock ставить пробовали перед последним read? Он, правда, не POSIX и в нём свой race есть, но в данном случае он, как я понимаю, не мешает.
Имхо, конечно.
В случае каких-то проблем с Вашим кодом не любой программист сразу поймёт что и как он делает. В случае с файлом — 99% сразу поймут что к чему.
Т.е. тут вопрос эффективности другой части системы — человека. Усложняя код Вы усложняете систему для человека.
Память конечно быстрее, никто не спорит — можно было запустить демона, который бы писал данные буферизованно, экономя и время и кол-во обращений к диску.
Чистить файл не обязательно, есть стандартные инструменты типа logrotate. Перевернул лог, удалил старый, никаких проблем.
В случае каких-то проблем с Вашим кодом не любой программист сразу поймёт что и как он делает. В случае с файлом — 99% сразу поймут что к чему.
Т.е. тут вопрос эффективности другой части системы — человека. Усложняя код Вы усложняете систему для человека.
Память конечно быстрее, никто не спорит — можно было запустить демона, который бы писал данные буферизованно, экономя и время и кол-во обращений к диску.
Чистить файл не обязательно, есть стандартные инструменты типа logrotate. Перевернул лог, удалил старый, никаких проблем.
Согласен, демон на С, который вычитывает данные и пишет их в какой-нибудь memory-mapped фаил, было бы куда эффективнее.
Вопрос в легкости развертывания кода. PHP-скрипт — это drop-in решение. Да и в скорости работы не уступает нативному решению (я проверял, т.к. изначальный вариант был написан на C)
Беда PHP в том, что в нём никто не проверяет ошибки. Вот, например, у вас код возврата select не анализируется :-)
То ли дело питон — просто вылетит исключение, всё в лучших традициях fail early, fail often.
То ли дело питон — просто вылетит исключение, всё в лучших традициях fail early, fail often.
А зачем анализировать возврат stream_select? Он тут служит не для выбора обновившегося потока, а просто как способ задержки.
Внимательно изучите код.
Внимательно изучите код.
Хабрапарсер съел шутливый тэг <holywar> в моём сообщении, ну да ладно.
Дело в том, что вы какие-то массивы с файловыми дескрипторами вроде передаёте в select… А вот представьте, что в один прекрасный момент какой-то из файловых дескрипторов станет невалидным — тогда select() вернет ошибку без задержки и может быть весь код зациклится в busy-loop (реальный случай из практики).
Ну и, на мой взгляд, в программировании вопроса «а зачем анализировать код ошибки» вообще не должно возникать.
Дело в том, что вы какие-то массивы с файловыми дескрипторами вроде передаёте в select… А вот представьте, что в один прекрасный момент какой-то из файловых дескрипторов станет невалидным — тогда select() вернет ошибку без задержки и может быть весь код зациклится в busy-loop (реальный случай из практики).
Ну и, на мой взгляд, в программировании вопроса «а зачем анализировать код ошибки» вообще не должно возникать.
Этот код — заготовка для дальнейшего развития. У меня на рабочих серверах реализовано все что надо — и отслеживание умерших обработчиков, и их перезапуск…
Код из топика может взять любой желающий и развивать далее.
Код из топика может взять любой желающий и развивать далее.
Вот-вот, поэтому я и недолюбливаю примеры как без обработки ошибок так и без упоминания о том, что её сделать не плохо было бы — мифический «желающий» пример скопипастит, а потом в один прекрасный момент наступает горе.
Если на боевых серверах всё обрабатывается — замечательно.
Если на боевых серверах всё обрабатывается — замечательно.
А копипастеру поделом. Кто же чужой код в продакшн кидает без анализа и осмысления???
А копипастер и не рассчитывал, что его небольшой опенсурцный проект будет использоваться кем-то кроме его самого =)
itblogs.ru/blogs/the7ofdiamonds/archive/2007/04/24/15634.aspx
itblogs.ru/blogs/the7ofdiamonds/archive/2007/04/24/15634.aspx
logrotate подразумевает временную остановку сервера. В случае с нагруженным ресурсом — это не вариант.
Не совсем так.
Насчёт лайти говорить не буду, т.к. не знаю, а nginx по USR1 просто переоткрывает логи, без остановки.
Управление nginx
Насчёт лайти говорить не буду, т.к. не знаю, а nginx по USR1 просто переоткрывает логи, без остановки.
Управление nginx
Жаль, что нгинкс не рекомендуется запускать с записью лога в пайп… хотя, может это и есть обход той самой проблемы?
И правильно не рекомендуют — что делать, если пайп умирает? В противном случае вебсервер должен брать на себя роль «daemontools» и сам запускать процесс, читающий пайп.
Кстати, согласно багтраку лайти так не поступает, при том баге уже почти два года.
Всё это какбэ говорит нам «писать логи в пайп — не лучшая идея».
Всё это какбэ говорит нам «писать логи в пайп — не лучшая идея».
UFO just landed and posted this here
К слову, функция mysql_ping сама восстанавливает подключение к mysql серверу, если оно было утeряно к моменту проверки. И только в случае невозможности его установить возвращается false;
я решау проблему переправки логов и обработки так:
на сервере где нужно читать лог:
tail -f logFile | nc ListenLoggerIp LoggerPort
ну а на ListenLoggerIp: LoggerPort сидит монстрик на java и всё это обрабатывает…
на сервере где нужно читать лог:
tail -f logFile | nc ListenLoggerIp LoggerPort
ну а на ListenLoggerIp: LoggerPort сидит монстрик на java и всё это обрабатывает…
мысли:
С агрегатором всё понятно, его основная цель — увеличить объём буфера, как бы продлить буфер pipe.
Просто так, к сожалению, нельзя увеличить объём буфера пайпа (по-умолчанию он вроде 4096), хотя можно пропатчить ядро :) В этом случае агегатор будет не нужен.
а вот с обработчиком… Не думаю, что что 5 обработчиков справятся со скармливанием потока БД лучше, чем один.
Попробуйте такой вариант — один обработчик, работающий по след. схеме:
Обработчик накапливает некоторый объём данных для слива в БД, к примеру до 100 штук но в течении не более 1-2 секунд.
После того, как накоплен нужный объём или произошел тайм-аут накопления — формируем sql для добавления, лучше в транзакции или какой-нибудь специальной блочной командой добавления.
Суть вот в чём — база всё равно одна, нет смысла тискать её 5-ю обработчиками — быстрее не получится, скорее наоборот.
С агрегатором всё понятно, его основная цель — увеличить объём буфера, как бы продлить буфер pipe.
Просто так, к сожалению, нельзя увеличить объём буфера пайпа (по-умолчанию он вроде 4096), хотя можно пропатчить ядро :) В этом случае агегатор будет не нужен.
а вот с обработчиком… Не думаю, что что 5 обработчиков справятся со скармливанием потока БД лучше, чем один.
Попробуйте такой вариант — один обработчик, работающий по след. схеме:
Обработчик накапливает некоторый объём данных для слива в БД, к примеру до 100 штук но в течении не более 1-2 секунд.
После того, как накоплен нужный объём или произошел тайм-аут накопления — формируем sql для добавления, лучше в транзакции или какой-нибудь специальной блочной командой добавления.
Суть вот в чём — база всё равно одна, нет смысла тискать её 5-ю обработчиками — быстрее не получится, скорее наоборот.
Идея для накопления данных в обработчике и составления большого запроса на вставку — интересна.
Вот только насчет записи в БД несколькими потоками вы ошиблись. Опыт показал что это позволяет вносить записи гораздо быстрее.
Вот только насчет записи в БД несколькими потоками вы ошиблись. Опыт показал что это позволяет вносить записи гораздо быстрее.
Ээээ а нельзя ли в системе увеличить объем буфера дял пайпа (или как там это называется), чтобы его хватало для отправляемых данных? Или данных в лог пишется так много?
p.s. Прочео в комментах, что там есть захаркоденное дурное ограничение, имхо — лучше патчить ядро, наверняка достаточно пару цифр поменять.
p.s. Прочео в комментах, что там есть захаркоденное дурное ограничение, имхо — лучше патчить ядро, наверняка достаточно пару цифр поменять.
При этом увеличится размер всех буферов всех пайпов в системе. Не очень бы этого хотелось.
Не, насколько я знаю не всё так просто, там размер буфера завязан на PAGE_SIZE — это раз, можно увеличить размеры ВСЕХ очередей, а не избранной, что может привести к интенсивному использованию памяти и доп. тормозам (пайпы ну очень часто используются в линукс-подобных системах)- это два.
Ужос!
В nginx-ru не раз обсуждалась тема и первым ответом авторам подобных решений было «пишите в файл». Почему? Ну, предположим, аггрегатор умер по какой-то причине. Хоп, и лайти прилетает SIGPIPE при записи в лог — с ненулевой вероятностью лайти от такой невежливости возьмет и умрёт.
Вот вы говорите, что надо перезапускать лайти для переоткрытия файлов — это, конечно, никуда не годится (неужели он действительно дропает соединения при SUGHUP? На форуме пишут обратное), но если допустимо потерять одну-две записи в лог, можно использовать ftruncate после того, как лог распарсен, если, конечно лайти открывает логи в режиме APPEND.
В nginx-ru не раз обсуждалась тема и первым ответом авторам подобных решений было «пишите в файл». Почему? Ну, предположим, аггрегатор умер по какой-то причине. Хоп, и лайти прилетает SIGPIPE при записи в лог — с ненулевой вероятностью лайти от такой невежливости возьмет и умрёт.
Вот вы говорите, что надо перезапускать лайти для переоткрытия файлов — это, конечно, никуда не годится (неужели он действительно дропает соединения при SUGHUP? На форуме пишут обратное), но если допустимо потерять одну-две записи в лог, можно использовать ftruncate после того, как лог распарсен, если, конечно лайти открывает логи в режиме APPEND.
Лайти перезапускает программу для записи в пайп при ее падении.
«Вежливая» перезагрузка сервера подразумевает прекращение приема новых соединений до момента пока сервер не отработает все оставшиеся соединения и не перезапустится.
«Вежливая» перезагрузка сервера подразумевает прекращение приема новых соединений до момента пока сервер не отработает все оставшиеся соединения и не перезапустится.
Лайти перезапускает пайп при падении? А почему же соответствующий баг не закрыт?
можно развязать сервер и БД через шину обмена сообщениями вроде memcacheq или spread
а тут RRDtool вам никак не поможет?
Сегодня в рассылке nginx'a была затронута схожая тема, описано неплохое решение: www.lexa.ru/nginx-ru/msg23177.html
Sign up to leave a comment.
Хитрости с логированием в однопоточных неблокирующих серверах.