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

Позвать спеца по MSSQL?

гыыы, главное ответ на вопрос прям под темой мигает ;-)

(0) Например, перейти с SATA-дисков на нормальный raid 10 из SAS. Или бюджетно - на SSD.
И памяти хотя бы 64Гб на сервер.

(3) Скажи это тем парням, которые запускали 1С на SQL в 2006 году.

они доставят ваши пакеты!)))
http://img3.joyreactor.cc/pics/post/anime-ghibli-Studio-Ghibli-kiki-558583.jpeg

(3) "перейти с SATA-дисков на нормальный raid 10 из SAS" - глупость. Ибо у нас и так сервак натуральный на злобных SASах.

(3) И память всё равно нихрена не загружена.:зЛо: При чём тут память-то? В файловом варианте на более слабой машинке лётает, а на крутом серваке колом стоит.:))

(6) Тьфу. Такую идею испортили. :)

(7) с кода надо оптимизацию начинать, в типовых быдлокода немеряно бывает

ЗАпомните...
скл-сервер не даёт ускорения работы 1с. Он даёт стабильность...

А чтобы работало быстро - надо переписывать код.

(10) + параллельность ещё даёт

Я спрашиваю про настройки, а не по железо - железо вполне свежее и дорогое. Есть ли настройки на ускорение записи??? Я боюсь, что по умолчанию эта какашка настраивается на ускорение чтения, но не записи.
(10) Если один и тот же код на SQLе тормозит в 10 раз - вряд ли это исключительно причина кода.;)

в инете столько рекомендаций настройки СКЛ... почитайте, сравните...

(12) Это явно проблема кода :-)

(12) скорость чтения-записи зависит больше от дисковых массивов, никак ни от ПО, в файловой и клиент-серверной одинаковые операции делаются разное время.
начинать надо с замеров. Документ долго проводится - включи замер производительности, смотри где тупит, потом думать дальше

(14)А может у них файлы транзакций уже гигами исчиляются...

(16) объём журналов не влияет на скорость емнип

У меня тоже похожая проблема - я несколько раз пробовал докопаться в чем дело - так ни до чего не докопался.
На форуме это не первый случай когда тормоза именно с 2008 SQL-ом: на 2005-ом летает, на 2008-м производительность в разы падает.

(0) Судя по: " Есть у нас обработка (т.н. Робот), которая по COM'у создаёт новые документы .... в файловом варианте эта штука выполняется за минуту с копейками, а в SQL'ном - по 12-15 минут!" - 100% проблема в коде.

(0) настроить обслуживание индексов, добавить отсутствующие индексы, переместить TempDB на отдельный максимально быстрый массив дисков - сделано?

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

(12) Отладчик в руки и смотреть, какие именно процедуры тормозят.
Универсальных "ускорителей" не существует.

(17) А если файл транзакций огромный и находится на одном диске с базой данных? Тоже не влияет?

(13) Читал, а толку? Везде написано про индексацию и статистику - что толку, если это уже есть? Попробовал указать точные значения для TCP-порта для IPAII, как в одном месте сказано - ноль эмоций. Я боюсь, что 1С каждый раз долго и упорно шарится по TCP-портам в поисках экземпляра SQL - может такое быть?
(19) Не понял?..
(20) Про индексы написал же. Что значит "отсутствующие" индексы? - Я что, в SQLе могу добавлять индексы не зависимо от того, какие индексы включены в конфигурации 1С???
(21) Это я в курсе, но Типовую конфигурацию настолько глубоко мне менять не позволят.
(22) Блин, да я про ускорение записи SQL'я спрашиваю!!! Если нет такой, помогающей 1С'ке, значит нет...
(23) На другом диске и я периодически сжимаю базы - ноль эмоций.

Обновление статистики, дефрагментация индексов и прочее.

(23) на одном диске и большой размер его - разные вещи. Влиет больше именно положение, а не размер

(21) Типовые обычно нормально спроектированны.

подписался на комменты, потом поржу

(23) И чего? Дописать в конец файла инфу о транзакции можно хоть прии мальеньком, хоть при большом размере. Гораздо важнее ГДЕ он лежит.

(24) Вот оно, открытие.... Да, можешь.

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

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

(27) Да, но иногда помочь серваку можно. До 30% в среднем можно помочь.

в скуле единственная настройка от конфига по умолчанию - макс дегрии оф параллелизм = 1

(34) Ну ты уж полез:)

(24) Не один раз наблюдал ситуации, когда криво написанный запрос (а тем более по ОЛЕ) на файловой базе отрабатывал на ура, а на скуле либо вообще валил одинэску, либо выполнялся очень долго.

(30) Вот, блин!!! Надо будет тестовую базу замутить тогда... А, кстати, если потом потребуется перезалить dt'шник, то эти sql'ные индексы умрут? Надо будет заново их лепить?
(34) Это плохо, что = 1 или так надо, а больше - плохо?

(31) Нормально спроектирован, просто есть кривоватые моменты, которые лечатся легко.

Я не говорю, что криво спроектированно, я говорю, что
"Много неясного в странной стране, Можно запутаться и заблудиться. Даже мурашки ползут по спине, Если представить, что может случиться. …" © Высоцкий.

Ну вот к примеру, контроль остатков по товарам организации - годный, легкий на ВТ, котроль по складам - люденящий душу писец с множеством вложенных и ситуацию спасает лишь то, что берутся оперативные остатки (без указания даты в параметрах ВТ), иначе бы все плакали бы кровавыми слезами и 1С давно бы это оптимизировало :-)

(0) Баннер SoftPoint видал? Обратись к ним - помогут.

(27) Да ну? Правда?

(40) Правда.

(37) надо 1, чтоб не было распаралеливания планов запросов

(42) А почему так? Параллелизм в данном случае оказывается плох???

(37) А ты часто дт-шник перезаливаешь на мощный сервер?? Это какой же там размер мощной базы?:)

(37) это так надо

(43) скуль больше думает, а надо ли ему параллелить запрос

чем выполняет сам запрос

А в сакле ли дело, товарищи? Может там система тупит али rphost-ов мало... Короче в (0) инфы мало и необъективно.
Сейчас окажется, что там одна единственная балалайка, называемая сервером, но не есть таковая по конфигурации аппаратной, на коей вертится всё, и терминал, и сервер 1С, и SQL... И вообще, не исключено, что там все x86

(41) Не верю (с)

(42) Крайне, крайне сложный вопрос. Иногда затраты на распараллеливание построения плана запроса превышают затраты на построение плана без параллельной обработки. В общем случае при наличии более чем 24 ядер(чистое имхо) я лучше уберу параллельное построение планов запроса.

(46) Это если статистика кривая, что лечится.

(51) при =1 он не заглядывает в статистику по этому поводу, все равно ускорение есть

(37) Бывает, что некоторые запросы грузят без толку все ядра при mdop = 0. Установка в 1 может снизить нагрузку на сервер, но скорость работы вряд ли увеличит, а может и наоборот - снизить.

(48) Тоже возможно. От автора сабжа требуется расписать версию, память, рейд, положение файлов баз данных,(в т.ч. и системных).
(53) Иногда требуется более тонкая настройка ядер, в т.ч. даже при =1.

Но если ТС в принципе в кодах 1С не копался?.. Ведь он отрицает необходимость его оптимизации, а так бы ему не пришлось доказывать, что быдлокод имеет место быть, хотя всем остальным это доказывать незачем

(45)(46) Ясно, спасибо!

(55) ну, у автора же не "как ускорить 1с", а "как ускорить мсскуль для 1с"

(54) Не о том речь, а о том, что сейчас часто жалуются на тормоза СУБД при этом абсолютно не рассматривают, что всё вертится на одной машине, а некоторые таланты еще и виртуалят этот зоопарк...

так-то, конечно, кривой код в 100500 раз больше влияет

(52) Но и замедление может иметь место.

(59) в (0)  в файловом варианте эта штука выполняется за минуту с копейками, а в SQL'ном - по 12-15 минут.

Явно не в кривизне кода дело.

(61) запросто в нём тоже, по разному скуль и файловая "субд" работает. таже В ИЕРАРХИИ в файловой норм, в скуле ппц запросик

(55) Не просто копался, а сам и писал/правил. Правда, начинал не я - до меня было. Просто МСФО в УПП вообще никакая, а нам нужны исторические курсы оплат - вот и лазается по всем авансам в поисках правильной даты оплаты и, соответственно, курса.
Но там визуально видно, где именно тормозит - везде! Даже в тех документах, что мы и не трогали, например Амортизация по МСФО - даже она тормозит даже визуально (у меня там пишется время работы каждой стадии).
(57) Вот именно!!! Спасибо за поддержку!;)

(61) дело очень даже может быть в кривизне кода.

(63) Звучит как запросы в цикле, чему удивляться то?

(63) Конфигурацию системы покажешь?

До кривизны просто руки ещё не доходили - попрофайлерю ещё, конечно. Но уже видел, что именно запись в базу набора записей регистра и тормозит.

оптимизирую конкретный тормозящий кусок кода удаленно за $$

(67) неподчиненный РС?

(66) Сказал же, УПП с доработками. Или хотите сам cf'ник?;)

(62) Ну профайлер в руки. Иногда всего-то надо проиндексировать временные таблицы в запросе, чтобы скорость резко возросла.
(67) лог-файл где лежит и модель восстановления какая?

(70) Сервера 1С и SQL. Настройки SQL.

(65) Ну, конечно, запросов там немало, но не в цикле. Сперва один запрос делает таблицу значений, а потом по мере необходимости программа в ней роется. Хотя я как-то заметил, что ТЗ в 1С вещь тоже тормозная - как-то заменил её чем-то другим, но уже не помню. :(

Я не помню точно, но вроде vde69 или кто-то еще публиковал уже скрипты для поиска узких мест Microsoft SQL...

(18) Надо смотреть что там за установки сервера.
А так, 2008 и уж R2 тем паче, намного шустрее 2005....

+(74) анализ блокировок от vde69:
http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

SoftPoint:
http://www.softpoint.ru/article_id415.htm

(72) Винды везде, ессно, 64-битные.
Сервер 1С (правда вот-вот замена будет с виртуалкой - пока глюки с разименованием компов) с 2003 Виндой, 8Гб, Xeon E5335 (4/8 ядер).
Сервер SQL-2008 Enterprise c 2008 Виндой (на виртуалке), 16Гб (выделено), Xeon E5-2650 (выделено 4 ядра).
Настройки? Какие? Их там мильон и больше...:(

(76) это анализ ожиданий, название неверное. Ожидание блокировок это другое.

(77)
https://www.google.ru/search?q=MICROSOFT+SQL+SERVER+2008+ДЛЯ+ПОДДЕРЖКИ+СИСТЕМЫ+1С8+АДМИНИСТРИРОВАНИЕ%2C+ОПТИМИЗАЦИЯ%2C+ОБЕСПЕЧЕНИЕ+БЕЗОПАСНОСТИ&aq=f&oq=MICROSOFT+SQL+SERVER+2008+ДЛЯ+ПОДДЕРЖКИ+СИСТЕМЫ+1С8+АДМИНИСТРИРОВАНИЕ%2C+ОПТИМИЗАЦИЯ%2C+ОБЕСПЕЧЕНИЕ+БЕЗОПАСНОСТИ&aqs=chrome.0.57.449&sourceid=chrome&ie=UTF-8

на виртуалке

Вот оно че, Михалыч.

(77) И всё на одной физической балалайке?

НУ КТО ТУТ СПОРИЛ?

(77) Мда. На вируталке. Понятно.

По старомистской традиции посты класса(77)  (срыв покровов) как раз появляются примерно через час эфирного времени, примерно к 77 посту :-)

(84) Ну мы растем, растем! Раньше к 90-му посту только бывало..

(79) Что-то не увидел в результатах ни АДМИНИСТРИРОВАНИЯ, ни ОПТИМИЗАЦИИ. ;)
(80)(83) И что? Это смертельно??? :УЖАС:
(81) Что - всё? Я же ясно написал, какие процы - из них видно, что 1С-сервер и SQL - это разные ЖЕЛЕЗКИ.

скуль? На виртуалке????????

там еще небось pdc вместях крутится... с эхченджем

(76) что то уважаемый вы не показываете наиболее эффективные и бесплатный инструментарий http://www.gilev.ru/online/ , али боитесь конкуренции )))
(0) начни с http://www.gilev.ru/systemperfomance/
затем ставь инструментарий

(88) Хто-хто???

(86) почта?

(90) pdc = Primary Domain Controller :))))))

(87) А хотя бы 1С-сервер на виртуалке - можно?

(86) Да нет конечно. Но про дисковую оптимизацию забудь.

(93) можно, и sql можно не слушай ты их

(86) гугли:
MICROSOFT SQL SERVER 2008 ДЛЯ ПОДДЕРЖКИ СИСТЕМЫ 1С8 АДМИНИСТРИРОВАНИЕ, ОПТИМИЗАЦИЯ, ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ

(93) все можно, вопрос в том как все это настроить на оптимальное быстродействие.

(95) Можно, но не таком железе.

(92) Что вы, что вы... Хотя надо спросить, чего там они наваяли... Вроде Лотус-сервер там сидит и ещё чего-то - для этого виртуалку и делали. Но не я - это ОНИ!:))
То есть виртуалка - это смерть SQL'ю? ТОЧНО???

(75) вот хз - щас еще раз перечитал темы - толи дело в Винде 2008, то ли в SQL 2008 - но падение производительности есть:

v8: v8: Связка Windows Server 2008R2 + SQL 2005 STD x64 + 1C Сервер х32
тут человек даже померял разные конфиги

v8: Низкая производительность Server 2008 + MS SQL 2008

v8: И снова производительность SQL сервера
тут ошибся человек в описании - у него не 2003, а 2008, он это потом написал.

v8: Возможности повышения производительности сервера баз данных MS SQL 2008
v8: Низкая производительность Server 2008 + MS SQL 2008
Возможности повышения производительности сервера баз данных MS SQL 2008

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

Бугага.
MS SQL работает напрямую с драйвером диска, минуя всякие рассово верные от своей же Microsoft WinAPI CreateFile() ReadFile() WriteFile()

А тут ему прослойку в виде виртуальной машинки подсунули, ага.

про 2012 sql много задвигали, что он заточен под виртуалкой работать...

(99) вот разница между физическим и виртуалкой http://gilev.blogspot.ru/2013/02/1.html

(99) Обсуждалось здесь. Есть разные точки зрения на скуль на виртуалке. Я придерживаюсь точки зрения, что это нехорошо. Даже подборку статей приводил - стырено со скуля ру

(98) А чем вам Xeon E5-2650 не нравится? Или не радуют 4 ядра выделенных ему? Так он - милые мои - и их-то не утилизирует.:))))) Думаете, я не смотрю на загрузку ресурсов? - Проц свободен, памяти до ж..ы, винты вот.. не знаю, но очередь запросов как бы не напрягает, сеть тоже свободна... Имхо, вывод один - SQL (или 1С-сервер, который не может снабдить оный данными) гоняет пустые циклы.

(99) Нет, но сажать с Lotus Domino/Notes я бы не стал...

(105) Ты не можешь посмотреть что делает SQL?!

(101) "MS SQL работает напрямую с драйвером диска"
Да ладно? Он что, подменяет драйвер файловой системы что ли? Всё-таки он работает с файлами.. ну разве что не через дескрипторы, а скорее всего через мемори маппинг.

(105) rphost-ов сколько? Сам rphost x64 или x86?

(107) Как? Где?

(109) Сейчас 2 оставил, а вообще и 3 включал. Разницы не заметил - оставил 2, чтоб було.
Ну раз Винда 64-битная, то какой 1с-сервер на неё поставить можно? Емнип, 32-битный просто не встанет... Или это SQL'я касалось, не помню.

(110) см (96)

(111) ???
Запросто можно воткнуть службу x86...

(105) Что мешает поставить SQL на НЕ виртуальный сервер и потестировать?

Гм. Еще не понятно как это 16 Гб. - "памяти до ж..ы"?
Что SQL совсем не использует?

(0) разместите SQL и сервер1С на одном сервере, это
минимум что можно сделать в вашем случае для ускорения.

(115) Фигасе.... Двух крокодилов на одну антилопу...

(116) Да нормально. Хватило бы памяти. Зато сеть исключишь.

(117) (Зато сеть исключишь.)
А чего её исключать? - Там гигабитка стоит. Да и по загрузке видно, что никакой загрузки на ней нет - вот если бы 1с-сервер слал данные по полбазы в секунду, тогда бы ещё стоило чесаться, имхо. Он же и сам особо не напрягается - редко когда вижу у него по 13% загрузки на поток rphost.
(114) (Что SQL совсем не использует?)
Выделено ему 12 гиг - я вообще не понимаю, зачем в защищённом режиме выделять память? Оно на то и защищённый режим, чтобы пользовательская прога ничего не знала про выделенную ей память (условно говоря ;)).

(118) надоест флудить, обращайтесь - поможем, причем
а) дешевле
б) лучше чем другие
опыт большой, контакты в моем профиле

(117) А чё её исключать, сеть не самое слабое место, ИМХО

(119) ребята из СофтПоинта хуже? :))))

(121) мы сделаем лучше )

(118) балин если тс такой умный то нафиг этот топек?
тс утверждает что производительность железа ок
хорошо, возможно дурит оптимизатор
тс утверждает что планы обслуживания настроены, ок исключаем вину оптимизатора.
остается што? код и структура метаданных.
вот такой печальный вывод из тех крох инфы что предоставил автор.

(122) Откуда такая уверенность? :)

(188) Ну тогда у тебя ничего не тормозит, смирись..

(125)->(118)

(117)(115) могу сказать, что размещение 1с и скуля на одном сервере плохо сказывается на масштабируемости. При однопоточной работе да, на одной машине лучше.

(127) Почему плохо?
Наоборот, меньше задержки при большом количестве запросов.

(128) 1с и скуль конфликтуют по ресурсам

(123) А у меня иной вывод: SQL не настроен на быструю запись и занимается не пойми чем, когда его просят записать.

(130) РС независимый?

(127) да, но не думаю что у автора система 24\7 с кучей пользователей, так что это вариант (самый простой по просьбе тс ускорить за один клик)
(130) нет такой волшебной галки в sql "ускорить запись", SQL самодостаточный продукт, ничего крутить подкручивать не требует в основном.

(0) думаю проблема в коде. Похожая история. Недавно тестили на хорошой мощной железке базу. Вцелом быстрее, но время формирования некоторых отчетов выросло в 10 раз. Комментарии в коде отчетов какбэ намекают в чем тут скорее всего дело).
Вряд ли ты найдешь в SQL волшебную кнопку СделатьХорошо, как бы тебе ни хотелось.

(125) Нельзя смириться, ибо годовой делается больше часа.
(131) Чего?...О_О

(133) "Суть проблемы в том, что некоторые злобные отчеты, которые чуть ли не часами выполнялись в файловой базе, в SQL'ной стали выполняться быстрее, но другие вещи просто безумно тормозят."
уже одна эта разнонаправленная динамика как бэ намекает тебе, что скуль тут непричем.

+(135) и дело в "других вещах"

Они ж там (в МС) вечно орут, что от версии к версии ВСЁ у них всё быстрее и быстрее... И гиде оно быстрее?

(136) Если ты не умеешь их готовить, то чего орать?!

(138) А ты его настраивал?!

Garry1010 - предупреждение. Истерию заканчиваем.

(135) Не понял...О_О Чем это она намекает? Логику не улавливаю.

(136) причем тут МС? Ты что думаешь, что учитывая текущие редакции сервера и скуля, они не научились нормально работать? Да, можно говорить о каких-то советах-припарках, которые можно найти в нете, но дело тут, имхо, в 1С.

(138) Так (132) говорит, что не надо ничего настраивать - оно, типа, самодостаточно.;)

(136) То есть намекаете, что 1С плохо транслирует со своего языка запросов в MS_SQL'ный? "Учитывая текущие редакции"...

По моему непрезентативному опыту чаще всего проблема в 1с-ном коде. Потом проблема в скуле. И только потом ограничения железа.
Убить корявым 1с-ным запросом можно любой скулевский сервер.

(144) если, он умалчивает о погрешностях, которые он почти не берет в расчет, то я почти с ним соглашусь. Но это что называется "со своей колокольни".

(145) я не пойму, у тебя что база без дописок?

(145) Так и есть, мало того, 1С только недавно "якобы" оптимизировала работу с MS SQL...

(145) я не намекаю, а предполагаю открытым текстом, что дело в том как написаны "другие вещи", о которых ты говоришь. Что это хоть за вещи? Отчеты? Или о чем речь? Или в этих "вещах" всё типовое?

(144) Зависит от объема БД... Нагрузки и т.д., короче целей...

(145) SQL пишет чуть менее чем дохера табличек при проведении документов.
Не то, что там записей много, а самих таблиц.

(130) В 99% тормозов sql-сервера виноват неверный выбор метода джойна. Обычно это nested loop join, который эффективен для мелких таблиц, но дичайше тормозит на больших.

(145) Кстати, сколько операций производится при записи в регистр сведений?

(152) ??? Чего-чего?!

(153) Для ТС это наверняка дебри, он небось ТЖ в глаза не видел...

(155) Что чего - чего? Много табличек, говорю.

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

Потом вспомни про 2-х монстров - регистров бухгалтерии.

(157) Млин, причем здесь сам движок СУБД?!

(157) Более важно не ЧТО делает sql-сервер, а КАК он это делает. Интересно было бы перехватить тормозящие запросы sql-профайлером, и запустить их с показом плана выполнения.

(160) А что мешает?

(160) см Подсистема "Инструменты разработчика" 1С 8 от tormozit-а:
http://devtool1c.ucoz.ru/

(148) Я ж сразу написал, что с дописками. И написал почему и где.
(151) Базы не шибко толстые, как я понимаю. В файловом варианте по 2-3 гига всего. Нагрузка слабая, собственно, только в период закрытия месяца МСФО гоняем по несколько раз на каждую базу, по мере исправления первички по РСБУ. Пользователей в базах максимум по 3 человека одновременно.
(161) А как выяснить, что же именно тормозит в нём?

(163) Гилёв Вам сватался, я Вам сватал СофтПоинт-овцев...
Решений много, ЦУП, например...

тема прям твоя Тормозит база 7.7 + SQL на крутом сервере

(161) Не знаю, что мешает автору это сделать. Только в общем всё это напрасный труд. В языке запросов 1с к сожалению нет возможности указать предпочтительный метод соединения.. :(

(165) Я тебя тут пиарил уже :)

(166) ???

(166) Ты с планом выполнения запросов не путаешь?

(166) Есть возможность писать запросы используя, в частности, временные таблицы, таким образом, чтобы максимально использовались индексы. Чтобы, например, не сваливалось в table scan

(169) Что именно я путаю с планом соединения?
В mssql есть хинты.. в частности можно написать вместо просто "join" - "hash join", "merge join" и т.п.. В языке запросов 1с этого нет, и 1с сама похоже их не пытается ставить, при формировании запроса sql-серверу. А именно ошибочный выбор метода связи в плане запросов и вызывает тормоза, когда запрос выполняется несколько минут и грузит почти исключительно процессор на сервере.

(167) да я про другое, я про то что там примерно на 95 посте автор принял совет который ему дали 3 дня назад :)

здесь так-же, автор влезает в споры и нифига не делает :)

(144) в вашем случае однозначно ничего не надо в SQL крутить, скорее всего проблема в коде или структуре метаданных.
Скорее всего у вас неоптимальные запросы, профайлер в руки и ссмотреть планы запросов.

(171) Да и без этих хинтов можно вполне неплохо жить, другое дело коли одинес-писари конструктором пишут и зачастую слабо понимают что написали.

(173) Да какой ему профайлер?! Хотя бы просто посмотреть, что там происходит...

(173) блин всем кто советут смотреть профайлер:

сами хоть раз в жизни ВИДЕЛИ ЗАПРОС ОСТАТКОВ В УПП С ВКЛЮЧЕНОМ РЛС ????

советчики херовы, там с одним запросом разбиратся месяц можно! Это Вам не 7.7 где все просто...

Тупо для того что-бы понять где именно находится кусок кода в 1с который в плане запросы имеет 90% времени нужно дохера опыта или дохера времени.

тфу, ругаюсь я :)

-----------------------------------

восьмерочные запросы без инструментов анализа смотреть просто глупо! (разумеется если это не одиночный селект)

(176) + а учитывая что запрос в 1с может собиратся по модулям и иметь с десяток разных схожих вариантов то вообще ппц...

(176) ну а что делать? денег на ЦУП нет, к Гилеву тоже денег надо, волшебной галки "ускорить запись" нет, вот тсу и остается только профайлер и ТЖ.

(173) (проблема в коде или структуре метаданных.)
Структура типовая - писал уже сто раз! Код... Код, конечно, придётся дорабатывать, коль он тупит на SQL'е.
...
Кстати, чтобы не создавать новую тему, кто-то имеет данные, как лучше заполнять документ СписаниеМПЗМеждународный: один документ на месяц, отдельный документ на каждый документ РСБУ или ещё как? Просто именно эта штука у нас долго работает, возможно, дольше всех прочих.

те, кто говорят про ЦУП, вы хоть его щупали?

(178) СофтПоинт же обследование бесплатно делает.

(180) У нас свои системы диагностики.

(180) Хотя и ЦУП мы счупали, и СофтПоинт смотрели :)

(0) Попробуй, для начала, поставить сервер 1С на ту же машину, что и SQL-сервер

У себя запускали тест производительности от Гилева, на сервере 1С в виртуалке, физически размещенной там же, где и SQL, показывало индекс производительности 7.64, для пробы поставили сервер 1С на машину, где SQL крутится, индекс производительности показал 24.6
P.S. SQL стоит на физической машине, потребление памяти ему - ограничили (из 144 выделили 90). Но физическую машинку, "для безопасности", в домен админы не ввели, потому доменная авторизация при сервере 1С там, не работает. Пока жуем кактус...
P.P.S. Еще, удивительным образом, помогает DBCC FREEPROCCACHE в результате - раз в 5 минут в шедулер его засунули

(184) Еще один знаток...

(185) И не говори...

(179) База в 2-3 гига - это в архиве или в развернутом файловом?

жду коммента, "..... вы ТЖ то щупали?"

Да тут скуль явно не при делах, ИМХО, там вся эта базюлька в память легко влезать должна.

так же проверьте выравнивание разделов
http://msmvps.com/blogs/gladchenko/archive/2008/10/17/1651317.aspx

(188) ТЖ... Да есть же инструментарий, коли лень

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

(170) Индексы в ВТ надо с умом использовать.

(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) на мелких однопоточных операциях очень плохо себя связка ведет, но масштабируемость неплоха вроде как.
большие куски должна быстро по идее обрабатывать.
с другой стороны запись в РС очень плохо себя показала. тут сказать ничего не могу статистики мало собрано. может еще чего и выявится.
а вообще похоже издержек/потерь много