Увеличивается время выполнения шаблона в многопотоке

[yriy158]

Здравствуйте!

Ставлю на выполнение шаблон в 30 потоков на 90 выполнений. Выполение занимает 10 минут.
Ставлю тот же шаблон в 90 потоков на 270 выполнений. По логике время выполнения не должно было бы изменится (10 мин), но по факту выполнение занимает 20 минут.
Количество потоков в 1 процессе - 1.
Почему так? По нагрузке ЦП и оперативки - резерв есть, ЦП грузит максиму до 80%, оперативку до 70%, при том такие показатели что при 30 что при 90 потоках.
Почему время на выполнение увеличивается?
Шаб простой сравнительно, 2 гет запроса + регулярка и работа со списком.

 

[orka13]

Увы, сталкивался с подобным, и иногда выше потолка не прыгнуть, даже если ресурсов вроде как дофига.
Может списки привязаны к файлам на HDD? Если да, то пробуйте перенести их в виртуальный RAM-диск. Смотрите в подробных логах на каком кубике времени много жрет, и его усовершенствуйте.

 

[yriy158]

Увы, сталкивался с подобным, и иногда выше потолка не прыгнуть, даже если ресурсов вроде как дофига.
Может списки привязаны к файлам на HDD? Если да, то пробуйте перенести их в виртуальный RAM-диск. Смотрите в подробных логах на каком кубике времени много жрет, и его усовершенствуйте.

Попробую перенести на РАМ-диск, спасибо.
А в каком именно файле логов такая инфа есть(nonCriticalErrors.txt, executionLog.txt или в fileManagerLog.txt??

 

[Koqpe]

По логике время выполнения не должно было бы изменится (10 мин), но по факту выполнение занимает 20 минут.

Как думаете, в каком случае Вы быстрее купите булку хлеба, очередь из 30 человек или очередь из 90 человек.
Список у Вас один, залочен, потоки выстраиваются в очередь плюс как правильно заметили:

Может списки привязаны к файлам на HDD?

 

[orka13]

Попробую перенести на РАМ-диск, спасибо.
А в каком именно файле логов такая инфа есть(nonCriticalErrors.txt, executionLog.txt или в fileManagerLog.txt??

Включи "Трассировка проектов". И там в логе смотри какой будет ID жрет много милисекунд.

 

[one]

Потоки в ZP выполняются последовательно. Отсюда видимо и увеличение общего кол-во выполнений.

 

[yriy158]

Как думаете, в каком случае Вы быстрее купите булку хлеба, очередь из 30 человек или очередь из 90 человек.
Список у Вас один, залочен, потоки выстраиваются в очередь плюс как правильно заметили:

Потоки в ZP выполняются последовательно. Отсюда видимо и увеличение общего кол-во выполнений.

А почему должна быть очередь, если по иди все потоки должны работать одновременно при настройках 1 поток в 1 процессе?))

Если есть очередь при таких настройках, тогда ведь частично теряется суть многопотока. Как тогда определить какое максимальное количество потоков может одновременно работать? Я думал, что максимальное количесвто потоком ограничено железом, и подбирать его нужно исходя из нагрузки на ЦП и РАМ.

Да, список привязан к файлу на SSD, это может и тормозит проект, согласен. А как можно обойти это, что бы минимизировать потери времени на работу с таким списком?
Со стать об оптимизации LightWood'а, я понял что привязка списка к файлу на винчестере все же лучше, чем без привязки.

Старайтесь как можно реже использовать списки и таблицы в режиме "без синхронизации с файлом". Если используете, то лучше используйте список, ибо он легче таблицы для обработки системой.

 

[yriy158]

Сделал трассировку проектов. Действительно, много времени идет на "Получить строку" и "Записать строку", больше 5 секунд на каждое такое действие.
Может как-то можно ускорить эти процессы?
Суть шаба: "Получить строку" с ссылкой на страницу с .txt - парсим инфу - "Записываем строку" в .txt. Все потоки работают с одними и теми же .txt файлами.

 

[ByMagnum]

С данными случаями встречаюсь у себя, с базами данных, жесткий диск не успевает перезаписывать информацию, если это HDD, если SSD - побыстрее в разы будет информация перезаписываться.
Попробуйте физически файлы раскидать по жестким дискам, физическим, если как таковые имеются.
А если же диск физически распилен на тома, то суть таже самая будет, тут можно даже и не пытаться раскидывать материалы.

Для понятия: Вы всем так сказать "скопом" потоков, одним моментом обращаетесь к жесткому диску, на что соответственно диск просто не успевает перезаписывать, читать информацию. Играет роль также обьем этих самых файлов, т.к. для процедуры перезаписи файла требуется открыть файл, прочитать и вставить (апнуть) информацию. Т.е. чем больше обьем, тем больше времени требуется для открытия, чтения, записи файла. Отсюда у Вас и время в разы увеличивается.
Это для понятия проблемы, чтобы ее решить*

 

[Koqpe]

Не зная всех деталей трудно подсказать, можете попробовать так: сделайте три копии Вашего шаблона и запускайте каждый в 30 потоков на 90 выполнений, конечно если позволяет логика работы с входным списком.

 

[Gfoblin]

Суть шаба: "Получить строку" с ссылкой на страницу с .txt - парсим инфу - "Записываем строку" в .txt. Все потоки работают с одними и теми же .txt файлами.

Рамдиск

 

[arhip1985]

выделенный процесс - галка

 

[orka13]

ну может файл списка больше 10 мб ? заметил что зенка без задержки только с размером до 5...10 мегабайт норм работает. Экспериментируйте.

 

[one]

Я бы на БД перешел.

 

[ByMagnum]

Я бы на БД перешел.

поддерживаю, вероятнее всего уменьшилось бы время обращения и вообще в целом уменьшится время выполнения.

 

[yriy158]

Рамдиск особо не помог, только слегка.
Файл не болше 1-3 МБ.
Копии шаблонов и отдельный запуск, скорее всего, помог бы, но немного геморно, ибо нужно буде изначально делить общую базу на части. Хотя как вариант - неплохой.
С БД никогда не работал, буду вникать и пробовать, раз это быстрее.
На данный момент нашел немного другой обход:
Выделаю диапазон (первые 20 строк) в подсписок с файла на моем ПК - иуже работаю с этими 20 строками вовнутренном списке, а когда строки в подсписке заканчиваются, то опять беру диапазон со списка и ложу в подсписок.
Получается что количество запросов к файлу на моем жестком уменьшается в 20 раз. Такой вот штукой удалось сократить выполнение одного потока с 53 секунд до 40 секунд. По данных трассирования потоков. время на выполнение работы с файлом сократилось в 5+ раз.

 

[ByMagnum]

Я бы Вам посоветовал работать файл (брать инфо парсинга, работы) - zenno (сама работа) - база данных (инсертить)

В этом случае Вы достигнете высокой скорости работы zennoposter.

Результаты, как пример, можете свободно забрать в phpmyadmin - экспорт - exel = профит.

 

[Gfoblin]

Рамдиск особо не помог, только слегка.

на рамдиск выкинул?

Перезапустить не забудьте

 

[yriy158]

на рамдиск выкинул?

Перезапустить не забудьте

Типо указать вместо диска Z свой рамдиск? Нет, такого я не сделал) Просто перенес шаб и файлы, откуда берутся/записывается инфа на рамдиск и всё.

Я бы Вам посоветовал работать файл (брать инфо парсинга, работы) - zenno (сама работа) - база данных (инсертить)

В этом случае Вы достигнете высокой скорости работы zennoposter.

Результаты, как пример, можете свободно забрать в phpmyadmin - экспорт - exel = профит.

Буду вникать, спасибо. Но пока знаний в области БД ровно ноль))

 

[Gfoblin]

Типо указать вместо диска Z свой рамдиск?

да т.к. потоки тоже еще кучу хлама пишут
и TEMP туда же перенесите

 

[yriy158]

выделенный процесс - галка

А это где такая настройка есть?
Если вы об этом

То у меня вообще стоит галка "Не использовать браузер" ибо всё на пост/гет запросах.