Этой статьей открываем небольшой (наверное) цикл, посвященный разного рода ошибкам, с которыми сталкиваются пользователи 1С и поддержка. Естественно, речь пойдет не о функциональных ошибках, а о тех, что связаны с производительностью и стабильностью работы систем 1С. Да, их на первый взгляд много и появляются новые, но попробуем классифицировать самые популярные.
В интернете можно найти довольно много всякой информации про ошибки 1C, но она носит скорее бессистемный характер, т.к. не всегда понятно кто виноват, куда смотреть и что делать. Первопричины ошибок действительно далеко не всегда очевидны и нужно правильно интерпретировать получаемые данные от тех систем мониторинга, которыми вы пользуетесь. Некоторые ошибки мы уже описывали в том или ином виде в других своих статьях, но назрела необходимость перегруппировать и дополнить информацию, чтобы все было в одном месте. Поэтому основной целью будет в одном цикле статей показать популярные виды ошибок, их проявление, причины, как диагностировать и как бороться (исправлять). Если ошибку описывал ранее, то дополнительно буду давать ссылку на другую свою статью. На том вступление завершаю.
Ошибки нехватки памяти на сервере приложения 1С
Можно переформулировать это как «Сервер 1С или один из его процессов потребил памяти больше, чем ему дозволено в настройках».
Распространенные тексты ошибок:
Недостаточно памяти для …
Недостаточно свободной памяти для…
Превышен предел использования памяти рабочим процессом
Завершение работы сеанса: недостаточно памяти
Для моделирования возьмем обычную демобазу УТ на платформе 8.3.27 и дадим ей на вход прожорливый запрос, который съедает всю память на сервере 1С. Настройки управления памяти на сервере 1С – по умолчанию.

С такими настройками пользователю выдалась неожиданная ошибка по тексту, никак не связанная с нехваткой памяти.

Но в ТЖ все по-честному: "Превышен максимальный расход памяти сервера за один вызов..."
17:38.451000-0,EXCP,5,level=WARNING,process=rphost,p:processName=test,OSThread=8844,t:clientID=253,t:applicationName=1CV8C,t:computerName=SP27-TERMINAL,t:connectID=8,SessionID=1,Usr=Администратор,AppID=1CV8C,DBMS=DBMSSQL,DataBase=sp27-mssql3\test,Exception=f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe,Descr='Bad alloc: f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe: Превышен максимальный расход памяти сервера за один вызов: limit=21988130890, size=21988131936',Context='Форма.Вызов : ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Модуль.ВыполнитьЗапросСервер ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Форма : 1314 : Результат = ОбъектОбработки().ВыполнитьЗапрос(Текст, МассивПараметров, ТабличныйДокументРезультата, ПараметрыВыводаЗапроса, ОтчетПоВыполнениюЗапроса, МеткаЗапроса); ВнешняяОбработка.КонсольЗапросов.МодульОбъекта : 839 : МассивЗапросов = Запрос.ВыполнитьПакет();'
Такая же ошибка в ТЖ будет и при выставлении разных лимитов в настройках сервера 1С, только для пользователя появилось уже более вменяемое сообщение:

Сообщение из ТЖ:
24:54.186000-0,EXCP,5,level=WARNING,process=rphost,p:processName=test,OSThread=8696,t:clientID=43,t:applicationName=1CV8C,t:computerName=SP27-TERMINAL,t:connectID=24,SessionID=66,Usr=Администратор,AppID=1CV8C,DBMS=DBMSSQL,DataBase=sp27-mssql3\test,Exception=f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe,Descr='Bad alloc: f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe: Превышен максимальный расход памяти сервера за один вызов: limit=5433868033, size=5433868752',Context='Форма.Вызов : ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Модуль.ВыполнитьЗапросСервер
Перебирать и комбинировать настройки лимитов в рамках статьи не буду, это, скорее, вопрос изучения документации, покажу только как это выглядит в мониторинге, чтобы вы в будущем могли правильно сориентироваться.
Рассмотрим первый случай, когда памяти действительно не хватило (настройки по умолчанию).
На что смотрим: график свободной оперативной памяти на сервере, график потребления памяти процессом(ами) rphost, ну и график размера файла подкачки. Подписал их все на рисунке, корреляция видна и очевидна. В моменте, соответствующему установленной на графиках вертикальной линейки, на панели «Дополнительная информация» видно, что пользователь Администратор и его процесс с PID 6708 потребил ~21,1 Гб, а на панели «ТОП процессов» этот же rphost потребил 21,4 Гб памяти. Цифры немного отличаются, т.к. добываются из разных мест (консоль 1С и ОС) с небольшим временным лагом.

Итак, в Perfexpert мы сразу можем найти виновника (Администратор), понять причину (выполнялся определённый запрос, показанный красной стрелкой) и решить что делать (поставить ограничение по памяти, переписать код/запрос, добавить памяти, «наградить» Администратора).
С точки зрения остальных пользователей – им грустно: сервер несколько минут не отвечал пока процесс PID 6708 не соизволил отпустить память.
Теперь установим все лимиты. Тут важно, чтобы «Безопасный расход за один вызов» был больше, чем «Временно допустимый объем памяти процессов». Иначе параметр будет проигнорирован.

Получаем такую же пользовательскую ошибку:

И сообщение из ТЖ с лимитом, но отличающееся от нашего значения ровно на 1 000 000 000 байт. Не понятно почему так. Если кто знает, напишите в комментариях.
46:27.863000-0,EXCP,5,level=WARNING,process=rphost,p:processName=test,OSThread=8516,t:clientID=61,t:applicationName=1CV8C,t:computerName=SP27-TERMINAL,t:connectID=5,SessionID=1,Usr=Администратор,AppID=1CV8C,DBMS=DBMSSQL,DataBase=sp27-mssql3\test,Exception=f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe,Descr='Bad alloc: f6f167a0-dcc9-49ad-8f8e-2c9d9904e4fe: Превышен максимальный расход памяти сервера за один вызов: limit=11000000000, size=11000003648',Context='Форма.Вызов : ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Модуль.ВыполнитьЗапросСервер ВнешняяОбработка.КонсольЗапросов.Форма.Форма.Форма : 1314 : Результат = ОбъектОбработки().ВыполнитьЗапрос(Текст, МассивПараметров, ТабличныйДокументРезультата, ПараметрыВыводаЗапроса, ОтчетПоВыполнениюЗапроса, МеткаЗапроса); ВнешняяОбработка.КонсольЗапросов.МодульОбъекта : 839 : МассивЗапросов = Запрос.ВыполнитьПакет();'

Здесь точно такая же корреляция, но файл подкачки уже не растет, он остался на том же уровне, т.к. системе памяти хватает. Ограничение по потреблению сработало раньше, чем память закончилась и «пострадали» только те пользователи (в нашем примере это один Администратор), которые работали на этом процессе.
Определенно, такое поведение системы гораздо лучше, осталось только прикинуть какие лимиты вам нужно выставить в настройках сервера 1С. Для этого нужна статистика хотя бы за 1-2 месяца, которая вам и покажет пики. Как правило, интенсивное использование памяти происходит в регламентные периоды типа закрытия месяца, расчета себестоимости и т.п. Поэтому обязательно включите в анализируемый период эти и подобные тяжелые операции.
Ошибка нехватки портов на сервере приложений 1С
Довольно распространенная ошибка, часто вызванная недопониманием последствий настройки «Количество соединений на процесс». По умолчанию этот параметр равен 256. Т.е. на одном rphost’е будут в пределе 256 сессий. Некоторые администраторы снижают этот параметр вплоть до 25-30, руководствуясь посылом «Пусть в случае чего отвалятся только 30 пользователей, нежели 256». Вроде логика в этом есть, но подходит она далеко не всем. Во-первых, надо четко понимать какое среднее/максимальное количество активной сессий в вашей ИС. Во-вторых, достаточность аппаратных ресурсов сервера, чтобы управляться с большим количеством rphost’ов. В-третьих, требования к задержкам разных операций, т.к. запуск каждого нового rphost’а – это задержка на секунды и даже минуты.
Про нехватку портов на сервере 1С есть раздел в статье «Записки оптимизатора 1С (ч.11). Не всегда очевидные проблемы производительности на серверах 1С». В ней приведен реальный пример с боевой базы. А здесь мы смоделировали искусственно эту ошибку, установив параметр «Количество соединений на процесс = 1».

Итого, запустив более 32 сессий (1591-1560), мы сразу исчерпаем лимит стандартного диапазона портов. Кстати, никто не запрещает его расширять. Но помним про ресурсы. Каждый новый rphost – это память, время запуска (оно далеко не мгновенно) и риск, что сервер 1С не справится с таким количеством процессов. Они могут подвисать, сервер может перестать контролировать какие-то rphost’ы, предоставив их самим себе, с утечкой памяти. В общем, поведение нестабильно и не всегда предсказуемое.
У пользователя (тонкий клиент) при попытке подключиться к ИБ возникает ошибка, в которой сообщается о том, что свободных рабочих процессов нет. А если это фоновое задание, то оно просто молча не выполнится, без всякого дополнительного информирования.

Как за этим следить и предвидеть?
В Perfexpert можно смотреть, во-первых, за количеством процессов rphost, а во-вторых, за номером максимального порта того или иного процесса. И то и то подскажет, что лимит если не наступил, то уже близко.

Например, на рисунке выше видно, что вверху списка находится процесс с максимальным номером порта 1591. При этом, если посмотреть на график количества активных рабочих процессов, то их количество – 28, а не 32.

Такое бывает. Не все порты заняты (есть пропуски, отмеченные красными стрелками), но сервер 1С не отдает в моменте новым процессам свободные и возникает ошибка типа «Свободный рабочий процесс не найден». Поэтому обязательно следим за обеими метриками – последний занятый порт и общее количество активных рабочих процессов. Если лимит близок и подобные эпизоды не единичны или даже часто встречающиеся, необходимо пересмотреть настройки 1С либо в сторону увеличения параметра «Количество соединений на процесс», либо в сторону расширения диапазона портов.
Ошибки нехватки свободного места на диске
Место на диске может закончиться на сервере 1С или на сервере СУБД. Но это не самые частые случаи. Например, на сервере 1С в случае нехватки места на диске пользователь во время выполнения любых своих действий получит ошибку вида «На устройстве нет свободного места...»:

Что смотрим и за чем наблюдаем: Счётчик свободного места на логическом диске <С> и дисковую активность на сервере приложений.

В данном синтетическом примере виновник торжества – проводник Windows, с помощью которого пользователь «kolesnikov» копировал несколько крупных файлов на диске <C>.
Но гораздо (!) чаще встречается другая ситуация с нехваткой свободного места.
Ошибка СУБД. Закончилось место в файловой группе базы tempDB.
Проблема: во время выполнения операции, которая использует временные таблицы возникает ошибка: Не удалось выделить новую страницу для базы данных “TEMPDB”, так как файловая группа “DEFAULT” заполнена из-за нехватки места в хранилище или достижения файлом базы данных максимального допустимого размера.

Ошибка возникает либо по причине действительно того, что место на диске закончилось, либо установлено ограничение на прирост базы [tempDB].
Для моделирования воспользуемся как раз вторым сценарием и установим ограничение максимального объёма файлов для [tempDB]. Для файла базы – 2 048 Мб, а для файла лога – 2 054 Мб. Файлы уже имеют максимальный размер в 2 000 Мб, поэтому добавление даже 64 Мб приводит к ошибке.

В 1С через внешнюю обработку запускается операция, которая использует временную таблицу.
Результат: процент использования файла базы достиг 100% и в трассе мониторинга Exception появилась соответствующая ошибка:

За чем наблюдаем, чтобы не пропустить такую ситуацию:
Самое простое и элементарное: за свободным местом на диске, где располагается [tempDB]. И да, [tempDB] лучше располагать на отдельном диске, не совмещая с файлами основной базы данных.
За объемом файлов tempDB и процентом их использования. На рисунке – это соответствующие графики на левой панели. При желании в Perfexpert можно установить нотификацию, чтобы не пропустить событие.
Итого сегодня мы рассмотрели три укрупненных вида ошибок в 1С, связанные со стабильностью работы ИС: ошибки нехватки памяти на сервере 1С, ошибки нехватки портов на сервере 1С, ошибки нехватки свободного места на дисках.
Продолжение следует…
Ссылки на остальные части Записок оптимизатора 1С:
Записки оптимизатора 1С (ч.1). Странное поведение MS SQL Server 2019: длительные операции TRUNCATE
Записки оптимизатора 1С (ч.2). Полнотекстовый индекс или как быстро искать по подстроке
Записки оптимизатора 1С (ч.3). Распределенные взаимоблокировки в 1С системах
Записки оптимизатора 1С (ч.4). Параллелизм в 1С, настройки, ожидания CXPACKET
Записки оптимизатора 1С (ч.5). Ускорение RLS-запросов в 1С системах
Записки оптимизатора 1С (ч.6). Логические блокировки MS SQL Server в 1С: Предприятие
Записки оптимизатора 1С (ч.7). «Нелогичные» блокировки MS SQL для систем 1С предприятия
Записки оптимизатора 1С (ч.8). Нагрузка на диски сервера БД при работе с 1С. Пора ли делать апгрейд?
Записки оптимизатора 1С (ч.9). Влияние сетевых интерфейсов на производительность высоконагруженных ИТ-систем
Записки оптимизатора 1С (ч.10): Как понять, что процессор — основная боль на вашем сервере MS SQL Server?
Записки оптимизатора 1С (ч.11). Не всегда очевидные проблемы производительности на серверах 1С
Записки оптимизатора 1С (ч.12). СрезПоследних в 1C:Предприятие на PostgreSQL. Почему же так долго?
Записки оптимизатора 1С (ч.13). Что не так в журнале регистрации 1С в формате SQLitе?
Записки оптимизатора 1С (ч.14.1). Любите свою базу данных и не забывайте обслуживать
Записки оптимизатора 1С (ч.14.2). Пересчет индексов на SSD-дисках. Делаем или игнорируем?
Записки оптимизатора 1С (ч.14.3). Отличия в обслуживании статистик в MS SQL и в PostgreSQL
Записки оптимизатора 1С (ч.15). Параллелизм запросов 1С в PostgreSQL
Записки оптимизатора 1С (ч.18.1). Ошибки 1С в части производительности и стабильности ИС