Более 100 потоков BAS задыхается.
-
@BabloUser Бывает, что 100 потоков работают эффективней и быстрей, чем 1000. Можешь попробовать не выводить в лог. Заметил, что когда большой объем в лог идет бас подвисает
-
@Denis_krsk да заметил, запись в лог пишется же в фаил, там нагрузка на хард,
к слову, дело не в серваке, железо топое стоит, канал гигабитный, анологичные софты на тех же запросах летаю на 1000 потоках. дело именно в басе не могу заюзать скрипты в овер много потоках, и от этого становиться грустно. Проблема глобальная, нужно рапортовать, ибо серьезные люди работа с серьезным количеством потоков. Где именно срабатывает эффект узкого горлышка, не могу выявить, поэтому и запостил сюда, может кто-то как то решал такую траблу. А сказать что нужно уходить на свой код это не дело, мне нравиться BAS по этому и рапортую. 100 потоков против 1000 они кажутся как бы быстрее выполняются это да но сравнить сторонние чекеры-мекеры сделанные школьниками на делфи бас сильно проигрывает по скорости. И это не дело господа.12 лямов доменов чекаю на 200 потоках 3и сутки и плачу...
мысль всегда была как бы отключить запись в лог элементарные sucess и fail и может из за этого тупняк.
-
@BabloUser Заменяй регулярки, они кушают много ресурсов. Ещё для проверки попробуй сделать работу в 100 потоков и запустить 10 скриптов. Возможно дело в среде.
-
просто создание потока потребляет приличное количество ресурсов, если пустой скрипт ничего кроме ждания(случайное время) не даелающий в 1000 потоков еще может завершится, то 10000 потоков отедает ядро моего и5 через край и хавает 5 гигов оперативки, дальше я его прибил ибо быть беде
upd: и не случайное врем тоже(тоже 5 гигов)
-
@Fox да, если несколько экземпляров запускать то тогда таким методом добивается результат в 1000 потоков, в совокупности. Дело в среде, пробывал на вин 7, 8 10 на серваках 2003 2012r2 все тоже самое.
-
@ruzne потребление реcурсов у меня не выходит за предел 30 % по всем ресурсам цп, ram, чтение запись харда я не пробывал до 10 к потоков мне бы 1000 всего )
согласись это не дело скрипт по факту ничего не делает и в каком то месте потребляет ресурс я так и не понял где это узкое место у него на чем он валиться.
-
@BabloUser
и не стоит забывать про js, каждый поток - функция(и кст не одна), каждая функция объект, объект - структурированные данные, довольно сложные, которые нужно хранить, так что про то что он ничего не делает говорить нельзя
я думал дело в четверге
ничего не знаю, но возможно существуют ограничения на количества соединений операционной системы например или еще чего
-
@ruzne это понятно что js но суть в том что вычислительная операция не грузит процесор что дает понять что задача успевает обрабатываться, дело точно не в четверге это возможно пятница для тех кто работает на 10 потоках они начинают с пятницы и до понедельника а моя задача тут и сейчас. Если есть ограничение на сокеты тут парень включай голову и думай еще раз почему анологичный софт, те же запросы шлет и лихо поднимает 1000 + соединений без единого пука.
-
@BabloUser
да я думаю perl/lwp, ничего не помешало мне как запустить его из бас так и вернуть результат в зад, штаричок
для всякого нужно выбирать правильный инструмент, я например сегодня 5 шкантов забивал в отверстия плоскогубцами, но если бы мне нужно было бы заколотить их сотню, я бы поднялся на пару этажей выше и взял киянку.
-
@ruzne может ты лютый строитель но ты невнимателен выше для тебя написано предлагать уходить с баса на код это не суть данного поста, пока тут только два адекватных ответа от FOX и Denis_krsk от тебя лишь изошла в чистом виде хуцпа про гвозди и дни недели.
Интересно как ты прокомментируешь заявленое разработчиком на промо странице.
"Очень быстрый и оптимизированный http клиент (до 2000 потоков)
Увеличьте скорость ваших скриптов с помощью http-клиента."правильный инструмент говоришь?
-
Я делал похожий фидбек о производительности в многопотоке.
Тебе стоит последовательно рассказать какие действия выполняются в скрипте, это то с чего нужно начать разбирать проблему.
О логировании - это действительно грузит цп, я выключал вывод в лог и результаты, это немного помогло с зависаниями.Сходу могу предложить такие варианты для тестов
- поменять время работы потока (если сейчас поток отрабатывает за 10 минут то сделать так что бы он отрабатывал за 1 минуту и наоборот);
- разбить один скрипт с 1к потоков на 4 копии по 250 потоков.
-
Дело в оптимизации скрипта.
Я свободно запускаю 2к потоков на запросах, и дажн с node js в каждом потоке.
Попробуйте запускать потоки пачками, может поможет
-
@DrPrime а можешь скинуть простой любой пример на запросах который у тебя запускается и нормально отрабатывает на 2 к потоках.
-
@venom777 в самом первом комменте последовательность. У тебя не похожее у меня ресурсов с лихвой остается если на 1000 потоков выкрутить. У меня вообше нет проблем с производительностью и нехваткой ресурсов я уже тут язык пообил об этом. Трабла в том что бас ЗАВИСАЕТ на обычном GET запросе на 1000 потоках ПРИ ЭТОМ ВСЕ РЕСУРСЫ ЖЕЛЕЗА ЗАНЯТЫ МАКСИМУМ НА 30%
"разбить один скрипт с 1к потоков на 4 копии по 250 потоков"
пока решил свою проблему запуском несколько экземпляров одновременно по 200 потоков, но это не дело...
-
@BabloUser
не могу отрицать что действительно среда
это же как надо чтобы гвоздь от шканта не отличить? все же просто, гвозьди забиваются микроскопом, в крайнем случае кулькулятором.
будет ли мое предположение верным если я представлю что данные для чека берутся из от кудато(базы данных или допустим файла)
12 миллионов врятли поместтся в ресурсе значит это база данных и если она то встроенная раз необходимо использовать исключительно бас ну или чтение из файла, я пот например ранее пытался почитать басом файл на 30ГБ, бас у меня заканчивался вместе с оперативной памятью.
для простоты допустим все-таки внутренняя база данных как и у меня на 200К+ записей
и логикак опять же, допустим такая же как и у меня - из базы берется строка, чтото происходит(гет-запрос + простая регулярка или xpath), строка в базе изменяется\дописывается/перезаписывается.
я думаю то тогда бутылковое горлышка в поиске\чтении\записи в базу.
аргументы такие - имел по выше описаной схеме, причем данные обрабатывал в три этапа, трижды искал, трижды полуал и столько же перезаписывал, при том процесс бас 3-5% на процессор немного оперативки, совсем висит, процесс базы 25-30% процессора.
решил уменьшить количество действий с базой данных, ну и раз это то в три раза, логика посредине усложнилось, обращений к базе данных на еденицу времени уменьшилось.
итак: не то бы что не весит, так подвисает конечно, но загрузка всего на 100% со всех сторон, ну дак ладно там 150 браузеров. окно программы отзывчивое и вообще замечательное. подвисает как раз в тот момент когда большинство потоков переходит в такой режим что сложная логика по средине отсекается браузер не используется и происходят частые обращения к базе данных. общяя нагрузка на системе падает а окно баса вывешивается.
вопрос как оптимизировать работу с базой данных при обработке большого количества записей, я вот понимаю что если я бы брал с базы данные большими страницами а не построчно было бы пошустрее, а как добовлять и главное модифицировать записи в больщем количестве.
