ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

15.11.23

База данных - HighLoad оптимизация

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

Меня зовут Антон Дорошкевич. Я из города Новосибирска, компания «ИнфоСофт». В мои должностные обязанности, помимо прочего, входит обслуживание клиентов по РКЛ.

За несколько лет обслуживания мы накопили топ задач и вопросов, которыми я хочу поделиться со счастливыми обладателями КОРП-лицензии на платформу 1С.

Зачем поделиться?

  • Во-первых, этот топ вопросов оказался для нас неожиданным. Когда мы готовились оказывать услуги по расширенной корпоративной лицензии, мы готовились вообще к другому.

  • Во-вторых, узнать о возможных проблемах будет полезно тем, кто планирует в ближайшее время купить лицензии КОРП. Он хоть поймет, где больно почти у всех и куда нужно рулить, чтобы не заехать в тупик.

 

Крупная компания – это когда у тебя более 500 пользователей в базе

 

 

 

Начнем не с проблемы, а с вопроса, встречающегося почти у 99% пользователей 1С, которые чувствуют себя крупными. Вопрос звучит так: «Когда вообще нужен КОРП? Когда на него переключаться?»

Тут просто миллионы заблуждений.

Самое главное из них: «У меня все тормозит, я сейчас куплю КОРП, там все будет летать». Многие думают, что фирма «1С» сделала так, чтобы покупали КОРП – поставила на обычную ПРОФ-платформу «двигатели», у которых мощность меньше. А если поставить КОРПовый движок, машина сразу поедет.

Такого не будет. У вас все тормозило, а когда вы купите КОРП у вас все будет тормозить в два раза дороже. Это все, чего вы добьетесь. Никакой скорости КОРП сам по себе не дает.

КОРП нужен, только если у вас в одной базе вот-вот станет больше 500 пользователей. Все остальные ограничения ПРОФ-версии платформы, по сравнению с корпоративной, либо легко обходятся масштабированием кластера, либо вообще не критичны.

Критично ли для вас 12 ядер на сервере 1С? Нет. Не критично. Гораздо дешевле поставить еще один сервер, пусть даже виртуальный. Если у вас стоит какой-нибудь монстр на 96 ядер, нарежьте его по 12 ядер, поставьте на каждый виртуальный сервер лицензию ПРОФ за 90 тысяч и пользуйтесь дальше. Не нужно ради этого обновлять все лицензии на КОРП.

Таким образом можно легко нивелировать или обойти почти все ограничения, кроме одного – 500 пользователей. Если у вас 500 пользователей в одной базе – вам нужно переходить на лицензии КОРП, других шансов нет.

Да, когда вы не на КОРПе, вы не можете использовать профили безопасности, ограничения ресурсов, счетчики производительности в кластере. Но я вам честно скажу – и на КОРПе их используют крайне редко. По-настоящему это нужно только тем, кто предоставляет клиентам свой Фреш или Облако.

Да, есть в КОРП очень гибкая настройка Требований назначения функциональности (ТНФ) в разрезе баз, типов клиентов, указания конкретного регламентного или фонового задания, тут надо трезво оценить нужна ли вам такая гибкость.

КОРП нужен только крупным компаниям. По мнению фирмы «1С», крупная компания – это когда у тебя 500 пользователей в базе. Если у тебя 500 пользователей в базе нет – ты чуть меньше, чем крупный, и тебе КОРП особо не нужен.

 

Что такое РКЛ?

 

 

Когда компания уже купила КОРП-лицензии на платформу – возникает главный вопрос: «Что такое РКЛ? Зачем это вообще?»

80% пользователей считают, что это просто налог 15%, который нужно заплатить фирме «1С», потому что она хочет денег. Больше никаких мыслей.

Так вот, это не налог. Да, деньги. Да, надо платить. Но РКЛ – это не просто деньги, которые вы отдали за право обновлять КОРП-платформу.

На самом деле РКЛ – это год работы. Вы оплачиваете год техподдержки.

Первую линию техподдержки вам будет оказывать ваш франч, причем тут у франчей есть очень серьезные ограничения – РКЛ могут оказывать только те компании, у которых в штате есть эксперты по технологическим вопросам. Без экспертов по технологически вопросам оказывать РКЛ фирма «1С» запретит.

Очень часто как раз первая линия решает возникшую проблему из-за того что имеет на поддержке много КОРП-систем и скорее всего уже столкнулась с вашей или похожей проблемой. Для систем время работоспособности которых критично для бизнеса это очень важно.

Более того всё жёстко регламентировано в том числе и по скорости реакции: https://consulting.1c.ru/upload/adminFiles/services/reglament-corp-tech-podderzhky-polzovateley_1sept2023.pdf

 

 

Заблуждение: КОРП – это не про скорость

 

И тут у заказчиков возникают большое заблуждение, многие думают: «О, классно! Мы сейчас купим КОРП и РКЛ, и у нас все заработает быстрее. У них же там ЭТВ-шники, они будут эти вопросы решать!»

 

 

Не заработает. И решать они эти вопросы не будут.

Очень важно, что РКЛ отвечает только за ошибки платформы – помогает вам расследовать причины поведения платформы.

  • Никакой оптимизации кода для скорости в РКЛ не входит.

  • Никаких анализов технологического журнала, чтобы у вас заработало быстрее, в РКЛ не входит.

Этого не будет делать ни первая линия техподдержки, ни фирма «1С», которая стоит дальше.

Что представляет собой корповая поддержка фирмы 1С?

  • Во-первых, это другой email-адрес – не v8@1c.ru.

  • Во-вторых, в этой техподдержке фирмы «1С» реально отвечают за 24 часа. Там отвечают не стандартной фразой робота: «Здравствуйте, соберите технологический журнал». Там отвечает реальный специалист, по-человечески – он все проверит, попросит что-то сделать и будет с вами реально на связи.

Даже если вы забьете на эту проблему, вам надоест собирать технологический журнал, вы не захотите или не сможете создать тестовую среду, чтобы подтвердить на ней эту ошибку – вы забьете на эту ошибку, а 1С уже нет. Специалисты с корпоративной поддержки фирмы 1С будут вам напоминать письмами: «Ну что там у вас? Когда развернете? Или нам закрыть обращение?» Классная мотивация, потому что закрывать страшно, но если ты ничего не сделаешь, они тебе помочь не смогут. Простая техподдержка вас не мотивирует что-то делать, а эта техподдержка мотивирует.

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

Хорошие РКЛ-щики занимаются и скоростью – они распарсивают ваши технологические журналы, указывают вам на то, где у вас больно. Они за вас код не перепишут – хотя, может, и перепишут, если отдельно договоритесь. А так, они вам хотя бы укажут:

  • где больно;

  • где скоро будет больно;

  • где массовая маленькая операция;

  • где большая долгая операция.

Мы как-то делали для одного клиента парсинг технологического журнала за неделю – там в топе оказалась операция, занимающая огромное количество времени, которая за неделю выполнялась миллионы раз. Проверяем – это регламентное задание. Как мы все относимся к бэкграунд-джобам? Да и пусть занимает, что такого-то? Но мы на всякий случай спросили, что оно делает? И нам ответили: «Это фоновое собирает данные для отчета для чувака, который уже уволился, и этот отчет больше никто не смотрит».

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

Т.е. с РКЛ-щиками работать эффективно – они на вас снаружи смотрят и заставляют еще раз подумать.

 

Что происходит в мире РКЛ?

 

 

Но давайте разберемся, если РКЛ-щики не отвечают за скорость, за что они отвечают? И что там в этом мире РКЛ вообще происходит?

Первое, за что отвечают партнёры, продавшие вам РКЛ (далее буду называть именно их - РКЛ-щики) – это настройка ваших СУБД. Любых. Ваши РКЛ-щики обязаны знать, как настраивать MS SQL и PostgreSQL. Если вы обращаетесь к своим РКЛ-щикам, а они говорят, что у них нет специалистов по СУБД – такого быть не может. Требуйте с них. Это не налог. Это их работа в течение года. Они обязаны вас консультировать. Они не лезут и не настраивают вам кнопочки. Они смотрят и выдают рекомендации. Они обязаны это делать – и по PostgreSQL, и по MS SQL.

Помимо настройки СУБД, они обязаны вас консультировать по настройке кластеров 1С – разбираться, как вам сделать несколько центральных серверов, как настроить требования назначения функциональности, уровни отказоустойчивости. Они должны знать все-все-все галочки и циферки во всех настройках кластера 1С. Это их прямая обязанность. Они обязаны вас насчет этого консультировать – таким образом они повышают стабильность вашей системы.

РКЛ-щики должны быть экспертами, уметь анализировать и настраивать систему. Причем в КОРПе настройки СУБД – это очень маленький процент задач. Мы только пару раз за несколько лет кому-то что-то настраивали. Если бы там что-то было неправильно настроено, оно давно бы легло. Вряд ли у вас пользователи настолько терпеливые – если бы они терпели такое, это уже на уровне мазохизма было бы.

 

Лицензирование КОРП платформы: проблема с лицензиями через USB-ключи

 

 

А вот с чем очень часто бывают проблемы и вопросы – это, как ни странно, лицензирование. Никто не может понять, как работают лицензии.

Да и вообще вопросов по лицензированию очень много. Все почему-то считают, раз лицензии программные, значит их расход учитывается по сессиям, и на одном компьютере нельзя запустить 15 баз 1С, используя одну лицензию. Это заблуждение, так можно. Просто учет лицензий будет сложнее. Купите двадцать программных лицензий – там будет помимо 3-х сетевых пин-кодов ещё 20 локальных пин-кодов. На каждом компьютере введите этот код и вперед – хоть по 800 1С-ок на этом компьютере запускайте, съестся одна лицензия, потому что она локальная.

Самое ужасное происходит при обновлении USB-шных ПРОФ-лицензий до КОРПовых.

Вот были обычные USB-шные ключи с ПРОФ-лицензиями, понадобилось их обновить на КОРП – это обновление происходит привязкой программной лицензии КОРП к ПРОФовой USB-шке, после чего у вас все становится КОРПовое.

Этот ужас обновления USB-шной ПРОФ-лицензии до USB-шно-программной КОРП-лицензии прекрасно работает, но только до тех пор, пока у вас не случается один очень интересный сценарий.

Допустим, у вас есть ПРОФовая флешка на 500 пользователей. Раз вам нужно 500 пользователей – вам нужна лицензия КОРП. Вы обновились, к вам приехала коробочка с бумажечкой программной лицензии, и вы привязали к этой флешке файлик программной лицензии.

Казалось бы, вы все сделали правильно, но это работает только до тех пор, пока все доступные лицензии на этой флешке не будут заняты. Как только пользователи реально займут все лицензии на этой флешке, из вашего общего пула мгновенно исчезнут 500 КОРПовых лицензий. 
Это именно, если флешку сервер видит по сети через настройки файла nethasp.ini, если же флэшка установлена локально на сервер, то даже при занятии всех лицензий программная лицензия успешно пройдёт проверку привязки.

Сервер 1С КОРП постоянно считает, сколько ему доступно корпоративных клиентских лицензий. Для этого он опрашивает сервер лицензирования. Или, если он сам является сервером лицензирования, опрашивает сам себя – постоянно это пересчитывает. Проверяя лицензии в очередной раз, он обратится к файлу лицензий, файл лицензий ему скажет: «Я привязан к этой флешке», а флешка ответит: «Лицензий нет». При этом сервер выдаст ошибку и выгонит ваших 500 пользователей.

Допустим, у вас на сервере стоит 2000 корпоративных лицензий – 4 флешки по 500. При этом все пользователи могут заходить на сервер со своими локальным ПРОФ-лицензиями, если у каждого на компе стоит еще по флешке. Они заходят с ПРОФ, но всех пускают. При этом используется функциональность КОРПа, потому что сервер 1С видит, что ему на всех пользователей корпоративных лицензий хватает – используются они или нет, неважно.

Но в том сценарии, о котором я рассказал, у вас мгновенно выключатся 500 корпоративных лицензий. Сервер получит информацию, что ему доступно только 1500, и 500 пользователей из ваших 2000 выгонит, они все получат ошибку. 1501-й пользователь не может войти, пока та лицензия не освободит хотя бы одну штуку.

К чему я так долго про лицензирование? Вы можете обложиться любыми отказоустойчивыми системами. Сделать 800 кластеров, 500 реплик, но как только вы потеряете одну лицензию, система вашим же бизнесом будет признана неработоспособной вообще. При этом вы будете думать, что у вас все работает. Админы счастливы, нагрузки нет, все кайфово, но никто зайти не может.

Поэтому призываю – уйдите от USB, от этой технологии 20 века – перейдите на программные лицензии целиком, проапгрейдьтесь до конца. Хватит быть киборгами. Давайте уже станем все программными.

Причем все, что я рассказываю, написано на ИТС – но вы попробуйте почитать ИТС и понять это.

 

Кластер 1С: чем проще, тем лучше

 

 

Следующий момент, который очень много пьет крови у корпоративных заказчиков, как ни странно – это кластер 1С.

Наверное, надо расшифровать картинку: на картинке сота меда, а кластер 1С – это огромная ложка дегтя туда.

90% проблем у корпоративных заказчиков связаны с кластером 1С. Глючит, повис, сожрал память, перестал пускать пользователей, что-то с лицензиями и т.д.

Несмотря на то, что платформа 1С – это лучшая в мире платформа, ни у кого такой крутой платформы больше нет, все проблемы на КОРПе, по моему опыту, связаны либо с некорректным поведением кластера 1С или с его некорректной настройкой.

Мы отсекаем код 1С. Понятно, что кодом 1С можно положить все что угодно – это РКЛ вообще не касается. Все остальные проблемы – это кластер 1С.

Что с этим делать?

Бесплатный совет – максимально упрощайте свои кластерные системы. Не надо стремиться в монструозные кластеры.

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

Не надо делать четыре центральных сервера. Зачем? Что за риски ядерной войны вы туда заложили? Для любой отказоустойчивой системы два центральных сервера – выше крыши. Понятно, что отказ центрального сервера – это авария, админы вскочат и побегут его чинить. Но, пока они чинят тот центральный сервер, который сломался, второй центральный выдержит.

Не надо монструозить. Монструозные схемы очень сложно расследовать. Чтобы повторить вашу ошибку и сгенерить ваш уникальный случай, нужно набрать такой же набор серверных лицензий и поставить рядом такую же тестовую систему. В итоге все это оказывается большим «черным ящиком», который нельзя починить. И мы работаем от сбоя к сбою. Так не надо.

Не бывает КОРПов с одной базой. В любом случае баз несколько. Но не старайтесь все базы засунуть на один мегакластер. Проблем будет больше.

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

Остальные базейки – ЗУП, БП, Документооборот, еще что-нибудь – выносите на отдельные сервера. В этом случае не надо экономить на серверной лицензии. Будет проще жить. Намного проще и в итоге дешевле.

 

Полнотекстовый поиск

 

Дальше будет две смешных проблемы – владельцы файловых баз нас даже засмеют, что в КОРПе это вообще проблема. Но, оказывается, это проблема.

 

 

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

На самом деле, проблема еще шире – она не только в полнотекстовом поиске, она вообще в поиске. Когда пользователь начинает что-то искать в большой базе – это кошмар и ужас.

Этот совет я уже говорю три года, он помаленьку в мозг проникает, но еще раз скажу – удаляйте поле общего поиска со всех форм. Пользователи будут плакать, угрожать начальством. Удаляйте все равно, потому что обучить пользователей поиску через сочетание клавиш Alt-F вообще нереально. У нас останется один путь – удалить общее поле поиска, тогда поиск будет происходить просто по набору символов в нужном столбце.

Следующий момент там же – это сортировки в динамическом списке. Кошмар. Ужас. Никому нельзя позволять это делать. Программно удаляйте все нафиг, кроме сортировки по дате либо по номеру, которые являются индексированными полями. Не дай бог у вас будет сортировка в динамическом списке по полю, которое получается через точку. Вообще кошмар. К сожалению, платформа 1С настолько крута, что дает столько возможностей пользователю, что любой пользователь вам повесит всю систему за миллиард долларов. Вообще в легкую. Поэтому сортировки должны быть под запретом – установите ограничение программно, и все лишние поля в списке уберите без возможности их достать.

Тут надо понимать что пользователи делают такие настройки в динамическом из-за того что не могут дождаться от 1С-ок нужных отчётов и превращают список в отчёт.

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

Если хотите, чтобы поиск работал, как в Яндексе, сервер под него нужен, как в Яндексе – с двумя терабайтами оперативы и массивом из nvme. Отдельный – чтобы на него требованием назначения функциональности угонять весь полнотекст.

И раз мы КОРПы, должны быть отказоустойчивыми, то и второй сервер нужен такой же – когда этот сломается, все туда должно переехать. Но когда он туда переедет, несколько часов полнотекстовый поиск работать не будет – он будет заново формировать полнотекстовый поиск. Ему его неоткуда взять.

Вот смешная проблема, но она есть. Следующая проблема еще смешней.

 

Журнал регистрации

 

 

Копий об журнал регистрации сломано много – вести его или нет, в каком режиме его вести, логировать все или только ошибки и т.д.

Но у КОРПов есть такая мегаслужба – называется «Служба информационной безопасности». Казалось бы, эти ребята вообще-то наши друзья айтишники, но они из какого-то другого мира, и им плевать на наши айтишные проблемы производительности. Они требуют вести журнал регистрации целиком. Мы говорим: «Вы же раз в пятилетку туда заглядываете для одного запроса» – «Ну и что? Нам нужно это иметь».

Так вот – разделите журнал регистрации на часы. Не надо вести журнал регистрации в днях, годах на проде.

Три дня назад у одного нашего РКЛ-ного клиента возникла проблема – центральный сервер ВДРУГ просто остановился. Посмотрели по Zabbix – там видно, что неожиданно, буквально за три минуты, сервер выжрал сто процентов оперативной памяти и остановился.

Оказалось, что проблема возникла еще вчера, но админ очень хотел спать, и, надеясь, что ночью ничего не произойдет, поставил везде в настройках кластера для управления памятью минус один – жри оперативки сколько хочешь, ни на что не реагируй. Это раз.

До этого 1С могла срубать сеансы, а теперь она ничего не срубает, ей запретили.

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

И когда админ утром просто попытался что-то искать в журнале регистрации, rmngr выжрал всю память, и сервер упал.

Ситуация – смешная, она выеденного яйца не стоит. Но она привела к остановке корпоративной системы на три часа.

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

Что делать?

  • Первое – журнал регистрации должен быть разделен на часы.

  • Второе – в продуктовой базе от журнала регистрации должен быть доступен только последний час максимум три. Все остальное тупо скриптом переносится в другую папку и архивируется. Иначе при поиске вы рискуете положить все.

  • И третье – хотите анализировать журнал регистрации, делайте это не на продуктовой площадке. Сформируйте себе отдельную площадку, желательно вообще с файловой базой – и ищите там. В файловой базе по журналу регистрации все вообще кайфово ищется. Либо выгружаете все в ElasticSearch или ClickHouse – и ищете там через SQL-запросы.

В общем, 1С в КОРПе должна отвечать за запись журнала регистрации, но ни в коем случае не за поиск по нему.

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

Это смешная проблема, но она очень массовая. Она почти у всех. Я сейчас рассказываю только о массовых проблемах и вопросах.

 

Переход на Linux

 

 

Следующий момент. Сейчас все переходят на Linux, и это вызывает много вопросов – людям непонятно, как жить с 1С в мире Linux.

Да, переходим, других вариантов нет. Единственное – пожалуйста, разделите процесс перехода на три этапа:

  • Первым этапом на Linux должна переехать СУБД PostgreSQL.

  • Вторым этапом на Linux уезжает сервер 1С. Это очень больно, потому что вам придется переписать весь техдолг, до которого не доходили руки. Вам придется отказаться от COM-объектов – это очень больно. Мы об этом говорим уже много лет, но когда у вас в 1С тянется информация из источников, которые никак, кроме COM, ADO, ODBC и т.д. не умеют отдавать эту информацию… Попробуйте сейчас в данном железном занавесе санкций и ухода ПО, заставьте разработчика того иностранного ПО написать вам API, чтобы что-то получать по нему в вашей СУБД. Очень больно. Это нужно очень долго планировать – даже не знаю, как вам тут помочь. Это просто большой проект.
    Не рассчитывайте, что у вас получится быстрее, чем за полгода переключить сервер 1С на Linux. Но есть небольшой лайфхак. Почти всегда все, что связано с невозможностью перехода с Windows на Linux в сервере 1С – это обмены. А обмены – это почти всегда бэкграунд-джобы.
    Но поскольку вы все – счастливые обладатели корпоративной платформы, где конкретные регламентные операции можно выгнать на отдельный сервер, используя требования назначения функциональности – так и сделайте.
    Ваши регламентные операции на COM-объектах унесите на отдельный сервер с Windows. И там потихоньку их по очереди исправляйте. Одно исправили, чтобы на Linux работало – можно убрать это фоновое задание из требований назначения. И так вы помаленечку переедете – будет уже не так больно.
    Кстати, помимо всяких обменов, очень у многих на серверах выполняется обработка документов Microsoft Office – Word и Excel. Это тоже надо будет переписать на механизмы БСП

  • И уже только на третьем этапе переводите на Linux ваших конечных клиентов. Там вся проблема в подключаемом оборудовании и в отсутствии сервером терминального доступа на базе Linux. Больше там вроде бы проблем никаких нет.

В целом, я рассказал почти обо всем, что у КОРПа болит. Для нас было очень неожиданно, что у КОРПа больше всего болит кластер 1С, журнал регистрации и полнотекстовый поиск. А теперь еще и новая проблема – переход на Linux.

Дорошкевич Антон, с заботой о вас и вашей 1С.

 

Вопросы

 

Вопрос по последнему пункту. Что даст переход сервера 1С на Linux?

У каждого перехода есть какая-то причина.

Например, если у вас для какого-то нового проекта разворачивается новая площадка, у вас других вариантов нет – только Linux. Вы сейчас не можете купить Windows. Это раз.

Второе. КОРПы есть и в госсекторе – они там обязаны исполнять приказ Минкомсвязи. Других шансов нет. Под козырек и пошел.

А если вы на Windows, вас все сейчас устраивает и никто не заставляет переходить на Linux (госсектор, политика компании и так далее) – ничего не трогайте. Пусть все работает. В этом случае переходить на Linux имеет смысл только ради PostgreSQL – и то там только СУБД перевести, сервер 1С не надо трогать.

Пока сервер 1С стабильнее всего работает на Windows. Да, это будет меняться, но сейчас это намного стабильнее. В фирме «1С» тоже не волшебники – они не могут вам за три дня сделать, чтобы все уже на Linux работало. Им нужно какое-то время.

Но, опять же, что бы ни делала фирма «1С», COM-объекты по Linux не заработают. Linux не знает такого слова. Поэтому код ваших конфигураций вам все равно придется переписывать. И всякие интеграции с системами не через API придется переписывать.

Если пользователи работают на терминальных серверах, есть ли какой-то опыт перевода под Linux?

На Linux не существует нормально работающих серверов терминального доступа.

А что делать? Валить, да?

Если конфигурация на неуправляемых формах, есть три варианта:

  • Первый – перевести на управляемые формы.

  • Второй – перевести на локальную работу.

  • И третье – написать веб-оболочку хотя бы для 80% ваших пользователей. Пусть они в вебе тыкают.

Под Linux не существует серверов терминального доступа работающих с нормальной скоростью. Все варианты, которые есть, сделаны через SSH – это тормозит примерно после третьего-четвертого пользователя. Тормозит так, что у вас просто меню «Пуск» открывается минут шесть на любых мощностях.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

 

Group 2087327209 (1).png

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    7326    Evg-Lylyk    61    

42

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    4287    spyke    28    

48

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    6501    vasilev2015    20    

40

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    10254    208    ZAOSTG    74    

111

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    4434    glassman    17    

40

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    9413    doom2good    49    

70
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1950534 15.11.23 14:55 Сейчас в теме
rphost-ов разве не больше на лицензии КОРП, чем на проф? В рамках одной ИБ?
5. a.doroshkevich 1423 16.11.23 14:10 Сейчас в теме
(1)нет, количество рпхостов на иб не регулируется версией лицензии, это регулируется количеством соединений на процесс в настройках рабочего сервера
2. Bitnikov 391 15.11.23 18:44 Сейчас в теме
Отличная статья! Спасибо.
Поправлю только то, что в ПРОФ версии (8.3.23) нельзя вынести даже все ФЗ на отдельный рабочий сервер, а не только конкретные. Есть официальный ответ по этому поводу от 1С:

Нет, так сделать нельзя, так как любое значение (даже без точки) в поле дополнительного параметра включает КОРП функционал. А указать там хотя бы "BackgroundJob" необходимо
4. a.doroshkevich 1423 16.11.23 14:08 Сейчас в теме
(2)обязательно проверю на 8.3.23 и отпишусь
Спасибо за замечание!
8. a.doroshkevich 1423 17.11.23 13:54 Сейчас в теме
(2)Андрей, а можете показать ТНФы серверов с приоритетами как пытались настроить?
9. Bitnikov 391 17.11.23 17:55 Сейчас в теме
(8) Антон, да, по ИТС
Прикрепленные файлы:
10. a.doroshkevich 1423 17.11.23 17:57 Сейчас в теме
(9) И что в итоге получали? Ошибку того что применяете КОРП функционал?

По документации - всё это должно работать на ПРОФе
По моим тестам 8.3.23 - это работает на ПРОФе

Тут или ошибка конкретной версии платформы или что-то в настройках ТНФ
12. Bitnikov 391 18.11.23 16:23 Сейчас в теме
(10) ТНФ применяются, но при входе в конфигурацию выдается сообщение об использовании КОРП функционала.
На ИТС, кстати, приведены эти примеры, но не написано четко это ПРОФ или КОРП функционал. Написал в 1С, первая линия ответила, что должно работать, я ответил что не работает, приложил эти скрины, далее получил от второй (или следующей) линии поддержки, что это КОРП функционал (их ответ выше). То, что заполнение значения дополнительного параметра как и Имени ИБ - это КОРП.
Прикрепленные файлы:
13. a.doroshkevich 1423 18.11.23 16:25 Сейчас в теме
(12) если такое поведение при настройках тнф, как вы показали, то это несоответствие документации, а значит ошибка, по моему мнению
Я бы в 1С ещё раз написал, только сразу предоставьте файлы реестра кластера
15. Bitnikov 391 18.11.23 20:34 Сейчас в теме
(13) Я не нашел явных противоречий того, что это поведение не соответствует документации. На ИТС написано, что ПРОФ позволяет использовать ТНФ в том случае, если в этих правилах не указываются дополнительные параметры. Правда в скобках перечислено не все и от этого присутствует какая-то недосказанность, но которую прояснили из официального ответа 1с) Я понял это так.
16. a.doroshkevich 1423 18.11.23 21:10 Сейчас в теме
(15) в том и дело, что для ПРОФ запрещено только то что в скобках перечислено
Ну тут смотрите сами)
19. svlasik 22.11.23 13:57 Сейчас в теме
(10)
По моим тестам 8.3.23 - это работает на ПРОФе

Запускали больше 10 сеансов?
До 10 сеансов на ПРОФ работает КОРП функционал.

По документации - всё это должно работать на ПРОФе

Серверная лицензия ПРОФ позволяет использовать требования назначения функциональности в том случае, если в этих правилах не указываются дополнительные параметры

для ПРОФ запрещено только то что в скобках перечислено

(имя информационной базы, имя приложения или вид фонового задания).
BackgroundJob - Имя приложения. В консоли администрирование будет отображаться именно так.
BackgroundJob.CommonModule - вид фонового задания
3. PerlAmutor 130 15.11.23 22:37 Сейчас в теме
Было бы неплохим "жестом доброй воли" со стороны 1С в платформах под Linux разрешить выносить фоновые задания через ТНФ на лицензиях уровня ПРОФ хотя бы на момент интенсивного импортозамещения, скажем на год-два.

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

А еще PostgreSQL сваливается в full scan, если во внешнем источнике данных есть индексы с полями типа int4 или просто достаточно маленького размера, чтобы преобразовать любимый 1С - numeric (даже numeric(6)) к int4. Тут никакие новые функции запроса типа ЦЕЛ() не помогут, и ВЫРАЗИТЬ() тоже (на выходе всегда numeric), только смена архитектуры таблиц (расширение размера). Как это ни странно, но в отличие от MSSQL, PostgreSQL в таких случаях просто берет значение каждого поля (напр. id), приводит его к numeric и сравнивает со значением. На табличках где десятки миллионов записей полное сканирование "доставит"... Еще если переписывать процедуры будете, то не забывайте, что в процедурах PostgreSQL все идет в транзакции, к тому же он версионник, а это значит что удаление таблиц, индексов и т.п. - все откатываемое при исключении и может потребоваться много места на дисках и хорошая их скорость, чтобы эти версии могли лечь рядом до финального коммита. Закупайтесь дисками.
Alex_Iz; ivanov660; v3rter; G.Shatrov; a.doroshkevich; +5 Ответить
7. paulwist 17.11.23 12:46 Сейчас в теме
(3)
Еще если переписывать процедуры будете, то не забывайте, что в процедурах PostgreSQL все идет в транзакции, к тому же он версионник, а это значит что удаление таблиц, индексов и т.п. - все откатываемое при исключении и может потребоваться много места на дисках и хорошая их скорость, чтобы эти версии могли лечь рядом до финального коммита.


Как-то двусмысленно написано ... ПГ использует транзакции, а MSSQL нет.
11. PerlAmutor 130 17.11.23 19:21 Сейчас в теме
(7) В MSSQL при входе в процедуру по-умолчанию включен режим AutoCommit. Чтобы откатить все сделанные в процедуре изменения необходимо обернуть её в TRY..CATCH, явно открывать транзакцию. Т.е. в MSSQL процедуры больше похоже на скрипты, если явно транзакцию не открыть в TRY..CATCH, то можно в начале процедуры удалить таблицу, потом на каком-то участке кода получить исключение и таблица удаленная в самом начале обратно не вернется. Процедуры в PostgreSQL можно сравнить с обработчиками событий 1С: ПередЗаписью, ПриЗаписи, ОбработкаПроведения, где все идет в неявной транзакции.
14. paulwist 18.11.23 20:02 Сейчас в теме

(11)
2PerlAmutor
Что-то я не очень понял ваше обьяснение «на пальцах», могли бы вы привести код демонстрирующий такое поведение!

А-ля
Создаем соединение
Устанавливаем автокоммит
1. Код-скрипт для MSSQL
2. Код-скрипт для ПГ
6. coollerinc 192 17.11.23 12:24 Сейчас в теме
Прочитал и не понял, для чего нужна КОРП лицензия? Только понял, что появляется хорошая тех.поддержка, которая может хорошо проконсультировать по производительности.
17. ivanov660 4547 19.11.23 22:09 Сейчас в теме
(6)Если у вас в базе одномоментно меньше 500 пользователей, то скорее всего она вам не нужна. Если больше, то придется покупать.
18. Zwe3do4et 19.11.23 23:32 Сейчас в теме
Второе – в продуктовой базе от журнала регистрации должен быть доступен только последний час максимум три. Все остальное тупо скриптом переносится в другую папку и архивируется.

подскажите пожалуйста, как и чем это делается?
additive; +1 Ответить
20. a.doroshkevich 1423 22.11.23 14:01 Сейчас в теме
(18)
1. В Конфигураторе 1С настраиваете разбивание ЖР по часам
2. Пишите скрипт для вашей ОС, который будет каждый час забирать файлы ЖР, созданные более 3 часов назад и перемещать в другой каталог, лучше ещё и архивировать
ivanov660; +1 Ответить
21. Gilev.Vyacheslav 1916 16.07.24 17:15 Сейчас в теме
Жалко что так позно прочитал эту весёлую статью )))
"Многие думают, что фирма «1С» сделала так, чтобы покупали КОРП"
И правильно думают, для этого и разделили, чтобы больше бабла рубить. И выкручивать руки чтобы покупали более дорогую версию, и при этом 1с могла отмазываться - мол мы вас не заставляли, вы сами деньги принесли.
Если бы не хотели чтобы покупали корп, то и платформы не стали делить на корп и проф.
22. Gilev.Vyacheslav 1916 16.07.24 17:28 Сейчас в теме
" Гораздо дешевле поставить еще один сервер, пусть даже виртуальный. " Если на физический сервер с Windows Server поставить роль Hyper-V Server, то даже не успев еще внутри развернуть виртуалку, если база 1с работает на физике, то она словит замедление с высокой вероятностью.
Если же на голое железо поставить проксмокс к примеру и две виртуалки (два сервера 1с виртуальных), то большой штраф по скорости то же высоковероятен.
Восколько в итоге обойдется по стоимости такая "дешевизна" большой вопрос.
Еще терпимо можно было бы предложить контейнеры потестить, но не вот это всё...
Прикрепленные файлы:
Оставьте свое сообщение