На мой взгляд массовое изменение объектных данных это разовая история как правило и инструменты которые её обычно выполняют (обработки вроде "Групповое изменение реквизитов" и регламентное "Отложенное обновление ИБ") даже пытаются в многопоточность.
Если это какой-то кастомный инструмент, то тут вопросы уже не к 1С.
Может быть кстати. Только на производительность это очень слабо влияет на мой взгляд если с индексами все в порядке. Если там scan через раз происходит, то да беда. Но не в объеме базы.
Я бы добавил, что тогда надо и SharedMemory включить не забыть.
Если MSSQL из коробки можно назначить конкретные ядра процессора которые она может использовать, то 1С в это не умеет без костылей. Тут можно достичь обратного эффекта. При этом проблема будет плавающая, что в двойне неприятно.
Но в малых системах конечно можно попробовать. В больших стоимость администрирование подобного становится дороже чем потратиться на ресурсы.
SQL Autoudpate statistic можно на малых системах, в больших может быть рост ожидания на блокировках схемы, т.к. обновление статистики накладывает блокировку на изменение схемы по объекту по которому пересчитывается статистика. Если такое происходит, то лучше пересчитывать статистику в плане обслуживания все таки.
В многопользовательском режиме при достаточно большом количестве пользователей 1С +/- эффективно использует (равномерно нагружает) все ядра при должной настройке.
Но некоторые вещи нельзя распараллелить и именно из-за них есть рекомендация при прочем равном пожертвовать количеством ядер в сторону частоты ядра в определенных случаях. Но тут все довольно индивидуально. Кому-то лучше будет больше ядер.
>Кроме этого, на производительность влияют : ... используемая редакция (ПРОФ/КОРП)
Каким образом? ПРОФ ограничен только количеством ядер, но проще и дешевле поднять в кластере еще один сервер с 12 ядрами, чем приобретать КОРП.
КОРП реально нужен только если у вас достаточно большое число пользователь и достаточно сложная структура. КОРП больше про управление, а не производительность. И если вы рассматриваете КОРП только для решения проблемы производительности, то с большой долей вероятности вы делаете что-то не так.
>Кроме этого, на производительность влияют: ... количество рабочих процессов, потребление памяти
Это действительно так. Но тут лучше не экспериментировать с параметрами рабочего процесса, а понимать как это работает и в чем конкретно причина проблем с производительностью и как её решить и почему именно так. А в статье было бы не плохо раскрыть этот вопрос.
С памятью тоже лучше исходить из понимания что именно происходит. Самая частая проблема это фрагментация памяти. И добавляй не добавляй плашки памяти это в целом проблему не решит. А вот обдуманный перезапуск рабочих процессов очень может даже поможет.
Уменьшить количество информационных баз на одном сервере
И каким образом это поможет?
Разделить данные на активные и архивные на уровне 1С
Совершенно не понимаю что тут имеется в виду. Можно более подробнее раскрыть суть?
Если у вас проблему производительности, то лучше для начала понять в чем конкретно причина, где узкое место и уже исходя из этого знания планировать осознанное решение. А не экспериментировать с настройками и архитектурой авось что-то получится. Но чтобы понять причину первое что нужно сделать это настроить мониторинг всего этого хозяйства. О чем в статье ни слова.
Программная лицензия в 99% случаев нет. Аппаратной всё равно.
Но надо понимать, что программная лицензия привязывается к конкретной машине на которой она установлена. Поэтому иногда лучше под сервис лицензирования выделить отдельную виртуалку с постоянными параметрами и с неё раздавать лицензии app-серверам. При такой схеме конфигурацию app-серверов можно будет безболезненно изменять.
Будет реализовано за счет угрозы потери данных, что очень рискованное решение на мой взгляд. По опыту перетаскивание файловой БД с HDD на SSD, потом на NVMe очень не надолго дает отсрочку от принятия решения к переезду на SQL. Полгода-год. Мое мнение, что овчинка не стоит выделки надо решать проблему радикально.
Если мне память не изменяет, то 1Совские блокировки и так хранятся в памяти соответствующего менеджера кластера.
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера >на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков. Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
Конечно bare metal. Процентов на 10%. Можно еще 1С кластер и СУБД не разносить и поставить на одной физической машине -- за счет shared memory еще процентов 10-20% можно будет выиграть. Только вот при резком росте нагрузки это не поможет. А вот управляемость, стоимость эксплуатации, отказоустойчивость, скорость восстановления и прочее, прочее сильно пострадают.
На мой взгляд лучше использовать виртуалки и при кратном росте нагрузок увеличивать их ресурсы и/или думать как масштабировать систему чтобы пережить пик.
А зачем? Если только файловая БД, но это история не про средние и большие нагрузки. В клиент-серверном варианте и так оперативные данные БД в оперативке в кэше.
Что у 1С (не СУБД) требовательно к I/O я вот так сходу даже придумать не могу. Сеансовые данные разве что, но они и так мапятся в RAM.
Еще стоит отметить, что под каждую версию платформы придется поднимать отдельный экземпляр сервера 1С на сервер лицензирования соответствующей версии. Если у вас зоопарк платформ, то 4Gb RAM далеко не факт что хватит.
О том где размещать серверные лицензии вопрос дискуссионный. 1С рекомендует непосредственно на машине где запущен сервер. Т.к. с сервиса лицензирования лицензию может утащить любой, то могут быть неприятные ситуации. Но тут все индивидуально конечно.
Если есть куда упрощать, то значит она не простая. Что она сложнее жизни других разработчиков никто вроде не говорил, но согласитесь, что на мероприятии для разработчиков 1С было бы странно упрощать жизнь разработчикам не 1С. Полагаю всегда могут найтись разработчики 1С которые хотят упростить себе жизнь. Например я. Нет.
Если вам нужны условные частные сети в государственных целях, то со всеми необходимыми руководствами сможете ознакомиться в секретной части при условии, что у вас есть соответствующий доступ конечно же.
Поддержу. С франчи рулетка какая-то. То нормальный код, местами даже классный, то спагетти-код приправленный вышеописанными ужасами вроде запросов в цикле. При том это может встречаться в рамках одной задачи.
Я так и не понял что такого натворили пользователи, что все дружно должны страдать. Напомните пожалуйста в чьих интересах вроде как должен действовать контроль за финансово-кредитными организациями со стороны ЦБ РФ?
На мой взгляд массовое изменение объектных данных это разовая история как правило и инструменты которые её обычно выполняют (обработки вроде "Групповое изменение реквизитов" и регламентное "Отложенное обновление ИБ") даже пытаются в многопоточность.
Если это какой-то кастомный инструмент, то тут вопросы уже не к 1С.
https://habr.com/ru/companies/1c/articles/761012/
Может быть кстати. Только на производительность это очень слабо влияет на мой взгляд если с индексами все в порядке. Если там scan через раз происходит, то да беда. Но не в объеме базы.
Я бы добавил, что тогда надо и SharedMemory включить не забыть.
Если MSSQL из коробки можно назначить конкретные ядра процессора которые она может использовать, то 1С в это не умеет без костылей. Тут можно достичь обратного эффекта. При этом проблема будет плавающая, что в двойне неприятно.
Но в малых системах конечно можно попробовать. В больших стоимость администрирование подобного становится дороже чем потратиться на ресурсы.
SQL Autoudpate statistic можно на малых системах, в больших может быть рост ожидания на блокировках схемы, т.к. обновление статистики накладывает блокировку на изменение схемы по объекту по которому пересчитывается статистика. Если такое происходит, то лучше пересчитывать статистику в плане обслуживания все таки.
В многопользовательском режиме при достаточно большом количестве пользователей 1С +/- эффективно использует (равномерно нагружает) все ядра при должной настройке.
Но некоторые вещи нельзя распараллелить и именно из-за них есть рекомендация при прочем равном пожертвовать количеством ядер в сторону частоты ядра в определенных случаях. Но тут все довольно индивидуально. Кому-то лучше будет больше ядер.
А что именно вы хотите распараллелить в транзакционной системе?
Каким образом? ПРОФ ограничен только количеством ядер, но проще и дешевле поднять в кластере еще один сервер с 12 ядрами, чем приобретать КОРП.
КОРП реально нужен только если у вас достаточно большое число пользователь и достаточно сложная структура. КОРП больше про управление, а не производительность. И если вы рассматриваете КОРП только для решения проблемы производительности, то с большой долей вероятности вы делаете что-то не так.
Это действительно так. Но тут лучше не экспериментировать с параметрами рабочего процесса, а понимать как это работает и в чем конкретно причина проблем с производительностью и как её решить и почему именно так. А в статье было бы не плохо раскрыть этот вопрос.
С памятью тоже лучше исходить из понимания что именно происходит. Самая частая проблема это фрагментация памяти. И добавляй не добавляй плашки памяти это в целом проблему не решит. А вот обдуманный перезапуск рабочих процессов очень может даже поможет.
И каким образом это поможет?
Совершенно не понимаю что тут имеется в виду. Можно более подробнее раскрыть суть?
Если у вас проблему производительности, то лучше для начала понять в чем конкретно причина, где узкое место и уже исходя из этого знания планировать осознанное решение. А не экспериментировать с настройками и архитектурой авось что-то получится. Но чтобы понять причину первое что нужно сделать это настроить мониторинг всего этого хозяйства. О чем в статье ни слова.
Программная лицензия в 99% случаев нет. Аппаратной всё равно.
Но надо понимать, что программная лицензия привязывается к конкретной машине на которой она установлена. Поэтому иногда лучше под сервис лицензирования выделить отдельную виртуалку с постоянными параметрами и с неё раздавать лицензии app-серверам. При такой схеме конфигурацию app-серверов можно будет безболезненно изменять.
Будет реализовано за счет угрозы потери данных, что очень рискованное решение на мой взгляд. По опыту перетаскивание файловой БД с HDD на SSD, потом на NVMe очень не надолго дает отсрочку от принятия решения к переезду на SQL. Полгода-год. Мое мнение, что овчинка не стоит выделки надо решать проблему радикально.
Если мне память не изменяет, то 1Совские блокировки и так хранятся в памяти соответствующего менеджера кластера.
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера
>на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
Конечно bare metal. Процентов на 10%. Можно еще 1С кластер и СУБД не разносить и поставить на одной физической машине -- за счет shared memory еще процентов 10-20% можно будет выиграть. Только вот при резком росте нагрузки это не поможет. А вот управляемость, стоимость эксплуатации, отказоустойчивость, скорость восстановления и прочее, прочее сильно пострадают.
На мой взгляд лучше использовать виртуалки и при кратном росте нагрузок увеличивать их ресурсы и/или думать как масштабировать систему чтобы пережить пик.
А зачем? Если только файловая БД, но это история не про средние и большие нагрузки. В клиент-серверном варианте и так оперативные данные БД в оперативке в кэше.
Что у 1С (не СУБД) требовательно к I/O я вот так сходу даже придумать не могу. Сеансовые данные разве что, но они и так мапятся в RAM.
Еще стоит отметить, что под каждую версию платформы придется поднимать отдельный экземпляр сервера 1С на сервер лицензирования соответствующей версии. Если у вас зоопарк платформ, то 4Gb RAM далеко не факт что хватит.
О том где размещать серверные лицензии вопрос дискуссионный. 1С рекомендует непосредственно на машине где запущен сервер. Т.к. с сервиса лицензирования лицензию может утащить любой, то могут быть неприятные ситуации. Но тут все индивидуально конечно.
Сегодня как раз читал статью по этой теме. Ссылку оставлять не буду, но гуглится по "Фабрика накруток. Как vk превращает рунет в телевизор"
Писать на почту на яндексе и выразить желание взломать государство? Дайте подумать...
Если есть куда упрощать, то значит она не простая. Что она сложнее жизни других разработчиков никто вроде не говорил, но согласитесь, что на мероприятии для разработчиков 1С было бы странно упрощать жизнь разработчикам не 1С. Полагаю всегда могут найтись разработчики 1С которые хотят упростить себе жизнь. Например я. Нет.
Если вам нужны условные частные сети в государственных целях, то со всеми необходимыми руководствами сможете ознакомиться в секретной части при условии, что у вас есть соответствующий доступ конечно же.
Поддержу. С франчи рулетка какая-то. То нормальный код, местами даже классный, то спагетти-код приправленный вышеописанными ужасами вроде запросов в цикле. При том это может встречаться в рамках одной задачи.
Я так и не понял что такого натворили пользователи, что все дружно должны страдать. Напомните пожалуйста в чьих интересах вроде как должен действовать контроль за финансово-кредитными организациями со стороны ЦБ РФ?
Загляните в расчет себестоимости при закрытии месяца в типовой бухгалтерии например.