Как долго выгружается база 1с

Обновлено: 04.07.2024

Планируется переход на версию 8.3, поэтому на данный момент работают две платформу 8.2.19.83 и 8.3.5.1486. (ключ 64 битный)
7 баз 8.2 с кол-во пол-ей не более 30 (sql1)
5 баз 8.3 с кол-по пол-ей от 1-2 (sql2)

Имеем хаотические проблемы связанные с кластером 8.3 , периодически очень долго запускаются базы 8.3 ( от 30 -5 минут)
и вылетают пол-и из за нехватки памяти.

Были проделаны работы:

а) Оптимизация работа по памяти кластера 8.3
параметры кластера:
Интервал перезапуска:86400
Интервал превышения допустимого объема памяти:30
Включенные процессы останавливать через:30
Приоритет по памяти

параметры рабочего сервера:
Безопасный расход памяти 512мб
Объем памяти рабочих процессов, до которого сервер считается проивод 700 мб
Кол-во ИБ на процесс: 1
Кол-во соединений на процесс 25

Решило проблему с вылетами

2) Перенастройка клиентов на поиск лицензии со стороны сервера с исправлением файла на сервере nethasp.ini
NH_SERVER_ADDR = 192.168.112.18
NH_USE_BROADCAST = Disabled
В данном случаи у нас 30 лицензий программных и ключ на 10 на 18 сервере.

3) После старта службы агента 8.3 в логах зафиксирована проблема:

Сбойное приложение ragent.exe, версия 8.3.5.1486, штамп времени 0x54f76689, сбойный модуль rtrsrvc.dll, версия 8.3.5.1486, штамп времени 0x54f7685d, код исключения 0xc0000005, смещение ошибки 0x00000000000020f4, ИД процесса 0xcb4, время запуска приложения 0x01d065fa56ec19bd.

4) Была попытка переставить платформу (8.3) с нуля, но ошибка осталась.

5) Было принято решение совместить базы с первым скулем.

6) Технический журнал 1с отдан по ИТС поддержке, ошибок не обнаружено.

На данный момент все ВМ лежат к кластере Hyper-V. Из предполаемых решений только 2:

а) Разнести службы на разных пользователей
6) Сменить диапазон портов на 8.3 службе
в) Поднять 2012 r2 (запланирован переход инфраструктуры под hyper-v 3.0) и установить скуль внутрь машины, посмотреть что будет.

Когда кластер 1c функционировал только как 1с 8.2, объем памяти был равен - 2 гб с 1 ядром. И никаких проблем с производительностью никогда не было. Поэтому увеличение ОЗУ до 4 гб и ядер до 2- ух, обусловлено тем, что базы работают в тестовом режиме. Учитывая что все транзакции у нас обрабатывает скуль а запросы делает пользователь как толстый клиент. Выставлять большее значение я на тот момент не видел смысла. При чем проблемы зафиксированы в основном утром, неважно один человек заходит или 4 сразу. В середине дня проблем не зафиксировано.

P.S. 8.2 работает как и раньше, с ней все хорошо.

Победа далась не легко….
Я постараюсь описать все детально, хотя и прошло довольно много времени. Надеюсь информация, собранная мною поможет системным администраторам и даст пишу для размышления.
Перенес я базы на 1 скуль и переназначил я пользователя для 8.3 агента – не помогло…

Исколесил я наш рунет вдоль и поперек и нашел две интересные статьи, которые предлагаю и вам ознакомиться.

Покопавшись где-то с недельку и перепробовав несколько методик, проблему с первым запуском я решить не смог. Но заметил одну интересную закономерность… При работе тонкого клиента, второй запуск системы происходит почти моментально. Изменил настройки кол-во ИБ на процесс: 8 (баз на 8.3 пока что 5). В итоге так как на создание RPHOST сервер перестал тратить время при заходе в след. базу и оставшееся он тратил только на выгрузку конфы из скуля. Сократил время старта второй баз на 10-7 секунд.

Такой вариант меня в принципе устраивает полностью, учитывая, что с каждой базой работает по 7-10 пользователей, конфа держится постоянно в RPHOSTe и время захода равняется 4-8 секундам с аутентификацией вместе.

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

Но всплыл еще один неприятный момент, на одном из форумов я получил вот такой ответ:
Offtop. У вас лицензии КОРП?

Расширенные возможности сервера уровня КОРП «1С:Предприятия 8.3» по сравнению с 64-разрядным сервером уровня ПРОФ:
* безопасный расход памяти за один вызов;
* количество ИБ на процесс;
* объем памяти рабочих процессов, до которого сервер считается производительным;
* максимальный объем памяти рабочих процессов;
*стратегия балансировки (по памяти, по производительности);

Использование перечисленных функциональных возможностей при помощи продуктов «1С:Предприятие 8. Лицензия на сервер (x86-64)» уровня ПРОФ, то есть не имеющих в названии обозначения КОРП, является неправомерным.

Решил уточнить у ребята из трех разных компаний, знают ли они что есть платформа корп и проф. На что был получен ответ в виде: крутящегося пальца у виска и посылка на форум 1с. И вот ниже ответ от саппорта 1с:

Фактически при использовании Платформы ПРОФ ,согласно лицензии, можно использовать только дефолтные настройки кластера.

Если при настройках кластера "по умолчанию" у Вас возникают проблемы (нехватка памяти, невозможность обновить конфигурацию и тд), то
данное поведение является ошибкой (либо платформы либо данного прикладного решения).
Просьба с конкретными примерами создавать обращения на исправление.
На время исправления ошибки может быть письменно выдано разрешение (за подписью директора ЗАО "1С") на использования функционала лицензии Корп.
2) >>> Прошу уточнить, т.е. есть две платформы 8.3?
Нет. Платформа не текущий момент одна.
Однако право использования функционала КОРП появляется только при покупке соответствующей лицензии.
Программного контроля данной лицензии на текущий момент также нет.
Таким образом лицензия КОРП является больше юридическим понятием.

никак не можем выгрузить базу 1с. делаем так: конфигуратор-администрирование-выгрузка иб. очень долго что-то думает, потом выдает ошибку (точно не помню какую). раньше выбирали формат дбф, а теперь нет выбора., только дт. помогите.

1. какую ошибку ?<br>2. дбф было в 7ке

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

А прежде чем выгружать проверяли действительно ли место на диске есть?

да, место есть. просто нужно как-то заархивировать. может есть какие-нибудь настройки

раньше выгружали базу за 3 минуты, сейчас за целый день выгрузить не можем. Это после обновления и установки платформы 8.2

и сколько вашего места есть на диске и каков размер базы?<br>Вообще говоря, формат .dt всегда был в 8ке. Других не было для выгрузки. Он уже сжатый формат. Дополнительных настроек нет.

сколько места на с ?

7,06 ГБ. Вот опять написал, что недостаточно места. Я его на всю ночь оставляла выгружать. дак только утром закончил и выдал ошибку. Это нормально.

как же нам выгрузить эту базу, подскажите. Может другие способы есть. Мы это делаем для того, чтобы загрузить версию 2.0

Читают тему:

Мероприятия

1C:Лекторий: 25 ноября 2021 года (четверг, начало в 12:00) — Специальные механизмы в "1С:ЗУП 8" (ред. 3)

Где купить СОФТ
Вакансии фирм-партнеров "1С"

Центры Сертифицированного Обучения
Интернет курсы обучения "1С"
Самоучители
Учебный центр № 1
Учебный центр № 3

Сертификация по "1С:Профессионал"
Организация обучения под заказ
Книги по 1С:Предприятию

При использовании материалов активная прямая гиперссылка на перепечатанный материал обязательна.

Редакция БУХ.1С не несет ответственности за мнения и информацию, опубликованную в комментариях к материалам.

Редакция уважает мнение авторов, но не всегда разделяет его.

Дизайн сайта

Мы используем файлы cookie, чтобы анализировать трафик, подбирать для вас подходящий контент и рекламу, а также дать вам возможность делиться информацией в социальных сетях. Если вы продолжите использовать сайт, мы будем считать, что вас это устраивает.

Бухгалтерский учет для государственных учреждений Казахстана, редакция 4.0;
Бухгалтерский учет для государственных предприятий Казахстана, редакция 2.0;
Бухгалтерия для Казахстана, редакция 3.0;
Розница для Казахстана, редакция 2.0;
Управление торговлей для Казахстана, редакция 3.0;
Управление нашей фирмой для Казахстана;
Зарплата и управление персоналом для Казахстана, редакция 3.0;
и другие.

Совет 1. Регулярное тестирование и исправление информационной базы поможет ускорить 1С

Шаг 1. Копирование базы

Шаг 2. Тестирование и исправление информационной базы

Реиндексация таблиц информационной базы;
Проверка логической целостности информационной базы;
Проверка ссылочной целостности информационной базы;
Пересчет итогов;
Реструктуризация таблиц информационной базы.

При наличии ссылок на несуществующие объекты: очищать ссылки.

При частичной потере данных объектов: удалять объект.

Частота выполнения: один раз в 2-4 недели.

Совет 2. Улучшение аппаратных компонентов компьютера

количество оперативной памяти;
пропускная способность локальной сети;
производительность дисковой подсистемы.

Оперативная память (ОЗУ)

Локальная сеть

Не использовать нестабильное беспроводное соединение Wi-Fi, особенно при плохом уровне сигнала. В большинстве случаем Wi-Fi сеть не обеспечивает должной пропускной способности и стабильности.

Нужна стабильная сеть

Проверить стабильность соединения до основного компьютера: простейшая команда ping (ip-адрес-основного-компьютера) -t покажет общую картину.

Сетевой канал может резко терять стабильность на больших пакетах. Если обычная команда ping не выявляет потерь, то есть смысл проверить так:

ping server -n 100 -l 50000

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

ping server -t

Обмен пакетами с server [192.168.1.101] с 32 байтами данных:
Ответ от 192.168.1.101: число байт=32 время=1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=2мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=2мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=19мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=8мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=2мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=5мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=8мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=5мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=10мс TTL=128
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Ответ от 192.168.1.101: число байт=32 время=1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=2мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=4мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=19мс TTL=128
Ответ от 192.168.1.101: число байт=32 время=3мс TTL=128

ping server -t

Обмен пакетами с server [192.168.1.101] с 32 байтами данных:
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128
Ответ от 192.168.1.101: число байт=32 время<1мс TTL=128

С конфигурациями на основе управляемого приложения можно и нужно работать через тонкий клиент.

«Тонким» клиент называется потому, что умеет исполнять ограниченный набор функциональности встроенного языка. В частности на тонком клиенте недоступны все прикладные типы данных. Вместо этого тонкий клиент оперирует ограниченным набором типов встроенного языка, предназначенным лишь для отображения и изменения данных в памяти. Вся работа с базой данных, объектными данными, исполнение запросов – выполняется на стороне сервера. Тонкий клиент только получает готовые данные, подготовленные для отображения.

Пропускная способность 1 Гбит/с

Дисковая подсистема

Совет 3. Настроить работу в связке 1С+веб-сервер

Работа с файловой базой данных через веб-сервер возможна с помощью тонкого клиента или веб-клиента. Но, лучше использовать тонкий клиент. Он быстрее чем браузер примерно на 20%, а также может использовать локальные лицензии. Веб-клиент может использовать только клиентские лицензии сервера.

Чтобы завершить установку веб-сервера Apache необходимо установить его службой в операционную систему: запустить командную строку cmd с правами администратора и выполнить следующую команду:

Заполнить несколько полей:

Доступ к опубликованной базе с других компьютеров

Статический ip-адрес

У сервера должен быть статический ip-адрес. Ведь, если главному компьютеру будет назначен другой ip-адрес, то клиентские компьютеры не смогут получить доступ к информационной базе.

Блокировка порта веб-сервера

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: