Эта тема на forum.dklab.ru


lorien: Потребление ресурсов при парсинге
Ой... классно вы сделали с выпадающим поиском.
Я создал похожую тему на phpclub но некий Фанат там сначала поиздевался, а потом её в корзину сбросили, попробую счастья тут попытать.
Вопрос такой:
Какие места в программе могут быть источником сбоя при большом объёме работы? Программа - скрипт парсинга страниц из интернета. Страница скачивается (CURL), затем парсится и полученная инфа заносится в БД. Так вот при большом количестве документов... сотни тысяч... в одном скрипте возникала ошибка... другой завесил сервер, хотя потом отработал правильно. В чём могут быть потенциальные грабли?
Я понимаю, что можно разбить работу на части и запустить каждую часть отдельно, но ведь формально скрипт ведь должен отработать и при полном объёме?
Юрий Насретдинов:
В чём могут быть потенциальные грабли?
Оперативная память заканчивается
Евгений Галашин:
некий Фанат там сначала поиздевался, а потом её в корзину...
((((-:

А Вы уверены, что Вам нужно проделывать столько работы, причём именно на PHP?
Дмитрий Котеров:
lorien, Вам стоит почитать http://citforum.ru/howto/smart-questions-ru.shtml
Ошибка может быть в чем угодно.
Anonymous:
Да, действительно, вопрос у меня абстрактный. Я уже переделал скрипт для работы по вызову кроном и у меня появился следующий вопрос: как правильно организовать парсинг в несколько потоков?
Проблема в том, что есть, диапазон чисел ( id страницы ): нужно парсить их в несколько потоков, так чтобы каждый поток брал новый кусок пинов и чтобы он знал, какие пины обрабатываются в данный момент, чтобы не обрабатывать их повторно + надо как-то контролировать количество потоков, чтобы их было определённое количество.
Может быть, у кого-нибудь есть пример подобного скрипта?
Дмитрий Котеров:
В PHP очень плохо с fork-ом - вернее, в mod_php он не поддерживается (только в cgi_php, да и то - если админ включил).
Рекомендую просто повесить в крон запуск сприпта каждую минуту, а в нем уже решать, что делать да как. В итоге у Вас через 5 минут будет 5 работающих одновременно скриптов - считайте, 5 потоков. Только смотрите, чтобы их было не больше N, а то хостер забьет тревогу! Не стартуйте лишние, обламывайте их на старте.
lorien:
Я пришёл к двум решениям:
- первое, как вы предлагаете
- второе, это в одном скрипте отрывать сразу несколько сокетов и в цикле тянуть из них информацию.
Можно совместить первый и второй способ - главное не переборщить :-) Я сейчас думаю о том, как организовать работу одновременных потоков т.е. как очередному запущеному потоку взять для себя работу и сказать остальным, чтобы не трогали эту часть страничек. Допустим номер очередной страницы, которую нужно пропарсить хранится в БД ( адреса страниц имеют вид: http://domain.tld/path/page\.php\?pin=\d{10} ). Очередной поток считывает этот номер и "сразу же" увеличивает его не единицу :-). А вдруг какой-то ещё поток успеет считать этот номер? Как этого избежать?
Дмитрий Котеров:
Используйте блокировку таблиц, например (LOCK TABLES). А можете сделать и через flock().
lorien:
А как лучше ограничивать количество одновременно работающих экземпляров скрипта? Я могу завести в таблице БД поле для счётчика, но ведь если скрипт вдруг "сдохнет" во время работы, то он не уменьшит счётчик на единицу и тогда в счётчике будет числиться фиктивный экземпляр и реально уже будут работать только N-1 экземпляр скрипта.
Ramzes:
lorien
Пусть скрипт периодически отписывается о своей работе и кидает в базу текущее время, а потом скрипт когда проверяет, он будет смотреть, если один экземпляр уже целый час мазохизмом страдает - значит он сдох и можно ео не считать, а вообще посмотрите утечку памяти, не создавайте кучу переменных, работайте в одном комплекте...
Дмитрий Котеров:
как лучше ограничивать количество одновременно работающих экземпляров скрипта?
Существует такое понятие как "семафор", однако в Вашем случае, наверное, это будет слишком сложно.
Можете, в принципе, реализовать это дело также через flock(), содавая по одному файлу с уникальным именем (getmypid()) в начале работы скрипта, а потом подсчитывая число заблокированных файлов (LOCK_NB) - это и будет общее число работающих в настоящий момент скриптов. В конце файлы удаляйте. Если скрипт сдохнет - ничего страшного, его файл останется, но он окажется незаблокированным, так что не подсчитается.

Эта тема на forum.dklab.ru