Развернул распределенку. 4 территориально удаленных филиала(отдельных юр. лица) на БУХ 3.0 КОРП для регламентного учета. Обмен через FTP

Возникло несколько вопросов - на тему как с этим овном люди работают.
1. Рабочие процессы дико жрут память (до 75 ГБ)
2. Базу вообще нельзя обновить через конфигуратор - жмешь завершить все сеансы, однако сеансы не завершаются(постоянно появляются фоновые задания). Что реально нужно включать блокировку регламентных заданий перед каждым обновлением ? (перезапуск агента не помогает)
3. БУХ корп была обновлена до релиза 3.0.37.32 - файл обмена в узлы сформировался 330 мб (!!!) Просто охренненно, если учесть что Распределенка используется в тех местах где нет устойчивого(и быстрого) интернет канала.
4. Далее эти 330 мб никак не могли в течении суток загрузиться в узлы. Причина была установлена - оказывается регламентное задание в ценнтральной базе каждые 15 минут перезатирало файл обмена - это просто шикарно. То есть при загрузке в узел файл не блокируется(!!) - а тупо перезатирается в момент чтения - гениальное решение ... В 8.2 УПП РИБ и 8.2 КА РИБ таких проблем не было.
5. Не работает отказоустойчивый кластер (но это на всех форумах уже  обсосано)

(0) ну ничего) у меня файл обновления в рознице РИБ 500)) Причина тупая. Выгружается весь ЦФник я так понимаю. Нигде не находил решения)

Еще возможно что на удаленных узлах будет не хватать памяти при обновлении ну если только там не 64-bit)

(1) только в одном 32, в других 64

Я пока полностью не разобрался в том какие мне регламентные задания и когда нужны - тупо отключил все. И поэтапно включал. Уже не первый месяц все норм. Только с обновлениями проблемы с длительностью.

Первое обновление релиза прошло без проблем, а второе - 330 мб. Из этого следует что он CF не выгружает.

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

но он cf выгружает если ты вносил изменения в конфу если изменений нет то cf не должен грузится

cf он вообще не выгружает никогда - только измененные объекты конфигурации.

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

Помогло только удаление папки C:\Program Files (x86)\1cv8\srvinfo\reg_2541

Вот поэтому я и отказался от РИБ в БП еще в 2.0. Намучился я сними

(7) У меня всегда выгружается cf если было на главном узле какое-либо не значительное обновление\изменение. Странно конечно как-то. А вот как бороться с тем что очень долго обновляет иной раз я хз %)

(10) проверь сообщение обмена - не может такого быть.

В одной базе прогрузилось сообщение обмена - через конфигуартор обновили - далее в режиме предпрития обвновление застыло на 5% . За сутки ничего не поменялось - 5%

Была найдена статья http://infostart.ru/public/185679/

Отвязан узел от РИБ - далее только после этого приянлос обновление в режиме предприятия. Далее опять привязали к РИБ и запустили обмены.

Потом возник следующий нюанс - несмотря на многократные обмены с центральной базой - у пользователей выскакивало сообщение "Обновление базы не завршено ... обратитесь к администратору". В итоге пользователь с админскими правами зашел и нажал кнопку "Синхронизировать и продолжить" и только тогда все заработало.

Кто же с этим работает то ? Что же за хрень, такой стыд.

(12) Ну с отвязкой у меня в самом начале один раз был инцидент)) но фигня война))

(12) Нет, правда, при изменении в конфигурации последующая выгрузка хранит инфу по методанным. Иначе как объяснить рост файла обмена с пары мегабайт до 500-600?!?!

Я единственное что внутрь его не заглядывал. не до того было. Просто конфу менять нельзя. Так что играем с тем что есть))

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

В любом случае - открываешь перед синхронизацией обработку - Регистрация изменений для обмена - там видно все измененные данные(необязательно лезть в файл обмена).

В целом все со скрипом прошло.

Сейчас у нас все управленческие программы с большим числом пользователей сидят на 8.2 и переводить что-то работающее в режиме 24/7 на 1с 8.3 - глупость.

По обмену FTP - докачки нет, рвется и недокачивается (особенно на больших файлах обмена).

Релизовали обмен - через локальный ресурс = папка + яндекс диск. Крутитсся хорошо, файлы обмена до 400 мб отрабатывает отлично.

Предположение: после обновления релиза - в файл сообщений пишется целиком конфа поставщика (в текущем релизе весит 288 мб). Обычно после обновления файл обмена весит 320-340 мб.

1)Это какая у тебя база и как настроено что 75гигов оперативки кушает?
2)Ну так настраивать надо чтобы они предсказуемо появлялись.
Выставляй определенное время. Оставь достаточный перерыв для обновления.
3)Нормальный размер для обновления. В чем проблема?
Канал узкий? А при чем тут 1с?
4)Ну если криво настроил зачем кого то винить?
5)Кластер это в первую очередь шикарные каналы связи.
Какой нафиг кластер если у вас распределенка? Вещи просто несовместимые.

В общем РИБ вещь вполне работоспособная, но не надо от нее ждать чуда.
Для начала долгая вдумчивая настройка. А не тыкнуть пару кнопок по инструкции вычитанной на сайте, и надеятся что все будет отлично.

(18)На хреновых каналах FTP вообще трудно использовать. Даже если не про 1с речь.
Неплохо работает btsync, хотя не из коробки надо кой какие настройки подкручивать. Зато качает тихим сапом, на любом канале. И файл появляется только после полной загрузки.
Т.е недокачанного файла в принципе быть не может.

(19) дружок джамп ...

1) Ну меня другая база на 400 ГБ на 1с 8.2 в работе 24/7 - и там память жрет 3 ГБ процесс. А эти базы бух 3.0 малюсенькие, и процесс отъел 75 гб - из-за того что релиз 1С 8.3 косячный очередной раз.

2) Согласен

3) Ненормальный размер. Это ошибка что пишется вся конфигурация поставщика в файл обмена (должны только изменения писаться). Канал узкий и нестабильный ? Для этого РИБ и нужен, иначе все бы использовали терминальный доступ.

4) Что где криво ? в зеркале ?

5) Кластер не имеет отношения к обмену, не имеет отношения к распределенке. Кластер был поднят на центральной базе - и он нихрена не работает - о чем было обсуждения на многих тематических форумах. Отказоустойчивый работал в 8.2, а в 8.3 его сломали и не починили до сих пор. Ждем новых релизов 1С

6) РИБ работает у меня на 1С 8.2 УПП 400 ГБ (два узла - обмен через FTP) и на 1С КА 8.2 350 ГБ (12 узлов - обмен через FTP). Так что не рассказывай что это такое - там много перепрограммировано и все работает несколько лет.

7) 1Сный FTP не поддерживает докачку. EPIC FAIL - громадный косяк, нелепость, позор, стыд и срам.

(21)
1)С тем что 8,3 вообще косячная я полностью согласен.
А вот РИБ - вполне себе работает, не хуже чем на 8,2
3)А какой размер обновлений там? И сколько весит конфигурация?
4)Ну так надо прикидывать за сколько вообще реально будет прокачиватся в филиалы и не допускать такой ситуации. Это админ должен думать, а не 1с.
6)Ну у меня тоже работает, на 8,2 довольно большой, на 8,3 мелочевка, на ней вроде никаких особых проблем не заметил.
7)Весь сетевой функционал от 1с в любых версиях это стыд и позор. Поэтому ежели нужна стабильная работа с сетевыми сервисами надо пользоваться сторонними решениями.