gifts2017

Еще раз, по-новому: производительность 1С: 7.7/1С: 8 + SQL

Опубликовал Konstantin Korolyoff (kos) в раздел Администрирование - Оптимизация БД (HighLoad)

Еще один подход к увеличению производительности 1C+SQL = использование RAM-дисков

 

По оптимизации 1С+SQL = в инете много информации.

В большинстве случаев (1с77/1с8х) всё рекомендации, методики и алгоритмы сводятся к двум вещам:
- оптимизация индексов и статистики
- управление блокировками

При этом предполагается "вмешательство" в стандартные структуры и процедуры БД от 1С.....


Вот к чему я пришел:

У всех этих методов есть существенный недостаток:
- если вмешиваться в штатные механизмы от 1С: тогда сложно поддерживать восстановление своих "хотелок" после реструктуризации БД - ...


Предлагаю собственно иной взгляд и подход: посмотрим на родные средства сервера SQL+Win и попробуем оптимизировать скорость только "там", не изменяя "коробочные" технологии от 1С.

* В БОЛЬШИНСТВЕ СЛУЧАЕВ СТАНДАРТНЫЕ МЕХАНИЗМЫ 1С "ИЗ КОРОБКИ" ОПТИМАЛЬНЫ (в 90%)
* НЕ ОПТИМАЛЬНЫ (как правило) НАШИ ДОПОЛНИТЕЛЬНЫЕ "навески" НА ТИПОВЫЕ РЕШЕНИЯ
-  либо потому что мы чего-то не знаем
-  либо потому что этот "узкоспециализированный костыль" по другому не работает
В результате мы начинаем оптимизировать "всё" и "вся" , жадно вычитывая решения из интернет......

Я же предлагаю (исходя из соображения стоимости сопровождения) по-иному взглянуть на проблему:
1) свои ошибки (внутри 1С) исправлять (однозначно)
2) бросить затею "оптимизировать 1С" - вместо этого посмотрим на САМ сервер WIN+SQL



В моем  случае (на одной площадке, сервере) имеем 8шт 1С7.7 баз + 3 штуки 1С8, одна из которых УПП
Все разного размера и интенсивности.

Как угодить всем?


железо (минимум, для моего объема)

* 2xCPU, 48Gb RAM, RAID-10 SAS 8x300Gb
* сеть: 1Гбит
* сервер = виртуализация (proxmox), на котором
 - MS Терминал (4-8 ядер, RAM из расчета 128-512Мб на юзверя)
 - MS SQL 2008r2 (16 ядер, 24Гб RAM)
 - остальные VM: в этом топике - не важно

По настройкам SQL+Win:

1) настроки Win для SQL читаем здесь: www.sql.ru/blogs/gladchenko/332

2) настройки собственно самого SQL (у меня такие - методом проб и экспериментов, для этого железа):

 

exec sp_configure 'show advanced options',1  
exec sp_configure 'backup compression default',1  
exec sp_configure 'default trace enabled',0 отключаем, не нужно
exec sp_configure 'priority boost',1 у нас на этой VM-машинке MS Win ничего кроме MS SQL нет
exec sp_configure 'lightweight pooling',0 это для старых серверов, нам не нужно
exec sp_configure 'cost threshold for parallelism',1

если запрос долше 1сек

- параллелим его

exec sp_configure 'max degree of parallelism',64

заставляем SQL принудительно использовать

все ядра, что имеются

exec sp_configure 'max worker threads',8192

заставляем принудительно,

по умолчанию (когда = 0) использует 512

exec sp_configure 'locks',50000

количество блокировок вплоть до этого значения

не будем считать проблемой

exec sp_configure 'network packet size (B)',8192

у нас сеть 1Гбит, интенсивность работы высокая,

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

exec sp_configure 'max server memory (MB)',22528 22 = 24Гб - 2Гб под ОС
exec sp_configure 'min server memory (MB)',0  
exec sp_configure 'min memory per query (KB)',1024

оставляем стандартно, но

не забываем про количество пакетов
( у меня макс доходит до 5000 batch/sec )

смотрите чтобы не сьели всю память

(1024*5000 = 5Гб !!!)

exec sp_configure 'query wait (s)',2147483647 запросы ждут выполнения "до бесконечности"
exec sp_configure 'recovery interval (min)',60

чекпоинты БД делаем не чаще 1раз/час (для скорости),

хотя это условность (см.MSDN)

exec sp_configure 'remote access',1 естественно
exec sp_configure 'remote query timeout (s)',600 как бы понятно
reconfigure with override  

 

 

3) выносим tempdb - на RAM-диск в 2Гб (я пользуюсь imDisk Toolkit-ом, ни разу не подводил, GPL)
4) для всех баз устанавливаем такие параметры (много раз писалось, приведу еще раз для общей картины):

 

recovery model

simple

обсуждалось много раз

autocreate stat off  
autoupdate stat off  
асинхронное обновление статистики on на всякий случай
page verify torn page detection

или вообще NONE: надежность вряд ли пострадает, скорость выше

files  

* если более 1 (физического) массива дисков - разностим MDF/LDF (иначе не обращаем внимания)

* путь к файлам MDF/LDF - должен быть без длинных путей (т.е. переностим все MDF/LDF файлы в корень диска/ков)

* но не на диске С:\ (естественно)

* помним про autogrow и прочее...(думаем)

регламенты  

еже-ночные:

1) _1sp_dbreindex

2) full backup



5) В СЛУЧАЕ МОНОПОЛЬНОГО ПЕРЕПОВЕДЕНИЯ БАЗЫ (1С77) :
делаем "финт ушами":
- средставим тогоже imDisk создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)
- переносим туда БД (backup/restore в новое место)
- выставляем: autocreate stat / autoupdate stat = ON
- запускаем _1sp_DbReindex + sp_updatestats
- проводим базу
- выставляем: autocreate stat / autoupdate stat = OFF
- опять backup и restore на диск, на старое место...

6) если RAM совсем много: переносим "туда" нашу БД "на всегда" :
при этом:
- каждые 10 минут FULL BACKUP
- при старте SQL - агентом вызываем скрипт для restore
- при стопе SQL - агентом вызываем скрипт для full backup


Все остальные способы (индексы и прочее)

- именно в случае вмешательсва в стандартные структуры и процедуры от 1С-ки
- дают выигрыш в производительности максимум 10-15%
- при этом затрат на обслуживание (времени) уходит просто уйма.

А с учетом того что память и диски сегодня стоят ....
Проще наростить мощность сервера и вынести (когда нужно) базу в память...

Я пошел экстенсивным путем.

Всё это -  к обсуждению Laughing

Критика приветсвуется.

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. Алексей Роза (DoctorRoza) 16.02.15 08:19
В большинстве случаев (1с77/1с8х) всё рекомендации, методики и алгоритмы сводятся к двум вещам:
- оптимизация индексов и статистики
- управление блокировками


Основная и единственная рекомендация - это грамотные, оптимальные запросы! Оптимизация индексов, это что, добавить новые, реструктуризировать старые? Блокировки - сейчас все на управляемых блокировках, автоматических режим - это редкость. А в целом, все проблемы от самих же программистов, а точнее, их безграмотности. (ИМХО)
alul; нормальный такой; ojiojiowka; +3 Ответить 2
2. Сергей Михайлов (sv_mikh) 16.02.15 08:34
Спасибо, очень помогло: exec sp_configure 'max degree of parallelism',64. (заставляем SQL принудительно использовать все ядра, что имеются). Была проблема недозагруженности процессоров. Респект!
3. Сергей Михайлов (sv_mikh) 16.02.15 08:36
(1) DoctorRoza, не все проблемы от программистов. Если сам скуль настроен криво, то никакие хорошие запросы не помогут. Если работает типовое решение, то вероятность его положить плохими запросами есть, но она не так сильно может испортить жизнь, как кривой скуль.
4. Дмитрий Тарасов (tarassov) 16.02.15 08:58
По моему опыту, для существенного ускорения 1Сv7.7, особенно в случаях массового перепроведения документов, не обязательно на RAM-диск отсылать всю базу. Достаточно туда перепрописать temp-каталоги!
5. Василий Коровин (vasyak319) 16.02.15 11:15
"путь к файлам MDF/LDF - должен быть без длинных путей"

А зачем? Путь используется один раз - при открытии файла. Дальше все обращения через дескриптор. Физическое место записи файла тоже от пути не зависит.
6. Василий Коровин (vasyak319) 16.02.15 11:17
Кстати, не стоит переоценивать мастерство типовых программистов. Я тут пару дней назад хотел даже статью написать, как ускорил УПП на 40%, слегка изменив типовой код, да что-то глюкануло и она не сохранилась, зараза такая.
7. Александр Сандуев (korsar2001) 16.02.15 13:40
Перевод на "Прямые запросы" очень сильно помогает при больших размерах баз
8. Юрий Гончарук (yukon) 16.02.15 15:02
exec sp_configure 'max degree of parallelism',64

Нехило, учитывая, что согласно http://support.microsoft.com/kb/2806535 рекомендуемое значение равно 8, и не должно превышать 16.
For servers that use more than eight processors, use the following configuration:
MAXDOP=8
For servers that have hyperthreading enabled, the MAXDOP value should not exceed the number of physical processors.


autocreate stat off
autoupdate stat off
page verify torn page detection

Учитывая, что указанные опции строго рекомендуется ВКЛЮЧИТЬ, а PAGE_VERIFY даже после сброса сервером в NONE после апгрейда базы рекомендуют выставить в CHECKSUM, то данные рекомендации похожи на способ поиметь проблем на ровном месте.

Безусловно, если вы специалист, то вы с данными проблемами справитесь, а вот те кто повторит за вами вряд ли поймет, что именно у него происходит.

UPD. А да, для базы sharepoint и biztalk серверов указанные опции по дефолту выключены и включать их не нужно. Сомневаюсь, что характер работы 1С с SQL сервером похож на работу указанных приложений.
нормальный такой; +1 Ответить 2
9. Василий Коровин (vasyak319) 16.02.15 15:08
(8) Автор, видимо, предполагает ручное обновление статистики, что для больших баз не просто лучший выход, а единственный, так как триггериться автообновление статистики будет реже (меньше процент изменений) и в итоге планы запросов будут строиться по статистике данных давно забытых периодов.
10. Вячеслав Гилёв (Gilev.Vyacheslav) 16.02.15 15:46
(0) мы на курсах http://www.gilev.ru/kurs/ рассказываем прежде всего о том, что нет единого универсального рецепта для всех
создаваемое замедление состоит из набора разного количества причин и степени вклада в общее замедление
можно конечно делать "с бубном", но анализ причин на перспективу даст больше пользы

и железо, и настройки среды, и код - все должно быть сбалансировано

для маленьких баз можно больше результата достичь улучшением железа
для больших баз больше кодом...
zinal; cleaner_it; nnn123; нормальный такой; +4 Ответить 1
11. Юрий Гончарук (yukon) 16.02.15 15:56
(9) vasyak319,

Для больших баз все решается индивидуально. Вот только базы с параметрами "создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)" вряд ли можно отнести к большим базам, хотя бы 100-200Gb надо для начала.

Для tempdb есть еще такой ход конем "As a general guideline, create one data file for each CPU on the server" https://msdn.microsoft.com/en-us/library/ms175527%28v=SQL.105%29.aspx

Что касается
exec sp_configure 'recovery interval (min)',60
чекпоинты БД делаем не чаще 1раз/час (для скорости), хотя это условность (см.MSDN)

То MDSN https://msdn.microsoft.com/ru-ru/library/ms191154.aspx прямо говорит, что "Этот параметр является дополнительным и его следует изменять только опытным администраторам баз данных или сертифицированным техническим специалистам SQL Server."
12. Канат Джумадылов (Fox-trot) 16.02.15 22:28
все это канешна здорово, но на деле все настолько индивидуально, что все это мона спокойно забыть ;-)
13. Konstantin Korolyoff (kos) 17.02.15 00:19
(8) yukon, и всем.

В комментариях увидел 6 критических замечаний. Постараюсь ответить.

1) Вы утверждаете (ссылаясь на MS)
рекомендуемое значение равно 8, и не должно превышать 16. ........


у них же (MS) здесь https://msdn.microsoft.com/en-us/library/ms188611.aspx
сказано, что "Setting the max degree of parallelism option to 0
allows SQL Server to use all available processors upt to a maximum of 64 processors
in a parallel plan execution." иными словами
"дает ВОЗМОЖНОСТЬ использовать все процессоры вплоть до значения 64"
Я же ЗАСТАВЛЯЮ его использовать ВСЕГДА значение 64
(это не значит, что у меня 64 ядра, это значит что реально будет использовать ВСЕ что есть физически)

2) по поводу статистики
autocreate stat off & autoupdate stat off

В моем случае
* очень высокая интенсивность работы (кол-во запросов доходит до 5000шт/сек)
* tempdb - находится в памяти
* БД (иногда) тоже там же (а значит IOPS в 100 выше чем при работе с дисками)
Поэтому
* статистика - не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)

3)
page verify = torn page detection (или даже NONE !)

Опять же
* на сервере установлена ECC-память (аппаратный CHECKSUM)
* базы (как правило) в пямяти (опять же экономим ресурсы CPU на вычислениях)

4)
Сомневаюсь, что характер работы 1С с SQL сервером похож на работу указанных приложений

Я не знаю, какой "характер" работы у указанных Вами приложений, я знаю 2 типа работы приложений с БД
* OTLP (очень большая интерсивность маленьких, часто повторяющихся запросов, например FOREX)
* OLAP (объемные запросы на выборку данных, для построения "глобальных" аналитических отчетов)
В моем (конкретном) случая я бы отнес "характер работы"
(при массированном проведении документов) к типу OTLP
где критическим местом является: (1) дисковая подсистема (2) процессор

(11) yukon, Чуть ниже постом, Вы говорите:

5)
Вот только базы с параметрами .....<skip>... вряд ли можно отнести к большим базам


Данная статья не рассматривает работу SQL с большими базами данных.
В данной статье идет разговор "о производительности" (т.е. о скорости работы)
в высоконагруженных системах.
В данном случае (как в пословице) : "Размер не имеет значения".
Я считаю (когда показатель "Количество запросов в секунду" доходит иногда до 5000)
- у меня HighLoad System

6)
Что касается ...exec sp_configure 'recovery interval (min)',60


Опять же - я делаю не "просто изменить параметр", а ровно 2 вещи:
* recovery interval (min) = 60
= хочу отключить АВТОМАТИЧЕСКИЙ вызов CHECKPOINT "мыслями" сервера SQL
* и выполняю каждые 10 минут FULL BACKUP(который уже имеет CHECKPOINT)
= своей головой (у меня БД в RAM)
Так что здесь - проблем не вижу.

Надеюсь, "осветил" все критические моменты.
Коллеги, задавайте вопросы, с удовольствием отвечу.
14. Konstantin Korolyoff (kos) 17.02.15 04:27
(10) Gilev.Vyacheslav,

Конечно же, это не универсальный рецепт на все случаи жизни.
Это ПОДХОД для решения конкретной задачи:

Условия:
* размер БД позволяет "засунуть" ее в RAM
* высокая интенсивность (нагрузка) на SQL - большое количество МЕЛКИХ запросов (у меня иногда до 5000/сек)
* крутится несколько "разношерстных" баз на одном SQL - оптимизировать каждую (средствами 1С) затратно (time=mony)
* в данных условиях узким местом являются: (а) дисковая система (б) процессор

Решение:
1. снять нагрузку на процессор: убираем ВСЁ что заставляет его пересчитывать и оптимизировать
2. отказываемся от тяжеловесных механизмов (таких как CHECKPOINT-ы)
3. помещаем БД в память

Требования:
1. памяти должно быть достаточно
2. память обязательно должна быть ECC !!!!!
3. обязательно "шедулим" бекапы БД из памяти на диск (чаще, чем это предполагает делать SQL авто-CHECKPOINT-ом)

Замечание1:
* у меня замечено, что даже при запуске "бухами" всяких там "концемесячных"
регламентов в 1С8 УПП = нагрузка на сервер сохраняется равномерная
* поэтому (конечно же, прежде всего) такой "подход подходит" (каламбурчик) к 1С77 (особенно при перепроведении БД)
* а уж если их (77) несколко запустить на перепроведение одновременно , тогда держитесь....
* да собственно и пользователи (если оставить БД в памяти на всегда) будут ОЧЕНЬ благодарны за скорость 8))

Замечание2:
* конечно же эти "мои" 1с77 давно используют "костыли": такие как 1С++, "ПрямыеЗапросы" и т.д.
* "ПрямыеЗапросы" (однозначно) использовать в 2х случаях: для форм (параметризованные) и для отчетов (select-ы всякие)
* а вот если говорить про модуль проведения: не думаю, что они будут эффективней "временных регистров" от 1С....
(кстати, известный всем, кто в теме 1с++ = ЁПРСТ = тоже так думает = это я о проведении и прямых запросах....)

ЭТА СТАТЬЯ НЕ РЕЦЕПТ - ЭТО ПОДХОД !!!! И ДЛЯ 1С8 = ОН ТОЖЕ РАБОТАЕТ.

А рецепты - действительно - каждый должен варить сам: по своему вкусу..... и своей ситуации 8))

P.S. Думаю этот подход позволит прожить 1С77 еще 20 лет, к тем которые уже она прожила... 8))
15. andrey dyak (dyak84) 17.02.15 06:07
Спасибо сколько живеш столько нужно учится. Учение свет. Будет на выходных чем занятся.Автор так держать много и интересно.
16. Василий Коровин (vasyak319) 17.02.15 14:29
(13)
Поэтому
* статистика - не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)


Знаете, очень напомнило серию Футурамы, как Зойдберг кино снимал: "Самым длительным и дорогим этапом в кинопроизводстве является монтаж и прочий постпродакшн, поэтому мы решили обойтись без него".

Почитайте на MSDN, в каких случаях апдейтится статистика, вычисляются планы и для чего это вообще нужно.
17. Konstantin Korolyoff (kos) 17.02.15 15:17
(16) vasyak319,

1) предполагается что будут использоваться родные 1С-кие кластерные индексы "из коробки"
и в (собственно) запросах никаких хинтов писать не будем.
Естественно: не забываем про порядок полей в запросах (как в индексах).....и т.д.

2) как я уже говорил
* "родные индексы" (как правило) - изначально оптимальны в большинстве случаев
* или Вы хотите еще что-то ускорить ? может insert/update при помощи статистики ? 8))

3) Еще раз:
* физически скорость носителя RAM "без статистики" выше чем HDD "со статистикой"
* конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним (+память сьедает)
* индексы никто не отменял (по крайней мере я)
* настаиваю - в структуры и процедуры от 1С (на строне SQL) не нужно "лазить"

4) прочитайте на том же MSDN как влияет статистика на производительность
* как в сторону ускорения - о чем говорят все (в том числе и Вы, и я)
* а также в сторону ухудшения - о чем тоже написано, но никто об этом не говорит (Вот я хочу сказать, но не дают)
Не зря ведь в самом видимом места свойств базы есть флажек "ON/OFF" ?

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

Хотелось бы больше услышать "практиков" ( а не умеющих читать теоретиков ).
Коллеги, больше конструктивизма.
18. Артем Целовальников (slazzy) 17.02.15 15:22
(13) kos,
сказано, что "Setting the max degree of parallelism option to 0
allows SQL Server to use all available processors upt to a maximum of 64 processors
in a parallel plan execution." иными словами
"дает ВОЗМОЖНОСТЬ использовать все процессоры вплоть до значения 64"
Я же ЗАСТАВЛЯЮ его использовать ВСЕГДА значение 64
(это не значит, что у меня 64 ядра, это значит что реально будет использовать ВСЕ что есть физически)


Тут дело в том, что в 1С стандартно довольно сложные запросы, которые почти не параллелятся, либо делают это очень криво и в итоге теряют в скорости. Я неоднократно слышал о том, что надо принудительно выставлять max degree of parallelism в 1 и именно это ускоряет работу. Поэтому лично мне принудительное выставление maxdop в 64 для 1с кажется нонсенсом, ведь 90% запросов всё равно будут выполнять однопоточно, ещё 9% просто замедлят свою производительность изза кривого распараллеливания и 1% может быть ускорится :) но может у вас на это другие взгляды

Просто я не админ, я программист. У меня конечно стоит sql на своем компе и я частенько играюсь с планами запросов и разбираюсь в них. И в принципе крайне редко я видел многопоточные планы запросов.
Быть может на крупных hightload базах это выглядит иначе)
19. Konstantin Korolyoff (kos) 17.02.15 15:57
(18) slazzy,

1с77 - да, криво, однопоточно.
Не зря ведь все (или почти все) "прикрутили" 1С++ и ПрямыеЗапросы к 77,
и получили побольше вольностей в отношении SQL на стороне клиента....Запросы пишем САМИ, не 1С.
При проведении документов: "ВременныеРегистры" считаю оптимизировать бессмысленно: единственное что может ускорить проведение: правильная расстановка измерений (чтобы select отрабатывал быстрее) и отказ на регистрах от лишних галочек (чтобы не тормозил insert/delete/update).
На этом оптимизация проведения документов заканчивается
(ну кроме - как всегда - собственно "бизнес" логики, и запутанных циклов/ветвлений/.....)
Дальше: начинаем лезть во внутренности 1С77, кишки ей накручивать, оптимизировать SQL сервер...

1С8х
А разве "язык запросов" в снеговике не "просто парсится" самой 1С-кой в обычный SQL и отдается ODBC?
Или Вы про те запросы, которые отвечают за стандартные 1С-вские диалоги ?
Ну так их много и они очень коротки, там параллелится собственно нечему....

У меня = только те, что больше 1й секунды = exec sp_configure 'cost threshold for parallelism',1
Остальные автоматом будут последовательными.....

РЕБЯТА!!!! ОПЯТЬ ВЫ ПРО "ТОЛЩИНУ БАЗЫ" !!!!
Параллелизм не зависит от толщины базы - он зависит от времени выполнения запроса.

А в случае сервера 1С (который типа кластер): разве там не используется параллелизм?
Они явно указывают MAXDOP=1 для всех и всегда ????
Не верится что-то ... Неужели настолько всё запущено.......
уж 2015 год, 2014 SQL, 2012 Win..... а 1С всё в ХХ веке?

Я действительно - не знаю, может Вы и правы....
Внутренности 1С8 не исследовал, но тогда....... Блин, что же делать???
Нужно переходить на OpenERP ! или SAP ....
Шутка....
20. Konstantin Korolyoff (kos) 17.02.15 16:31
Еще раз по поводу отключения статистики.
Мои аргументы, так сказать:

аргумет первый, "железный" (админский)
* используем RAM (что изначально быстрее HDD)
* не хочу хранить в памяти "лишннюю" информацию (место, пусть мало, но всё же)
* не хочу нагружать CPU расчетами планов - хочу заставить работаь его безалтернативно = строго по индексам

аргумент второй, "программный" (программистский)
* предполагаю что все запросы, "вшитые" в 1С - ничтожно микроскопические (а значит уже оптимальны)
* запросы (которые пишет программист) ОБЯЗАНЫ "попадать" в кластерные индексы таблиц (иначе он не программист)

Аргумент третий, админский
* не забываем про регламентные задачи на ночь, куда входит sp_updatests, в том числе.

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


21. Василий Коровин (vasyak319) 17.02.15 17:58
(20) "* не хочу нагружать CPU расчетами планов - хочу заставить работаь его безалтернативно = строго по индексам"

А так он что, по ленинским местам что ли работает? Оптимизатор нужен не для того, чтобы делать выборку каким-то магическим образом, минуя индексы, а чтобы выбрать, в том числе (но не только!), какой индекс лучше использовать.
И своим запихиванием базы в память вы, конечно, чтение-запись ускорите, но если памяти у вас изначально было достаточно, то большая часть используемых данных и так была в кэше, а вот запросы, которые, например, выбрали неоптимальный метод слияния из-за отсутствия статистики, как с этим кэшом у вас тормозили, так и в памяти тормозить будут.
22. Андрей М (_Z1) 17.02.15 20:38
(20)
Если такой "противник" обновление статистики
то отключай и асинхронное обновление статистики.

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

Конечно ты молодец что написал subj ,
но многие твои утверждения сомнительны на мой взгляд.
23. Андрей М (_Z1) 17.02.15 20:41
(all) кстати на базах 7.7 о чем не сказано в subj , мне дало выигрыш включение
форсированой параметризации ( проверял на тестах )
24. Соня Иванова (CoverG) 18.02.15 11:23
(23) _Z1, А что это за зверь такой - форсированная параметризация в 7.7?
25. imispb imispb (imispb) 18.02.15 11:41
База в памяти с бэкапом в 10минут. Возникает вопрос: в случае зависания и прочих проблем, как восстановить то, что сделано в базе за последние 10 минут. У нас в компании, это практически невозможно. Я бы никогда базу не стал размещать в RAM. Даже если это очень соблазнительно, с точки зрения производительности. Был похожий случай. Что там случилось с памятью, сейчас не скажу, но вот базы побились во всем кластере и восстановить последние изменения представилось невозможным. Для себя сделал вывод: никогда рабочую базу в RAM не пихать. Для перепроведения больших баз, наверное имеет смысл перенести в RAM, провести и вернуть обратно.
26. Антон Стеклов (asved.ru) 18.02.15 12:36
(17) kos,
конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним
дык не вопрос, нагружайте Nested Loops'ами.

Я еще вечером до вас доберусь и пройдусь по вашим "рекомендациям".
vasyak319; +1 Ответить
27. Виталий Онянов (Tavalik) 18.02.15 13:04
при этом:
- каждые 10 минут FULL BACKUP

А почему полный бэкап, а не дифференцированный?

делаем "финт ушами":
- средставим тогоже imDisk создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)

А с учетом того что память и диски сегодня стоят ....
Проще наростить мощность сервера и вынести (когда нужно) базу в память...

Везет вам, база всего 20 Гб. Как быть, если размер одной базы в 100 Гб. и выше и баз несколько?

А не могли бы вы привести хотя бы приблизительные данные о том, насколько увеличилась производительность после переноса tempdb на RAM-диск, и после переноса БД на RAM-диск?
28. Андрей М (_Z1) 18.02.15 13:05
(24) CoverG,
_Z1, А что это за зверь такой - форсированная параметризация в 7.7?

параметризация не в 7.7 а для ms sql базы.( сервер начиная с sql2005 )
Вот параметр на картинке
Прикрепленные файлы:
29. Дмитрий Тарасов (tarassov) 18.02.15 13:24
(25) imispb,
База в RAM, это конечно перебор. Для 1С7.7+MSSql в RAM вполне достаточно разместить каталоги временных файлов (на собственнм опыте проверено: скорость перепроведения вырастает на порядок)
30. Дмитрий Мальцев (DimKirov) 18.02.15 14:00
Статья познавательная в плане дальнейшего самооблразования, не более. Рекомендованные параметры не расписаны. И я более чем уверен, что не все на изусть знают на что вышеперечисленные параметры влияют.
Идея tempdb разместить в памяти - это понятно. остальное ... только если прочитать всё обсуждение :)
31. Андрей Старченко (dr.death) 25.03.15 09:52
'max degree of parallelism' Этот параметр отвечает не за использование Sql какого то количества процессоров, а говорит о том на сколько ядер можно распараллелить ОДИН запрос, при этом не факт, что увеличится производительность. значение 0 этого параметра и так говорит нам о распараллеливании запросов на ВСЕ имеющиеся ядра, значение >1, отграничивает распараллеливание (не более) на указанное число ядер, значение =1 говорит нам что ОТДЕЛЬНО ВЗЯТЫЙ ЗАПРОС полностью исполнится на ОТДЕЛЬНО ВЗЯТОМ ЯДРЕ. Кстати рекомендация от 1С именно значение 1. Распараллеливание ОДНОГО запроса на несколько ядер имеет смысл, если запрос "ТЯЖЁЛЫЙ", но 90 % всех исполняемых запросов мелкие, и распараллеливание только увеличит время их выполнения из-за неверного плана.
vasyak319; +1 Ответить
32. Евгений Недашковский (airalchemist) 22.04.15 11:21
Я извиняюсь, но все приведенные автором настройки (за исключением MAXDOP и обновления статистики) скорее имеют эффект плацебо. Это в сравнении с настройками по умолчанию.
Что касается MAXDOP, то dr.death всё правильно написал - этот параметр влияет на выполнение единичных запросов. sv_mikh сделал себе только хуже - теперь у него запросы распараллеливаются на 64 потока (если все ядра свободны) и вместо того, чтобы запрос быстро выполнился на одном ядре, он тянется по нескольким, тратя время на разбиение на потоки и синхронизацию. Готов поспорить, что теперь топовое ожидание СУБД - CXPACKET. Т.е. часть потоков выполнилась и ждёт пока выполнятся другие и так по замкнутому кругу.
Если нет желания заморачиваться - ставьте MAXDOP в значение равному количеству ядер. Максимум - восемь. Если стало хуже - ставьте единицу (один запрос на ядро). Если есть желание потюнить - меняйте значение (можно на лету, службу СУБД перезапускат не надо) и играйтесь с временем выполнения. Не забудьте после каждой смены значения удалять план выполнения, либо вообще сбросить буферный пул и кеш запросов.
Помните - вашей целью является оптимизация скорости, а не равномерная загрузка всех ядер CPU.

Что касается обновления статистики... Вопрос: что будет быстрее - выборка одного значения по покрывающему индексу с обычного HDD, либо поиск значения путём полного сканирования таблицы, которая находится на RAM-диске? В зависимости от ответа на данный вопрос сами решайте, следовать ли советам автора.

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

Ну и что касается регламентных заданий, рекомендую: https://ola.hallengren.com/ (на английском).