По оптимизации 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 (у меня такие — методом проб и экспериментов, для этого железа): |
||||||||||||||||||||||||||||||||||||
|
|
| 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%
— при этом затрат на обслуживание (времени) уходит просто уйма.
А с учетом того что память и диски сегодня стоят ….
Проще наростить мощность сервера и вынести (когда нужно) базу в память…
Я пошел экстенсивным путем.
Всё это — к обсуждению 
Критика приветсвуется.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
— оптимизация индексов и статистики
— управление блокировками
Основная и единственная рекомендация — это грамотные, оптимальные запросы! Оптимизация индексов, это что, добавить новые, реструктуризировать старые? Блокировки — сейчас все на управляемых блокировках, автоматических режим — это редкость. А в целом, все проблемы от самих же программистов, а точнее, их безграмотности. (ИМХО)
Спасибо, очень помогло: exec sp_configure ‘max degree of parallelism’,64. (заставляем SQL принудительно использовать все ядра, что имеются). Была проблема недозагруженности процессоров. Респект!
(1) DoctorRoza, не все проблемы от программистов. Если сам скуль настроен криво, то никакие хорошие запросы не помогут. Если работает типовое решение, то вероятность его положить плохими запросами есть, но она не так сильно может испортить жизнь, как кривой скуль.
По моему опыту, для существенного ускорения 1Сv7.7, особенно в случаях массового перепроведения документов, не обязательно на RAM-диск отсылать всю базу. Достаточно туда перепрописать temp-каталоги!
«путь к файлам MDF/LDF — должен быть без длинных путей»
А зачем? Путь используется один раз — при открытии файла. Дальше все обращения через дескриптор. Физическое место записи файла тоже от пути не зависит.
Кстати, не стоит переоценивать мастерство типовых программистов. Я тут пару дней назад хотел даже статью написать, как ускорил УПП на 40%, слегка изменив типовой код, да что-то глюкануло и она не сохранилась, зараза такая.
Перевод на «Прямые запросы» очень сильно помогает при больших размерах баз
Нехило, учитывая, что согласно рекомендуемое значение равно 8, и не должно превышать 16.
MAXDOP=8
For servers that have hyperthreading enabled, the MAXDOP value should not exceed the number of physical processors.
autoupdate stat off
page verify torn page detection
Учитывая, что указанные опции строго рекомендуется ВКЛЮЧИТЬ, а PAGE_VERIFY даже после сброса сервером в NONE после апгрейда базы рекомендуют выставить в CHECKSUM, то данные рекомендации похожи на способ поиметь проблем на ровном месте.
Безусловно, если вы специалист, то вы с данными проблемами справитесь, а вот те кто повторит за вами вряд ли поймет, что именно у него происходит.
UPD. А да, для базы sharepoint и biztalk серверов указанные опции по дефолту выключены и включать их не нужно. Сомневаюсь, что характер работы 1С с SQL сервером похож на работу указанных приложений.
(8) Автор, видимо, предполагает ручное обновление статистики, что для больших баз не просто лучший выход, а единственный, так как триггериться автообновление статистики будет реже (меньше процент изменений) и в итоге планы запросов будут строиться по статистике данных давно забытых периодов.
(0) мы на курсах рассказываем прежде всего о том, что нет единого универсального рецепта для всех
создаваемое замедление состоит из набора разного количества причин и степени вклада в общее замедление
можно конечно делать «с бубном», но анализ причин на перспективу даст больше пользы
и железо, и настройки среды, и код — все должно быть сбалансировано
для маленьких баз можно больше результата достичь улучшением железа
для больших баз больше кодом…
(9) vasyak319,
Для больших баз все решается индивидуально. Вот только базы с параметрами «создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)» вряд ли можно отнести к большим базам, хотя бы 100-200Gb надо для начала.
Для tempdb есть еще такой ход конем «As a general guideline, create one data file for each CPU on the server»
Что касается
чекпоинты БД делаем не чаще 1раз/час (для скорости), хотя это условность (см.MSDN)
То MDSN прямо говорит, что «Этот параметр является дополнительным и его следует изменять только опытным администраторам баз данных или сертифицированным техническим специалистам SQL Server.»
все это канешна здорово, но на деле все настолько индивидуально, что все это мона спокойно забыть 😉
(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))
Спасибо сколько живеш столько нужно учится. Учение свет. Будет на выходных чем занятся.Автор так держать много и интересно.
(13)
* статистика — не нужна (оптимизация планов только зря расходует ресурсы CPU на вычисления для планов)
Знаете, очень напомнило серию Футурамы, как Зойдберг кино снимал: «Самым длительным и дорогим этапом в кинопроизводстве является монтаж и прочий постпродакшн, поэтому мы решили обойтись без него».
Почитайте на MSDN, в каких случаях апдейтится статистика, вычисляются планы и для чего это вообще нужно.
(16) vasyak319,
1) предполагается что будут использоваться родные 1С-кие кластерные индексы «из коробки»
и в (собственно) запросах никаких хинтов писать не будем.
Естественно: не забываем про порядок полей в запросах (как в индексах)…..и т.д.
2) как я уже говорил
* «родные индексы» (как правило) — изначально оптимальны в большинстве случаев
* или Вы хотите еще что-то ускорить ? может insert/update при помощи статистики ? 8))
3) Еще раз:
* физически скорость носителя RAM «без статистики» выше чем HDD «со статистикой»
* конкретно в случае с RAM: нагружать процессор расчетами статистики — считаю абсолютно лишним (+память сьедает)
* индексы никто не отменял (по крайней мере я)
* настаиваю — в структуры и процедуры от 1С (на строне SQL) не нужно «лазить»
4) прочитайте на том же MSDN как влияет статистика на производительность
* как в сторону ускорения — о чем говорят все (в том числе и Вы, и я)
* а также в сторону ухудшения — о чем тоже написано, но никто об этом не говорит (Вот я хочу сказать, но не дают)
Не зря ведь в самом видимом места свойств базы есть флажек «ON/OFF» ?
Не нужно носом тыкать других, читать умеют все (ну или почти).
Да, и простите за мой «футуристический» язык.
Хотелось бы больше услышать «практиков» ( а не умеющих читать теоретиков ).
Коллеги, больше конструктивизма.
(13)
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 базах это выглядит иначе)
(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 ….
Шутка….
Еще раз по поводу отключения статистики.
Мои аргументы, так сказать:
аргумет первый, «железный» (админский)
* используем RAM (что изначально быстрее HDD)
* не хочу хранить в памяти «лишннюю» информацию (место, пусть мало, но всё же)
* не хочу нагружать CPU расчетами планов — хочу заставить работаь его безалтернативно = строго по индексам
аргумент второй, «программный» (программистский)
* предполагаю что все запросы, «вшитые» в 1С — ничтожно микроскопические (а значит уже оптимальны)
* запросы (которые пишет программист) ОБЯЗАНЫ «попадать» в кластерные индексы таблиц (иначе он не программист)
Аргумент третий, админский
* не забываем про регламентные задачи на ночь, куда входит sp_updatests, в том числе.
Как-то так.
При соблюдении всех этих условий — считаю что статистика не нужна (оптимизировать просто — нечего)
(20) «* не хочу нагружать CPU расчетами планов — хочу заставить работаь его безалтернативно = строго по индексам»
А так он что, по ленинским местам что ли работает? Оптимизатор нужен не для того, чтобы делать выборку каким-то магическим образом, минуя индексы, а чтобы выбрать, в том числе (но не только!), какой индекс лучше использовать.
И своим запихиванием базы в память вы, конечно, чтение-запись ускорите, но если памяти у вас изначально было достаточно, то большая часть используемых данных и так была в кэше, а вот запросы, которые, например, выбрали неоптимальный метод слияния из-за отсутствия статистики, как с этим кэшом у вас тормозили, так и в памяти тормозить будут.
(20)
Если такой «противник» обновление статистики
то отключай и асинхронное обновление статистики.
насколько помню обычная статистика выполняется после выполнения запрса.
ассинхроное обновление идет вместе с запросом и поэтому данные этого запроса
не будут учтены в статистике, а так оставив только асинхронное обновление статистики статистика у тебя обновляется причем чуть быстрее чем обычная статистика ( потому что делается паралельно ) но статистика будет менее качественной потому что не учитывает изменения запроса.
Конечно ты молодец что написал subj ,
но многие твои утверждения сомнительны на мой взгляд.
(all) кстати на базах 7.7 о чем не сказано в subj , мне дало выигрыш включение
форсированой параметризации ( проверял на тестах )
(23) _Z1, А что это за зверь такой — форсированная параметризация в 7.7?
База в памяти с бэкапом в 10минут. Возникает вопрос: в случае зависания и прочих проблем, как восстановить то, что сделано в базе за последние 10 минут. У нас в компании, это практически невозможно. Я бы никогда базу не стал размещать в RAM. Даже если это очень соблазнительно, с точки зрения производительности. Был похожий случай. Что там случилось с памятью, сейчас не скажу, но вот базы побились во всем кластере и восстановить последние изменения представилось невозможным. Для себя сделал вывод: никогда рабочую базу в RAM не пихать. Для перепроведения больших баз, наверное имеет смысл перенести в RAM, провести и вернуть обратно.
(17)
дык не вопрос, нагружайте Nested Loops’ами.
Я еще вечером до вас доберусь и пройдусь по вашим «рекомендациям».
— каждые 10 минут FULL BACKUP
А почему полный бэкап, а не дифференцированный?
— средставим тогоже imDisk создаем RAM диск размером 20Гб (ну или сколько там БД + 10%)
Проще наростить мощность сервера и вынести (когда нужно) базу в память…
Везет вам, база всего 20 Гб. Как быть, если размер одной базы в 100 Гб. и выше и баз несколько?
А не могли бы вы привести хотя бы приблизительные данные о том, насколько увеличилась производительность после переноса tempdb на RAM-диск, и после переноса БД на RAM-диск?
(24) CoverG,
параметризация не в 7.7 а для ms sql базы.( сервер начиная с sql2005 )
Вот параметр на картинке
(25) imispb,
База в RAM, это конечно перебор. Для 1С7.7+MSSql в RAM вполне достаточно разместить каталоги временных файлов (на собственнм опыте проверено: скорость перепроведения вырастает на порядок)
Статья познавательная в плане дальнейшего самооблразования, не более. Рекомендованные параметры не расписаны. И я более чем уверен, что не все на изусть знают на что вышеперечисленные параметры влияют.
Идея tempdb разместить в памяти — это понятно. остальное … только если прочитать всё обсуждение 🙂
‘max degree of parallelism’ Этот параметр отвечает не за использование Sql какого то количества процессоров, а говорит о том на сколько ядер можно распараллелить ОДИН запрос, при этом не факт, что увеличится производительность. значение 0 этого параметра и так говорит нам о распараллеливании запросов на ВСЕ имеющиеся ядра, значение >1, отграничивает распараллеливание (не более) на указанное число ядер, значение =1 говорит нам что ОТДЕЛЬНО ВЗЯТЫЙ ЗАПРОС полностью исполнится на ОТДЕЛЬНО ВЗЯТОМ ЯДРЕ. Кстати рекомендация от 1С именно значение 1. Распараллеливание ОДНОГО запроса на несколько ядер имеет смысл, если запрос «ТЯЖЁЛЫЙ», но 90 % всех исполняемых запросов мелкие, и распараллеливание только увеличит время их выполнения из-за неверного плана.
Я извиняюсь, но все приведенные автором настройки (за исключением MAXDOP и обновления статистики) скорее имеют эффект плацебо. Это в сравнении с настройками по умолчанию.
Что касается MAXDOP, то dr.death всё правильно написал — этот параметр влияет на выполнение единичных запросов. sv_mikh сделал себе только хуже — теперь у него запросы распараллеливаются на 64 потока (если все ядра свободны) и вместо того, чтобы запрос быстро выполнился на одном ядре, он тянется по нескольким, тратя время на разбиение на потоки и синхронизацию. Готов поспорить, что теперь топовое ожидание СУБД — CXPACKET. Т.е. часть потоков выполнилась и ждёт пока выполнятся другие и так по замкнутому кругу.
Если нет желания заморачиваться — ставьте MAXDOP в значение равному количеству ядер. Максимум — восемь. Если стало хуже — ставьте единицу (один запрос на ядро). Если есть желание потюнить — меняйте значение (можно на лету, службу СУБД перезапускат не надо) и играйтесь с временем выполнения. Не забудьте после каждой смены значения удалять план выполнения, либо вообще сбросить буферный пул и кеш запросов.
Помните — вашей целью является оптимизация скорости, а не равномерная загрузка всех ядер CPU.
Что касается обновления статистики… Вопрос: что будет быстрее — выборка одного значения по покрывающему индексу с обычного HDD, либо поиск значения путём полного сканирования таблицы, которая находится на RAM-диске? В зависимости от ответа на данный вопрос сами решайте, следовать ли советам автора.
В любом случае, если у вас есть понимание что и зачем вы делаете и как можно проверить результат — делайте что угодно. Просто не надо слепо следовать чужим советам.
Ну и что касается регламентных заданий, рекомендую: (на английском).
Уберите RAID 10 , систему отдельный диск , базы распределите по остальным . RAM Диск Вам помогает только потаму что это ДРУГОЙ диск . Запись в temp 2мб/сек и Вы создав под такую нагрузку RAM диск думаете ускоряетесь . Уберите RAID 10 , поставьте кучку зеркал из маленьких SSD , лучше вообще под каждую базу отдельное зеркало , не бойтесь динамических виндовых зеркал , отлично все работает . Убрав RAID10 у Вас должно в 2 раза быть все быстрее , проверьте .
Оставлю здесь для сравнения ссылки на официальные рекомендации:
Настройки Microsoft SQL Server для работы с 1С:Предприятием:
Регламентные операции на уровне СУБД для MS SQL Server:
Новички сейчас накидают автору плюсов. а вот старички посмотрят-посмотрят да пойдут стороной. Уж больно много спорных моментов. Уж лучше б написал «вот конкретно для такой-то базы на таком-то железе теперь все летает». А то преподносится как универсальные методы.