Ошибка SDBL в
1С:Предприятие 8.0 и один из методов ее устранения.
Вот что по этому поводу могу сказать я. Ошибка эта тоже начала доставать, поэтому было проведено маленькое исследование. Вот его результаты:
1) Сервер 1С в процессе работы потребляет виртуальную память. Особо подчеркиваю - виртуальную. Сюда входит о та часть памяти, которая располагается в ОЗУ, и та часть памяти, которая размещается в свопе. Народ часто при описании ошибки SDBL отслеживает и указывает только количество памяти процесса, размещенного в ОЗУ, а это значение может сильно меняться (у кого-то SDBL наступает при 1 Гб ОЗУ, а у нас это было при 1,4 Гб - это неважно).
2) У сервера 1С есть врожденный косяк - он писался как традиционное Win32 приложение, а они в стандартной архитектуре Win32 больше 2 Гб виртуальной памяти получить не могут. Конечно, потом MS сделала ключик /3GB, но он требует поддержки также и от самого приложения (т.е. оно должно уметь работать с ним), а 1С дорабатывать сервер под этот ключ не стала. Как результат, даже при использовании ключа /3GB и включения поддержки 3 Гб в настройках сервера 1С в DCOM сам сервер 1С больше 2 Гб виртуальной памяти брать отказывается, что очень обидно :(
3) В сервере 1С есть механизмы управления памятью. 1С над ними работает, улучшая их работу от релиза к релизу. У нас стоит последний релиз 8.0.18.2, и мониторинг потребляемой сервером 1С памяти показал, что в целом он постоянно запрашивает у операционной системы дополнительную виртуальную память, хотя возможны кратковременные отдачи памяти назад в операционную систему. Поскольку в целом он память только потребляет, то с достижением порога в 2 Гб виртуальной памяти, выделенной процессу, начинаются ошибки SDBL. В этот момент сервер приходится перезагружать, чтобы сбросить выделенную процессу память в 0 и начать процесс потребления памяти опять.
4) Т.о., в 32-битной версии сервера 1С диапазон выделенной памяти процессу при любых настройках колеблется от 0 до 2 Гб. Это практический диапазон, в котором возможна бесперебойная эксплуатация сервера.
5) Тут я очень сильно сейчас поругаю 1С. К примеру, 1С 8.х позиционируется компанией 1С как основа для построения промышленных решений, а не просто как бухгалтерия малого предприятия. Базы данных промышленных приложений могут хранить много или очень много данных. В большинстве случаев промышленное приложение без передачи своей базы данных под управление СУБД не может обойтись. Но давайте посмотрим на меры, предпринятые компаний Microsoft к позиционированию своего SQL сервера как промышленной СУБД. Ей также, как и 1С, были разработаны и 32-битная, и 64-битная версии своего продукта. Но, в отличие от 1С, и в 32-битной версии, и в 64-битной версии MS реализовала полную поддержку больших объемов ОЗУ - версия SQL Enterprise поддерживает 64 Гб ОЗУ. Причем это реализовано как в 32-битных версиях SQL (через AWE), так и в 64-битных версих (прямая поддержка больших объемов ОЗУ самой ОС). Более того, 32-битный SQL сервер умеет также работать и с ключом /3GB, позволяя получить для базы данных еще один гигабайт. Подводя итог, получаем такую картину в 32-битной трехзвенной архитектуре 1С (по максимальным объемам ОЗУ):
Клиент (2 Гб) - Сервер 1С (2 Гб) - SQL сервер (64 Гб). Таким образом, сам Сервер 1С становится узким звеном, поскольку именно на нем должны обрабатываться большие объемы данных, а обработать он их не может, потому что памяти не хватает. Тут какая-то женщина администратор писала, что их СУБД имеет размер 100 Гб, и сервер 1С они вынуждены по нескольку раз в сутки перезапускать. Вот такая вот грустная история получается с внедрением 1С на крупных промышленных предприятиях. Почему я так напираю на 32-битные версии? Потому что пока еще индустрия не перешла на 64-битный софт, и использование 32-битных версий для многих компаний остается еще весьма и весьма актуальной темой. Он отлажен и проверен годами, и в общем-то, кроме пресловутого порога 4 Гб нет другой причины для ухода от него в 64-битные версии, которые появились на рынке относительно недавно.
6) Что же нам предлагает 1С для решения проблемы малого (по промышленным масштабам) объема памяти, выделяемого серверу 1С:
А) в 32-битной версии включить поддержку 3 Гб памяти, выделяемой процессу. Но так как это не было реализовано программно в самом сервере 1С, должного эффекта это не даст – ошибка SDBL будет появляться при 2 Гб выделенной процессу памяти (виртуальной).
Б) Заставить программистов найти запросы, возвращающие большие выборки, и переписать их. Однако эта мера, при высоких трудозатратах, не уберет ошибку SDBL, ибо потребление памяти сервером 1С не прекратится совсем, а только замедлится.
В) Перезапускать сервер 1С. При этом старый процесс, взявший много памяти, закрывается, а его ресурсы (в первую очередь память) возвращаются ОС. Новый экземпляр процесса сервера 1С начинает свою работу с 0 памяти, выделенной процессу. Тоже проблемы не решает, т.к. эта мера не влияет на само свойство сервера 1С потреблять память.
Г) Перейти на технологическую платформу 8.1. Как заявляет сама 1С, в 8.1 были существенно переработаны механизмы обработки больших выборок. Но, на мой взгляд, все свелось к одному. В 8.0 результаты всех выборок падали в память, а в 8.1 1С разделила их на маленькие, которые по-прежнему падают в память, и большие, которые сливаются во временные файлы на диске. Однако в любом случае свойство сервера потреблять память не убрано, и поскольку в общем-то это та же 8-ка, то 2 Гб порог остался. По некоторым сведениям с форума переход на 8.1 не избавил людей от этой ошибки, хотя другие рапортуют о том, что у них она пропала. Я думаю, что все объясняется просто – принятые 1С в 8.1 меры существенно замедлили скорость роста потребляемой сервером памяти, поэтому те, кто не жалуются, просто еще не достигли порога в 2 Гб, а кому-то даже такое существенное замедление роста не помогло и они достигли предела в 2 Гб.
Д) Это модернизированный вариант г). Суть в том, что администраторы в компании разворачивают несколько серверов 1С, объединенных в кластер, а программисты раскидывают исполняющиеся задачи по серверам 1С кластера. Удельная нагрузка на одиночный сервер 1С падает, а следовательно отсрочивается и момент достижения 2 Гб предела. Но это фактически означает, что однопоточную конфигурацию какой-нибудь УПП фактически переписать в многопоточную. При этом компания вынуждена идти на существенные финансовые, трудовые затраты и временные затраты – закупка софта и железа, затем переписывание конфигурации (а вы знаете, как в мире сейчас тяжело с обучением программистов многопоточным вычислениям, а ведь это родственные задачи). Да и программисты от такого вряд ли будут в восторге.
Е) Для тех, кого это уже достало и сил уже больше нет, переход на 64-битный софт. Это 64-битная ОС и 64-битная версия сервера 1С. Тут виртуальной памяти, выделяемой одному процессу столько, что об этом можно забыть на ближайшие 10 лет и на эту тему больше не волноваться. При любых скоростях потребляемой сервером 1С памяти достижение порога, определяемого для процесса, наступит очень-очень не скоро, так что проблема можно сказать исчезает. Скорее сервер будет выключен для прочистки вентиляторов J, а тогда и память сбросится. Вопрос только в том, насколько 64-битные ОС и сам сервер готовы к промышленному режиму эксплуатации. Насколько я знаю, в самих 64-битных ОС еще не всегда можно найти драйвера для оборудования, а на форуме нет еще ни одного отзыва об эксплуатации 64-битной версии сервера 1С.
Ж) Сама 1С переписывает на системном уровне 32-битную версию сервера 1С, реализовав полную поддержку механизма PAE/AWE, что позволит серверу 1С адресовать до 64 Гб памяти (если его запускать на версиях Windows Server Datacenter Edition). Однако по имеющимся сведениям 1С никогда на это не пойдет, т.к. на рынке уже есть ее 64-битная версия сервера 1С, обеспечивающая использование такого же объема памяти.
7) А вот это метод, который мы сами открыли (на право первенства не претендуем, но на форуме и в инете таких сведений не нашли). Почему-то в рекомендациях 1С о нем ничего не говорится. Поскольку одним из решений является периодический перезапуск сервера, мешающий ему набрать 2 Гб памяти, то это можно делать двумя путями. Первый путь – администратор в заданное время скриптами или чем угодно принудительно закрывает , а затем вновь запускает процесс сервера. Второй путь – штатные средства подсистемы DCOM. В настройках DCOM сервера 1С есть такой параметр "Enable idle shutdown". Суть его в том, что система DCOM отслеживает активность процесса сервера, и если он простаивает, т.е. простаивает без работы и находится в состоянии «idle», то DCOM его закрывает до тех пор, пока сервер 1С кому-нибудь не понадобится. При поступлении запроса к серверу 1С DCOM ставит такой запрос в очередь, а сама запускает сервер 1С. Как только он успешно запущен, система DCOM передает ему для обработки ожидающий запрос. Легко догадаться, что такое поведение лучше, чем простое обрубание сервера, т.к. есть вероятность, что администратор закроет процесс сервера в тот момент, когда он делает важную работу. Теперь внимание! По умолчанию значение параметра "Enable idle shutdown" равно 3 минуты. Мои наблюдения за использованием "Enable idle shutdown" механизма DCOM и нашего сервера 1С показали, что у нас он не срабатывает, видимо потому, что сервер 1С за три минуты не переходит в состояние «idle». Как результат, сервер работает бесконечно, накапливая потихоньку выделенную ему виртуальную память до 2 Гб, после чего отказывается работать, выдавая ошибку SDBL по любому поводу. Но логика подсказывает, что даже если внутри сервера есть механизмы, подобные «keep-alive», все равно ночью процесс сервера должен простаивать (после выполнения всех ночных регламентных работ). Уменьшив интервал таймера с 3 минут до 1, я добился нужного эффекта. При одноминутном интервале наступают моменты, когда сервер 1С простаивает в течение одной минуты. Этого достаточно, чтобы DCOM гасила процесс, освобождая ресурсы сервера 1С и возвращая их операционной системе. На данный момент мониторинг сервера показал, что он действительно сбрасывается под утро. Пока я таким эффектом доволен и предлагаю его попробовать тем, кого достает ошибка SDBL. Возможно, что на 100 Гб базах процесс сервера 1С будет успевать набирать 2 Гб память в течение 2-3 часов рабочего времени и придется сервер сбрасывать принудительно, но пока у нас база 6 Гб, и нас это устраивает. К тому времени, когда она достигнет 100 Гб, возможно уже 64-битный софт будет отлажен и получит повсеместное распространение.
