Почему 1с долго сохраняет конфигурацию на сервере Linux?
Установил сервер 1С на Centos + база на postgres. 1С сервер, клиенты и конфигурация последних релизов.
Доступ удаленный через интернет. База чистая.
Конфигуратор запускаю на windows, запускаю загрузку конфигурации УНФ (400 мб) - загружает около 3-4 часов.
При этом связь с сервером отличная, файлы таких объемов заливаются за несколько минут.
После загрузки конфигурации нажимаю обновление конфигурации и зависает опять на пару часов.
Любое изменение конфигурации и дальнейшее ее сохранение вызывает часовые ожидания.
Повторю, чистая база.
При этих ожиданиях нагрузка на сервере возрастает лишь на 10%, процессор загружается на 10-15%, диски тоже чуть-чуть.
Что за тормоза, кто-нибудь сталкивался?
Пробовал работать с загруженной конфигурацией, добавлять, редактировать информацию(как пользователь), все работает без тормозов...
Но с сохранениями кофигурации что-то страшное. Или так и должно быть?
Конфигуратор запускаю на windows, запускаю загрузку конфигурации УНФ (400 мб) - загружает около 3-4 часов.
Где при этом лежит конфигурация? Уж не на компьютере ли случайно? Если конфигурация на компьютере - это нормально.
Если конфигурация на сервере - это ненормально и надо смотреть где проблема.
Новую конфигурацию конечно с компьютера закачиваю. Ну а потом она же наверное должна на сервере храниться. Что-то изменю в ней и зависает на несколько часов
ради эксперимента поставил сервер 1С + MS sql на свой старенький ноутбук.
локально(по 127.0.0.1) конечно изменения конфигурации происходят в течении нескольких минут, несмотря на то, что ресурсов тут вообще никаких нет, но 1С конфигуратор все делает быстро.
А вот клиент 1С уже тупит.
ради эксперимента поставил сервер 1С + MS sql на свой старенький ноутбук
.Особой разницы тут нет какой именно скуль - MS или postgres
Особенность работы такая.
Локально все делается очень быстро, по сети немного подтормаживает, но не сильно критично если пинг низкий( в локальной сети) а вот издалека - это уже тормоза.
Cтавьте сервер разработчика рядом и работайте по RDP.
Хотя это конечно костыль.
Если работать нормально - не открывайте конфигуратор на продакшене вообще, нечего там делать.
Для разработчиков организуйте свой сервер рядом с ними, пусть с тестовой базой работают.
И все, никаких тормозов.
А зачем в данном случае быстрый пинг? При обновлении конфигурации миллиард запросов что-ли идет на сервер? Странная схема обмена данными.
Скорее всего на винде поставлю сервер и с конфигуратором по RDP буду работать, чтобы конфигуратор локально находился.
Ну а потом UpdateDBCfg
То же самое с выгрузкой баз, и работой с хранилищем, реиндексацией, и прочими нужными вещами.
Я и на винде только скриптом обновления накатываю - в конфигураторе чтобы обновить приходится тыкнуть десяток раз на кнопки, причем между тыканьем кнопок приходится ждать по несколько минут или десятков минут, мне банально времени своего жалко.
Так оно без запуска графической оболочки еще и шустрее заметно работает.
На той же винде если обновление в конфигураторе накатывается 10минут, то с командной строки за 3-4минуты проскочит.
Нет, это ненормально. УНФ-ская конфа должна быстро загружаться. У меня на виртуальном сервере с Убунтой таких тормозов на этой конфигурации не было. Точно не помню, но сохранение явно было не дольше 10 минут (возможно даже в рамках 5 минут - уже года 3 не обслуживаю их сервер, просто забыл).
Мысли в слух:
1) Диск далеко не SSD и вообще на последнем издыхании.
2) Диск в порядке, но система в бесконечном свопе.
3) Администратор сервера урезал доступ к ресурсам для процессов сервера 1С (cgroup или подобное).
Пинги по разному шли 5-10-20. Но проблемы были на нашей стороне, а Хетцнер выдавал отличный канал связи. Вот только конфигуратором я пользовался прямо там (на хостинге), а потому все было довольно быстро.
Если Конфигуратор на другом конце Интернета...
Давай подумаем - при работе конфигуратора локальная копия конфигурации находится в локальном кеше единым файлом. Когда нажимаем на сохранение инициируется передача копии из кеша на сервер 1С с запись в СУБД в таблицу ConfigSave (где, на сколько я помню, делается единая запись с данными конфигурации). Т.е. выполняется копирование на сервер единого 400Мб-файл. Т.е. часы уходят на то, что бы скопировать один файл и записать его в СУБД.
Далее при обновлении БД происходит копирование конфигурации БД (из таблицы Config) на локальную машину и выполняется сверка с локальной копией (точно знаю, что принудительно сохраненная копия с сервера не получается и при рассинхронизации кеша возможны проблемы). Далее запускается локальное сравнение и при необходимости формируется пакет патчей (выдается пользователю вопрос для подтверждения внесения правок в структуру данных), который далее отправляется на сервер (обе конфигурации там уже есть, а потому пакет должен быть от килобайтов, до нескольких мегабайтов при условии мелких правок, которые у автора занимают часы), а на сервере правки транслируются в альтертейблы, апдейты и инсерты, которые выполняются местной СУБД (постгря).
На самом деле все тонкие места с легкостью проверяются. С помощью Варшарка/Фидлера/(любимый снифер) засекаем тайминги и размеры пакетов обмена с сервером 1С. Далее лезем в логи Постгри и смотрим тамошние тайминги - когда и что делалось. В результате имеем понимание, какого именно ресурса нехватает и куда копать дальше.
Еще раз повторюсь: часовые затраты на обновление УНФ - это ненормально. Как же ERP будет обновляться? Сутками? :)
Простой
Простой
