Рассмотрим ситуацию, с которой часто сталкиваются при переходе на новые редакции конфигураций. Допустим, мы обновили базу 1С:Комплексная автоматизация (КА) с релиза 2.4 на 2.5. После успешного обновления и запуска мы замечаем, что время проведения документов существенно увеличилось — например, с 2–5 секунд до 9–17 секунд. При этом групповое перепроведение работает катастрофически медленно.
Проанализируем ситуацию с помощью замера производительности в конфигураторе. Часто в таких случаях замер показывает аномальную картину: львиную долю времени (до 66% и более) занимает выполнение простой платформенной функции СтрЗаменить(), которая, судя по профилировщику, вызывается сотни тысяч или миллионы раз внутри процедуры ПроведениеДокументов.ДополнитьЗапросОтраженияДокумента. Выясним причину такого поведения и разберем по шагам, как вернуть системе прежнюю скорость работы.
В первую очередь после любого мажорного обновления проверим, все ли обработчики обновления завершили свою работу. Переход с КА 2.4 на 2.5 затрагивает архитектуру многих подсистем (учет затрат, производство, новые ФСБУ), и база требует выполнения сотен фоновых операций.
Убедимся, что регламентное задание по переходу на новую версию отработало до конца. Если статус показывает, что все обработчики (например, все 458 операций) завершены, а система всё равно тормозит, перейдем к следующему этапу диагностики.
Если конфигурация типовая, расширения отключены, а аппаратные ресурсы сервера не менялись, то проблема кроется на уровне платформы 1С:Предприятие. Выясним, почему возникает ложная нагрузка на функцию СтрЗаменить().
Обновление является масштабным, и если после него сервер 1С не был корректно перезагружен, в так называемом «серверном кэше» остаются неактуальные структуры данных и скомпилированный код от старой версии конфигурации. Это вызывает внутренние конфликты в платформе. Замер производительности при этом начинает показывать аномалии, указывая на базовые функции работы со строками, хотя фактическая проблема заключается в поврежденном кэше сеансовых данных.
Файлы, хранящиеся в папке snccntx — это файлы сеансовых данных. Технически файлы вида snccntx.dat представляют собой внутреннюю noSQL базу данных платформы (key-value хранилище). В ней платформа 1С временно сохраняет служебную информацию, необходимую для работы сеанса пользователя:
Когда там остается «хлам» от старой конфигурации, скорость работы многократно падает.
Обычной очистки локального кэша пользователя в данной ситуации недостаточно. Посмотрим на алгоритм правильной очистки серверного кэша.
Крайне важно понимать один нюанс: нельзя просто удалить файлы из папки srvinfo. Сначала нужно корректно остановить все службы 1С. Более того, рабочие процессы rphost.exe или менеджер кластера rmngr.exe могут зависнуть в памяти и продолжить блокировать файлы сеансового кэша. Если их не завершить принудительно, удаление будет неполным, и проблема не решится.
Рассмотрим пример скрипта (bat-файла), который выполняет безопасную остановку служб, принудительно завершает зависшие процессы и очищает нужные каталоги. Обязательно подставьте свои пути и имена служб перед использованием.
set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
Обратим внимание на блок с командами taskkill. Именно они гарантируют, что ни один фоновый процесс платформы не будет удерживать файлы snccntx.dat и файлы профилей *.pfl. После выполнения данного скрипта можно заново запустить службу агента сервера 1С:Предприятия.
Проанализируем поведение системы после запуска. После удаления файлов в каталогах snccntx первое открытие базы данных и первое проведение документов будут выполняться медленнее обычного. Это абсолютно штатное поведение платформы.
Система загружает данные с нуля, заново компилирует программный код под новую архитектуру КА 2.5 и формирует актуальный чистый кэш. После того как кэш обновится (обычно достаточно провести пару документов каждого вида), последующие операции вернутся к нормальной скорости (2–5 секунд на документ), а ложная нагрузка на платформенные функции полностью исчезнет.