Переменную не обработать
- Автор темы Monah IRH
- Дата начала
Monah IRH
Новичок
Да сделано это уже. Скачивается частями (изначально качало целиком, но я пару сообщений назад написал, что модифицировал алгоритм, теперь качаю по частям и обрабатываю). Обрабатывается в цикле. Старую часть uset, новую на место старой загоняю. После каждой части сохраняю аналзируемые цифры в отдельные переменные. Во время обработки куча модификаций разных идет и с цифрами и с текстом через Preg_match в том числе реализован их поиск, поэтому регэкспов реально много.. т.к. скрипт вылетает на 12м проходе, значит памяти на первые 11 хватает, следовательно ( как мне кажется это единственная возможная причина ) что-то лишнее остается после преобразований в памяти кроме результирующих цифр.. вот и думаю возможно ли как-то посмотреть содержимое всех переменных сразу во время работы, аналогично дебагеру в том же Си.
-~{}~ 09.08.08 22:57:
У хостера 4.4.2
на локальной машине 4.4.1
Bu-Bu
Любитель PHP
Значит нужно уменьшать части до разумных пределов. У меня была такая фишка с определением ТИЦ на 700 сайтов. Пока не довел количество сайтов до 15 за один проход - сервер вываливался. И насчет переменных - нужно попробовать реализовать сохранение через файлы, т.е. каждый раз перезаписывать лог с новыми данными
Monah IRH
Новичок
почему. есть конкретные ужасные причины этой версии php?
Хост заказчика скрипта (и работать скрипт в последствие уже будет без моего участия на ихнем хосте в закрытой зоне).. вешаться не хочется, а делать надо..( и так уже простой почти неделю.. парюсь, ничегоне получается, кофе уже кончается.. и здоровье)
Bu-Bu
Любитель PHP
Что-то не может переполняться! Разбил файл на части, затем делай цикл типа foreach ($part as $value) и в конце каждого прохода $result дописывай к файлу log.txt и ничего переполняться не будет! А потом уже лог анализируй, а если и он большой, то и его дробить надо. Или качай все на локаль и извращайся по-своему.ю
tony2001
TeaM PHPClub
>выяснилось, что регулярные выражения не обрабатывают текст размером больше 100 000 байт.
не надо писать кривые рекурсивные регэкспы, которые переполняют стэк.
а если уж так хочется - увеличивайте размер стэка.
>Большие файлы умные дяди открывают с помощью file.
угу, и потом делают implode().
не мели ерунду.
не надо писать кривые рекурсивные регэкспы, которые переполняют стэк.
а если уж так хочется - увеличивайте размер стэка.
>Большие файлы умные дяди открывают с помощью file.
угу, и потом делают implode().
не мели ерунду.
Monah IRH
Новичок
в итоге безуспешных скитаний по строкам своего кода и результате каких-то манипуляций нашел ошибку "Request-URI Too Large". Исправил её - всё заработало. Ошибка возникала на месте в коде, которое появилось после изменения алгоритма. В итоге делаю вывод, что сначало тупо не хватало памяти, потом тупо делал слишком длинный запрос. Видимо просто на сервере стоит защита от зацикливания скриптов, которая обрубала его выполнение, поэтому он и вылетал. С регулярками дело было не связано.. кстати на локальной машине 7ми метровый файл исполняется нормально, так что ограничения на 100 000 байт вроде нету. Надеюсь это не временный глюк, что всё заработало, а действительно так. Спасибо за помощь 
Bu-Bu
Любитель PHP
file - готовый массив строк и уж размер одной строки никак не может быть больше 1кб. Почитай любую инфу - простой цикл обработки этих строк будет гораздо быстрее, чем тупое прочесывание одной строки длиной сотни тысяч знаков. Какие блоки, товарисч? Так что ответ не так очевиден, по крайней мере для меня.
tony2001
TeaM PHPClub
>file - готовый массив строк и уж размер одной строки никак не может быть больше 1кб.
да ну!
т.е. тебе сложно представить себе гигабайтный файл без переносов строк?
>Почитай любую инфу - простой цикл обработки этих строк будет гораздо
>быстрее, чем тупое прочесывание одной строки длиной сотни тысяч знаков.
что это еще за бред =)
какое еще прочесывание?
разница только в одном - ты читаешь весь файл в память и по пути делишь его на куски, причем:
1) хранение более одной строки в один момент времени смысла не несет, всё равно обрабатывается только 1 строка за раз.
2) построчное деление имеет смысл только когда данные должны обрабатываться по строкам (CSV и т.п.).
я бы порекомендовал тебе для начала потренироваться на гигабайтном файле с парой \n внутри, а потом попробовать читать тот же файл блоками по несколько килобайт, обрабатывать один блок и переходить к следующему - увидишь разницу.
да ну!
т.е. тебе сложно представить себе гигабайтный файл без переносов строк?
>Почитай любую инфу - простой цикл обработки этих строк будет гораздо
>быстрее, чем тупое прочесывание одной строки длиной сотни тысяч знаков.
что это еще за бред =)
какое еще прочесывание?
разница только в одном - ты читаешь весь файл в память и по пути делишь его на куски, причем:
1) хранение более одной строки в один момент времени смысла не несет, всё равно обрабатывается только 1 строка за раз.
2) построчное деление имеет смысл только когда данные должны обрабатываться по строкам (CSV и т.п.).
я бы порекомендовал тебе для начала потренироваться на гигабайтном файле с парой \n внутри, а потом попробовать читать тот же файл блоками по несколько килобайт, обрабатывать один блок и переходить к следующему - увидишь разницу.
Bu-Bu
Любитель PHP
Не думаю, что гигабайтный файл без переносов строк вообще возможен. Скорее всего любой текстовый файл будет с форматированием, а товарищ обрабатывает именно такой файл и явно с построчной информацией, иначе его разбор вообще теряет смысл. Прочесывание - я имел в виду прогон через регулярки.