Сабж. Не удобно запускать и управлять (и обновлять) 5-7 копями парсера с целью распределения нагрузки на сервер
Постоянно упираюсь в процессор. Например, сегодня одновременно парсил майлы с вконтакте (50 потоков без прокси), сниппеты с Гугла (прокси 75 потоков) и ссылки на авито из Гугла (прокси 75 потоков). Задействовано было только 1 ядро из 8 и ядро загружено на 100%. Загрузка остальных ядер 0%. Из за перегрузки ядра, общая скорость парсинга меньше. При отключии парсинга сниппетов, загрузка ядра падает и скорость загрузки VK и Avito увеличивается почти в 2 раза. Загрузку процессора проверял утилитой htop. жесткий диск (iotop) не загружен, памяти свободной тоже достаточно
Похоже причина загрузки процессора в том, что базы получаются большие, по несколько десятков и сотен мегов (от 1млн строк в каждом файле) и на удаление дублей тратится много процессорного времени
да врятли, это очень быстрые операции, я думаю основная причина в неоптимизированных регулярных выражениях которые ты указываешь попробуй нагрузить ядро каким нибудь парсингом без своих регулярок
Регулярки не причем. Загрузил сейчас задание - парсить все подряд сниппеты в зоне ru. Результат как всегда - ядро перегружено, скорость парсинга из за этого относительно небольшая. Задача ресурсоемкая, за 10мин напарсил ~500 мегов сниппетов. Проц - Intel Quad-Core Xeon E3-1230, 3.4 Ghz
Проц - Intel Quad-Core Xeon E3-1230, 3.4 Ghz. До этого был Core i7-920 2.6Ghz, там тоже ядро перегружалось
Да точно, убрал Parse custom result, теперь 1 задание парсинга сниппетов на 300 потоках - загрузка ядра ~90%, в 3 раза увеличилась скорость. Unique level = Dynamic (без hash) Но это частный случай, я в основном использую Parse custom result c регулярками, по 5-10 одновременных заданий стоит в работе. В любом случае приходится распределять задания между несколькими копиями парсера. Регулярки использую такие: (([A-Za-z0-9_\.\-]{1,20})@([A-Za-z0-9\.\-]{1,20})\.([A-Za-z]{2,4})) Или конструкции в таком стиле - Контактное лицо:</div>(.*?)<
