Меня зовут Антон Дорошкевич. Я из города Новосибирска, компания «ИнфоСофт». В мои должностные обязанности, помимо прочего, входит обслуживание клиентов по РКЛ.
За несколько лет обслуживания мы накопили топ задач и вопросов, которыми я хочу поделиться со счастливыми обладателями КОРП-лицензии на платформу 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.
