Как ускорить работу MS SQL в его взаимодействии с 1С (УПП, если что)?
Давно уже работаем с SQL'ной базой (точнее базами), но спеца по SQL нет (SQL именно MS, 2008-ой). Суть проблемы в том, что некоторые злобные отчеты, которые чуть ли не часами выполнялись в файловой базе, в SQL'ной стали выполняться быстрее, но другие вещи просто безумно тормозят. Например, документы проводятся явно дольше - полное впечатление, что нужно что-то настраивать в SQLе на ускорение записи, но вот ЧТО???
Другой очевиднейший пример. Есть у нас обработка (т.н. Робот), которая по COM'у создаёт новые документы и вызывает экспортные процедуры для их заполнения (ежемесячное закрытие по МСФО, если что). Так вот за 2 прошедших месяца, например, в файловом варианте эта штука выполняется за минуту с копейками, а в SQL'ном - по 12-15 минут! Вот такая, блин, "очередная" лажа с этим MS'ом (мать их!).
Кто-нибудь может что-нибудь ценное предложить для наладки этого уродства? (Ессно, всякие обслуживания типа дефрагментации индексов и реиндексации включены.)

(185) Если сможешь что-то дельное подсказать, я не против. Только переписывать конфу, к сожалению, а может и к счастью, нет возможности. Т.к. 1) тиражное решение, которое должно оставаться на поддержке и 2) часть запросов вынесена в длл

Проверьте регламентные операции в сиквеле:
http://programmist1s.ru/1s-ekspert-reglamentnyie-operatsii-subd/

(187) Был бы размер архива, я бы так и написал, что архива - а я написал "файловой базы".;)
Короче, дело ясное, что дело тёмное... Будем копать дальше. Thanks!

(194) И? Дело явно не в самом SQL... База такого объема, как у ТС спокойно влезет в оперативку...

(193) Для начал их надо вообще использовать:)

(198) Всё зависит от объема.

(138)  Ты разницу между внутренним и внешним сервером автоматизации понимаешь? В одном случае нет маршалинга данных в другом он есть. Так и с базами. В случае с файловой БД это внутренний сервер, а в случае с SQL это внешний. И вызовы нужно упаковать в SQL запрос отправить его на сервер по TCP/IP. Сервер получит результат и опять по TCP/IP отправит результат. И чем больше мелких запросов тем времени больше тратится именно на маршалинг данных. В файловом варианте этого нет и все происходит в одном процессе. Выигрыш от SQL ты получишь, когда большинство вычислений будет на SQL сервере.

(200) а самба - она на святом духе работает?

(197) И... дело в том, что у нас аналогичная проблема, описание и тесты производительности я описал вкратце в (183)

Именно по результатам этого теста я и порекомендовал поставить Сервер 1С на ту же тачку, что и SQL.

(202) тест производительности Гилева однопоточный. пока можно воспользоваться тестом по ссылке у меня из лички, но в скором времени он будет сильно перепилен и результаты со старыми вариантами будут плохо сравниваться. Но общее представление о масштабируемости он даст и сейчас.

(201) С самбой не работал, поэтому ничего не могу ответить.
Любое межпросессное взаимодействие это по любому зло.
Но уменьшить потери времени можно на уровне драйверов или протоколов Named Pipes vs. TCP/IP Sockets

(204) самба - это условное название протокола сети виндовс

(205) Самба - это танец такой
samba - файл-сервер под *nix
а протокол - он smb...

(205)  Это
wiki:Server_Message_Block
?
Про маршалинг я тебе уже говорил, но есть еще такая вещь как переключение контекста http://vsokovikov.narod.ru/New_MSDN_API/Process_thread/context_switch.htm

, поэтому сейчас в моде синхронизация с использованием класса Interlocked
http://msdn.microsoft.com/ru-ru/library/system.threading.interlocked.aspx

(203) Прирост в однопоточном тесте, неминуемо скажется и на многопоточном, имхо. Разница лишь в том, на сколько повлияет на результат работа в несколько потоков.

(208) не совсем так

(208) производительность ... она бывает разная ...

Решил снова поднять тему.
Вот есть у меня обработка (как раз сейчас работаю с ней), которая просто подменяет значение какого-нибудь измерения регистра на другое, когда одно из них явно дублируется с другим (по разным причинам, в т.ч. и косякам при вводе начальных остатков). То есть она просто считывает набор записей регистра, заменяет данные и записывает обратно набор. Так вот в файловой базе только на первом документе она немного думает, а потом: выбор => Выполнить, выбор => Выполнить - раз-два, раз-два. А в SQL'е задолбаешься ждать выполнения - то есть причина-таки в самом SQL'е, а вовсе не в 1С-"быдло"коде.:))

(211) Мдя... А еще саклю ругаешь...

обновление статистики SQL, переиндексацию SQL, рекомендуемую настройку параллелилизма и выделение оперативки уже делали ?

(211) И всё таки я, для интереса, попробовал бы найти другой сервер - воткнуть туда Вин2003+SQL2005 и посмотреть.

(212) Не понял? А кого же ещё ругать, если он никак не может ничего записать. И какого барабана, интересно, 1С работает с SQL'ем синхронно, а не асинхронно? Зачем ждать от него ответа? Отослали данные и забыли про них! :гы-гы:
(214)У нас вообще 2008-ой стоит - должон быть ещё быстрее, чем 205-ый. Хотя я сомневаюсь, чтобы у МСа что-то новое было быстрее старого. Предыдущий опыт как бы намекает.:((

(211) хотя бы отладчиком замер делал?

Не понимаю чего все накинулись на автора.
Известная история что операция записи объекта (справочника,документа,набора записей) в SQL версии выполняется на порядок медленее чем в файловой.
Это механизмы самой трехзвенной архитектуры все тормозят.
И никак это не ускоришь.

(216) В данном случае этого не нужно - на глаз видно. Говорю же: было раз-два, раз-два, а в скуле пальцы над клавишами замерзают, пока дождёшься.

(217) Что совершенно не понятно, в чем причины? :\ Ибо ни проц, ни сеть не загружены при этом - смотрел специально.

(218) на? какой? строке? тормозит? если? смотреть? в? замер? производительности? кстати? отладка? на? сервере? должна? быть? включена? и? отладчик? должен? быть? подключен? к? сеансу? сервера?

(219) Трехзвенная архитектура - это причина.
Сервер 1С вносит свои, довольно большие, задержки.

(219) а может, если никто и нигде не загружен, но считывание набора записей из регистра "подмерзает" - может все дело в том, что выдерживается какой-то таймаут вокруг транзакции?

Все-таки интересно посмотреть сколько времени по отладчику по коду в обработке занимает строчка с записью набора в регистра и сколько следующее чтение из регистра.

(218) Ессно, на записи набора! :)) Как делать отладку на сервере, я в курсе - только это не нужно, ибо код не в серверном модуле и это не УП, а обычное приложение.
А что, обязательно на каждом слове вопрос ставить?
(219) Ладно, тогда на кой ляд клиент ждёт ответа от 1с-сервера? Отправил запрос с данными и забыл про них!!!
Да,.. чего от них требовать, если они ни многозадачонсть, ни многопоточность в клиенте (да и в сервере, видимо, тоже) никак реализовать не могут, хотя ей уже сто лет в обед.

(223) Оберни запись набора в транзакцию и зафиксируй ее по завершению обработки - получится или нет?

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

(223) так уж прямо и нету?ну-ну

(223) @Отправил запрос с данными и забыл про них@
Ага. Записал движения. А потом решил проверить остатки получившиеся... А движения-то до сервера ещё не доехали...

(226) Если сразу-сразу, то вот тогда и придётся ждать.;) А если просто записать, то ускорение на лицо.
(225) Многодачности-то? А что, есть? [ржу]
Тогда бы она грузила не одно ядро, а более, и загрузка проца было бы не 1/колво_ядер, а более.

(224) А вот это мысль - проверю.

(227) ну допустим 1 операция не может грузить более одного ядра. это нормально. далее сервер 1С легко может загрузить все ядра в проце - вопрос в количестве клиентских соединений.
Далее какие интересно операции тебе в клиенте надо выполнять в несколько потоков? или чем не устраивает механизм фоновых заданий(есть нарекания но в целом работает на ура)
а вообще опыт работы с многопоточностью есть? портфолио есть?
мы много умных слов знаем, а вот пользоваться не всегда

(5) опять анимэ :)

(220) Как ты это сделал?

(223) а вот не "естественно". в модуле набора записей может быть код, в подписках может быть код, в РЛС могут быть шаблоны кривые. по этому и интересует, именно на Набор.Записать() 99% или там еще есть вложенные в него запрос.Выполнить() и прочие?

Скриншот с замером будет?

Кстати, на скуле реально медленнее работает что-то подобное
Переменная = Выборка.Объект.Реквизит, особенно заметно в цикле

(227) сделай Многопоточный тест производительности 1с
http://fragster.ru/perfomanceTest/
много станет ясного

(233) вот будет (возможно) в версии 2.1 там тест файловых баз. вот тогда народ поймет.

а версия 2.0 почти готова

(227) Запускай запись набора отдельным фоновым заданием, без ожидания его завершения - вот тее и асинхронность

(236) это да, главное подобрать количество и очереди разбить правильно - ускорение до десятков раз.

Но меня смущает то что "на файловой на порядок быстрее".

(0) Удалите УПП, переходите на ИТРП.

(237) Файловая всегда работала быстрее.

(239) "на порядок"? т.е. набор в файловой записывается 0.01 секунды, а в скуляке 0.1?
ну и на файловой сложные запросы никогда быстро не работали.

(240) Не на порядок, моя оценка - 2 - 3 раза.

(241) в один поток - может быть. и именно на запись. На чтение далеко не всегда.

(242) А если монопольно , то и чтение вполне.

А вообще базы и в терабайт на MS SQL нормально кувыркались и без особых проблем.

(229) (а вообще опыт работы с многопоточностью есть?)
Есть! [бе-бе] И не на каких-то там непонятных net'ах чи чо, а на самом что на есть уровне виндового API - на С. Не шибко большой, но оно работало - только для меня, правда.:\
(238) А вот это ни мне и ни вам это решать.;) И что это за Юдо? (поиском посмотрел уже - не напоминайте)
(232) Конфа типовая - в модуле набора дописок нет.
(236) Так его же записать надо сейчас, а не по расписанию...

(224) Транзакции в 8-ке на скорость записи не влияют.
Этот совет из времен 7-ки.

(245) фоновые задания работают не по расписанию, только тсссс!

(247) Да я как-то не пользовался ими никогда, не вникал.
...
Кстати, а у нас SQL весь из себя Энтерпрайзный, а ни разу не видел, чтобы он использовал более 1 ядра (загрузка ЦП не более 25%). Хммм.О_О

(248) хочешь на это посмотреть? запусти (233)

(246) А в текстах модулей наборов записей по этим регистрам ничего не висит? или где-то еще?

(248) И потом говоришь про отсутствие в 1с асинхронности. Угу...

Я так понимаю автор аккуратно мерять ничего не жаелает:) Тогда вряд ли можно будет помочь, ибо общего диагноза не бывает. Ну а порассуждать это конечно мы всегда за.

(211) Угу я в свое время боролся с регистрами сведений, когда мне нужно загружать миллионные прайсы. Разница между конструкцией Merge и записью регистров сведений вЕЕЕЕсьма ощутима. Попробуй записать напрямую, и ты удивишься.

(211) И как это делать?
(224) Не-а, ноль эмоций.

(252) Чего именно? Обработку, с которой начал подъём темы? Увы, уже всё сделано, а второй sql'ной нет, а ваять не буду.

(252) +100500

(251) Одно с другим никак не связано.;)

А может быть все до банального просто. Например батарейка контроллера отсутсвует.(или кешировние на запись выключенно) Да мало ли чего может быть.

А вообще скорость в слабоструктурированный файл всегда будет выше чем в СУБД. Потому как там выше издержки. Например на поддержание транзакционной целостности. Впрочем тема какая то сумбурная.

+(259) Скорость записи имеласть ввиду:)

(0) Ну если не слезать с вируталки - можно много чего предъявить к SQL-серверу.

(0) Переведу на низколетающие клюшки. Дорого.

Эх, блин, вон оно чО - http://forum.ixbt.com/topic.cgi?id=7:42617 пост 13 (не знаю как тут оформлять ссылки:().
Короче, получается, что больше всего ASYNC_NETWORK_IO, то есть "Проверьте, что клиент обрабатывает данные от сервера"ОО_ОО. То есть надо настраивать 1с-сервер??? Что-то впервые слышу об этом...
Можно ему указать точный порт SQL'я? То есть настроить и первого, и второго на один порт, чтобы они не шарились в попытках найти друг друга?

(263) между серверами 10мбит?

(264) Ясно, что нет.;) Только вот SQL-то ругается на это!

Там ещё и WRITELOG есть, но он много меньше именно нетворка...

а сколько % на сеть?

Writelog - если ты не знаешь, зачем у базы модель восстановления full - поменяй на simble

(268) 32,6% в графе percent_total_signal_waits.

можно попробовать соединить сервера напрямую, а не через свич

(269) - в смысле, что ответ на (267).
(268) У всех баз и так Простая модель восстановления.
(270) Это вряд ли! :гы-гы: У нас такой мелочи не стоит. У нас там Циски всякие злобные.

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

(272) Так я его не смогу сделать - я не сисадмин в серверной.

(248) А нет... Наврал. Сейчас увидел и 29, и 33, и 36, и даже 39% загрузки скуля. Значит, жужжит, родимый!

(274) запусти (233), увидишь 100% (наверное :))

(275) а столько времени должен выполняться тест ? описалово есть ?

(276) около 30 минут

(263) Это сообщение? http://forum.ixbt.com/topic.cgi?id=7:42617#13
Правой кнопкой на (написано)

(275) Запустил. Вроде как нормально - даже лучше, чем на картинке отчета на инфостарте. От 500 на 1 потоке до 2500-4000 на 32 потоках и до 2500-5500 на 112. Хотя в сравнении с другими на http://fragster.ru/perfomanceTest/ как-то хиловато.:((
Кстати, проц до 100% так и не дошёл. Причём SQL вообще больше напрягался при меньшем кол-ве потоков (~8-32), чем при большем. Типовая загрузка сети никакая - 1-2% с редкими скачками до ~10% (на гигабитке), причём с ростом потоков нагрузка наоборот падала :гы-гы: до 0,4-0,6%. А вот 1с-сервер умудрялся нагружать 8 потоков на 100%, но, увы, ненадолго.

(279) Не надолго это из-за того что тест идет кусками по 10 секунд
Это твой там тест датой 2013-03-14 11:54:37 ?

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

(279) на ИС картинка от коре2 дуо с выключенным ХТ :)

в версии 2.0 нагрузка на скуль будет сильно больше, а на 1с - меньше

(280) Угу. А что там за кол-во пользователей в настройках? Я поставил 8.
(281) С кем выключенным?
(282) В версии 2.0 - этого теста? А как там можно регулировать такие вещи? О_О

хипер треадингом

регулировать - кодом. который дает больше нагрузки на скуль и меньше на рпхост

количество пользователей - это типа для статистики - сколько реальных польлзователей работает на этой связке и какая их субъективная оценка производительности этой самой связки

(284) Это по-каковски? :)) По-русски его обычно называют Гипер-трейдингом, а через "Х" - это глупые мерикосы пишут. У них и Гарри почему-то Харри. О_О
(286) Аааа, то есть я должен был самого себя написать...
(285) То есть крутить-вертеть, пока не получится то, что хочется? Ясно.

http://s16.radikal.ru/i190/1303/a0/0644ff02de58.png

(287).1 не Геракх, а Херакл, не богиня Гера...
.2 если на том сервере боевых баз нет - ничего не пиши
.3 нет, в 2.0 переработаны тесты таким образом, что они больше нагружают скуль, чем сервер 1с

(289) богиня чего, пrостите?

(289).3 Я это и имел в виду. Не я, конечно, буду крутить-вертеть, а автор.
.1 Всё-таки Геракл лучше звучит, чем Херакл.;) Особенно учитывая неблагозвучность первых трёх букв.:)

(280) Так не подскажете, как вам мои результаты? Это нормально или всё-таки плоховато? Кстати, тест шёл не 15 и не 30 минут, а минут 40-45.

(292) на мелких однопоточных операциях очень плохо себя связка ведет, но масштабируемость неплоха вроде как.
большие куски должна быстро по идее обрабатывать.
с другой стороны запись в РС очень плохо себя показала. тут сказать ничего не могу статистики мало собрано. может еще чего и выявится.
а вообще похоже издержек/потерь много