Хабр Курсы для админов
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 29
Закреплённые комментарии
Вышла вторая часть, отредактировать статью не могу. Вот она: https://habr.com/ru/articles/1080996/
Ещё такое включаю
EXEC sys.sp_configure N'cost threshold for parallelism', N'50'
GO
EXEC sys.sp_configure N'backup compression default', N'1'
GO
EXEC sys.sp_configure N'backup checksum default', N'1'А! Ну и конфигурирую Mail Agent, и (главное!) проверяю, что он работает.
вторая и 3я норм. А первая настройка подбирается под нагрузку. Надо смотреть количество и планы запросов уходящих в параллельную обработку, и в зависимости от этого подбирать значение. По сути значение - это вес запроса при превышении порога которого включается параллельный план исполнения.
Стоит отметить, что рекомендация "Второй приём — несколько виртуальных контроллеров. У каждого своя очередь команд, поэтому данные, журналы и tempdb разносятся по разным контроллерам. Это прямое продолжение принципа раздельных каналов, перенесённое с физического уровня на виртуальный." не имеет смысла для Hyper-V, начиная с Windows Server 2019.
А как же кол-во файлов в tempDB?
The recommended total number of data files depends on the number of logical processors on the machine. As general guidance:
If the number of logical processors is less than or equal to eight, use the same number of data files.
If the number of logical processors is greater than eight, use eight data files.
If
tempdballocation contention is still observed, increase the number of data files by multiples of four until the contention decreases to acceptable levels, or make changes to the workload.
Штатная утилита для тестирования производительности дисковой подсистемы - SQLIOsim (Validate I/O Subsystems with SQLIOSim - SQL Server | Microsoft Learn ), входит в дистр. SQL Server, начиная с какой-то версии (раньше скачивалась отдельно).
"соседняя виртуалка с файловым архивом отбирает IOPS у СУБД" - ну если файлопомойка и файлы БД лежат физически на одном LUN, то это вопрос к неправильной архитектуре хранения в СХД, ибо отличается всё: load profiles, tiering, dedup, и соответственно, размещение (нарезка CSV, параметры файлов vhdx, если мы о Hyper-V) подключенных к ВМ виртуальных дисков.
Во время прочтения, меня не покидало ощущение, что статья где-то задержалась лет на 5.
1) Внедрять серверные продукты MS после 2022, не привлекая внимание "санитаров" к соей персоне, это отдельный уровень отложенного экстрима. Доходнее другие виды "запрещенки" продавать/распространять.
2) Виртуализация Hyper-V, VMware... Особенно с текущей позицией Broadcom, это отдельный уровень острых ощущений для любителей адреналина. С отложенными последствиями, как в вышеизложенном пункте.
3) NVMe для базы данных 1С - обязательный параметр. Дисковая полка, RAID и другие варианты - только для тех, кто хорошо понимает, зачем им это надо.
Было бы интереснее сосредоточится на приведении уже работающих инсталляций в надлежащее состояние, с обязательным упором на сохранении лицензионности продуктов.
P.s. Все написанное исключительно ИМХО.
Внедрять серверные продукты MS после 2022
А они у вас перестали работать?
Новые внедрения, с ценой ~6-8 млн рублей только за лицензии MS, для условного 16 ядерного сервера 1C, пока никого не прельстили. Все готовы потратить часть этих денег для перевода своих "нетленок" на альтернативные программные платформы, отличные от MS, Broadcom.
Все новые внедрения 1С на продуктах MS, Broadcom встречались поголовно под черным флагом. Т.к. даже внедренцам 1С ERP сложно оправдать новые правила подписки Broadcom на VMware.
На 15 я бы сказал. Нет, сами-то принципы не поменялись, но вот область задействования тех или иных настроек... Прям умилило вот это разделение нагрузок по томам в эпоху NVMe и всеобщей виртуализации. Тюнинг MS SQL за пределами выноса на отдельную от сервера SQL машину, настроек ограничений памяти и параллелизма имеет смысл только ну в очень тяжелых инсталляциях, а их статья так или иначе не покрывает.
Ну к текущим развертываниям это применимо. Не смотря на стиль изложения в виде болтологии, по сути большинство рекомендаций верны. Всю эту муть можно изложить примерно в 10 предложений.
Вы правы, но к сожалению всё вышеперечисленное в статье продолжаю наблюдать из раза в раз. Последний аудит был месяц назад,наблюдаю всё тоже самое.
Статья интересная, есть что обсудить. например я в своей практике на 2х серверах где у меня крутится MSSQL Server под tempDB выделяю RAM диск из физической памяти, количество баз tempDB определяю примерно по количество ядер но не больше 8шт по 2Гб каждая. и того у меня из 128Гб ОЗУ примерно 20Гб это виртуальный диск для временных баз, 20% от оставшегося объема под ОС и сервисы и остальное все отдаю SQL Server. Что касается размещение 1С и SQL сервера на одной машине - если ресурсов хватает, сервисы разнесены по разным дискам то не вижу в этом ничего плохого, наоборот Shared Memory куда быстрее работает чем TCP/IP между 1С и SQL что дает хорошую прибавку в быстродействии. Для тестов производительности так же пользуюсь тестом Галиева, но это по желанию. Очень часто быстродействие возрастает когда оптимизируют код запросов в базу на стороне 1С, убедился в этом не один раз особенно когда конфигурация не типовая.
Очень часто быстродействие возрастает когда оптимизируют код запросов в базу на стороне 1С, убедился в этом не один раз особенно когда конфигурация не типовая.
Да не часто, а всегда. Типовая или не типовая вообще без разницы. Другое дело, что это очень дорогостоящий путь, где нужно под лупой рассматривать каждый тяжелый запрос вместе с бизнес-требованиями к нему и характером использования.
Подскажите, каким ПО создаёте RAM диск?
У администратора компетенция в операционных системах и сети, у разработчика в конфигурациях и проводках. Уровень СУБД остаётся между ними
не между ними, а кмк вообще ничей. Роль DBA столь специфичная, что ни один, ни другой ей не будет обладать. Просто по экономическим соображениям: в найме этот человек будет выглядеть дороже и бизнес не захочет переплачивать без болезненных проблем прямо сейчас.
Отсюда подход “а давайте заранее подумаем” крайне редкий.
Из-за такого подхода потом обнаруживается, что всю базу тормозит обработка, в которой значения из справочника/регистра вычитываются по одному и сравниваются в цикле, или вообще сортируются "пузырьковым методом" на самом 1С, вместо одного правильного запроса к SQL. Пока в справочнике/регистре было десяток значений, это никто не замечал. Но за пару лет там накопилось около полумиллиона значений. И код, проверенный еще на 1С 7.7, стал тормозить всех.
Виновата будет назначена конечно база данных. И никого не смущает, что tempdb вырастает в 20-50 раз больше самой базы 1С.
Я отношу оценку алгоритмической сложности, проблемы N+1 к компетенциям разработчика. Поэтому
в которой значения из справочника/регистра вычитываются по одному и сравниваются в цикле, или вообще сортируются “пузырьковым методом” на самом 1С
такое на совести разработчика. Но вот тюнинг СУБД под конкретные нагрузки и конкретные особенности железа - это отдельное искусство у DBA - вот именно его не будет.
Интересно только одно: что в таких крупных организациях тормозит переход на postgresql?
Упоминается SQL Server 2025, а разве 1С:Предприятие 8 может с ним работать? В требованиях упоминается максимум 2022
SQL Server умеет устанавливать режим совместимости (с некоторыми оговорками) на уровне базы данных. Подробности про режим совместимости можно почитать здесь.
Уважаемые коллеги, и все кто комментировал выше. Большое спасибо за все ваши комментарии. Меня наконец то выпустили из местного (Хабровского) "СИЗО" тьфу-тьфу.. конечно.. :)) теперь могу продолжать полноценно делиться наработками и обсуждать всякое "наболевшее". Рад что такая, казалось бы немного "банальная", и как правильно подметили выше "немного опоздавшая" статья нашла такой отклик. Я надеюсь что мои советы и рекомендации найдут достойное применение на практике. Да! и вышла вторая часть. Ссылку на нее размещу внизу статьи "там где был coming soon".
Вышла вторая часть, отредактировать статью не могу. Вот она: https://habr.com/ru/articles/1080996/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка MS SQL Server под 1С: планирование и развёртывание