flow-capture

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

screen спасёт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой скрипт после обработки 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

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

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