Как ускорить чтение большого архива gz?

Question

[maiskiykot]

Есть файлы на десятки миллионов строк. Делаю для себя поиск по ним. Проблема в чем - если, его раскрывать, то даже винда начинает притормаживать и вываливаются приложения. Пошел по пути чтения с помощью php. Собрал с миру по нитке такой вот код

ini_set('memory_limit', '2048M');
  ini_set('max_execution_time', '3000');
  
 $z = gzopen($_POST['file'],'r') or die("can't open: $php_errormsg");
    $string = [];

    while ($line = gzgets($z,1024)) {
     
       if (preg_match("!".$_POST['request'][0]."[^0-9]!",$line))
       $string[] = $line;
    
    }
      //далее обрабатываю $string.

Все бы ничего, но ищет минуты три инфу, а тот же Emeditor несколько секунд. Как оптимизировать поиск в пределах php? Всем спасибо!

Comments

[Рональд Макдональд]

Проститьки, если не в тему, но почему бы не перегнать все данные в БД? Или это невозможно?

[maiskiykot]

Рональд Макдональд, Мне данные не нужны - только результаты поиска. И речь идет об архивах.

[Stalker_RED]

А ещё ваш алгоритм не найдёт строку, которая попала на границу блока.

[maiskiykot]

Stalker_RED, Это о чем? Файл - лог, порублен \n

[Stalker_RED]

maiskiykot, вы его рубите не по \n, а по 1024

$line = gzgets($z,1024)

[Stalker_RED]

maiskiykot, впрочем сорри, если строки короче 1024, то все норм

Answer 1

[Stalker_RED]

zgrep -i mySearchStr myFile.txt.gz

Comments

[maiskiykot]

У меня винда

[Stalker_RED]

maiskiykot, если wsl работает, то не проблема.
Ну или через cygwin.

[maiskiykot]

Stalker_RED, Задача не глобальная - нет желания время тратить на модификации системы. Пока попытаюсь в пределах своей системы расшевелить.

[Ипатьев]

Поставить Git-SCM - 2 минуты
Но можно продолжать есть кактус.

[maiskiykot]

Ипатьев, Так оно ускорит процесс? Вопрос скорее факультативный - для общего развития, поэтому нет необходимости ваять что-то - просто попытаться оптимизировать

[Ипатьев]

maiskiykot, оно не ускорит, оно позволить использовать zgrep
который будет искать мгновенно

Answer 2

[Daria Motorina]

1) вижу в коде $_POST и получение файла из запроса, не проще ли написать консольный скрипт, который просто читает файл по указанному пути?
2) можно использовать генератор, чтобы не грузить память файлом
https://www.php.net/manual/ru/language.generators....
https://riptutorial.com/php/example/5441/reading-a...

Comments

[maiskiykot]

Пост, потому что из формы кидаю параметры запроса и имя файла. В консоли геморройно получится. Мне надо вывод сделать с чекбоксами и потом почекать и сохранить.

[Ипатьев]

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

Answer 3

[rPman]

на php анализ логов будет очень медленным, я переписывал на c++ и получал до 10крат ускорение (можно и больше, все зависит от логики анализа, а при использовании clang llvm еще 2х, например парсинг json ускоряется буквально на глазах, пока llvm собирает статистику исполнения), у тебя основная нагрузка именно тут.

так же пользуйся многопоточностью, например готовые консольные утилиты и пайпы, запуская их из своей программы:

pigz -dkc dump.log.gz | grep -e 'регулярное выражение' | программа_анализирующая_итоговые_строки

тут дополнительно gzip заменен на pigz, можно скачать для windows даст кратно ускорение на распаковку за счет многопоточности.

upd: замени gzip на zstd, вот уж где ускорение получишь, и бонусом еще несколько процентов уменьшения размера архивов.

Comments

[maiskiykot]

pigz этот разве ищет в архивах? Судя по доке - он просто для архивирования/разахивирования сделан. И потом, как его вызвать из php?

[rPman]

он не ищет, он распаковывает, ключи -dkc это распаковать без удаления архива в stdout
| - передать поток следующей программе grep, которая умеет искать к примеру regexp (ключ -e) или передавай в awk, древнейшая утилита на си, специально созданная для анализа текстовых файлов в потоках... если нужно сложнее, бери perl (он создавался как убийца awk и sed) ну и либо, как уже сказал, пиши на c++ сам

смысл пайпов в многопоточности, все указанные программы будут запущены одновременно и будут ждать данные друг от друга, в результате обработка данных будет паралельной а не последовательной как в твоем коде (распаковал, потом поискал)

upd: замени gzip на zstd, вот уж где ускорение получишь, и бонусом еще несколько процентов уменьшения размера архивов.

[maiskiykot]

rPman, Чувствую - это мне неасилить в рамках решения вопроса. Но, как вариант, в будущем гляну при наличии времени. Спасибо!

[rPman]

В догонку, избавляйся от windows, очень многое на ней работает 'чтобы хоть как то работало' например для отладки.

Понятия не имею почему, но собранная утилита на c++ (просто парсит json, в логах, где 1 строка json примерно на 300 байт) с использованием microsoft visualstudio обрабатывала ~170к строк в секунду, собранная в gcc llvm mingw разгонялась до 400к, но когда я тот же код с теми же ключами скомпилировал в linux, на той же машине я получил почти 800к

Answer 4

[ksnk]

Читать нужно не по строкам, а блоками, килобайт по 40. Просто проверь - чтение блоками всего файла или чтение построчное gzgets. Вот искать в таких блоках сложнее - нужно гарантировать что найденный кусок не попадет на границу буфера чтения. Для этого, можно последнюю "строку" блока сохранять и копировать в следующий блок.
Читать загзипованые файлы удобнее, imho, обычными файловыми операциями fread, feof вот только открывать его придется gzopen. Как нибудь так...

if (preg_match('/\.gz$/', $name)) {
                $_handle = fopen($name, "rb");
                fseek($_handle, filesize($name) - 4);
                $x = unpack("L", fread($_handle, 4));
                $this->finish = $x[1];
                fclose($_handle);
                $handle = gzopen(
                    $handle, 'r'
                );
            } else {
                $this->finish = filesize($name);
                $handle = fopen($name, 'r');
            }

Comments

[AUser0]

К этому очень полезному ответу добавлю...
А обязательно для фильтрации использовать preg_match()? В $_POST['request'][0] хранится имено regex, или простой текст? Если второе - то банальный strstr() ускорит работу...

[maiskiykot]

AUser0, strstr не подходит. Поиск идет в основном по IP, а strstr ищет довольно-таки вольно ту же 4 = 4 = 44 = 444 и т.д.

[maiskiykot]

По поводу блокового чтения. Тут, конечно, напрашивается такой вариант, но дело в том, что все строки важны и результат поиска - именно строка, а не простое совпадение. Поэтому получается, что блок надо все равно разбивать на строки и как-то еще стараться собирать куски строк от разбиения, потому что искомая строка может быть как раз тем результатом поиска.

[ksnk]

maiskiykot, Ну так и что ? Ищем внутри блока какой-то такой регуляркой

// нужно найти строку $_POST['request']! внутри блока
if (preg_match("!^.*?".preg_quote($_POST['request'], '!').".*?$!m",$line)){
   echo $line[0]; // вся найденная строка
}

preg_quote позволит не парится по поводу точек и звездочек в строке поиска, модификатор m и указание начала-конца строки с нежадными точками - выдадут всю строку
Если нужно привязать к номеру строки файла - вот тут будет интересно - нужно будет собирать статистику по всем попавшимся \n в блоках с привязкой к смещению в буфере+смещение чтения самого буфера. Регулярку поиска нужно делать с PREG_OFFSET_CAPTURE и потом по получившемуся смещению вычислять номер строки.

[maiskiykot]

ksnk, Это я все знаю, умею. Меня смущает именно строка, которая неизбежно будет покоцана в конце/начале блока. А таковых тыщи получатся. Десятки миллионов строк. А результат поиска как правило 2-3 строки.

[ksnk]

maiskiykot, Нужно сохранить последнюю строку прочитанного блока и добавить ее в следующий
Найти последнюю строку -strrchr ищем символ \n в буфере, сохраняем хвост в переменной и отсекаем буфер на столько символов. При чтении следующего буфера - приписываем ему вначало сохраненный предыдущий хвост

[maiskiykot]

ksnk, мне все равно нужно для поиска блок эксплодить, так что кусок найти можно, но тут опять возникает проблема, если вдруг блок окончится аккурат на \n

[ksnk]

maiskiykot, Это же хорошо. Не надо передвигать хвост :) Нам нужно гарантировать, что каждый блок начинается с новой строки И заканчивается целой строкой. Строка у нас - это то, что заканчивается на \n

[maiskiykot]

В общем беспристрастные тесты показали:
1. Мой вариант - найдено 3 совпадения - 104 секунд
2. Вариант поблочно 4Мб блок - найдено 2(!!!) совпадения - 89 секунды.

Величина блока особого выигрыша не дает +/- секунды, а вот потерянная строчка - полное фиаско!

[ksnk]

Потерянная строка - это не фиаско, а ошибка в программировании (imho, конечно :) ). У меня на файле 3Гига, примерно, поиск строк в конце файла идет 1 минуту, на машине разработчика, тестирование phpUnit. Не моментально, конечно, но это всеж php... Размер буфера 40000 (40к). От увеличения размера скорость уже не увеличивается. 4MB - тут уже можно в ограничения на память самого php нарваться...
Причем забавный факт, если использовать регулярку в качестве средства поиска по буферам, то работает примерно в 2 раза быстрее, чем иcпользовать функцию stripos
Если интересно - https://github.com/Ksnk/scaner. В tests/readlogTest.php пример поиска по длинному логу.

[ksnk]

maiskiykot, еще странное наблюдение. fread, похоже сейчас всегда читает по 8к, независимо от запрашиваемого размера чтения. Это выглядит странным багом, но проверяется у меня в отладчике. php 7.3.17

[ksnk]

maiskiykot, Извиняюсь, все не так страшно, ограничение было связано с тем, что я в тесте читал файл из tar.gz архива. Однако скорость чтения большого файла, хоть какими блоками, существенно медленнее строковых операций. Настолько, что на этом фоне различать по скорости строковые операции и работу с регулярками уже в большой степени бессмысленно, они примерно одинаковы, с точностью до ошибок собственной реализации.

[maiskiykot]

ksnk, В этом и суть. От блочного чтения скорость не прыгнула до 10 сек к примеру, а точность поиска пострадала. А мне нужна каждая строчка из 19,7 миллионов