При разноске необходимо учитывать пределы, которые ограничены SQL сервером:
Кол-во соединений не более 32тыс (далее вылетают аосы).
В классах разноски используются UserConnection, которые генерят дополнительные соединения к SQL, и не всегда они быстро закрываются (отдельная тема, планируется на обсуждение).
Также разноска использует большой ресурс цп SQL, что влияет на производительность приложения и всего остального, при "выкручивании" количества потоков. Мы указывали кол-во потоков в 100, 700, и в конце пробовали в 2000.
На своем опыте, разноска журнала который содержит более 5-10тыс строк происходит заметно дольше, чем разноска более маленьких, но много.
Есть параметр в стнд.функционале, максимальное число строк в журнале, который при разноске предварительно создает новые журналы и перемещает туда строки. Указывал по 500 строк в 1 журнал.
Номерная серия, является таблицей с писсимистич конкуренцией, и обращение к ней может происходить только 1 в один момент времени, что приводит к блокировкам (а те в свою очередь сводят многопоточность по факту в 1 поток).
К примеру, при создании доп журналов используется номерная серия (заранее указывайте макс.значение с запасом), что приводит к блокировкам.
Решением же проблемы с блокировками номерных серий(НС) будет снятие непрерывности, а также активация "предварительного" выделения номеров, что позволит сократить кол-во обращений к НС.
На текущий момент, примерная скорость разноски 50 журналов, включающих примерно 1млн строк в сумме, занимает порядка 6-10 часов.
На текущий момент возникают блокировки на запросах SQL:
Код:
INSERT INTO NUMBERSEQUENCETTS (TRANSID,RECVERSION,PARTITION,RECID) VALUES (@P1,@P2,@P3,@P4)
Также Insert в CustTrans занимает продолжительное время, что приводит к блокировкам.
Решил поделиться своим опытом, обсуждение приветствуется
