netup.ru

[littlesavage]

Представляю ya_get_nf_direct - еще один вариант утилиты выдирания детальной статистики UTM.


Cовместима по параметрам с имеющимя в UTM get_nf_direct'ом. Основные улучшения:

• Прозрачная распаковка gz/bzip2/lzma/xz архивов
  
• Возможность экспорт результатов в SQlite3 базу данных.
  
• Расширенные правила фильтрации с использованием полей БД, операторов =,!=,<,>, скобок и логических операторов И/ИЛИ/НЕ
  
• Возможность чтения данных с stdin (для этого и переписывалось).
  
• В качестве времени (-from, -to) можно указывать время в формате ГГГГ-ММ-ДД[TЧЧ:ММ:СС]
  
• По SIGINFO/SIGUSR1 показывает текущий статус
  
• Open source
  

Из зависимостей - libarchive >= 1.8. На большинстве систем придется его обновлять/доустанавливать.

Код на github: https://github.com/littlesavage/ya_get_nf_direct

[Rav]

Я так понимаю, что эта утилита только для старого формата хранения статистики?

[JAO]

А фильтрация содержимого там многопоточная?

[littlesavage]

Утилита только для нового формата.
Распаковка и фильтрация там однопоточная.

[JAO]

Вот фильтрацию не мешало бы разделить на число ядер в системе.

Для четырех тредов

1) читаем из потока кратное 4 число записей (или что осталось, если близко к концу файла) и складываем во входной массив
2) стартуем треды со следующими параметрами: первый тред стартует с нулевой записи, второй - с первой, третий - со второй, четвертый - с третьей, и идут до конца массива с шагом 4, каждому треду передается указатель на свой выходной массив, в который складываются номера отфильтрованных записей
3) когда все треды отрабатывают, главный тред выбирает из входного массива записи согласно номерам из четырех выходных массивов и так собирает урожай

Главное преимущество такого решения - скорость за счет работы только с оперативной памятью и полного отсутствия синхронизации тредов. Да, все блоки динамической памяти создавайте до запуска тредов и ни в коем случае не внутри них - это будет ударом по производительности. К примеру, если будете использовать std::vector<int> в качестве выходного массива, установите ему размер до запуска треда, чтобы во время работы треда он не делал движений по изменению своего размера (а они неявные).

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

[littlesavage]

Фильтрация выполняется значительно быстрее распаковки, она там вообще незаметна. Разбора текста там нет, выражение вначале преобразуется во внутреннее представление.
Вот распаковку можно распаралеллить. Хотя сейчас оно уже особо никому не надо За 2 года мне самому понадобилось воспользоваться этим фильтрм всего 1-2 раза.

[JAO]

Тогда и распаковку в треды. Операция ведется над группой файлов, или списком. Точно так же обработать список с шагом, равным количеству тредов. На выходе, правда, каша получится, но можно отсортировать как надо.