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

16.02.15

Еще один подход к увеличению производительности 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%
- при этом затрат на обслуживание (времени) уходит просто уйма.

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

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

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

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

производительность монопольно 1с77 SQL скорость проведения оптимизация базы

+47 –2

См. также

Однопользовательское открытие формы обработки

Инструменты администратора БД Программист Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)

Блокировка открытия формы обработки одним пользователем.

1 стартмани

24.05.2023 902 igor7777 1

Как ускорить 1С за 5 минут – Протокол Shared Memory (1С 7.7)

HighLoad оптимизация Системный администратор Платформа 1С v7.7 Конфигурации 1cv7 Бесплатно (free)

Вариант для SQL 77

18.10.2022 2556 Dionisiy 7

Групповое переименование файлов для 1С 7.7

Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Простецкий скрипт переименования файлов в папке в нижний регистр, будет полезен программистам и системным администраторам имеющим навыки програмирования в 1С. Можно легко настроить под себя, спасает мне периодически час времени, может, кому еще будет полезен.

1 стартмани

18.02.2022 4027 0 igor7777 6

Блокировки SQL базы данных 1С 7.7

HighLoad оптимизация Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Конфигурация на 1С 7.7, показывающая блокировки на MS SQL сервере и доменных пользователей по SPID. Используется 1С++ и классы.

1 стартмани

09.11.2021 4916 9 ShoDm 17

[7.7 ТиС. СТОП-БАРДАК] Автоперенос непроведенных документов на текущий день

Инструменты администратора БД Программист Пользователь Оперативный учет 7.7 1С:Торговля и склад 7.7 Управленческий учет Абонемент ($m)

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

2 стартмани

25.05.2020 5882 2 CheBurator 3

Инструкция: ускоряем tempdb переносом в RAM диск

HighLoad оптимизация Системный администратор Бесплатно (free)

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.

29.01.2019 47706 MrWonder 87

114

Анализ 1С: Предприятие 7.7 с помощью ELK стека

Журнал регистрации Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Бесплатно (free)

Рассмотрим систему на базе Elasticsearch, Logstash и Kibana (ELK Stack) для анализа логов 1С Предприятие 7.7 с целью визуализации и анализа событий 1С.

22.01.2019 11568 phsin 20

Автоматическое объединение конфигураций 1С 7.7

Скрипт позволяет выполнить объединение конфигураций и реструктуризацию из командной строки. Объединение выполняется штатными средствами конфигуратора 1С 7.7, взаимодействие с которым происходит путем посылки нажатий клавиш. Пригодится, если есть необходимость обновить или постоянно обновлять множество ИБ.

1 стартмани

22.04.2017 15864 4 devlabnn 2

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. DoctorRoza 16.02.15 08:19 Сейчас в теме

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

Основная и единственная рекомендация - это грамотные, оптимальные запросы! Оптимизация индексов, это что, добавить новые, реструктуризировать старые? Блокировки - сейчас все на управляемых блокировках, автоматических режим - это редкость. А в целом, все проблемы от самих же программистов, а точнее, их безграмотности. (ИМХО)

3. sv_mikh 11 16.02.15 08:36 Сейчас в теме

(1) DoctorRoza, не все проблемы от программистов. Если сам скуль настроен криво, то никакие хорошие запросы не помогут. Если работает типовое решение, то вероятность его положить плохими запросами есть, но она не так сильно может испортить жизнь, как кривой скуль.

2. sv_mikh 11 16.02.15 08:34 Сейчас в теме

Спасибо, очень помогло: exec sp_configure 'max degree of parallelism',64. (заставляем SQL принудительно использовать все ядра, что имеются). Была проблема недозагруженности процессоров. Респект!

4. tarassov 113 16.02.15 08:58 Сейчас в теме

По моему опыту, для существенного ускорения 1Сv7.7, особенно в случаях массового перепроведения документов, не обязательно на RAM-диск отсылать всю базу. Достаточно туда перепрописать temp-каталоги!

5. vasyak319 152 16.02.15 11:15 Сейчас в теме

"путь к файлам MDF/LDF - должен быть без длинных путей"

А зачем? Путь используется один раз - при открытии файла. Дальше все обращения через дескриптор. Физическое место записи файла тоже от пути не зависит.

6. vasyak319 152 16.02.15 11:17 Сейчас в теме

Кстати, не стоит переоценивать мастерство типовых программистов. Я тут пару дней назад хотел даже статью написать, как ускорил УПП на 40%, слегка изменив типовой код, да что-то глюкануло и она не сохранилась, зараза такая.

7. korsar2001 15 16.02.15 13:40 Сейчас в теме

Перевод на "Прямые запросы" очень сильно помогает при больших размерах баз

8. yukon 153 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 сервером похож на работу указанных приложений.

9. vasyak319 152 16.02.15 15:08 Сейчас в теме

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

11. yukon 153 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."

13. kos 46 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)
Так что здесь - проблем не вижу.

Надеюсь, "осветил" все критические моменты.
Коллеги, задавайте вопросы, с удовольствием отвечу.

16. vasyak319 152 17.02.15 14:29 Сейчас в теме

(13)

Поэтому
* статистика - не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)

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

Почитайте на MSDN, в каких случаях апдейтится статистика, вычисляются планы и для чего это вообще нужно.

17. kos 46 17.02.15 15:17 Сейчас в теме

(16) vasyak319,

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

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

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

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

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

Хотелось бы больше услышать "практиков" ( а не умеющих читать теоретиков ).
Коллеги, больше конструктивизма.

26. asved.ru 36 18.02.15 12:36 Сейчас в теме

(17)

конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним

дык не вопрос, нагружайте Nested Loops'ами.

Я еще вечером до вас доберусь и пройдусь по вашим "рекомендациям".

18. slazzy 42 17.02.15 15:22 Сейчас в теме

(13)

сказано, что "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. kos 46 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 ....
Шутка....

10. Gilev.Vyacheslav 1917 16.02.15 15:46 Сейчас в теме

(0) мы на курсах http://www.gilev.ru/kurs/ рассказываем прежде всего о том, что нет единого универсального рецепта для всех
создаваемое замедление состоит из набора разного количества причин и степени вклада в общее замедление
можно конечно делать "с бубном", но анализ причин на перспективу даст больше пользы

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

для маленьких баз можно больше результата достичь улучшением железа
для больших баз больше кодом...

Ответить

14. kos 46 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))

12. Fox-trot 163 16.02.15 22:28 Сейчас в теме

все это канешна здорово, но на деле все настолько индивидуально, что все это мона спокойно забыть ;-)

15. dyak84 17.02.15 06:07 Сейчас в теме

Спасибо сколько живеш столько нужно учится. Учение свет. Будет на выходных чем занятся.Автор так держать много и интересно.

20. kos 46 17.02.15 16:31 Сейчас в теме

Еще раз по поводу отключения статистики.
Мои аргументы, так сказать:

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

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

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

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

21. vasyak319 152 17.02.15 17:58 Сейчас в теме

(20) "* не хочу нагружать CPU расчетами планов - хочу заставить работаь его безалтернативно = строго по индексам"

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

22. _Z1 38 17.02.15 20:38 Сейчас в теме

(20)
Если такой "противник" обновление статистики
то отключай и асинхронное обновление статистики.

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

Конечно ты молодец что написал subj ,
но многие твои утверждения сомнительны на мой взгляд.

23. _Z1 38 17.02.15 20:41 Сейчас в теме

(all) кстати на базах 7.7 о чем не сказано в subj , мне дало выигрыш включение
форсированой параметризации ( проверял на тестах )

24. CoverG 18.02.15 11:23 Сейчас в теме

(23) _Z1, А что это за зверь такой - форсированная параметризация в 7.7?

28. _Z1 38 18.02.15 13:05 Сейчас в теме

(24) CoverG,

_Z1, А что это за зверь такой - форсированная параметризация в 7.7?

параметризация не в 7.7 а для ms sql базы.( сервер начиная с sql2005 )
Вот параметр на картинке

Прикрепленные файлы:

25. imispb 5 18.02.15 11:41 Сейчас в теме

База в памяти с бэкапом в 10минут. Возникает вопрос: в случае зависания и прочих проблем, как восстановить то, что сделано в базе за последние 10 минут. У нас в компании, это практически невозможно. Я бы никогда базу не стал размещать в RAM. Даже если это очень соблазнительно, с точки зрения производительности. Был похожий случай. Что там случилось с памятью, сейчас не скажу, но вот базы побились во всем кластере и восстановить последние изменения представилось невозможным. Для себя сделал вывод: никогда рабочую базу в RAM не пихать. Для перепроведения больших баз, наверное имеет смысл перенести в RAM, провести и вернуть обратно.

29. tarassov 113 18.02.15 13:24 Сейчас в теме

(25) imispb,
База в RAM, это конечно перебор. Для 1С7.7+MSSql в RAM вполне достаточно разместить каталоги временных файлов (на собственнм опыте проверено: скорость перепроведения вырастает на порядок)

27. Tavalik 3411 18.02.15 13:04 Сейчас в теме

при этом:
- каждые 10 минут FULL BACKUP

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

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

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

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

А не могли бы вы привести хотя бы приблизительные данные о том, насколько увеличилась производительность после переноса tempdb на RAM-диск, и после переноса БД на RAM-диск?

30. DimKirov 18.02.15 14:00 Сейчас в теме

Статья познавательная в плане дальнейшего самооблразования, не более. Рекомендованные параметры не расписаны. И я более чем уверен, что не все на изусть знают на что вышеперечисленные параметры влияют.
Идея tempdb разместить в памяти - это понятно. остальное ... только если прочитать всё обсуждение :)

31. 1cprogr_nsk 110 25.03.15 09:52 Сейчас в теме

'max degree of parallelism' Этот параметр отвечает не за использование Sql какого то количества процессоров, а говорит о том на сколько ядер можно распараллелить ОДИН запрос, при этом не факт, что увеличится производительность. значение 0 этого параметра и так говорит нам о распараллеливании запросов на ВСЕ имеющиеся ядра, значение >1, отграничивает распараллеливание (не более) на указанное число ядер, значение =1 говорит нам что ОТДЕЛЬНО ВЗЯТЫЙ ЗАПРОС полностью исполнится на ОТДЕЛЬНО ВЗЯТОМ ЯДРЕ. Кстати рекомендация от 1С именно значение 1. Распараллеливание ОДНОГО запроса на несколько ядер имеет смысл, если запрос "ТЯЖЁЛЫЙ", но 90 % всех исполняемых запросов мелкие, и распараллеливание только увеличит время их выполнения из-за неверного плана.

32. airalchemist 22.04.15 11:21 Сейчас в теме

Я извиняюсь, но все приведенные автором настройки (за исключением MAXDOP и обновления статистики) скорее имеют эффект плацебо. Это в сравнении с настройками по умолчанию.
Что касается MAXDOP, то dr.death всё правильно написал - этот параметр влияет на выполнение единичных запросов. sv_mikh сделал себе только хуже - теперь у него запросы распараллеливаются на 64 потока (если все ядра свободны) и вместо того, чтобы запрос быстро выполнился на одном ядре, он тянется по нескольким, тратя время на разбиение на потоки и синхронизацию. Готов поспорить, что теперь топовое ожидание СУБД - CXPACKET. Т.е. часть потоков выполнилась и ждёт пока выполнятся другие и так по замкнутому кругу.
Если нет желания заморачиваться - ставьте MAXDOP в значение равному количеству ядер. Максимум - восемь. Если стало хуже - ставьте единицу (один запрос на ядро). Если есть желание потюнить - меняйте значение (можно на лету, службу СУБД перезапускат не надо) и играйтесь с временем выполнения. Не забудьте после каждой смены значения удалять план выполнения, либо вообще сбросить буферный пул и кеш запросов.
Помните - вашей целью является оптимизация скорости, а не равномерная загрузка всех ядер CPU.

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

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

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

33. 888tbkru 06.12.18 22:31 Сейчас в теме

Уберите RAID 10 , систему отдельный диск , базы распределите по остальным . RAM Диск Вам помогает только потаму что это ДРУГОЙ диск . Запись в temp 2мб/сек и Вы создав под такую нагрузку RAM диск думаете ускоряетесь . Уберите RAID 10 , поставьте кучку зеркал из маленьких SSD , лучше вообще под каждую базу отдельное зеркало , не бойтесь динамических виндовых зеркал , отлично все работает . Убрав RAID10 у Вас должно в 2 раза быть все быстрее , проверьте .

34. v3rter 24.01.19 17:21 Сейчас в теме

Оставлю здесь для сравнения ссылки на официальные рекомендации:

Настройки Microsoft SQL Server для работы с 1С:Предприятием: https://its.1c.ru/db/metod8dev/content/5904/hdoc@78cb0de5

Регламентные операции на уровне СУБД для MS SQL Server: https://its.1c.ru/db/metod8dev#content:5837:hdoc

35. Дмитрий74Чел 239 24.01.19 17:43 Сейчас в теме

Новички сейчас накидают автору плюсов. а вот старички посмотрят-посмотрят да пойдут стороной. Уж больно много спорных моментов. Уж лучше б написал "вот конкретно для такой-то базы на таком-то железе теперь все летает". А то преподносится как универсальные методы.