Описание методики резервного копирования баз данных MS SQL Server по схеме дед-отец-сын и набор скриптов для ее реализации. Разработана для баз 1С, но подходит для любых.
Кстати, статья изменилась, мне кажется, раньше там было меньше букв.
Привожу здесь интересующие нас выдержки:
Безопасный расход памяти за один вызов
Примечание. Доступно только для лицензии КОРП. Подробнее о видах лицензий см. здесь.
Объем памяти в байтах, использование которого в процессе вызова сервера считается безопасным.
Может принимать значение от -1 до 9 223 372 036 854 775 807:
● -1 ‑ любой вызов сервера считается опасным, если за время вызова сервера объем памяти, занятый процессами кластера (рабочих процессов и менеджеров кластера), достигает используемого значения свойства Временно допустимый объем памяти процессов;
● 0 ‑ значение объема определяется автоматически, как 10% от используемого значения параметра Временно допустимый объем памяти процессов.
Временно допустимый объем памяти процессов
Определяет размер временно допустимого объема оперативной памяти, занятой рабочими процессами и менеджерами кластера (процессами кластера) на настраиваемом рабочем сервере, в байтах. Если объем памяти, потребляемой процессами кластера, превышает значение параметра, то система считает, что у данного рабочего сервера снижается производительность и на него больше не следует назначать новые соединения с информационными базами.
Данное значение используется для контроля над объемом памяти, которое используют рабочие процессы в целом и отдельный серверный вызов в частности:
● Контроль над памятью рабочих процессов.
Если параметр Временно допустимый объем памяти процессов оставался превышенным на время большее, чем указано в параметре Интервал превышения временно допустимого объема памяти процессов (параметр должен иметь значение большее 0), то начинается перезапуск рабочих процессов данного рабочего сервера. Перезапуск выполняется, начиная с рабочего процесса, потребляющее максимальное количество памяти в порядке уменьшения объема потребляемой оперативной памяти. При этом процесс перезапуска будет прекращен тогда, когда сумма потребляемой памяти оставшимися процессами кластера станет меньше или равна параметру Временно допустимый объем памяти процессов.
Во время перезапуска сеансы, обслуживаемые рабочими процессами, которые выбраны для завершения, переназначаются на другие рабочие процессы. Рабочий процесс будет завершен только после того, как он перестал обслуживать сеансы клиентских соединений.
● Контроль над памятью серверного вызова.
Каждый рабочий процесс кластера определяет объем памяти, занимаемой процессами кластера на этом рабочем сервере (назовем это значение ПамятьПроцессов). ПамятьПроцессов обновляется один раз в две секунды.
При начале вызова сервера фиксируется текущее значение ПамятьПроцессов на момент начала вызова (назовем это значение ПамятьПроцессовТекущая) и вычисляется разность значения Временно допустимый объем памяти процессов и значения ПамятьПроцессовТекущая (назовем это значение ПределПамятиЗаВызов). Если значение ПределПамятиЗаВызов получилось меньше значения Безопасный расход памяти за один вызов, то значением ПределПамятиЗаВызов становится значение Безопасный расход памяти за один вызов.
В процессе выполнения вызова вычисляется объем памяти, израсходованной при выполнении этого вызова (назовем это значение ПамятьЗаВызов).
Если в результате выделения памяти в одном вызове сервера значение ПамятьЗаВызов превышает значение ПределПамятиЗаВызов, то вызов прерывается исключением и завершается аварийно. При этом в технологический журнал выводится событие EXCP, содержащее:
● Текст исключения;
● Контекст исключения.
Параметр может принимать значение от -1 до 9 223 372 036 854 775 807:
● -1 ‑ временно допустимый объем памяти, доступный процессам кластера на данном рабочем сервере, не ограничен;
● 0 ‑ в качестве временно допустимого объема памяти процессов кластера на данном рабочем сервере используется значение по умолчанию:
● Для контроля над памятью рабочих процессов ‑ 70% объема оперативной памяти сервера.
● Для контроля над памятью серверного вызова ‑ 80% объема оперативной памяти сервера.
Значение по умолчанию равно 0.
Раньше я делал вывод, что максимальный расход памяти одного серверного вызова составит 10% от 80%, то есть 8% всей оперативной памяти сервера.
Сейчас можно прикинуть подробнее. Допустим, у нас на сервере 64Гб памяти, тогда Временно допустимый объем памяти процессов составит примерно 51Гб и Безопасный расход памяти за один вызов примерно 5Гб. Допустим, сервер 1С недавно перезапустили, на нем существует 1 рабочий процесс, который потребляет 1Гб. Тогда ПамятьПроцессов у нас будет 1, ПамятьПроцессовТекущая тоже 1, отнимаем от 51Гб 1, получаем ПределПамятиЗаВызов, равный 50Гб. 50Гб больше, чем 5Гб, поэтому ПределПамятиЗаВызов остается 50Гб.
Если же на сервере 16Гб, и на каждую ИБ выделен 1 процесс, что, кстати, 1С не рекомендует делать в другой статье (, так как "значительное число процессов rphost приводит к неэффективному использованию памяти процессами кластера", и все эти процессы потребляют уже сейчас 12Гб, тогда:
- Временно допустимый объем памяти процессов = 12,2Гб
- Безопасный расход памяти за один вызов = 1,2Гб
- ПамятьПроцессовТекущая = 12Гб
- 12,2 - 12 = 0.2, это меньше, чем 1.2, тогда ПределПамятиЗаВызов = 1.2Гб
Так что при прочтении текущей версии статьи выходит, что при наличии большого количества свободной оперативной памяти каждый серверный вызов может потребить количество памяти, значительно превышающее 8% ее объема, а когда свободной памяти остается мало, тогда этот параметр (Безопасный расход памяти за один вызов) начинает работать.
Вы можете провести свои собственные расчеты, взяв за основу реальные данные Вашего сервера, текущей и средней нагрузки на него.
Если Вы можете использовать настройку 1 ИБ на процесс, значит, используете лицензию КОРП, в этом случае можно поставить все эти параметры в -1 (ничего не ограничивать) и повторить эксперимент. Если процессы перестанут падать, дело в памяти, если продолжат, нужно искать другую причину.
Если речь идет о серверном варианте работы без использования лицензий КОРП, то есть настройки кластера могут быть только стандартными, максимальная память, выделенная одному процессу RPHOST, составляет 8% оперативной памяти сервера 1С. Кто не верит, не устраивайте холивар здесь, пишите в личку, обсудим. Поэтому при выполнении обменов, формировании масштабных отчетов и других ресурсоемких операциях память рабочего процесса может быть превышена на значительно большее время, чем задано в настройках кластера, а их поменять без лицензии КОРП нельзя. Поэтому вариантов обычно два - или выделять серверу 1С значительно больше памяти, чем ему на самом деле требуется, или разбивать масштабные операции на порции поменьше.
Платформа какая? Если 32 бита, возможно превышение максимального объема памяти процессом rphost, лечится только переходом на платформу x64 или разбивкой обмена на мелкие порции.
(1) Ничего хорошего не будет, я думаю. Скрипт не для этого предназначен. У нас тестовые базы создаются из бэкапов рабочих средствами SQL, и в них структура хранения одинаковая, поэтому конфигурации можно гонять через CF или через хранилище, в том числе автоматически с помощью OneScript. Мой скрип для решения частной задачи - только для копирования структуры хранения, когда нет возможности (времени или места) восстановить полную копию базы из бэкапа.
Описание методики резервного копирования баз данных MS SQL Server по схеме дед-отец-сын и набор скриптов для ее реализации. Разработана для баз 1С, но подходит для любых.
Готов помочь, но нужно смотреть нюансы, пишите лично.
Нет времени делать публикацию, но есть решение на SQL для ежедневного резервного копирования баз 1С с хранением истории, есть скрипты и хранилки для развертывания этих бэкапов в базы для разработчиков. Модифицировать это все под Ваш случай не вижу проблем.
Ну и, как писали раньше, есть варианты с AlwaysOn, зеркалированием или доставкой журналов транзакций, они тоже рабочие. От инфраструктуры и лицензий SQL сильно зависит выбор решения, также от модели восстановления Ваших баз.
Проблема не в Shared Memory, для работы которой достаточно на сервере 1С при подключении базы указать localhost в качестве имени сервера SQL. Записи в hosts у клиентов нужны для другого - в файлах конфигурации кластера 1С указано имя сервера, и он периодически сам к себе обращается по этому имени.
Можно начать с простого - сделать в hosts 2 записи, указав оба IP.
x.x.x.1 srv
x.x.x.2 srv
Заодно и балансировку нагрузки по обоим каналам получите. Более сложные способы в голове есть, но озвучивать пока не хочу.
Писал для себя, поделиться несложно.