Мне всегда любопытно было откуда берутся эти цифры 25% , 30% ?
Это просто некая величина, возможно даже подходящая многим - средняя по больнице, которую переносят из статьи в статью )). Но мы ее рассматриваем лишь как точку старта(!). А далее анализируем профиль нагрузки в части доли использования дисковой подсистемы при выполнении запросов. Для этого используем Perfexpert, т.к. в нем есть и счетчик Cache hit ratio, и трассы тяжелых запросов.
Процитирую кусок статьи:
Shared_buffers. После выбора первоначального значения оцениваем вероятностное попадание данных в кэш с помощью счетчика Cache hit ratio. Увеличиваем память, если показания счетчика часто опускаются ниже 80%. Дополнительно оцениваем в трассах тяжелых запросов те, которые больше всего «выгрызают» данных с диска и пытаемся их оптимизировать.
Не сталкивались, потому что им легко управлять. Обычно ставят 30% от ОЗУ - по умолчанию, поэтому у клиентов изначально такой проблемы быть не может. Далее из анализа это значение можно скорректировать.
Речь идет о блокировках на автообновлении статистик (на скрине видно). Новые еще не пересчитаны, а старые использовать нельзя. Они кратковременные. Аналогичное поведение и в MS - https://habr.com/ru/companies/softpoint/articles/823250/
Это и имелось в виду, возможно как-то не очевидно написано. Речь, конечно же про отдельные операции в запросе. Про work_mem будет подробный разбор в следующей серии. В том числе кейсы, когда значение work_mem выбрано слишком маленькое и, наоборот, слишком большое.
Почему же именно бухгалтерии и почему сотен гигабайт? 1С - это далеко не только бухгалтерия. А сотни гигабайт - это, наверное, тот минимальный размер БД, с которым к нам обращаются. Более того, в своей практике мы все чаще оперируем терабайтными базами с терабайтным приростом в год.
За 1С мы конечно же ответить не можем, но со своей стороны постоянно расширяем функционал мониторинга для анализа работы и производительности систем 1С на PostgreSQL и готовим интересные статьи на эту тематику. Подписывайтесь, чтобы не пропустить.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?
Если вы имеете в виду rowversion как колонку, показывающую версию изменений, то это не вариант. DB Replication не производит структурных изменений в БД.
Мы (Софтпоинт) не переписывали конфигурацию. Мы обеспечили бесшовный переход и страховочный мостик. Адаптацию кода заказчик взял полностью на себя - см. этап 2.
Приведенная в статье статистика собрана, обработана и выведена в пользовательском интерфейсе с помощью программы мониторинга Perfexpert. Кроме того, эта статистика сразу обогащена данными из 1С:Предприятие - именами пользователей, потреблением ресурсов, строками кода и т.п. В SQL Server Managment Studio в подобном виде статистики нет.
Для того, чтобы проанализировать статистику по блокировкам штатными средствами можно воспользоваться несколькими вариантами:
Точную сумму длительностей ожиданий логических блокировок можно увидеть из стандартного трассировщика MS SQL или с использованием технологии Extended Events.
Природу блокировки и деревья блокировок можно получить из системных представлений MS SQL и системных таблиц. (sysprocesses и прочее).
Блокировки и взаимоблокировки в секунду на сервере MS SQL можно посмотреть из счетчиков MS SQL: locks/s , deadlocks/s. Также из других счетчиков можно увидеть ожидания на "нелогических" блокировках, например на системе ввода вывода, работы с памятью и прочее.
Правильное дополнение, но цель статьи несколько другая - рассказать про виды блокировок, наиболее часто встречающиеся в системах 1С:Предприятие, для помощи в анализе проблем производительности. Если рассматривать методику и ход действий специалистов при анализе проблем блокировок, то одним из первых шагов будет ваше дополнение. Спасибо. Возможно, имеет смысл написать отдельную статью.
Отчего же, используем. Но это уже этап, когда нет возможности увидеть целиком проблему в мониторинге. Кроме того, он требует моделирования конкретных действий пользователя и программы, что не всегда возможно в тестовой среде, например, в силу интеграционных моментов.
Это транзакционная репликация, целостность и консистентность данных в баз-получателе, конечно, обеспечивается. Накатывание очереди может осуществлять как в один поток, так и многопоточно.
Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.
Это просто некая величина, возможно даже подходящая многим - средняя по больнице, которую переносят из статьи в статью )). Но мы ее рассматриваем лишь как точку старта(!). А далее анализируем профиль нагрузки в части доли использования дисковой подсистемы при выполнении запросов. Для этого используем Perfexpert, т.к. в нем есть и счетчик Cache hit ratio, и трассы тяжелых запросов.
Процитирую кусок статьи:
Не сталкивались, потому что им легко управлять. Обычно ставят 30% от ОЗУ - по умолчанию, поэтому у клиентов изначально такой проблемы быть не может. Далее из анализа это значение можно скорректировать.
Речь идет о блокировках на автообновлении статистик (на скрине видно). Новые еще не пересчитаны, а старые использовать нельзя. Они кратковременные.
Аналогичное поведение и в MS - https://habr.com/ru/companies/softpoint/articles/823250/
Это и имелось в виду, возможно как-то не очевидно написано. Речь, конечно же про отдельные операции в запросе. Про work_mem будет подробный разбор в следующей серии. В том числе кейсы, когда значение work_mem выбрано слишком маленькое и, наоборот, слишком большое.
Почему же именно бухгалтерии и почему сотен гигабайт?
1С - это далеко не только бухгалтерия. А сотни гигабайт - это, наверное, тот минимальный размер БД, с которым к нам обращаются. Более того, в своей практике мы все чаще оперируем терабайтными базами с терабайтным приростом в год.
Разбиение файлов tempDB конечно должно быть обязательным, здесь противоречий нет. Но оно не поможет при росте лога, а влияет на вероятность появления блокировок. В предыдущей статье как раз разбирал эту ситуацию: Записки оптимизатора (часть 7). «Нелогичные» блокировки MS SQL для систем 1С предприятия.
За 1С мы конечно же ответить не можем, но со своей стороны постоянно расширяем функционал мониторинга для анализа работы и производительности систем 1С на PostgreSQL и готовим интересные статьи на эту тематику. Подписывайтесь, чтобы не пропустить.
В целом, почти у любой задачи всегда есть несколько вариантов решения. Но, как вы можете понять из заголовка статьи, основная идея для её написания не в том, как вы говорите – "вылечить базу", а в том, как без прерывания работы пользователей в этой базе, объём данных которой составляет несколько терабайт, повысить версию платформы и без режима совместимости с её архаичными версиями. Учитывая сказанное, и представив, что проблем с хранением данных нет, для терабайтной базы, фактически, без технологического окна, предложенная в статье методика замены платформы 1С вызывает интерес нестандартным подходом?
Уже.
Прототип готов, включая систему мониторинга. Вот здесь есть раздел, посвященный этой задаче: Миграция с MSSQL Server на PostgreSQL. Предпосылки
Используется режим управляемых блокировок
Платформа 1С не терпит изменений в ее таблицах, а триггеры можно.
Если вы имеете в виду
rowversionкак колонку, показывающую версию изменений, то это не вариант. DB Replication не производит структурных изменений в БД.Да, можно и, наверное, нужно, указать для каждого оператора. Но в этом случае сделано было так.
Мы (Софтпоинт) не переписывали конфигурацию. Мы обеспечили бесшовный переход и страховочный мостик. Адаптацию кода заказчик взял полностью на себя - см. этап 2.
Запустить можно, но все в том же режиме совместимости. Т.е. ничего не изменится.
Ответил ниже, промахнулся с кнопкой.
Приведенная в статье статистика собрана, обработана и выведена в пользовательском интерфейсе с помощью программы мониторинга Perfexpert. Кроме того, эта статистика сразу обогащена данными из 1С:Предприятие - именами пользователей, потреблением ресурсов, строками кода и т.п. В SQL Server Managment Studio в подобном виде статистики нет.
Для того, чтобы проанализировать статистику по блокировкам штатными средствами можно воспользоваться несколькими вариантами:
Точную сумму длительностей ожиданий логических блокировок можно увидеть из стандартного трассировщика MS SQL или с использованием технологии Extended Events.
Природу блокировки и деревья блокировок можно получить из системных представлений MS SQL и системных таблиц. (sysprocesses и прочее).
Блокировки и взаимоблокировки в секунду на сервере MS SQL можно посмотреть из счетчиков MS SQL: locks/s , deadlocks/s. Также из других счетчиков можно увидеть ожидания на "нелогических" блокировках, например на системе ввода вывода, работы с памятью и прочее.
Правильное дополнение, но цель статьи несколько другая - рассказать про виды блокировок, наиболее часто встречающиеся в системах 1С:Предприятие, для помощи в анализе проблем производительности.
Если рассматривать методику и ход действий специалистов при анализе проблем блокировок, то одним из первых шагов будет ваше дополнение. Спасибо.
Возможно, имеет смысл написать отдельную статью.
Отчего же, используем. Но это уже этап, когда нет возможности увидеть целиком проблему в мониторинге. Кроме того, он требует моделирования конкретных действий пользователя и программы, что не всегда возможно в тестовой среде, например, в силу интеграционных моментов.
Это транзакционная репликация, целостность и консистентность данных в баз-получателе, конечно, обеспечивается. Накатывание очереди может осуществлять как в один поток, так и многопоточно.
Lob-значения, хранящиеся в таблицах 1С, мы успешно передаём. Причем в некоторых системах LOB-трафик занимает очень большую часть всего репликационного трафика.