Комментарии 35
- Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно
Простите, что?
Тут речь немного о другом. При коммите транзакции sql server обязан сначала записать данные в файл журнала транзакций (без кеширования/буферизации), а только потом в mdf файл (при этом допустимо кэширование, тк в файл журнала данные уже записаны и по журналу можно "дозавершить" транзакцию в случае внезапного отключения питания, например если mdf окажется "недозаписанным"). Когда файл журнала находится на отдельном диске, запись в него может пройти быстрее, тк отложенная запись в mdf от других транзакций не влияет на очередь того диска, на котором находится ldf
Чем вызван сам совет, я знаю. Но то, как это мотивирует автор, вызывает сомнения в том, насколько он понимает, о чём пишет.
Плюс в контексте акцента на размещении в облаках надо понимать, что "отдельные диски" в реальности там окажутся совсем не отдельными, и все вот эти советы по разнесению на диски надо по-хорошему пересматривать и перепроверять.
Да, транзакции сначала пишутся в файл транзакций. Только не при коммите, а именно в процессе обработки транзакции. Собственно, любое действие над БД начинается в памяти (в буфере), и потом фиксируется в файле транзакций, тем самым освобождая буфер.
Но сам процесс обработки каждой транзакции может быть очень длительным, к тому же одноврменно могут обрабатываться не одна, а несколько транзакций. Так что до момента коммита (или роллбэка) в файл транзакций может быть записано довольно много записей.
Кстати, с точки зрения механизмов СУБД сам коммит (или роллбэк) транзакции ничего особенного не делает — только снимает блокировки (а вот на чтение-запись не влияет никак).
А для файлов данных гораздо важнее скорость их считывания — но никак не записи. Их запись, вообще-то, асинхронно происходит. Планово. И довольно редко. Так что на скорость работы СУБД практически не влияет.
Насчет того, что изменения фиксируются в журнале еще до коммита транзакций, да Вы правы. Я очень коряво сформулировал. Насчет того, что запись в базу манее важна чем скорость чтения — это очень спорное утверждение, т.к. зависит от типа нагрузки на базу (OLAP/OLTP). Если в нашей OLTP-системе десятки тысяч меняющих запросов в секунду, в т.ч. массовых, затрагивающих не одну строчку и не одну таблицу, я не могу сказать, что скорость записи нам менее важна чем чтения )
Не учи физику в школе и твой мир всегда будет наполнен чудесами.
Статья неплохая, если поменять название. На чек-лист она не тянет.
Есть официальный чек-лист от 1С и он в 99% случаев работает
Check-list по настройке рабочих серверов в продукционной зоне
Выдача привилегии на Lock pages in memory может привести к тому, что в один прекрасный момент на сервере закончится память, а через диспетчер задач или другие инструменты мониторинга ресурсов вы даже не сможете понять, куда она делась. Только через Rammap можно будет что-то выяснить. Но далеко не все администраторы Windows про него знают и умеют пользоваться.
Поэтому я бы посоветовал обязательно документировать использование этого механизма.
Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дискахСтатья про чеклист для облаков. Если вы думаете что взяв в личном кабинете два «ssd» диска вы получите два физически разных ssd диска в своей виртуальной машине, то у меня для вас грустные новости, ибо все будет лежать на одной и той же СХД. Иначе это не облако, а дедикейтед сервер.
а для файла подкачки установить фиксированный размерпросто укажите стартовый размер в 512 мегабайт, а потолок равный двум объемам оперативной памяти. Если файл подкачки в процессе работы начинает расти, то по его размеру будет даже понятно какой недостаток памяти. В идеале он не должен начать расти.
ежедневную дефрагментацию индексовИспользуйте официальную терминологию: перестроить и/или реорганизовать. Отсебятина вредна.
а также полную реиндексацию не реже одного раза в неделюНачиная с 2016 SQL Server можно задать в плане обслуживания при каком проценте изменения индекса выполнять процедуры перестроения и реорганизации индекса в рамках одного задания. Скажем, если индекс протух на от 10 до 29% то делаем реорганизацию, если свыше 30% то перестроение. Если меньше 10 то вообще не трогаем. Очень удобно тем что процессы происходят по мере необходимости. Если база почти не изменяется, то смысл её ежедневно гонять из-за индексов, и полностью перечитывать на выходных?
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.Ох уже эти мифы из 90х, ну серьезно, они давно уже так не делают.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.Это две разных задачи. Если вы делаете бэкап всей VM то делайте его полностью, от и до. Бэкап баз средствами SQL это другой процесс, и два бэкапа лучше чем один. Есть технические окна для резервного копирования. Если таких окон нет, то проблему бэкапа и отказоустойчивости решают другими методами.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.Статья про облако. Что за чушь то :)
А еще в чеклисте не слова про настройку журнала операций 1С, при активной работе они принесут вам много сюрпризов.
А еще нет описания как пробросить физические ключи с площадки в облако.
А еще в чеклисте не слова про настройку журнала операций 1С, при активной работе они принесут вам много сюрпризов.
И про настройку программистов 1С, вот где поле непаханое-то для оптимизации. :)
Два диска будут лежать где угодно, но вот что ОС и ПО ВМ их будет считать разными — уже хорошо.
Потому что ОС, получив инструкции от ПО, может на одном диске включить кеширование, на другом — отключить (это как пример), и чем уламывать её кеш включать, проще два или более диска ей организовать. Тем более что в облаке мы платим только за место, но не за кол-во дисков.
А про бекап ВМ с СУБД отдельный момент стоит указать: поскольку у СУБД данные могут быть в памяти, но еще не оказаться корректно записанными на диск, то бекап методом мгновенного снимка дисков может дать нецелостное состояние файлов БД, со всеми вытекающими. Идеально еще на машине иметь агент от системы виртуализации, который прямо перед снапшотом «пнет» СУБД приготовиться к бекапу (скинуть на диск то, что нужно, и пр.) Это не всегда прямо говорится взлкх, но без подобного можно и удивиться потом при восстановлении.
у СУБД данные могут быть в памяти, но еще не оказаться корректно записанными на диск,
Ну, за все СУБД не скажу — а у MS SQL такое невозможно.
Первое действие, которое выполняется при изменении данных в базе — это запись в файл транзакций. Собственно, «метки оси времени» в этой СУБД учитываются в форме LSN (Log Sequence Number, номер записи в файле транзакций).
Это сделано специально: даже если «всё крахнет», данных с диска будет достаточно для корректного возобновления работы БД.
Даже запись в файл, если это не CoW, с его накладными расходами, может закончиться «ни там, ни здесь», и файл станет поврежденным/нечитаемым. И это ахилесова пята любого работающего с диском процесса (и если не сталкивались, то это, как говорится, просто везло). Так что лучше подумать о таковом заранее.
Ну и наоборот, не зря агенты систем виртуализации делаются же? Тем более что коммерческие СУБД они точно умеют готовить к бекапу.
(Вот с Postgresql чуть сложнее, но и там сходный подход. Зато производительность у PostgresPro Enterprise 1c на том же железе, как утверждается, выжимает большую производительность для 1с, так что есть смысл подразобраться)
про настройку журнала операций 1С
Что вы имеете в виду под «журналом операций 1С»?
Интересна эта тема?
Сравнение с MS SQL, режимы использования и настройка, использование в режимах выделенной инсталляции (dedicated/хостинг) и PaaS?
+ / -?
Экономика?
Что из этого больше интересует?
"Максимальная степень параллизма установить в 1".
Представьте что у вас сервер mssql 24 или больше ядер и всё это добро простаивает.
Так делать не надо. Поменяйте дефолтную стоимость запроса для его распараллеливания mssql с 5 до 50.
Называется "max degree of parallelism" (максимальный градус параллелизма).
Его дефолтное значение не менялось с 2000 или 2005 mssql. Сейчас в среднем раз в 10 больше будет вполне нормальным для erp и зуп.
(Если где то ошибся в цифрах поправьте меня, нет под рукой mssql)
О, уже вроде как технические специалисты любую сеть называют "облачком"? Как мы до этого дошли?
После тестов Гилева дальше читать не стал. Тест — раскрученный бренд, не более того. Код можно посмотреть, хоть он и закрыт, он поражает своей ненаправленностью, простотой и бестолковостью. Не верите и не хотите вскрывать код — сравните файловый режим и серверный на одном и том же железе. Получаем, что файловая работает в два раза быстрее! Проверка ожидания блокировок — нет, загрузка железа сервера 1с — нет, загрузка железа субд — нет, анализ задержек сети — нет.
Да, все так, как Вы пишете Но для упрощенных оценок вполне годится. Для инженерных оценок и сложных решений существуют другие инструменты. Они тоже упомянуты. Видели? Как они Вам? Удобно пользоваться? Легко развернуть и настроить? :)
Профи пишут собственные обработки (если не в курсе, так называются прикладные решения на платформе 1С, которые могут выполняться в большинстве конфигураций 1С, подробней: v8.1c.ru/platforma/obrabotka или здесь v8.1c.ru/platforma/vneshnie-obrabotki). Эти обработки имитируют реальные нагрузки, которые дают результаты тестирования с более высокой степенью достоверности и в контексте конкретной задачи.
Но, к сожалению, 90% «леди 1С» измеряют тестами Гилева все подряд, а потом утверждают, что размер имеет значение :) Мне было важно, чтобы «публика» задумалась и начала обсуждать эти и подобные проблемы, так как в современной ИТ-галактике нет абсолютно правильных решений, и истина рождается именно в таких обсуждениях)
вот нам последний раз червяк зашифровал все базы (файлы) и денег попросил.
а если бы он был включен — проблемы бы не было.
Здесь на хабре такие решения подробно разбирались. А также + / — такого подхода. Конечно, несколько контуров защиты всегда есть, как и регулярные бэкапы 3-2-1. Рекомендую делать бэкапы на инфраструктурном уровне, в СУБД и на уровне приложения (сама 1С умеет делать, включая регулярную выгрузку конфигурации — особенно ценно для «отката»/rollback, когда неосторожные разработчики что-то натворят или просто тестируют новую версию в продуктиве, но надо подстраховаться). Периодическая выгрузка-загрузка конфигурации также помогает решить еще несколько относительно полезных задач.
Советую прочитать
infostart.ru/public/1119557
www.1cbit.ru/blog/uskorenie-i-optimizatsiya-1s-kak-uskorit-rabotu-1s
а также
habr.com/ru/post/535662
Не хочу обидеть, но это был сарказм.
На фоне всей статьи, этот пункт — это как: отрежьте заключенному ноги, тогда он точно не убежит. А как же в туалет ходить? Будем носить его на руках, катать на каталке, приносить к нему утку.
У нас проблема была в потерянном времени, а мой вопрос: как обезопасить систему, на которой стоит mssql, а не базы, которые в нем. Ваш совет — отключить антивирус и делать бекапы (которые червь кстати также без проблем зашифрует, к примеру, если они были на подключённой шаре). И вот не надо про одностороннюю запись, про шифрование копий и прочее.
Вот теперь по возможности доброжелательно :) напишите, пожалуйста, что Вы хотели узнать, что интересует? Что надо решить, стоят задачи?
Мдаа... Кажется, радикально ускорить 1С можно только чем-то экстраординарным типа FPGA (пример: https://www.youtube.com/watch?v=63XgyHTlSS8&t=1173s)
Чек-лист по настройке инфраструктуры для повышения скорости работы 1С с MS SQL (особенно важно в облаках)