Размер базы в 1С УВС при работе в последней версии через API 2.0

Столкнулись с проблемой, что после перехода на новую версию 1С УВС,
которая поддерживает 2.0, у нас размер базы стал расти нереальными темпами.
3 GB в сутки. Поддержка "выражает удивление" и ничего более.
Сервер просто трещит и разваливается.
Да, эту информацию можно чистить хоть ежедневно,
проблема в таблице, куда пуляются все ответы из Меркурия,
этот лог никому не нужен, но процедура очистки не спасает от того,
что через базу пролетают гигабайты.
По нашим расчетам, если запустить все, рост в сутки будет 10 Gb.
Тогда все сервисы на 1С умрут. Даже новый сервер не спасет от такого.
Надо арендовать датацентр целиком.

У кого есть подобные проблемы, или никто не ушел дальше тестового примера на 2 строки?

Чрезмерное количество информации. Тупо отключить большую часть регистрируемой информации.
Либо настройками, если есть такая возможность. Либо через программиста.

Это мы понимаем.
Проблема в том, что модуль взаимодействия с Меркурий там закрыт и отключить не получится.
ввести настройки просим от разработчика, а он говорит - запустите очистку за последние дни.
Как будто это изменит обработку сегодняшнего.

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

TWAIN wrote:Это мы понимаем.
Проблема в том, что модуль взаимодействия с Меркурий там закрыт и отключить не получится.
ввести настройки просим от разработчика, а он говорит - запустите очистку за последние дни.
Как будто это изменит обработку сегодняшнего.

Требуйте от них. Или пригрозите от отказа программного продукта с возвратам средств. Типа перейдете на другой продукт. Ко их сейчас хватает.
Пусть сделают техническую возможно, при том что это не сложно. Или открывают Вам модуль и вы сами все сделаете.
P.S. как вариант можно изменить процедуру записи в регистр/журнал. После записи, сразу чистить. Для этого в их модуль лезть не надо.

Мы то требуем. Пока ответ, перефразируя, такой: "не может быыыыыть! ну сотрите лишнее".
Поэтому я и хотел поискать у кого еще есть такая проблема.
Требовать возврат средств поздновато, т.к. осталось всего ничего и работы сделано много.
Хотя очень хочется уже. И так 26 марта выпустили 2.0, а только 19 апреля оно заработало.

TWAIN wrote:Мы то требуем. Пока ответ, перефразируя, такой: "не может быыыыыть! ну сотрите лишнее".
Поэтому я и хотел поискать у кого еще есть такая проблема.
Требовать возврат средств поздновато, т.к. осталось всего ничего и работы сделано много.
Хотя очень хочется уже. И так 26 марта выпустили 2.0, а только 19 апреля оно заработало.

Добрый день! Проблема решена в релизе 2.0.2.3, релиз уже выпущен.

Каким местом она там решена? Мы установили его вчера и отработали сутки.
+3 гб.
Структура данных не изменилась, то есть размер одной записи.
Все по прежнему валится в лог, то есть количество записей.
Откуда ждать чуда?

В описании релиза сказано, что решена только проблема создания огромного объема темповых файлов при загрузке входящих ВСД.
У нас рост от производственных и исходящих транспортных операций.

TWAIN wrote:Столкнулись с проблемой, что после перехода на новую версию 1С УВС,
которая поддерживает 2.0, у нас размер базы стал расти нереальными темпами.
3 GB в сутки. Поддержка "выражает удивление" и ничего более.
Сервер просто трещит и разваливается.
Да, эту информацию можно чистить хоть ежедневно,
проблема в таблице, куда пуляются все ответы из Меркурия,
этот лог никому не нужен, но процедура очистки не спасает от того,
что через базу пролетают гигабайты.
По нашим расчетам, если запустить все, рост в сутки будет 10 Gb.
Тогда все сервисы на 1С умрут. Даже новый сервер не спасет от такого.
Надо арендовать датацентр целиком.

У кого есть подобные проблемы, или никто не ушел дальше тестового примера на 2 строки?

Работаем через УВС, тоже 2.0, на данный момент порядка 100-120 ВСД в сутки оформляется, база весит 1,3 Гб.
Сколько вы в сутки оформляете, раз такой прирост получается?

У на заводах -производителях тоже документов немного, порядка 400 на выпуск и 400 на отпуск.
Но, взведя статус заявки мы дальше стоим и курим в сторонке, пока система отправляет запрос в Меркурий,
получает ответ, отправляет повторный запрос и т.п. И вот каждый текст этих запросов и ответов сохраняется в базе.
На один документ делается несколько запросов. Всего там 3295 записей в журнале за сутки.
Но как я понимаю, размер каждой записи может быть огромным.
Судя по всему записи не переменной длинны,
либо там выделено адское пространство под запись по умолчанию, либо она динамически меняется.
Если второе, она может динамически увеличиваться но не уменьшаться - тогда один раз
у нас прошла адская портянка и теперь каждая запись у нас весит по 849 кб.
Либо размер структур таблицы меняется динамически в обе стороны и тогда получается,
что у нас иногда проходит пара запросов в сутки такой длинны и все остальные автоматически увеличиваются.
Возможно я не очень хорошо понимаю, как работают в 1С записи переменной длинны, но точно не как у нас в основной СУБД.

Журнал состояний если его скопировать за сутки и вставить в текстовый файл будет весить за сутки 10 Мб.
Это регистр из старой версии.
В новой версии добавился "Журнал загрузки данных по ВСД".
Нашел запись, она легко находится просто ходя по по ним, какая долго открывается,
у нее текст ответа 725 кб. судя по начинке это транспортный документ на несколько десятков строк.
<vd:vetDType>TRANSPORT</vd:vetDType>.
Если вы создаете на одну ВСД один транспортный документ, тогда у вас будет все компактно.
Если вы создаете в одном транспортном документе много записей, допустим 30-40 ВСД,
тогда текст ответа у вас составит до 1 мегабайта. Все записи у вас расширятся до этой величины и вуаля.
Почему я могу это понять потратив полчаса, а разработчики этого не могут - мне непонятно.
Я 1С "второй раз вижу", они там всю жизнь крутятся.

Думаю, если сделать запрос остатков или списка номенклатуры, размер ответа составит вообще нереальную величину

Нашел запись на 2 мегабайта. Это говорит о том, что возможно переменная длинна
реализована в каком-то виде, но имеются записи оооочень длинные. Все 3000 руками перебирать я уж не буду.

Сергей Шевченко wrote:

TWAIN wrote:Мы то требуем. Пока ответ, перефразируя, такой: "не может быыыыыть! ну сотрите лишнее".
Поэтому я и хотел поискать у кого еще есть такая проблема.
Требовать возврат средств поздновато, т.к. осталось всего ничего и работы сделано много.
Хотя очень хочется уже. И так 26 марта выпустили 2.0, а только 19 апреля оно заработало.

Добрый день! Проблема решена в релизе 2.0.2.3, релиз уже выпущен.

Ну понятно. Кому писал, перед кем распинался?
"Мама сказала деньги в бидоне".