Что делать, если тормозит база на 1С? Необходимо переходить на клиент-серверный вариант работы, то есть переложить весь объём работы на производительный сервер и пресечь перегон трафика по сети. Можно конвертировать все базы из файлового варианта в высокопроизводительный SQL. А если баз много, Microsoft SQL не купить и пара пользователей с разрешения начальства хотят постоянно создавать и перемещать копии баз. Файловый вариант в этом случае проще. Остаётся терминальный режим работы.
Организация
Много лет обслуживаю одну обувную организацию в Адыгее. Обслуживаю по факту (позвали — еду). В сети около пятнадцати компьютеров с сервером в обычной рабочей группе. На сервере расположено много баз 1С 7.7. Есть свой программист. Изначально с базами они работали в обычном файловом режиме по сети. То есть, по-очереди, так как совместная работа была невозможна — база начинала сильно тормозить. Программист поговаривал, что необходимо переводиться на терминальный режим работы, о чём я с самого начала начал и думал, да только не спешил это озвучивать — инициатива наказуема. Но сказали надо, значит надо.
Сервер
Их сервер на начинке 2011 года сборки — компьютер с процессором i7, 8 гигабайтами оперативной памяти и дискретной видеокартой довольно шустрый, хоть и не первого поколения. RAID-массив — зеркало (2 винчестера работают в режиме дублирования данных). Скорость чтения зеркала не меньше 100 Мегабайт в секунду — средний показатель. За сервером работал один из начальников — запретил, так как это не рабочая станция!
Диагностика, чистка и ремонт
Начинаю с «железной» технической части — вскрытие системного блока. А там пыли! С предыдущей поломки прошло несколько лет. На чистку близкую к идеальной был потрачен не один час. Вот теперь визуально всё хорошо. Но это только начало, так как один жёсткий диск в массиве был мёртв, и не один год, о чём я заблаговременно неоднократно говорил начальству. Благо третий жёсткий диск оказался такой же модели, поэтому умерший был извлечён, а на его место стал рабочий.
Программная часть
Много времени ушло на переброс нужных данных, создание образа системы, пересборку массива и восстановление образа (репликация бы отняла много времени). Потом чистка от программного мусора, антивирусные мероприятия, обновление безопасности, решение накопившихся проблем и т.п. Вот теперь можно сервер терминалов настраивать. Настроил более десятка пользователей — начальство, бухгалтерия, менеджеры, складские работники. Права ограничил, интернет запретил, решил почти все проблемы с печатью без стороннего коммерческого софта.
Проблемы с базой
И вот тут начались проблемы. Вернее, проблемы продолжились. После перевода на терминальный режим, складская база должна была работать быстро.
Терминальный режим — работа пользователей с сервером через удалённое соединение, когда все вычисления выполняются на сервере. У каждого пользователя есть своя учётная запись и он после соединения в окне видит свой рабочий стол на сервере и работает так же, как на своём компьютере. От компьютера по сети отправляются сжатые команды (координаты курсора, нажатия клавиш и т.п.), а обратно приходит сжатое изображение (сжатая графика, координаты значков, положения окон и т.п.).
Так как вся нагрузка ложится на сервер, а через сеть передаётся минимальный сжатый набор данных, то о никаких задержках не могло быть и речи. Исключение составляет передача графики и видео, но можно настроить максимальное сжатие, да и для локальной сети это не является проблемой. Через такой режим можно работать даже через медленное модемное соединение, так как мы отправляем команды и видим результат выполнения этих команд, а тормоза большей частью зависят от наличия графики и эффектов на удалённой стороне (при условии стабильного, хотя и медленного соединения).
Итак, что получилось? Все пользователи смогли работать с базами одновременно (ранее работали по-очереди). Базы гораздо меньше стали сбоить, так как переставали передаваться по сети. Но «возникло» заметное торможение двух.
Я без особого разбору взял вину на себя и начал разбираться. Сработали чувства, а не расчёт, а зря!
Что-то не то в терминальном режиме. Позже выяснилось, что тормозят не все базы. Например, бухгалтерские и складские базы работают быстро. Поступила жалоба о тормозах другой конфигурации — аграрной.
Под бухгалтерской базой подразумеваю конфигурацию 1С Предприятия 7.7 «Бухгалтерия», под зарплатой — конфигурацию «Зарплата+Кадры», под складской — «Торговля и склад».
Дальнейший анализ показал, что только обувная зарплатная конфигурация тормозит, причём только в определённых местах — модулях, а эти модули имеют графические данные (хотя также жаловались на скорость формирования некоторых отчётов, но там тоже присутствовала графика). Аграрную конфигурацию не рассматривал, оставив на потом. Далее я выбрал ложный путь. Не буду долго повествовать, но много времени потратил на ускорение графики удалённого рабочего стола. Заходил на сервер под локальной учётной записью администратора и единолично работал с базой — торможение минимальное, но было. Потом на всякий случай создал копию конфигурации без графики, но это не изменило ситуацию! А что самое интересное, понял, что обе конфигурации дорабатываются одним и тем же программистом! Вот с этого момента я начал сильно сомневаться, что вина моя.
В 2011-2012 годах мне довелось в качестве программиста дорабатывать одну сложную конфигурацию, в которой к тому же был зашифрован глобальный модуль — стояло средство защиты конфигурации, которую никак не снять. Прошло пять лет, но вспоминать — не с нуля начинать. Я полез в код…