Рано или поздно любой растущий бизнес сталкивается с ситуацией, когда привычная и ранее быстрая система 1С начинает откровенно зависать. Проведение одного документа затягивается на минуты, отчеты формируются бесконечно долго, а сотрудники начинают жаловаться на постоянное зависание интерфейса. Часто обслуживающие ИТ-компании предлагают решить эту проблему радикально и дорого — покупкой нового мощного сервера и дорогостоящего пакета лицензий Microsoft Windows Server, CAL и SQL Server на сотни тысяч рублей.
В этой статье мы подробно проанализируем реальный кейс с форума, разберем причины медленной работы файловой базы 1С на 12–14 пользователей и найдем оптимальные пути модернизации ИТ-инфраструктуры с минимальными финансовыми затратами.
Прежде чем бежать в магазин за новым серверным оборудованием, давайте проведем аудит текущей системы и выясним, где именно находится так называемое "бутылочное горлышко" (узкое место). Нам известны исходные параметры системы:
ТонкийКлиент по локальной сети).Проанализируем эти параметры. Многие ИТ-специалисты поспешат назвать этот сервер "машинкой для пасьянса", однако это не совсем так. Процессор Intel Xeon E3-1230v3 обладает отличной однопоточной производительностью, что крайне важно для платформы "1С:Предприятие". Его мощности вполне достаточно для обслуживания небольшого офиса. Так почему же система работает крайне медленно?
Главная проблема кроется в сочетании двух факторов:
.1CD через общую папку каждый клиентский компьютер берет на себя вычисления и прокачивает через локальную сеть огромные объемы информации. При проведении документов возникают жесткие блокировки таблиц. База блокируется целиком для всех пользователей, пока один из них записывает документ.Чтобы окончательно подтвердить нашу гипотезу о блокировках СУБД и медленных дисках, проведем простой эксперимент: попросим всех пользователей выйти из базы 1С в конце рабочего дня. Запустим сеанс под одним пользователем и попробуем провести тот самый документ, который днем проводился несколько минут. Если в одиночном режиме документ проведется за 2-3 секунды, значит, физической мощности процессора сервера более чем достаточно, а корень зла кроется в файловых блокировках СУБД и медленном диске.
Не спешите списывать старое серверное железо. Мы можем значительно ускорить его работу, сделав точечный и недорогой апгрейд.
Во-первых, разберем ситуацию с оперативной памятью. На форумах часто советуют "докупить оперативной памяти до 64 ГБ". Будьте внимательны: контроллер памяти процессора Intel Xeon E3-1230v3 физически поддерживает максимум 32 ГБ оперативной памяти DDR3/DDR3L. Соответственно, наш предел модернизации — расширить память с текущих 16 ГБ до максимально возможных 32 ГБ.
Во-вторых, полностью избавимся от обычных жестких дисков (HDD) для размещения баз данных. Нам необходимо приобрести два надежных твердотельных накопителя класса Enterprise или качественных потребительских SSD с высоким ресурсом перезаписи (например, серии Samsung PRO) объемом от 500 ГБ до 1 ТБ. Эти накопители необходимо объединить в зеркальный RAID-1 массив (для отказоустойчивости) с помощью встроенного контроллера или средствами операционной системы.
Установка SSD поднимет показатель IOPS со скромных 100 до внушительных 50 000–90 000 операций в секунду. Это мгновенно решит проблему дискового "бутылочного горлышка".
Если мы хотим оставить базу в файловом режиме, но полностью убрать сетевые задержки и минимизировать риск повреждения базы при сбоях сети, откажемся от работы через общую сетевую папку. Настроим бесплатную альтернативу — публикацию базы данных на веб-сервере Apache или IIS прямо на нашем сервере.
Разберем этот процесс по шагам:
http://имя_сервера/имя_публикации.При таком подходе пользователи будут работать через привычный ТонкийКлиент, но обмен данными пойдет по быстрому протоколу HTTP/HTTPS. Все тяжелые дисковые операции с файлом базы данных будут происходить локально на самом сервере, а не гоняться по сети. Это существенно повысит стабильность работы и скорость проведения документов.
Для понимания процесса автоматизации публикации приведем пример консольной команды для публикации файловой базы данных 1С на веб-сервере Apache под управлением операционной системы:
# Пример команды публикации файловой базы на веб-сервере Apache 2.4
/opt/1cv8/x86_64/8.3.12.1685/webinst -apache24 -wsdir UT_Base -dir /var/www/html/UT_Base -conn "File='/home/1c/bases/UT';"
Файловый режим для 12–14 активно работающих пользователей в УТ 11 — это всегда компромисс. Рано или поздно база вырастет, и блокировок станет слишком много. Идеальное решение — переход на полноценный клиент-серверный вариант.
Чтобы не платить более 150 000 рублей за лицензии Windows Server и MS SQL Server, мы можем развернуть полностью бесплатный стек программного обеспечения с открытым исходным кодом.
Проанализируем схему работы связки Linux + PostgreSQL:
Службы сервера 1С и СУБД PostgreSQL отлично уживутся на нашем модернизированном сервере с 32 ГБ оперативной памяти и быстрыми SSD-накопителями. Настройка СУБД в Linux выполняется стандартными командами управления службами.
Рассмотрим пример команды для управления службой PostgreSQL в среде Linux:
# Проверка статуса и перезапуск службы PostgreSQL для применения настроек оптимизации
systemctl status postgresql-14
systemctl restart postgresql-14
Иногда даже самое мощное железо не может быстро провести документ из-за накопившихся ошибок внутри самой базы или некорректных настроек программы. Разберем шаги по регулярному обслуживанию базы 1С:
Администрирование — Обслуживание — Регламентные задания и отключим все функции, которые не используются в повседневной деятельности компании. В файловом режиме они сильно нагружают систему.Администрирование — Тестирование и исправление. Обязательно выберем параметры РеиндексацияТаблиц и СжатиеТаблиц. Реиндексация перестроит индексы таблиц базы данных и ускорит поиск информации, а сжатие удалит "физический мусор" и уменьшит общий объем файла базы на диске.Подведем итог. Предложение обслуживающей компании потратить огромные деньги на покупку нового сервера и лицензий Microsoft — это не единственное и далеко не самое оптимальное решение проблемы.
Рекомендуем придерживаться следующего пошагового плана:
ТестированиеИИсправление с реиндексацией и сжатием таблиц.