1.2, Аноним (-), 17:52, 23/06/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надо же, он ещё жив.
Строго говоря, он был бы актуален лет 7 назад, а сейчас морально устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct заруливает сабж в гибкости и опять же по ресурсам.
| |
|
2.3, vi (?), 18:18, 23/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Надо же, он ещё жив.
> Строго говоря, он был бы актуален лет 7 назад, а сейчас морально
> устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct
> заруливает сабж в гибкости и опять же по ресурсам.
Доброго!
Есть результаты тестов?
| |
|
3.4, Аноним (-), 03:03, 24/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Делал только для себя, на 100мбитном канале, с десятком пользователей. Насчёт объективности - смотри сам.
Так вот, Данные о трафике у меня хранятся в базе, чтобы выборки делать кто/сколько выкачал.
Поставил ulogd (я говорю о первой ветке) - считать считает, на этом его преимущества заканчиваются. Он любую базу может поставить раком, если что-то качнуть во всю ширину канала. Даже при простом подсчёте - тоже грузит систему (примерно 15-20% от тогдашнего 3ГГц Прескотта). Вменяемых средств записи логов "хоть куда" при отказе бд - нет, если упала - потеряешь все данные о трафике за время, пока бд не поднимется.
ulog-acct - пишет только текстовый лог, с базой напрямую работать не умеет. Пришлось писать парсер логов для закидывания в базу. При подсчёте трафика - в топе процессов его видно только в момент записи логов (меньше секунды раз в 2 минуты). А вот загрузка лога в бд занимала ещё секунд по 5 (это с применением многострочных инсёртов и транзакций). Лучше, но хочется большего.
pmacct - аналогично выше, но умеет работать с базой. Может создавать таблицы по шаблону. В топе вообще не видно. Перешёл полгода назад - полёт нормальный - сейчас только отчёты смотрю.
По базе: изначально думал обойтись sqlit'ом. Фиг, как только база переваливает за гиг - всё начинает тормозить, там сплошные инсёрты. Поставил мускул - полегче, но всё равно тормозило (на innodb - дохло аналогично с sqlit'ом, с myisam - нормально). Посгре не пробовал.
| |
|
|
5.10, Аноним (-), 23:22, 25/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Спасибо, товарищ. Очень познавательно.
Примерно как сравнение по фичам windows 7 и Linux 1.0.
Все вышесказанное относится только к первой ветке ulogd, и никак не связано со второй.
| |
|
4.6, XoRe (ok), 23:51, 24/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
Для логов в БД рекомендую использовать более специализированные для этого движки.
А то через некоторое время myisam у вас тоже начнет нехило тормозить.
Что-то конкретное подсказать не могу.
Я бы попробовал csv движок.
| |
|
5.9, Аноним (-), 02:18, 25/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
Что-то мне подсказывает, что там с индексами будет проблема. Но тем не менее - пока работает и нагрузку держит - менять не буду.
| |
|
4.8, Аноним (-), 01:09, 25/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
После появления nfacct, всякие юзерспейсные pmacct можно отправлять на свалку истории :)
| |
|
|
2.7, Аноним (-), 23:53, 24/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Строго говоря, он был бы актуален лет 7 назад, а сейчас морально устарел. ulog-acct жрёт меньше ресурсов при подсчёте на аналогичном канале, pmacct заруливает сабж в гибкости и опять же по ресурсам.
Теперь его переписали с нуля, и в пору объявлять устаревшими и тормозными уже ulog-acct и pmacct :)
| |
|
|