Есть код:



Суть проблемы такова, что потоки не умирают должным образом и остаются в памяти, с учетом того, что в среднем каждый поток весит примерно 10 метров, то на 300-350 итерации цикла на сервере не остается оперативки, а 400 итераций - это даже не 1% файла. 

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

OS - ASPLinux 10

StealtH, с многопоточностью работаю через fork, но думаю что в этом моенте разницы не будет. Для того чтобы убивать зомби использую

Работать с тредами нужно очень аккуратно. Так как они капризные и могут возникать разные "эффекты" с памятью 
сделай хотяб так...


вот так !
потом зачем передавать $words[$j] ведь на то они и треды чтобы находится в одной области памяти к родителю сделай так чтобы, элемены массива выбирались  прям в сабе, хотя конечно мож я забыл что ты спрашивал. 

Это сообщение отредактировал(а) fray - 5.9.2007, 13:14

Bulat, помогло, но не совсем, памяти стали потоки съедать меньше, но все же остается момент когда они ее поедают, постепенно объем занимаемой памяти растет :(


fray, насчет юзать переменные прямо в сабе - хорошая мысль, попробовал, мне понравилось   

Все зависит от того чем ты занимаешься в дочерних процессах. Лично у меня дочерние процессы съедали не более 11,5 Mb. Но у меня шла работа с большими скалярами, объемом до нескольких сотен килобайт, может даже 1 мегабайт. Так вот при выполнении определенных операций, перл использует дополнительную память, которую впсоледствии не высвобождает. Пришлось переделать некоторые места кода, теперь несколько дочерних процессов съедают от 7,5 до 10,5 мегабайт. Немного для одного, но в целом не плохо.

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

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

У меня подобное было, но после оптимизации кода, я снизил до 9-10, немного конечно, но пара мегобайт умноженные хотя бы на 10 дочерних процессов уже ~20. 


я не стал отказыватся, видел как работают и на простых сокетах и с ЛВП, как-то не показалось, что настолько уж лучше 


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

POE спасет мир 
Это если работаете с сетевой многозадачностью.

Добавлено через 7 минут и 37 секунд
Тут можно посмотреть пример хорошего такого паучка. Код конечно приведен для примера. Оптимизированный такой скрипт на самописных "боевых" компонентах способен выжимать 100 - 1К запросов в секунду ;)