Экспертные работы. Оптимизация 1С.

• установка SQL без учета особенностей работы с системой 1С;
  
• установка сервера 1С прилагаемым помощником установки;
  
• развертка всех баз (и копий, и рабочих) на одном сервере 1С;
  
• Включение режима отладки на сервере 1С с рабочими базами, в том же кластере;
  
• регулярная отладка на рабочей базе новых доработок;
  
• регулярные динамические обновления конфигурации;
  
• отсутствие мониторинга и контроля параметров системы.
  

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

Если же информационная система создается «с нуля», то, начиная с этапа проектирования, необходимы консультации эксперта для предотвращения появления проблем в будущем.
В чём заключается работа эксперта?

1. Во время проектирования эксперт рассчитывает архитектуру и структуру баз данных;
   
2. во время разработки анализирует производительность запросов, ожидания на блокировках, наличие взаимоблокировок и другие найденные слабые места;
   
3. во время внедрения оптимизирует систему под задачи данной организации, занимается тонкой настройкой сервера 1С и сервера СУБД, выявляет проблемы, их причины и узкие места работы программы, находит лучшие решения проблем, оценивает и корректирует возможности масштабируемости системы;
   
4. во время эксплуатации выявляет проблемы, расследует их причины, находит оптимальные решения; работает над увеличением производительности и устойчивости системы путем определения регламентных процедур и анализа данных различных средств мониторинга, применения приемов ускорения прикладных операций и других мер; решает вопросы интеграции данной системы с другими системами.
   

В зависимости от целей обратиться за помощью эксперта можно на любом этапе работы.

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

• Настраивать сервер СУБД под работу именно с задачами 1С
• Не включать лишних служб сервера СУБД, если они не нужны еще для каких-либо нужд. Например, при использовании MS SQL Server для 1С минимально достаточно только службы компонента Database Engine и полного набора средств управления для настройки сервера. Все прочие службы, входящие в этот сервер СУБД, не будут использоваться сервером 1С. Но, если их установить, отнимут дополнительные ресурсы.
• Настраивать ежедневные планы обслуживания для реорганизации индексов таблиц, обновления статистики, очистки процедурного кэша. Если этого не делать, то со временем по неактуальной статистике и индексам оптимизатор сервера СУБД начнет строить неправильные планы выполнения запросов и время получения данных из базы возрастет.
• Настраивать еженедельные планы обслуживания для перестроения индексов таблиц. Последствия будут такие же, как и в предыдущем пункте, но операция более ресурсоемкая, и частота ее выполнения зависит от интенсивности добавления данных в базу. Если документооборот небольшой, то достаточно раза в неделю.
• Настраивать выгрузку полных бэкапов, и при необходимости – разностных бэкапов. При любой настройке конфигурации оборудования, операционной системы, серверов СУБД и 1С, все равно остается вероятность возникновения нештатных ситуаций, способных повредить или уничтожить данные базы. Очень важно к таким ситуациям быть всегда готовым. Поэтому следует организовать регулярную выгрузку полных бэкапов (как минимум раз в сутки). Это удобно делать средствами СУБД, поскольку процесс не требует слишком много ресурсов, не связан с отключением пользователей от базы на время выгрузки и выполняется сравнительно быстро. Если нужно иметь возможность восстанавливать базу не только на момент выгрузки бэкапа, но и на любой момент времени, то следует использовать еще и разностные бэкапы. Они запоминают не всю базу, а только отличия ее текущего состояния от состояния, когда выгружался полный бэкап. Такой вид бэкапа требует больше ресурсов, но и возможности дает расширенные.
• Ограничивать по доступной потребляемой памяти сервер СУБД. Если этого не сделать, то со временем сервер СУБД может захватить всю оперативную память, доступную операционной системе, и нехватка памяти приведет к медленной работе других процессов. Например, замедлится работа сервера 1С.
• Если сервер 1С и сервер СУБД находятся на одной машине, нужно использовать протокол Shared memory для обмена информацией между ними. По умолчанию используется протокол TCP/IP, но, если оба приложения стоят на одной машине, то и обмен между ними можно ускорить процентов на 30 только за счет включения Shared memory, то есть за счет обмена через оперативную память.
• Настраивать сервер 1С
• Устанавливать перезапуск рабочих процессов как минимум раз в сутки. В процессе работы сервер 1С резервирует под свои задачи некоторое количество оперативной памяти. Иногда могут возникать ситуации, когда задача выполнена, но, память под нее зарезервированная, по каким-то причинам не освобождается. В результате процессы занимают ресурсы, которые им в таком объеме не нужны.
• Ограничивать сервер по потреблению памяти. В процессе работы также возможны ситуации, когда из-за выполнения чересчур ресурсоемкого запроса или ошибки в коде конфигурации, сервер 1С начинает потреблять оперативную память неоправданно большими количествами. Чтобы такой сбой не влиял на работу остальных приложений и комфорт пользователей, нужно устанавливать показатель, превышение которого, сервер 1С будет считать проблемой и выполнять перезапуск проблемного процесса.
• Не включать на сервере с рабочими базами режим отладки. При включенном режиме отладки сервер 1С подстраивается под режим работы, при котором нужен постоянный перезапуск базы при ее отладке. Серверный контекст базы при старте первого сеанса в режиме отладки формируется не полностью и досчитывается по мере необходимости уже в процессе работы. В случае, если такой режим предполагает работу одновременно нескольких пользователей в базе, то одновременные запросы этих пользователей к метаданным могут также начать конфликтовать друг с другом, что приведет к замедлению работы системы.
• Для целей разработки и отладки разворачивать еще один экземпляр сервера 1С и его также настраивать по памяти и перезапуску процессов. При необходимости организовать работу разработчиков одновременно с работой пользователей в основной базе, можно без покупки дополнительных лицензий на сервер 1С. Следует поставить еще один экземпляр сервера 1С на ту же машину и настроить его иначе, чем основной. Например, включить на нем режим отладки. Такая установка невозможна с помощью предоставленного установщика, но делается легко посредством командной строки.
• Настраивать постоянный мониторинг состояния системы
• Сбор счетчиков по оборудованию в Performance Monitor в Windows по оперативной памяти, процессору, длине очереди диска (Memory\Available Mbytes, LogicalDisk\Free Megabytes, Processor\% Processor Time, Memory\Pages/sec, System\Processor Queue Length, PhysicalDisk\Avg. Disk Queue Length, Network Interface\Bytes Total\sec).
• Сбор логов технологического журнала и дампов по процессам сервера 1С. Наличие таких логов позволит в случае возникновения любой нештатной ситуации понять, что же именно произошло. Такой журнал собирает и фиксирует в отдельных файлах последовательность действий низкого уровня в процессах 1С. Имеет смысл всегда собирать сведения о событиях типов EXCP – ошибки и исключения процессов, CONN – события установки соединений с сервером, PROC – события процесса, влияющие на его дальнейшую работу, CLSTR – события изменения работы кластера.
• Настройка и сбор показателей APDEX по ключевым операциям, выполняемым пользователями в рабочих базах данных. Чтобы общение службы поддержки и пользователей системы было подкреплено не просто эмоциями и впечатлениями пользователей от работы с базой, а некоторыми количественными показателями, большинство современных конфигураций обладают встроенным функционалом, позволяющим собирать статистику в самой базе о времени выполнения и количестве выполнений некоторых критически важных для предприятия действий в базе. На основе этих данных рассчитывается показатель производительности каждого действия и системы в целом по международно признанной методике APDEX.
• Регулярный контроль отчета администратора по журналу регистрации на предмет наличия ошибок. Множество проблем, незаметных пользователю или не рассказанных вовремя пользователем, службе поддержки можно увидеть в обычном журнале регистрации базы данных. Чтобы упростить его анализ, можно использовать также включенные в большинство конфигураций отчеты администратора.
• Часть проблем решать административно
• Запрещать выполнять или максимально редко допускать выполнение ненадежных действий, вроде динамического обновления в рабочей базе. Нужно помнить, что динамическое обновление означает изменение конфигурации для части пользователей, которые вовремя перезапустились и сохранении старого варианта для другой части пользователей. Поэтому если применять такие возможности регулярно и не заботиться затем о тестировании-исправлении, нормальном обновлении и реструктуризации базы в монопольном режиме, то таких «старых» копий конфигурации может насобираться достаточно много. Сервер не всегда может эффективно обрабатывать все эти копии. Последствия могут быть самыми разными – от торможения выполнения операций в базе до нарушения бизнес-логики работы и повреждения данных.
• Не допускать отладки каких-либо механизмов на рабочей базе. В процессе отладки сеанс разработчика может на неопределенное время держать запущенной транзакцию в базе данных. Это означает, что все блокировки, наложенные в этой транзакции также будут висеть в системе неопределенное время и затруднять тем самым работу других пользователей.
• Всю разработку вести с использованием хранилища конфигурации с отдельными пользователями под каждого разработчика. Это значительно упрощает процесс поиска неисправностей после установки очередного обновления, при необходимости позволяет легко откатить конфигурацию на шаг назад после обновления.
• Все добавляемые в рабочую базу доработки предварительно тестировать на аналогичной по размеру и настройкам базе под пользователем с ограниченными правами. Производительность и работоспособность многих механизмов может сильно варьироваться в зависимости от объема данных, с которым работает механизм и дополнительных ограничений, накладываемых правами пользователя, под которым механизм запускается.
• Постоянно проверять показатели мониторинга и в случае выявления отклонений принимать упреждающие меры по устранению возможных проблем. Не всегда, чтобы диагностировать негативное изменение в системе, нужно ждать, пока это изменение будет замечено пользователем. Зачастую все такие отклонения видны заблаговременно в собранных данных о состоянии сервера.



Позвоните нам сегодня +7-495-989-70-50 или напишите на почту info@erp2b.ru

Мы стремимся предоставить нашим клиентам высочайший уровень поддержки Написать сейчас!