Опрос: Переход на ПРОФ и КОРП лицензии 10.09.2019

(191) Автообновление тонкого клиента с веб-сервера была такая настройка, убрали со всех баз. Базы переопубликовали после этого.

Публикация список баз, это где посмотреть? Я надеюсь, что версия ПРОФ позволяет подключаться к опубликованной базе на сервере, через тонкий клиент более 10 человек?

(201)Добрый день! При попытки проверить, выходит такая ошибка

(216)Софтварные. Я прям в замешательстве уже не знаю, что и делать. Вроде как теоретические должно работать больше 10 чел.

(225) Поднимаете сервер лицензирования. Инструкция тут. При активации привязываете лицензии к ID любого аппаратного ключа от 1С8, можно локального, можно по сети раздаваемого HASP. Все лицензии можно привязать к одному ключу.

(236) Опасения понятны и если честно не могу сказать, что произойдет, когда количество сессий превысит номинал ключа - этот вопрос надо бы задать на ТП 1С.

(255)
А чего бы оно нестабильно работало ))) Проблема эта касается только 32-х разрядников.

Обострение возникло из-за двух факторов

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

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

Второй возможный путь - запуск батника, который висит на сайте ИТС, тупо грохает процесс по достижению его заданной границы. Если вы в linux, то границу можно прописать в systemd. По мне этот вариант противоестественен. Убивать процессы - это фу.

Эту ошибку 1С признала, но они не спешат её исправлять. Прошло уже почти пол года с момента её выявления, а воз и ныне там. Тянут резину, кормят завтраками. Иногда хамят. Номер ошибки 10213993.
Партнёры бузят тут https://partners.v8.1c.ru/forum/topic/1849661?page=1
Будем рады вашей помощи в этой ветке.
ИМХО 1С по вытесненяет клиентов с 32-х битных продуктов. Уже как-то слишком вызывающе весь этот процесс выглядит.


2) А во-вторых ограничили указание колиество баз, которые могут обслуживать один рабочий процесс. При обслуживании каждой базы рабочий процесс помещает в память существенный объём данных, а последующие соединения, которые он обслуживает занимают в памяти совсем немного. Таким образом если раньше вы могли указать, что например два процесса будут обслуживать две базы и каждый процесс выделит внутри себя место под одну базу, то выход за границы адресации не так вероятен, он по крайней мере контролируем. А теперь при значении 8 баз на процесс, процесс может схватить обслуживание 2,3 баз и достигнет предела при небольшом количестве соединений. То есть у вас вместо двух процессов, которые обслуживают большое количество соединений по двум базам, будет несколько каждый из которых обслуживает обе и небольшое количество соединений. Из-за этого ограничения ваша система будет жрать больше памяти (впустую) и в совокупности теперь с тем фактом, что 32-х битные процессы автоматически не перезапускаются, вы вообще не сможете нормально эксплуатировать 32-х битные системы.

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

Если по первому фактору всё-таки есть надежда на решение вопроса(хотя при такой активности партнёров - вряд-ли), по второму - нет.

Ситуация до боли напоминает вот этот отрывок из саус парка:
https://www.youtube.com/watch?v=IM2HnVMKI-g&