Подскажите решение.

[ZVH]

Такая вот каша получается с брутом.
на c# при использовании TDS протокола и TCPclient не едем больше чем 500-800 потоков, далее чем больше потоков тем медленнее работаем)
на c++ при использовании драйвера SQL Server и SQLDriverConnect через пару минут перестаёт подключаться к любым таргетам используя данный драйвер, помогает только перезагрузка
дополню ссылкой на описание проблемы.

Does SQLDriverConnect (from unix-odbc) cache the DSN data? If so, how can I clear/purge it?

While using the UNIX-ODBC libraries from unixodbc site, I'm facing a problem with the SQLDriverConnect api. If I try to connect to my database twice in a row, first with incorrect DSN data (Data So...

unix.stackexchange.com

 

[DildoFagins]

Такая вот каша получается с брутом.
на c# при использовании TDS протокола и TCPclient не едем больше чем 500-800 потоков, далее чем больше потоков тем медленнее работаем)

Async используешь, или синхронное подключение и плодишь потоки операционной системы? Если второе, то лучше попробовать использовать асинхронные подключения и количество потоков равное количеству ядер процессора.

 

[ZVH]

Async используешь, или синхронное подключение и плодишь потоки операционной системы? Если второе, то лучше попробовать использовать асинхронные подключения и количество потоков равное количеству ядер процессора.

второе, асинхрон сложнее контролировать

 

[ZVH]

Async используешь, или синхронное подключение и плодишь потоки операционной системы? Если второе, то лучше попробовать использовать асинхронные подключения и количество потоков равное количеству ядер процессора.

используем потоки ОС, асинхрон в нашем случае сложнее контролировать, да и потоки ожидания у нас, так что нагрузки на проц минимальные даже при 10к потоках, на каждый поток по 3 дескриптора(потока, среды и соединения)

 

[ZVH]

Async используешь, или синхронное подключение и плодишь потоки операционной системы? Если второе, то лучше попробовать использовать асинхронные подключения и количество потоков равное количеству ядер процессора.

проблема скорее всего в том что где то что то кешируется самим драйвером, и в первом случае у нас просадка по скорости из за этого, во втором драйвер не едет по таргетам спустя определённое время
а где и что кешируется вообще хз, мы перелопатили это уже вдоль и поперёк)

 

[DildoFagins]

проблема скорее всего в том что где то что то кешируется самим драйвером, и в первом случае у нас просадка по скорости из за этого, во втором драйвер не едет по таргетам спустя определённое время

Ну я не могу так сванговать, в чем проблема. Но надо иметь ввиду, что вообще говоря, операционные системы не предполагают, что приложения могут создавать кучу потоков. Оверхед от создания потока довольно большой, поэтому во всех адекватных системах для каждого коннекта поток не создается (тот же Erlang, который может миллионы соединений отрабатывать на одном инстансе, использует асинхрон под капотом). Я как-то читал про тесты, и для 32-битных процессов на венде максимальное число потоков, до того как процесс выжрал всю память, было в районе 2000. В Линуксах можно установить лимит на количество потоков, по-умолчанию там стоит что-то типа 65 тысяч. Да и потом, когда количество потоков слишком большое, оверхед от переключения контекстов между ними становится ощутимым. Возможно, ты сталкиваешься именно с такой ситуацией.

 

[ZVH]

Ну я не могу так сванговать, в чем проблема. Но надо иметь ввиду, что вообще говоря, операционные системы не предполагают, что приложения могут создавать кучу потоков. Оверхед от создания потока довольно большой, поэтому во всех адекватных системах для каждого коннекта поток не создается (тот же Erlang, который может миллионы соединений отрабатывать на одном инстансе, использует асинхрон под капотом). Я как-то читал про тесты, и для 32-битных процессов на венде максимальное число потоков, до того как процесс выжрал всю память, было в районе 2000. В Линуксах можно установить лимит на количество потоков, по-умолчанию там стоит что-то типа 65 тысяч. Да и потом, когда количество потоков слишком большое, оверхед от переключения контекстов между ними становится ощутимым. Возможно, ты сталкиваешься именно с такой ситуацией.

у нас не создаётся поток под каждое подключение, у нас создаётся допустим 5000 потоков которые едут по общей очереди и складывают результат в общий лист, через профайлер тестили данные решения на предмет бутылочных горлышек, проблем нет, видим только что драйвер чем дальше тем дольше отвечает, тормозит именно неуспех, сначала по 2-3 секунды на ответ потом до 80-100 доходит спустя пару сотен тысяч таргетов

 

[Stallman]

видим только что драйвер чем дальше тем дольше отвечает, тормозит именно неуспех, сначала по 2-3 секунды на ответ потом до 80-100 доходит

Ну вы сами нашли проблему, чем еще кто поможет то? Либо написать эту часть кода тоже самим, и отказаться от SQL Server и SQLDriverConnect, что может быть лучшим решением, так как вам надо только пару функций оттуда,
либо научиться перезапускать эти драйвера, не перегружая всю систему, и перезапускать по росту таймаута до какого-то значения, но это хуже решение. Но проще.

 

[ZVH]

Ну вы сами нашли проблему, чем еще кто поможет то? Либо написать эту часть кода тоже самим, и отказаться от SQL Server и SQLDriverConnect, что может быть лучшим решением, так как вам надо только пару функций оттуда,
либо научиться перезапускать эти драйвера, не перегружая всю систему, и перезапускать по росту таймаута до какого-то значения, но это хуже решение. Но проще.

второе решие это прям жесткий костыль) первое решение сложно но реально) мы примерно этим и занимались всё время в шарпе) думаем дальше)

но данное решение едет медленно в шарпе)

 

[ZVH]

Послушаю ещё мнений, вопрос всё так же открыт. Возможна есть какая то альтернатива в целом к общему подходу реализации.