Почему продолжает расти потребление ОЗУ?

Roman Kitaev, большое спасибо, общая идея дошла.

Почему продолжает расти потребление ОЗУ?

Roman Kitaev,
1. Т.е. я без проблем могу

pub = await aioredis.create_redis('redis://localhost')

оставить в __main__ и сам pub передавать в качестве аргумента? Ок.
2. Я использую публичные прокси конкретно для этого скрипта, там овер-много блоков и мертвых прокси. В том скрипте, который чисто на multiprocessing работает вроде ничего не зациклилось. Может поищу что-то среднее между паблик и приват прокси, тогда уберу while
3. Хорошо.

По поводу "впихнуть пару строк" — можно попробовать оставить в первом скрипте, который качает данные. Я почти уверен, что одна регулярка почти не помешает IO операциям

Вы не поняли. Основная проблема в том, что ссылку на страницу, где я применяю регулярку, получить можно распарсив 1 из 3 страниц, при чем на любой из этих страниц как может быть ссылка, так и нет.
Т.е. последовательность такая:
1. Паршу страницу.
2. Ищу на ней ссылку.
3. Если есть ссылка, то перехожу к п. 4, если нет, то повторяю п 1.
4. Загружаю новую станицу.
5. Прохожусь по ней регуляркой в поиске емеил.

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, получаю html со всех страниц:
html_scrape.py (pastebin)
получаю данные из этих html:
html_parse.py (pastebin)
1. Насколько такой подход близкий к правильному?
2. И куда мне все-таки впихнуть вот эту пару строк:

response = await r.text()
match = re.search(r'[\w\.-]+@[\w\.-]+', response)

Суть в том, что этот кусок нужен для нахождения email на странице, ссылку на которую есть только на другой странице. Т.е. мне нужно: получить html страницы, распарсить её, найти ссылку на другую страницу и только на этой другой странице можно найти email. Все остальные страницы я могу в "сквозную" загружать с asyncio. Собственно, насколько сильно это может тормозить процесс парсинга html страниц, если я впихну туда 1 обычный реквест?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, извиняюсь, могу я в этом треде напоследок вам еще один вопрос задать касательно pub/sub механизма redis и создания multiprocessing pool?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev,

Ну и раз уж это парсить, то можно и всё остальное распарсить сразу

в смысле?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, не, дополнительные страницы можно парсить и по url, передавая его в качестве параметра в запросе. Единственное исключение:

response = await r.text()
match = re.search(r'[\w\.-]+@[\w\.-]+', response)

Я так понимаю это тоже CPU-bound и его нужно выкидывать из asyncio?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, а если обойтись все-таки 1 очередью?
Т.е. у меня есть основной сайт + 3 сайта с дополнительной информацией. Если я всегда с asyncio буду выгребать все 4 сайта и отдавать их через redis выполняться в multiprocessing?
С двумя очередями, как я вижу, будут плодиться лишние выполнения asyncio что может замедлить работу. Т.е. мне в любом случае нужно 100% грузить как минимум 2 страницы, если я буду грузить всегда 4 страницы, то это может быть быстрее, чем если создавать дополнительные асинхронные выполнения?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, понял, тогда что на счет другого:
Я захожу сначала на 1 страницу, нахожу на ней нужную мне ссылку, затем захожу по этой ссылке и там собираю нужную информацию, затем перехожу по еще одной ссылке и т.д.
Только для 1 записи мне нужно посетить минимум 3 страницы, иногда 5. Т.е. мне нужно зайти на страницу, спарсить с неё нужный результат и т.д.

Почему продолжает расти потребление ОЗУ?

загрузят процессор максимально возможно, не мешая друг другу

Т.е. эти условные 10 процессов будут отрабатывать максимально быстро и 100 задач по 10 процессов отработают быстрее, чем 100 процессов сразу?

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, я правильно понимаю, что эффективнее будет загружать страницы с asyncio (aiohttp), загружать их в в условный html_pages = [] и оттуда процессами брать и парсить их?

Причём, количество процессов бессмысленно указывать больше, чем ядер у тебя в компуктере.

Почему? Если я запущу на данный момент 10 процессов, то они отработают гораздо медленнее, чем если запущу 100 процессов.

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, нет, мой код работает и решает мою задачу, где вы вообще увидели в моем сообщении обратное?
Давайте еще раз продублирую вопрос: "Собственно: на что расходуется ОЗУ и можно-ли как-то это предотвратить именно для этого кода?". Сейчас "жор" ОЗУ очень незначительный, иногда даже память освобождается но вопрос всё еще актуальный.

Почему продолжает расти потребление ОЗУ?

Влад Григорьев, я и так использую scrapy/asyncio где это удобно сделать. Сейчас мне нужно проверять по 3500-4000 страниц в минуту, ни scrapy ни asyncio не удовлетворяют этим требованиям.

Почему продолжает расти потребление ОЗУ?

Можно. Написать нормально

Хорошо, что в вашем понимании "нормально", что-бы была возможность за 1 минуту собирать 1000 записей с ~4000 страниц?
Допустим, BS выкинул, проблемы с памятью нет, отлично. asyncio работает в разы медленнее, чем multiprocessing в конкретно моем случае.

Увы, говнокод на то и говнокод

Мой говно-код решает мою задачу, вы предлагаете мне её не решать, только лишь потому что "нормального" способа решения задачи нет, а говно-код - это "фу". Я правильно вас понимаю?

Почему продолжает расти потребление ОЗУ?

но человек считает что все эти решения оверхед

Откуда придумали? Я использую большую часть того, что мне советуют здесь.

который считает себя умнее остальных

Считал-бы - не задавал-бы здесь вопросы.

Мы же тебе помочь хотим, а ты сопротивляешься

Чем? Советом, что 10 процессов лучше 1000? Единственный, кто в этой теме пытается помочь - это longclaps
Если вы не обратили внимания, то мой вопрос: на что расходуется ОЗУ и можно-ли как-то это предотвратить именно для этого кода?

Почему продолжает расти потребление ОЗУ?

Поставь семафор на 100 одновременных соединений, тебе хватит

И так стоял на 300 соединений. Больше - ValueError. Но при 300 соединениях все значительно медленнее.

О каких потоках в asyncio ты говоришь?

Я условно, не знаю как называются правильно асинхронные выполнения (или так и называются?).

Почему продолжает расти потребление ОЗУ?

Нет, это порядка на два больше, чем должно быть

Да и вообще что означает "чем должно быть"? Я делаю столько, сколько мне нужно, а не сколько "где-то там должно быть".

Сделай процессов 10 — тебе хватит.

Не смешно-же. У меня 1к потоков и я хочу больше, а вы мне 10 предлагаете =)

Почему продолжает расти потребление ОЗУ?

longclaps, т.е. в теории soup.decompose() мог-бы помочь избавиться от утечки памяти? Сейчас перезапускать скрипт точно не буду, но в следующий раз попробую, может действительно беда в том, что не сразу из памяти удаляется объект soup. Хотя если это так в 100% случаев, то у меня сразу после запуска скрипта память закончилась-бы.

Почему продолжает расти потребление ОЗУ?

Roman Kitaev, сеть не полностью нагружается даже сейчас при 1к процессов, страницы ооооочень малого размера. На asyncio писал, ValueError: too many file descriptors in select() при ~350-400 потоках. Этого недостаточно.

Почему продолжает расти потребление ОЗУ?

longclaps, с чем это может быть связано? К слову, когда делал последний замер в 16:03 было свободно 40,3 ГБ ОЗУ, сейчас - 40,5 ГБ. Т.е. спустя чуть больше 3х часов начало попускать.

Почему продолжает расти потребление ОЗУ?

Да ладно, не много же.
Тем-не менее память куда-то уходит постоянно и мне бы понять почему.