LINUX.ORG.RU
ФорумAdmin

flow-capture


0

1

Использую flow-capture с параметром -R для запуска скрипта для обработки новых файлов. Каждый файл содержит статистику за 5 минут. То есть скрипт запускается, опять же, раз в 5 минут.

Проблема в том, что скрипт убивается раньше, чем успеет закончить выполнение. Он делает достаточно много работы, поэтому не укладывается в 5 минутный интервал. Как побороть эту проблему?

На ум приходит nohup, но уверенности нет.


Кем убивается?
Как можно догадаться из названия, nohup позволяет скрипту игнорировать сигнал SIGHUP

zolden ★★★★★
()
Ответ на: комментарий от berrywizard

Не спасет. flow-capture запущен в фоне и не дохнет при разлогинивании. Тут дело в другом.

rayven
() автор топика
Ответ на: комментарий от zolden

А вот кем убивается я не знаю. OM_KILLER в логах не отписывался, так что это не он. Возможно сам flow-capture и убивает процесс по таймауту. Я не знаю как он работает в этом отношении.

rayven
() автор топика

Можно написать скрипт, который будет запустить нужный скрпит «демоном», так, чтобы flow-capture и не знал, о том, что тот скрипт работает. И nohup не обязательно, на bash'е можно обрабатывать сигналы. Только, не понятно, если скрипт не успевает отработать за 5 минут, почему два скрипта смогут отработать за 10 минут?

mky ★★★★★
()
Ответ на: комментарий от mky

Только, не понятно, если скрипт не успевает отработать за 5 минут, почему два скрипта смогут отработать за 10 минут?

Да он там чуть-чуть не успевает. Но таки да, может со временем превратиться в снежный ком при определенной нагрузке. Буду думать как переписать так, чтоб успел.

rayven
() автор топика

если он не успевает за 5 минут, то получается что количество процессов со временем будет только расти

nohup не спасет, т к он убивается сигналом SIGTERM. есть вариант написать костыль noterm, но это чревато

наверное проще всего будет выпилить -R и просто запускать по крону, но опять же если оно не успевает за 5 минут, то может вылезти боком.

самым правильным вариантом наверное был бы демон, который следит за тем, чтобы файлы постоянно обрабатывались, но не больше чем в n потоков.

redixin ★★★★
()
Ответ на: комментарий от redixin

Уже думаю как-то на inotify замутить.

rayven
() автор топика

Как-то я работал в одном так-себе-провайдере, и там flow-capture просто тупо писал файлы каждые 15 минут в директорию. Т.е. файлы закрывались ч0тко в 0,15,30,45 минут часа.

А вот по крону уже через пару секунд после закрытия файла запускалось ядро биллинга, обрабатывало все финишированые флоу-файлы, которые находило (в идеале он был один, но в моменты нагрузки - больше) и после обработки каждого переносило его в другую директорию. Просто и асинхронно, никакой завязки на сам флоу-капчур.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Ну, коль есть параметр -R, почему бы его не использовать? Тем более, если нет желания заморачиваться с inotify или делать простой пулинг.

Я тут запустил скрипт автономно через time и получил, что он выполняется полностью за 1:38. Короче, он ни не успевает, а дохнет по какой-то другой причине. Он успевает сделать много, но не все, пока не умрет.

Буду смотреть как бы на перле перехватить сигналы, чтоб понять от чего же он дохнет.

rayven
() автор топика

По-моему, всё это фигня, пока не поймёшь почему и кем убивается процесс.

Lego_12239 ★★
()
Ответ на: комментарий от rayven

Вам шашечки или ехать? Не использовать именно потому, что он у тебя не работает. А еще потому, что он может и не успеть всё сделать до закрытия следующего файла, если тебя долбанут каким-нибудь даже небольшим DDOSом, который создаст кучу флоу. Асинхронность она почти всегда хороша, а тут тем более.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Не использовать именно потому, что он у тебя не работает.

Нужно сначала понять почему не работает.

А еще потому, что он может и не успеть всё сделать до закрытия следующего файла

Вот не успеть может, но я все же думаю, что успеет. Просто тут еще есть фактор потраченного на это времени: это я делаю для себя и в свое свободное время, это не является основной работой. Хотя, конечно, если ни чего «в лоб» решить не получится, то я напишу как Вы предлагаете, я согласен, что это правильный подход.

Асинхронность она почти всегда хороша, а тут тем более.

Пока хочу только переписать с использованием многопоточности ибо задача легко параллелится, а на 2.8x6 ядрах гнать все в один поток — глупо.

rayven
() автор топика
Ответ на: комментарий от rayven

Для обсчёта траффика удобнее считать сразу несколько флоу-файлов в параллели, а не заморачиваться с кучей тредов.

Когда я писал биллинг, то в итоге пришел к тому, что перловый скрипт запускался раз в 15 минут, а флоу-капчур выплёвывал файлы каждые 5.

В итоге скрипт запускал сразу три процесса ядра на Си для обсчёта сразу трёх файлов параллельно.

А в самом ядре многопоточность сводилась к тому, что основной тред читал и распаковывал (флоу-файлы по умолчанию пожаты в gzip6) данные и складывал их в асинхронный буффер, а второй тред уже брал их оттуда и занимался обсчётом юзая хэш-таблицы.

В общем и целом получалось быстро и расширяемо - всегда можно добавить ядер и сделать разбивку флоу хоть по 1 минуте.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Мой скрипт после обработки flow-файлов заносит данные в RRD. Что бы в кактусе все было красиво, RRD нужно обновлять каждые 5 минут.

Суть в том, что мне нужно запустить около 100 раз flow-report с разными переменными, он генерит ~200 отчетов, на их основе заносятся данные в ~100 RRD.

Спасибо всем, кто пытался помочь. Проблему с крашем в однопоточной версии я решил. Мораль такая: инициализировать переменные перед использованием надо.

Сейчас переписал с использованием многопоточности. Нарвался похоже на проблему, описанную здесь: https://lists.oetiker.ch/pipermail/rrd-users/2006-September/011680.html. Хотя, я не пытаюсь одновременно получить доступ к одной RRD из разных потоков, как пишет автор. У меня проблема возникает при одновременном доступе к функциям RRD::Simple: segmentation fault; Так что скрипт многопоточный, но доступ к RRD пока делаю только в одном потоке в одно время (использую lock()).

rayven
() автор топика
Ответ на: комментарий от rayven

rayven

Кстати, с 10 потоками 1:40 превращается в 1 минуту, при необходимости создания новых RRD. Не плохо, но с одновременным апдейтом RRD было бы быстрее.

Если все RRD уже существуют, укладывается в 15 секунд. Гуд.

rayven
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.