Как уменьшить размер в 1С?

Сравнение размера пустой базы для разных версий 1С

Те пользователи, которые всегда работали только в одной из версий 1С, не могут себе представить, что с каждым серьёзным обновлением (с выходом новой версии) размер информационной базы конфигураций 1С:Предприятие всё возрастает и возрастает. Для примера возьмём 1С:Бухгалтерию начиная с версии 7.7 и сравним размеры пустых баз, то есть только что созданных. Сравнивать пустые базы проще, поскольку иначе пришлось бы брать базы с одинаковым количественным и качественным составом документов, что, согласитесь, требует как минимум специально создать такие базы. Если есть желание — можете на досуге этим заняться, но я просто предпочитаю сравнить пустые базы (этого более чем достаточно).

Также хочу уточнить понятие «пустой» базы 1С для тех, кто не в курсе. При создании новой информационной базы из шаблона в неё уже закладывается вся конфигурация, то есть это много-много программного кода и других нужных для работы данных, так что размер тут в любом случае будет больше нуля. А вот насколько больше…

Давайте сравним размеры пустых информационных баз для версий 1С:Бухгалтерии 7.7, 8.2 и 8.3:

  • версия 7.7: 150 Мб;
  • версия 8.2: 450 МБ;
  • версия 8.3: 650 Мб;

Цифры несколько приблизительные. В любом случае видно, что с каждой новой версией увеличивается не только размер самой платформы 1С, но и размер информационной базы. Причём речь идёт об увеличении размера базы в несколько раз.

Технические особенности работы в 1С:Бухгалтерии 8.3 рассматриваются наряду с ведением учёта в нашем специальном видеокурсе по данной конфигурации. Курс включает в себя 240 уроков продолжительностью 42 часа и предназначен для освоения программы с самых основ. Посмотрите примеры уроков и учебный план!

Дальше — больше!

Если говорить о 1С:Бухгалтерии, то размер её базы практически сразу после создания ещё больше возрастёт за счёт загрузки КЛАДР / ФИАС: адреса-то вводить как-то нужно! Загрузка адресного классификатора в базу приводит к очень серьёзному увеличению размера базы. Вот для сравнения данные по пустым базам 1С Бухгалтерия, в которые загружен весь КЛАДР:

  • версия 8.2: 1500 Мб (+ 1 Гб к пустой базе);
  • версия 8.3: 3000 Мб (+ 2,5 Гб к пустой базе);

Данные опять же достаточно приблизительные, но, тем не менее, первый вывод вполне ясен:

Важно!

Чтобы размер базы 1С неоправданно не возрастал, НЕ загружайте в базу весь КЛАДР / ФИАС без необходимости!

Полная загрузка этого справочника нужна только в том случае, если вам на самом деле нужно вводить адреса по всей России. Не загружайте справочник «на всякий случай». Если же он у вас уже загружен, то для уменьшения размера базы 1С удалите («выгрузите») лишние, неиспользуемые регионы и место, занимаемое информационной базой 1С, сильно уменьшится! Подробно про этот способ уменьшить размер базы 1С читайте .

Нет документа — нет проблемы!

Со временем в базе накапливаются старые документы, многие из которых уже никогда не понадобятся. Если массово избавиться от таких документов (и не только от документов, но и записей регистров и других данных), то размер базы можно существенно уменьшить. Возможно это стало начиная с версии 1С:Бухгалтерии 8.3, метод получил название «свёртка базы».

Если коротко, то вы можете выбрать некоторую дату, раньше которой документы вам уже не понадобятся, и «свернуть» базу при помощи специальной обработки из раздела «Администрирование».

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

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

Очистка журнала регистрации в 1С 8.3

Ещё один простой способ уменьшить размер базы 1С:Предприятие, если Вам кажется что её размер вырос в несколько раз. Что делать в таком случае? Нужно сократить размер логов информационной базы.

Здесь имеется ввиду файловый вариант информационной базы 1С.

У 1С:Предприятие 8.3 в папке с базой есть подпапка 1Cv8Log, в которой хранятся лог-файлы всех выполненных операций. Со временем размер логов может достигать очень значительного размера и даже значительно превышать объём собственно полезных данных Вашей базы. Особенно это заметно в тех случаях, когда база интенсивно используется.

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

Логи в 1С:Предприятии называются журналом регистрации. Вот его-то и нужно очистить.

Саму базу запускать не нужно. Откройте конфигуратор, выбрав Вашу базу, и выберите в верхнем меню пункт, показанный на скриншоте ниже.

В меню «Администрирование» выберите пункт «Настройка журнала регистрации «, после чего в открывшемся небольшом окне нажмите кнопку «Сократить» и укажите укажите дату, до которой нужно удалить данные из логов. После нажатия кнопки подтверждения (OK) в зависимости от размера лога может потребоваться некоторое (иногда значительное) время. Дождитесь завершения операции, после чего проверьте размер папки с базой 1С — размер должен уменьшиться.

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

Есть ещё один способ очистить журнал регистрации 1С 8.3. Для этого нужно просто удалить папку с логами. Обратите внимание, что в этом случае удалятся все логи!

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

Как ещё можно сжать базу 1С?

Вежливо попросить фирму 1С работать лучше. Очевидный случай — сжать базу архиватором, но это хорошо подходит только при резервном копировании. Например, если базу 1С с полностью загруженным КЛАДРом и занимающую порядка 3 Гб сжать WinRAR-ом, то размер архива составит всего-то 300-350 Мб, то есть база уменьшится аж в 10(!) раз. Советую иметь это ввиду перед копированием базы. Архивация занимает некоторое время, но однозначно того стоит.

Прочие методы сжатия базы 1С я тут приводить не буду.

Сжимать или не сжимать?

С точки зрения обычного пользователя 1С, размер базы особого значения не играет. Многие вообще не знают, где эта самая база находится, не говоря уже о том чтобы задумываться об уменьшении её размера (вспоминают при переносе базы на другой компьютер).

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

У многих пользователей при работе с конфигурациями на платформе 1С возникает вопрос: «Можно ли повысить производительность?» или «У нас при работе возникают блокировки, медленно работает база и долго проводятся документы».

На эти и другие подобные вопросы один ответ.

Да, можно оценить производительность системы, собрать подробную техническую информацию об имеющихся «узких местах» и затем проанализировать полученную информацию с целью дальнейшей оптимизации.
Для таких целей предназначен «Центр управления производительностью» (ЦУП) – инструмент для мониторинга и анализа производительности клиент-серверных информационных систем на платформе 1С:Предприятие 8. Основные задачи, которые могут быть решены при помощи ЦУП:

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

Основные причины неприемлемой производительности системы:

  • Неоптимальные запросы;
  • Избыточные блокировки;
  • Взаимоблокировки.

Сотрудники нашей компании обладают необходимыми компетенциями и знаниями, а также практическим опытом повышения производительности информационных систем различной сложности и конфигурации. Квалификация подтверждена уникальными сертификатами «Эксперт по технологическим вопросам».

Мы всегда готовы помочь в решении проблем с производительностью любой сложности. С гарантией!

Основные причины неоптимальной работы запросов

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

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

Эти факторы могут прямо или косвенно повлиять на то, что запросы будут работать неоптимально. Но я буду, в основном, говорить именно про текст запроса, потому что это – самая основная и первая причина неоптимальной работы запросов.

Чем «портят» запросы программисты?

Как это выглядит? Я вам из Барнаула привез самолетик, к которому спроектировал довольно большое крыло в надежде на то, что он так лучше полетит. Но происходит примерно так: самолетик падает плашмя вниз. То же самое с запросами. Разработчик, предполагая использование в запросе каких-то навороченных решений, может воспроизвести такой текст запроса, который «не полетит», поскольку его результат становится тяжелым, как и в случае с этим самолетиком.

Итак, сконцентрируемся на тексте запросов. Что может «утяжелить» запрос? Здесь перечислены основные причины такого «утяжеления», про все это подробно написано на всем известном сервисе http://its.1c.ru/, очень доступном, открытом – вы можете принимать это во внимание.

Безусловно, самым часто встречающимся случаем является неиспользование отборов внутри виртуальных таблиц. Я думаю, что нет ни одного разработчика 1С, кто не знает этого правила, однако в реальных решениях такие ошибки все-таки встречаются довольно часто. Причем их могут совершать даже разработчики с многолетним стажем

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

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

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

Почему-то иногда прикладные разработчики говорят: «подготовка подходящего покрывающего индекса – это не наша обязанность, мы же просто прикладные разработчики». Соответственно, когда нужно получить данные с отбором по полю A и C, они, не имея подходящего индекса, довольствуются тем, что происходит сканирование кластерного индекса или же таблицы.

Методика оптимизации запросов

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

Неожиданные результаты применения методики оптимизации запросов

Итак, методика оптимизации запросов у нас имеется, вы можете ее использовать, все замечательно. Однако ее практическое применение может оказаться с неожиданными результатами. Я о таких неожиданных результатах знал давно, поэтому специально для доклада подготовил несколько примеров.

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

Справа показаны замеры скорости исполнения, сделанные с помощью всем известной обработки с диска ИТС «Консоль запросов для управляемого приложения 8.3», позволяющей видеть затраты на исполнение запроса для сервера MSSQL. Как вы видите, в данном случае использование временной таблицы не привело к более быстрому результату, поскольку затраты на ее создание оказались более существенными, чем работа с вложенным запросом. Такое очень часто встречается на практике.

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

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

Другая ситуация: я нередко вижу, что разработчики, используя правила составления запросов, описанные на ИТС или где-то еще, искаженно воспринимают информацию в части, например, работы с вложенными свойствами полей составного типа.

Например, на слайде показан текст запроса, демонстрирующий обращение к полю составного типа «Регистратор» (а именно к его вложенному свойству «Контроль цен»). Здесь видно, что запрос, в конечном счете, не производит обращения к документу «Реализация товаров и услуг», поскольку свойства «Контроль цен» у этого вида документов нет, и, соответственно,сама платформа не генерирует никаких дополнительных левых соединений. А на практике я встречаю чрезмерные усилия разработчиков (не всех, конечно), направленные на то, чтобы исключить лишние источники данных, хотя они в этом случае и так не будут подключены. И это тоже нередко встречающаяся ситуация.

Фильтрация внутри виртуальных таблиц

Еще одна интересная ситуация – это фильтрация внутри виртуальных таблиц.

Как вы понимаете, использование параметра «Отбор по периоду» при получении актуальных данных не требуется. И если произвести получение остатков на актуальную отметку времени без использования этого параметра, мы получим данные с использованием одного источника – физической таблицы итогов. А при указании в этом значении любого подходящего периода (например, будущего времени сегодняшнего дня, который тоже будет указывать на необходимость получения актуальных остатков), у нас уже произойдет получение данных из двух источников – таблицы итогов и таблицы движений. И в результате мы получим значительное снижение производительности запроса. Такая ситуация тоже очень часто встречается.

Использование критериев отбора для получения некластеризованного индекса

Однако в возможностях, которые предоставлены нам платформой, есть и неявные способы повышения производительности за счет «неявного индексирования» (так я назвал этот способ). Например, если нам необходимо осуществить выборку данных по табличной части документа с отбором по номенклатуре, то в случае, если этот реквизит табличной части не проиндексирован, мы можем получить низкопроизводительный запрос. Поэтому, если мы хотим, чтобы у нас был построен индекс для эффективной выборки данных с отбором по этому полю, мы можем воспользоваться способом «неявного индексирования» – добавить критерий отбора. При этом мы получим необходимый индекс для такой выборки, не усложняя себе работу по обновлению текущей конфигурации в дальнейшем.

И опять же, эта теория описана на ИТС.

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

Неправильное использование критерия отбора

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

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

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

Как правильно оптимизировать запросы?

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

  • Самое главное, на что хотелось бы обратить внимание, это то, что прежде чем приступить к оптимизации того или иного запроса, необходимо выяснить, как часто он выполняется и нужно ли его вообще оптимизировать. Если запрос исполняется один раз в три года, то смысл в такой оптимизации отпадает.
  • Также я хочу отметить самую распространенную, на мой взгляд, причину неоптимальной работы запросов – это получение «лишних» данных. Иногда достаточно всего лишь «отсечь» ненужные источники, чтобы запрос «полетел». Отбросить лишнее, на мой взгляд, является самым первым, что вам необходимо выполнить. Соответственно, я отметил это в начальных пунктах данного порядка оптимизации запросов.
  • Кроме этого, очень важно правильно оценить:
    • Стоимость исполнения запроса,
    • Затраты ввода/вывода,
    • А также затраты процессора на исполнение данной операции на стороне СУБД.

Для этого у нас есть специальная обработка «Консоль запросов для управляемого приложения 8.3», позволяющая при использовании сервера MS SQL визуально увидеть план запроса, затраты, понесенные на его исполнение, и пр.

  • Ну и, безусловно, не забывайте оптимизировать систему в тех же условиях, в которых она и работает.

Продукт для интерактивного изучения методов оптимизации запросов

Как вы видите, вся статья связана с демонстрацией практических результатов, которые я получил в процессе переписывания неоптимальных запросов. Но как научиться оптимизировать запросы, если нет подходящих инструментов? Размышляя над этим, мы решили создать продукт»Интерактивное изучение методов оптимизации запросов».

Это решение выложено на Инфостарте, есть даже бесплатный вариант, вы можете его использовать и получить эти навыки.

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

После проверки вашего решения (для этого есть специальная кнопка «Проверка») вы получаете оценку исполнения вашего запроса (производится сравнение времени исполнения вашего запроса и эталонного, текст которого вам изначально недоступен). Если ваши затраты меньше или равны затратам на исполнение эталонного запроса, ваш запрос является эффективно оптимизированным.

Если у вас возникают какие-либо сложности, вы всегда можете обратиться к информационной поддержке:

  • Представлены ссылки на краткие рекомендации методистов;
  • На материалы сервиса «Статьи ИТС»;
  • И, безусловно, дана сама инструкция, которая содержит текст эталонного запроса. Вы можете использовать этот эталонный запрос, пройти задание и увидеть, в чем же была разница между вашим запросом и оптимизированным.

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

Решение опубликовано на сайте Инфостарт – //infostart.ru/public/374023/ .

Архитектура корпоративной системы интерактивного обучения

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

Порядок работы с сервером интерактивного обучения следующий:

  • Организатор обучения направляет учащимся приглашения к исполнению заданий или прохождению аттестации.
  • Руководитель подразделений, используя интернет-браузер или прямое подключение к информационной базе сервера интерактивного обучения, отслеживает результат. Для предоставления веб-страницы результата используется http-сервис.
  • Учащиеся получают доступ к заданиям посредством запуска обработки «Консоль изучения программ». Ее технология основана на использовании веб-сервисов – она очень легкая, не требующая каких-то мега-соединений, ресурсов и прочего. На нашем проекте мы видели одновременное использование сервиса количеством человек свыше 1000.

Вот пример той статистики, которую видит руководитель подразделения. Статистика генерируется http-сервисом «Сервер интерактивного обучения».

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

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

06.05.2016 Оптимизация 1С представляет собой комплекс мер, посредством которых достигают повышения скорости работы и стабильности системы.

Компания «Инсайт-Альянс» в рамках услуг по сопровождению программных продуктов 1С и технологического обслуживания предлагает сервис по комплексной и частичной оптимизации 1С-продуктов. Оптимизация продуктов возможна как на стадии установки, так и в уже работающей системе существующих бизнес процессов.

Услуги по технологической поддержке и оптимизации систем 1С предназначены для предприятий, работающих с высоконагруженными системами «1С: Предприятие 8». Практика показывает, что проведение работ по оптимизации приложений 1С требуется в компаниях, которые:

  • используют сложные территориально-распределенные системы;
  • эксплуатируют сложноинтегрированные информационные системы совместно с программой «1С:Предприятие 8»;
  • задействуют более 100 сотрудников для работы в одной информационной базе «1С:Предприятие 8»;
  • работают с объемами данных от 5 ГБ в одной базе.

Симптомы необходимости в оптимизации продуктов 1С варьируются от ярко выраженных хронических сбоев до периодически возникающих проблем:

Жалобы пользователей на

  • Неприемлемую общую производительность системы.
  • Неприемлемую производительность на отдельных операциях.
  • Внезапное ухудшение производительности.
  • Частое возникновение сообщений о блокировках.

А также:

Долгое проведение документов.

Скорость выполнения критичных бизнес-операций не приемлема требованиям бизнеса.

Оптимизация запросов 1С

Значительная часть проблем, приводящих к неоптимальной работе запросов, может быть обнаружена путем анализа кода конфигурации и структуры метаданных. Имеется перечень типичных ошибок в коде и структуре данных, последствия которых достаточно хорошо изучены и легко предсказуемы. Анализ кода с использованием этого перечня позволяет решить большую часть проблем с производительностью запросов, не углубляясь в детальную техническую информацию (текст запроса на языке SQL, план запроса и т.д.).

Основные причины не оптимальной работы запросов, диагностируемые на уровне кода конфигурации и структуры метаданных:

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

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

Оптимизация баз 1С

Как правило, оптимизация баз 1С (как SQL так и других) требуется в случаях:

  • количество пользователей 1С превышает 30
  • медленное построение отчетов
  • медленно проводятся документы
  • возникают конфликты блокировок

Выполнение специалистами «Инсайт-Альянс» работ по оптимизации 1С позволяет достичь следующих результатов:

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *