Почему 1с долго сохраняет конфигурацию на сервере Linux?

Question

[webiru]

Установил сервер 1С на Centos + база на postgres. 1С сервер, клиенты и конфигурация последних релизов.
Доступ удаленный через интернет. База чистая.
Конфигуратор запускаю на windows, запускаю загрузку конфигурации УНФ (400 мб) - загружает около 3-4 часов.
При этом связь с сервером отличная, файлы таких объемов заливаются за несколько минут.
После загрузки конфигурации нажимаю обновление конфигурации и зависает опять на пару часов.
Любое изменение конфигурации и дальнейшее ее сохранение вызывает часовые ожидания.
Повторю, чистая база.
При этих ожиданиях нагрузка на сервере возрастает лишь на 10%, процессор загружается на 10-15%, диски тоже чуть-чуть.
Что за тормоза, кто-нибудь сталкивался?
Пробовал работать с загруженной конфигурацией, добавлять, редактировать информацию(как пользователь), все работает без тормозов...
Но с сохранениями кофигурации что-то страшное. Или так и должно быть?

Answer 1

[АртемЪ]

Конфигуратор запускаю на windows, запускаю загрузку конфигурации УНФ (400 мб) - загружает около 3-4 часов.

Где при этом лежит конфигурация? Уж не на компьютере ли случайно?
Если конфигурация на компьютере - это нормально.
Если конфигурация на сервере - это ненормально и надо смотреть где проблема.

Comments

[webiru]

Новую конфигурацию конечно с компьютера закачиваю. Ну а потом она же наверное должна на сервере храниться. Что-то изменю в ней и зависает на несколько часов

[АртемЪ]

webiru, Пинг до сервера 1с какой у вас?

[webiru]

АртемЪ, пинг 40 мс

[webiru]

ради эксперимента поставил сервер 1С + MS sql на свой старенький ноутбук.
локально(по 127.0.0.1) конечно изменения конфигурации происходят в течении нескольких минут, несмотря на то, что ресурсов тут вообще никаких нет, но 1С конфигуратор все делает быстро.
А вот клиент 1С уже тупит.

[АртемЪ]

webiru,

пинг 40 мс

Ну так и будет медленно работать с таким пингом.

ради эксперимента поставил сервер 1С + MS sql на свой старенький ноутбук

.Особой разницы тут нет какой именно скуль - MS или postgres
Особенность работы такая.
Локально все делается очень быстро, по сети немного подтормаживает, но не сильно критично если пинг низкий( в локальной сети) а вот издалека - это уже тормоза.
Cтавьте сервер разработчика рядом и работайте по RDP.
Хотя это конечно костыль.

Если работать нормально - не открывайте конфигуратор на продакшене вообще, нечего там делать.
Для разработчиков организуйте свой сервер рядом с ними, пусть с тестовой базой работают.
И все, никаких тормозов.

[webiru]

А зачем в данном случае быстрый пинг? При обновлении конфигурации миллиард запросов что-ли идет на сервер? Странная схема обмена данными.
Скорее всего на винде поставлю сервер и с конфигуратором по RDP буду работать, чтобы конфигуратор локально находился.

[АртемЪ]

При обновлении конфигурации миллиард запросов что-ли идет на сервер?

Именно так.

Странная схема обмена данными.

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

Скорее всего на винде поставлю сервер и с конфигуратором по RDP буду работать, чтобы конфигуратор локально находился.

А зачем??? Ну серьезно, зачем вам открывать конфигуратор на рабочей базе?

[webiru]

АртемЪ, а разве можно потом накатить модернизированную конфигурацию на рабочую базу без конфигуратора?

[АртемЪ]

webiru, Так кто мешает сделать это прямо на сервере?
Ставите платформу, и потом скриптом, что нибудь вроде -

/opt/1C/v8.3/i386/1cv8 \
  DESIGNER \
  /L RU \
  /VL RU \
  /S 'srv\db' \
  /N admin \
  /P admin \
  //UpdateCfg PathToYourConfig

Ну а потом UpdateDBCfg
То же самое с выгрузкой баз, и работой с хранилищем, реиндексацией, и прочими нужными вещами.

Я и на винде только скриптом обновления накатываю - в конфигураторе чтобы обновить приходится тыкнуть десяток раз на кнопки, причем между тыканьем кнопок приходится ждать по несколько минут или десятков минут, мне банально времени своего жалко.
Так оно без запуска графической оболочки еще и шустрее заметно работает.
На той же винде если обновление в конфигураторе накатывается 10минут, то с командной строки за 3-4минуты проскочит.

Answer 2

[Дмитрий Кинаш]

Нет, это ненормально. УНФ-ская конфа должна быстро загружаться. У меня на виртуальном сервере с Убунтой таких тормозов на этой конфигурации не было. Точно не помню, но сохранение явно было не дольше 10 минут (возможно даже в рамках 5 минут - уже года 3 не обслуживаю их сервер, просто забыл).

Мысли в слух:
1) Диск далеко не SSD и вообще на последнем издыхании.
2) Диск в порядке, но система в бесконечном свопе.
3) Администратор сервера урезал доступ к ресурсам для процессов сервера 1С (cgroup или подобное).

Comments

[АртемЪ]

Дмитрий Кинаш,

У меня на виртуальном сервере с Убунтой таких тормозов на этой конфигурации не было

А виртуальный сервер у вас далеко был? Какой пинг до него - 1мс или 60-100мс.

[Дмитрий Кинаш]

Пинги по разному шли 5-10-20. Но проблемы были на нашей стороне, а Хетцнер выдавал отличный канал связи. Вот только конфигуратором я пользовался прямо там (на хостинге), а потому все было довольно быстро.

Если Конфигуратор на другом конце Интернета...

Давай подумаем - при работе конфигуратора локальная копия конфигурации находится в локальном кеше единым файлом. Когда нажимаем на сохранение инициируется передача копии из кеша на сервер 1С с запись в СУБД в таблицу ConfigSave (где, на сколько я помню, делается единая запись с данными конфигурации). Т.е. выполняется копирование на сервер единого 400Мб-файл. Т.е. часы уходят на то, что бы скопировать один файл и записать его в СУБД.

Далее при обновлении БД происходит копирование конфигурации БД (из таблицы Config) на локальную машину и выполняется сверка с локальной копией (точно знаю, что принудительно сохраненная копия с сервера не получается и при рассинхронизации кеша возможны проблемы). Далее запускается локальное сравнение и при необходимости формируется пакет патчей (выдается пользователю вопрос для подтверждения внесения правок в структуру данных), который далее отправляется на сервер (обе конфигурации там уже есть, а потому пакет должен быть от килобайтов, до нескольких мегабайтов при условии мелких правок, которые у автора занимают часы), а на сервере правки транслируются в альтертейблы, апдейты и инсерты, которые выполняются местной СУБД (постгря).

На самом деле все тонкие места с легкостью проверяются. С помощью Варшарка/Фидлера/(любимый снифер) засекаем тайминги и размеры пакетов обмена с сервером 1С. Далее лезем в логи Постгри и смотрим тамошние тайминги - когда и что делалось. В результате имеем понимание, какого именно ресурса нехватает и куда копать дальше.

Еще раз повторюсь: часовые затраты на обновление УНФ - это ненормально. Как же ERP будет обновляться? Сутками? :)