Pull to refresh

Comments 34

  1. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
    В этом случае работа с файлами может идти не последовательно, а практически параллельно

Простите, что?

Тут речь немного о другом. При коммите транзакции sql server обязан сначала записать данные в файл журнала транзакций (без кеширования/буферизации), а только потом в mdf файл (при этом допустимо кэширование, тк в файл журнала данные уже записаны и по журналу можно "дозавершить" транзакцию в случае внезапного отключения питания, например если mdf окажется "недозаписанным"). Когда файл журнала находится на отдельном диске, запись в него может пройти быстрее, тк отложенная запись в mdf от других транзакций не влияет на очередь того диска, на котором находится ldf

Чем вызван сам совет, я знаю. Но то, как это мотивирует автор, вызывает сомнения в том, насколько он понимает, о чём пишет.


Плюс в контексте акцента на размещении в облаках надо понимать, что "отдельные диски" в реальности там окажутся совсем не отдельными, и все вот эти советы по разнесению на диски надо по-хорошему пересматривать и перепроверять.

В огороде бузина, а в Киеве дядька.

Да, транзакции сначала пишутся в файл транзакций. Только не при коммите, а именно в процессе обработки транзакции. Собственно, любое действие над БД начинается в памяти (в буфере), и потом фиксируется в файле транзакций, тем самым освобождая буфер.
Но сам процесс обработки каждой транзакции может быть очень длительным, к тому же одноврменно могут обрабатываться не одна, а несколько транзакций. Так что до момента коммита (или роллбэка) в файл транзакций может быть записано довольно много записей.
Кстати, с точки зрения механизмов СУБД сам коммит (или роллбэк) транзакции ничего особенного не делает — только снимает блокировки (а вот на чтение-запись не влияет никак).

А для файлов данных гораздо важнее скорость их считывания — но никак не записи. Их запись, вообще-то, асинхронно происходит. Планово. И довольно редко. Так что на скорость работы СУБД практически не влияет.

Насчет того, что изменения фиксируются в журнале еще до коммита транзакций, да Вы правы. Я очень коряво сформулировал. Насчет того, что запись в базу манее важна чем скорость чтения — это очень спорное утверждение, т.к. зависит от типа нагрузки на базу (OLAP/OLTP). Если в нашей OLTP-системе десятки тысяч меняющих запросов в секунду, в т.ч. массовых, затрагивающих не одну строчку и не одну таблицу, я не могу сказать, что скорость записи нам менее важна чем чтения )

Если человек не дочитает статью до пункта 9, то начальное упоминание про priority boost подталкивает на бездумное включение может подпортить жизнь.

Boost priority вообще не нужно использовать после 2008й версии sql server. Эта опция deprecated и оставлена только для обратной совместимости при апгрейде на более свежие версии. Сам Майкрософт так говорит.

Вспоминается…
Не учи физику в школе и твой мир всегда будет наполнен чудесами.
Статья неплохая, если поменять название. На чек-лист она не тянет.
Есть официальный чек-лист от 1С и он в 99% случаев работает
Check-list по настройке рабочих серверов в продукционной зоне

Выдача привилегии на Lock pages in memory может привести к тому, что в один прекрасный момент на сервере закончится память, а через диспетчер задач или другие инструменты мониторинга ресурсов вы даже не сможете понять, куда она делась. Только через Rammap можно будет что-то выяснить. Но далеко не все администраторы Windows про него знают и умеют пользоваться.
Поэтому я бы посоветовал обязательно документировать использование этого механизма.

Статьи по 1С всегда холиварны, «всегда найдется китаец это делает лучше тебя» :)

Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (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С»?
моя неточность, каюсь.

Администрирование — Поддержка и обслуживание — Журнал регистрации

Все то, что по умолчанию лежит в
C:\Program Files\1cv8\srvinfo\reg_1541\[GUID]
Если честно я ожидал в статье про 1С в облаках описание решения, когда реализуется виртуалка с сервером 1С, а база лежит в каком нить DBaaS.
Спасибо за хорошую идею. Постараюсь написать в ближайшее время. У меня собирается материал по использованию Postgres Pro с 1С.
Интересна эта тема?
Сравнение с MS SQL, режимы использования и настройка, использование в режимах выделенной инсталляции (dedicated/хостинг) и PaaS?
+ / -?
Экономика?
Что из этого больше интересует?
Начните с банального. Вот как ставить 1С и MSSQL на сервер мы все знаем.
А как мне поставить 1С и подключить к облачной базе данных? А на примере отечественных провайдеров? Каковы затраты, на что обращать внимание? Как экономить на таких серверах?
Еще раз спасибо за идеи, постараюсь сделать в ближайшее время. Смерть выходным :)

Если 1с у тебя онпрем, а база в облаке, то с получившимся латенси на ввод-вывод оно всё будет тааааак тормозить.

Дык разговор то про 1С сервер в облаке и инстанс дб тоже в том же облаке. А до 1С rdp или веб у клиентов.
Перепечатка документации от фирмы 1с. Таким на инфостарте баловались. Теперь и тут?

"Максимальная степень параллизма установить в 1".
Представьте что у вас сервер mssql 24 или больше ядер и всё это добро простаивает.


Так делать не надо. Поменяйте дефолтную стоимость запроса для его распараллеливания mssql с 5 до 50.
Называется "max degree of parallelism" (максимальный градус параллелизма).


Его дефолтное значение не менялось с 2000 или 2005 mssql. Сейчас в среднем раз в 10 больше будет вполне нормальным для erp и зуп.


(Если где то ошибся в цифрах поправьте меня, нет под рукой mssql)

Случайно продублировал название того же параметра.
Правильно: «Стоимостной порог для параллелизма». Его нужно менять, а «Максимальная степень параллизма» ни в коем случае не надо делать в 1. Только обдуманно.
(Хабр не дал исправить коммент, поэтому исправляюсь во втором)

О, уже вроде как технические специалисты любую сеть называют "облачком"? Как мы до этого дошли?

А какие облачка существуют? Публичные, частные, домашние...? Да, этим термином многие «накрывают» целые инфраструктуры, корпоративную виртуализацию с сервисами vCloud Director или аналогичными, а некоторые даже свою «домашнюю» платформу, например, типа NextCloud :)
Что для Вас облако?

После тестов Гилева дальше читать не стал. Тест — раскрученный бренд, не более того. Код можно посмотреть, хоть он и закрыт, он поражает своей ненаправленностью, простотой и бестолковостью. Не верите и не хотите вскрывать код — сравните файловый режим и серверный на одном и том же железе. Получаем, что файловая работает в два раза быстрее! Проверка ожидания блокировок — нет, загрузка железа сервера 1с — нет, загрузка железа субд — нет, анализ задержек сети — нет.

Спасибо за Ваш комментарий. Действительно, тест достаточно упрощенный. Это знают все «1С-ники»: «тест в попугаях, служит для относительной оценки, например, поменял диски или настройки железа сервака и посмотрел, как это повлияло на производительность...».
Да, все так, как Вы пишете Но для упрощенных оценок вполне годится. Для инженерных оценок и сложных решений существуют другие инструменты. Они тоже упомянуты. Видели? Как они Вам? Удобно пользоваться? Легко развернуть и настроить? :)
Профи пишут собственные обработки (если не в курсе, так называются прикладные решения на платформе 1С, которые могут выполняться в большинстве конфигураций 1С, подробней: v8.1c.ru/platforma/obrabotka или здесь v8.1c.ru/platforma/vneshnie-obrabotki). Эти обработки имитируют реальные нагрузки, которые дают результаты тестирования с более высокой степенью достоверности и в контексте конкретной задачи.
Но, к сожалению, 90% «леди 1С» измеряют тестами Гилева все подряд, а потом утверждают, что размер имеет значение :) Мне было важно, чтобы «публика» задумалась и начала обсуждать эти и подобные проблемы, так как в современной ИТ-галактике нет абсолютно правильных решений, и истина рождается именно в таких обсуждениях)
пункт 3. встроенный в винду тоже отключать? в частности тот, который видит воздействие приложений на файлы.
вот нам последний раз червяк зашифровал все базы (файлы) и денег попросил.
а если бы он был включен — проблемы бы не было.
Никого не хочу обидеть, но написано «для опытных админов» :)
Здесь на хабре такие решения подробно разбирались. А также + / — такого подхода. Конечно, несколько контуров защиты всегда есть, как и регулярные бэкапы 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, а не базы, которые в нем. Ваш совет — отключить антивирус и делать бекапы (которые червь кстати также без проблем зашифрует, к примеру, если они были на подключённой шаре). И вот не надо про одностороннюю запись, про шифрование копий и прочее.

Давайте попробую ответить еще более доброжелательно, так как Вы же потратили время на чтение и коммент к этой странной статье?:) Как и чем защищать, Вы лучше меня знаете. Но мне показалось, что что-то Вам таки было важно найти, но, вероятно, не нашли в этом опусе?
Вот теперь по возможности доброжелательно :) напишите, пожалуйста, что Вы хотели узнать, что интересует? Что надо решить, стоят задачи?
Only those users with full accounts are able to leave comments. Log in, please.