Главная страница

Практические задания администраторов UserH. Пользователь 8, он же UserH


Скачать 69.4 Kb.
НазваниеПользователь 8, он же UserH
АнкорПрактические задания администраторов UserH
Дата07.02.2023
Размер69.4 Kb.
Формат файлаdocx
Имя файлаПрактические задания администраторов UserH.docx
ТипДокументы
#924124

Пользователь _8, он же UserH


Все задания выполняются после подключения к учебному терминальному серверу
RDP study.gilev.ru:2089 , Логин UserH8, пароль QZ86Ax1*8x

Доступ в сервисы Gilev.ru: логин UserH, пароль UserH567

Все информационные базы на сервере 1С по адресу study2:30841

Доступ на сервер СУБД: STUDY2 , логин UserForBase1C , пароль UserForBase1C

Задание 1: совместно подберём сервер под потребности клиента


Нужно подобрать серверное оборудование для:
200 пользователей базы «Управление торговлей 11»
и 100 пользователей «Бухгалтерия Предприятия 3», на перспективу использования сервера в течение как минимум следующих трёх лет (за сколько лет данные в базах уже есть, текущие размеры баз на момент покупки сервера, а также любые другие требования требуется предложить самостоятельно из опыта).

Задание общее для класса: в терминальном сеансе создайте файл в Excel, сохраните в папке C:\Users\Public\Documents\подбор 2023-01 файл UserH.xls, куда подберите оборудование под эту задачу без фиксированного бюджета (нужны основные составляющие, без монитора, клавиатуры, кабелей и прочей мелочёвки). Оценку проводим без учёта стоимости лицензирования.

Затем в этом же файле рядом подберите оборудование под эту же задачу, но с бюджетом 450 тысяч рублей (цены например nix.ru, regard.ru, team.ru, любых других удобных онлайн-каталогов).

По итогу: обсуждаем балансировку нагрузки и резервирование, обсуждаем стратегии баланса конфигурации и цены.

Обсуждаем перспективы дальнейших действий в связи с ростом объёма данных и нагрузки на БД.

Задание 2: совместно решаем проблемы с закрытием месяца


Разбираем реальный случай: клиент испытывает проблемы со скоростью закрытия месяца. Обсуждается вариант возможности заменить процессор частотой 2 ГГц на некий другой. Диалог с представителем клиента:

К лиент: Если не хватает частоты, то должна быть загрузка процессора

Наш спец: Ну тогда мы зачем вам, если вы всё знаете и умеете

Клиент: То есть, хотите сказать, что это не так?!

Вопрос: есть ли ошибка в утверждении «частота процессора имеет значение, если процессор не загружен на 100%»?

Сначала 2-3 минуты каждый слушатель думает сам, без коллективных обсуждений, пишет свои аргументы на бумаге, затем коллективно обсуждаем и приходим к общему решению вопроса.

Задание 3: развернуть и запустить тест TPC


1. Создайте на сервере 1С новую базу: кластер серверов 1С:Предприятия - study2:30841, имя информационной базы в кластере – tpc_08, тип СУБД «MS SQL Server», сервер баз данных STUDY2, имя базы данных tpc_08, пользователь базы данных UserForBase1C , пароль UserForBase1C, флажок «Создать базу в случае отсутствия».

2. Загрузка файла dt с базой теста: в терминальной сессии найдите на диске C: папку C:\1с\сервисы, в ней файл GILV_TPC_G1C_83.dt, загрузите его в созданную базу.

Как это сделать: открыть базу в режиме конфигуратора, в разделе меню «Конфигурация» нажать «Открыть конфигурацию», затем в разделе меню «Администрирование» выбрать пункт «Загрузить информационную базу…», выбрать GILV_TPC_G1C_83.dt, в ответ на вопрос «Продолжить» нажать «Да», в ответ на «Перезапустить конфигуратор?» ответить «Нет».

3. Зайдите в созданную базу в режиме Предприятия, укажите в качестве имени пользователя UserH, далее нажмите «Не хочу сохранять пароль».

4. Кнопку «Выполнить тест» пока нажимать не надо. Нажмите её только по сигналу преподавателя, дождитесь окончания, сообщите результат преподавателю. Вторую часть теста запускать не нужно.

Задание 4: посмотреть отчет в сервисе APDEX


Подключитесь к терминальному серверу, запустите 1С Предприятие, в окне списка баз найдите группу «Сервисы (серверная часть)», в ней выберите базу сервиса APDEX.

Зайдите в эту базу в режиме Предприятия, логин Work с пустым паролем.

На появившемся экране приложения 1С выберите в окне «Информационная база» базу ApdexMain. В меню справа нажмите «Отчеты» - «Отчет по интервалам». В окне отчета выберите период с начала прошлой недели по текущую дату, выберите операцию «ОткрытиеОсновнойТаблицыАпдекса», в окне «Интервал» оставьте 1 секунду, нажмите «Сформировать».

Посмотрите, сколько на графике визуально операций выполнялось до 1 и 2 секунд, визуально сравните с более длительными выполнениями. Затем в окне «интервал» выставляйте последовательно от 2 до 6 секунд, каждый раз нажимая «Сформировать», и наблюдайте график – какие столбики будут лидировать, и насколько они будут выделяться среди остальных.

Вернитесь в главное окно программы, выберите информационную базу QueryTJMain, нажмите «Динамика производительности в показателях APDEX», выберите период с начала прошлой недели по текущую дату, посмотрите на изменение среднего времени операции QueryTJ_ПереносДетальныхДанныхВАрхивнуюБазу, а также на изменение количества операций QueryTJ_ЗаполнениеДанныхТоп.

Задание 5: настройка счётчиков загрузки оборудования

Теория


Основная задача сервиса Анализа загруженности оборудования (Hardware) – выявление наиболее «страдающих» компонент оборудования при пиковых нагрузках системы. Сервис позволяет оценивать степень загруженности компонент сервера и определять характер загрузки при анализе «узких мест» в работе оборудования. Результаты анализа также используются при анализе причин чрезмерных нагрузок на железо, создаваемых приложениями, и при подборе компонент серверного оборудования.

Схема работы сервиса


Данные «Performance Monitor» (о загруженности компонент ПК и состояния СУБД MS SQL Server) за период передаются в сервис, где обеспечивается их хранение и автоматический анализ превышения фактических значений относительно «порогов». Значения норм показателей работы компонент ПК («порогов») в сервисе заданы заранее, по необходимости, эти значения могут быть самостоятельно отредактированы.

• Решение проблем с производительностью MS SQL Server лучше начинать с анализа счетчиков производительности. Это позволяет сделать экспресс-анализ наличия проблем в коде, связанных с блокировками. Наличие блокировок снижает обычную загруженность оборудования, что может повлиять на корректность оценки о производительности оборудования.

• Для объективных выводов необходимо анализировать данные за длительный период. В сервис необходимо передавать данные за период, включающий дни с «обычной» нагрузкой и дни с пиковыми нагрузками на систему (ежемесячный расчет себестоимости, закрытие месяца, отчетный период, и дни с прочими факторами, влияющими на повышенную загруженность компонент оборудования). Тогда собранные данные позволят получить полное представление о проблемах на сервере, касающихся памяти, процессора и/или дисковых операций ввода/вывода.

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

Практика


1. Откройте инструкцию http://gilev.ru/hardwaresetup/ и ознакомьтесь.

2. Зайдите в терминальном сеансе в Пуск – Администрирование – Источники данных (ODBC)-64бит, в разделе «Пользовательский DSN» нужно нажать «Добавить», выбрать драйвер, названный в точности «SQL Server» (в списке будут и другие похожие, выбрать надо именно этот), задать имя perfmonsr_08, указать сервер STUDY2, поле «Описание» можно не заполнять. На следующем экране в разделе «Как SQL сервер должен проверять подлинность пользователя?» оставить все настройки по умолчанию, нажать «Далее». Тут в разделе «использовать по умолчанию базу данных» нажать флажок, выбрать базу PerfmonData_08, нажать кнопки «Далее», «Готово», «Проверить источник данных» (должно появиться сообщение «Тест успешно завершен»), «ОК», «ОК».

3. Зайдите в терминальном сеансе в Пуск – Администрирование – Системный монитор – Группы сборщиков данных – Особые. Создайте группу сборщиков данных perfmonct_08, ниже выберите пункт «Создать вручную (для опытных)», на следующем экране нажмите флажок «Счетчик производительности», «Далее». Добавьте в список счётчики «Система – Контекстных переключений/с», «Процессор - % загруженности процессора» (Экземпляры выбранного объекта = _Total) и «Память – Доступно МБ», после чего нажмите «Далее»-«Далее». На экране «Создать группу сборщиков данных?» в поле выбора пользователя вместо «По умолчанию» укажите учётную запись UserH8 и пароль QZ86Ax1*8x затем выберите «Сохранить и закрыть», нажмите «Готово».

4. В списке «Группы сборщиков данных» выберите созданную вами группу perfmonct_08, и в центральной секции откройте свойства счётчика производительности, выберите формат журнала «SQL», В поле «Имя источника данных» введите perfmonsr_08. Перейдите во вкладку «Файл», нажмите флажок «Приписывать имя компьютера к имени файла», поле «Формат имени файла» менять не надо (по умолчанию он заполнен как надо), нажмите «ОК», в открывшемся окне подтверждения пароля введите пароль QZ86Ax1*8x

5. Запустите сбор счётчиков, убедитесь в отсутствии сообщений об ошибках.

Дальнейшая часть инструкции будет рассмотрена в следующем задании.

Задание 6: получить данные сборщиков оборудования в сервис


1. Создайте на сервере 1С по адресу study2:30841 базу 1С 8.3 с именем hardware_08, тип СУБД «MS SQL Server», сервер базы данных STUDY2, имя базы данных hardware_08, пользователь базы данных UserForBase1C , пароль UserForBase1C.

2. В терминальной сессии найдите на диске C: папку C:\1с\сервисы. Загрузите из этой папки файл HardwareClient82.cf в получившуюся базу 1С. Как это сделать: зайдите в получившуюся базу Конфигуратором, в разделе меню «Конфигурация» выберите пункт «Открыть конфигурацию», затем снова «Конфигурация» - «Загрузить конфигурацию из файла» - выбрать файл HardwareClient82.cf. В ответ на вопрос «Обновить конфигурацию базы данных» нажать «Да», в появившемся окне «Реорганизация информации» нажать «Принять». Теперь можно закрывать Конфигуратор и запускать эту базу в режиме Предприятия.

3. В справочнике «Рабочие станции» создать новую запись: имя компьютера STUDY2, логин UserForBase1C, пароль UserForBase1C, нажать «Записать и закрыть». Затем создать ещё одну запись: имя компьютера ISINKA2. В качестве сервера СУБД выбрать запись из того же справочника STUDY2 (счетчики собираются с сервера ISINKA2, а загружаются на STUDY2), база хранения счётчиков PerfmonData_08 (сюда должны заливаться данные в результате выполнения предыдущего задания), нажмите «Записать и закрыть», затем зайдите в этот элемент заново, в нижнем окне должна появиться запись вашего сборщика данных. Скопируйте оттуда из поля «Имя Набора» данные внутрь поля «Имя набора счетчиков». Нажмите кнопку «Заполнить GUID», в результате появившийся гуид (вида например {CAF5C1ED-3A01-4C32-8432-E49DD9F8D2AA}) должен сам заполнить поле GUID выше, нажмите кнопку «Получить информацию по счетчикам», нажмите флажок «Загружать данные счетчиков производительности». И затем «Записать и закрыть».

4. В меню «Настройки» создайте новый элемент, в поле «Учётная запись в сервисах Gilev.ru» укажите UserH.

5. Откройте меню «Регламентные и фоновые задания», выберите Задание «ОперативнаяЗагрузка ДанныхСчетчиков», нажмите «Выполнить сейчас».

6. Убедитесь, что в меню «Данные счетчиков производительности» появились данные.

7. После кофе-брейка запустите 1С Предприятие, в окне списка баз выберите базу серверной части сервиса Hardware. Зайдите в базу с вашим логином UserH и паролем UserH567, и смотрите полученные данные.

Задание 7: получить статистику ошибок 1С и блокировок из технологич. журнала


1. Создайте на сервере 1С по адресу study2:30841 информационную базу 1С с именем status_08, тип СУБД «MS SQL Server», сервер базы данных укажите STUDY2, имя базы данных status_08, пользователь базы данных UserForBase1C , пароль UserForBase1C.

2. В терминальной сессии найдите на диске C: папку C:\1с\сервисы, загрузите из неё файл QueryTJClient83.cf в созданную базу, зайдите в получившуюся базу.

3. В разделе «Анализ исключений и ошибок», в пункте «Настройки» создайте новую запись:

Учётная запись в сервисах Gilev.ru: UserH

путь к конфигурационному файлу: \\study2\Conf_08

путь к файлам логов технологического журнала: \\study2\Log_08

остальные значения оставьте по умолчанию.

5. В меню «Сервис» нажмите «Включение (обработка) технологического журнала», нажмите «Включить мониторинг».

6. Убедитесь, что по указанному вами пути логов в подпапке ERROR_EXCP появились новые папки.

7. Воспроизведение проблемы в тестовой базе: открыть исследуемую базу в режиме предприятия. В нашем случае: сервер study2:30841, база – Base_08, логин – admin, без пароля. В открывшемся интерфейсе справа вверху зайдите в раздел «Тестирование», нажмите там «Сервис» - «Имитация событий на сервере» - «Запустить имитацию событий». В результате на сервере 1С должен произойти ряд событий, которые в должны попасть в технологический журнал 1С (откуда они каждый час настроенной вами клиентской частью автоматически отправляются в сервис Gilev.ru Status, соответственно становятся видны примерно спустя час после их попадания в логи).

8. Спустя час после нажатия кнопки «Имитация событий на сервере» - запустите 1С Предприятие, в окне списка баз найдите группу «Сервисы (серверная часть)», в ней выберите базу сервиса Status, зайдите в базу с вашим логином UserH и паролем UserH567. В открывшемся интерфейсе перейдите во вкладку «События технологического журнала», и посмотрите полученные данные.

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

Задание 8: оценка размера исследуемой базы,
прогноз достижения граничных значений размеров

Настройка сервиса


1. Создайте новую информационную базу в клиент-серверном варианте (т.к. используются регламентные задания), на сервере study2:30841 с именем sqlsize_08, сервер баз данных STUDY2, имя базы данных sqlsize_08, пользователь базы данных UserForBase1C , пароль UserForBase1C.

2. В терминальной сессии найдите на диске C: папку C:\1с\сервисы. Загрузите из этой папки файл SqlsizeClient82.cf в созданную базу.

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

Описание параметров:


Включена – флаг включения/выключения анализа базы.
Учётная запись в сервисах Gilev.ru – учетная запись, предварительно зарегистрированная в сервисах Gilev.ru (пароль высылается по Е-mail при регистрации). Укажите UserH.

Код, представление базы в сервисе – код базы в клиентской части, укажите UserH.

Параметры сервера MS SQL:

Имя сервера – адрес сервера с ролью MS SQL Server. Укажите STUDY2
Имя базы – название исследуемой базы данных на сервере MS SQL. Укажите Base_08
Логин - логин к серверу MS SQL. Укажите UserForBase1C
Пароль – пароль к серверу MS SQL. Укажите UserForBase1C
Таймаут подключения – максимальное время для работы запросов к СУБД в секундах (укажите 1001 сек., в этом случае опрос таблиц проводится не всех сразу, а поштучно).
Каталог сервера СУБД – сетевой путь к каталогу на сервере СУБД для оценки пропускной способности сети. В нашем случае оставьте это поле пустым.

Параметры базы 1С:

Версия платформы – версия исследуемого сервера приложений 1С. Выберите 1С: 8.3
Имя сервера - адрес сервера с ролью сервера 1С: Предприятие 8. Укажите study2:30841
Имя базы - название исследуемой базы на сервере 1С. Укажите Base_08
Логин – пользователь в исследуемой базе 1С с правами администратора. Укажите admin
Пароль – пароль пользователя 1С. В нашем случае оставьте это поле пустым.
Каталог сервера 1С – каталог, в котором сервер 1С хранит настройки зарегистрированных баз. В нашем случае укажите P:\srvinfo\8_3_10-08 (это локальный путь на сервере 1С, вам этот диск в терминалке не виден).

После внесения всех параметров нажмите кнопку их сохранения (иконка дискетки).

Для проверки правильности сохранённых настроек в каждой группе параметров есть соответствующие кнопки «Проверка подключения». Результатом удачной проверки является сообщение «Соединение успешно установлено», после этого можно нажимать «Записать и закрыть».

4) После создания настроек, по расписанию регламентных заданий будет выполняться периодический анализ сервера SQL. Просмотр выполненных задач, и корректировка их расписания возможна с помощью обработки «Регламентные и фоновые задания»

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

Результат анализа можно увидеть на сайте http://gilev.ru/sqlsize, или при подключении тонким клиентом 1С к серверной части базы сервиса SQLSize.

Практика


1. Подключитесь к серверной части базы сервиса SQLSize с логином Work и пустым паролем

2. Откройте закладку «Параметры СУБД» - «Настройки конфигурации». Определите доступный размер оперативной памяти из параметра «max server memory (MB)» (потребуется нажать кнопку «Показать ещё»)

3. Откройте закладку «Размеры таблиц» и определите суммарный размер базы.

4. Сравните размер оперативной памяти и размер самых больших таблиц, превышают ли самые большие таблицы объём доступной оперативной памяти СУБД, и если да – то как сильно.

5. Определите, с какой скоростью в месяц растут самые большие таблицы.

6. Посчитайте через какой промежуток времени база удвоит свой размер. Посмотрите в шапке отчёта «Размеры таблиц» на прогноз размера базы к концу текущего года.

7. Посчитайте, какой будет размер у базы через полгода и соотношение к доступной оперативной памяти. Дайте общую оценку соответствия объемов памяти для исследуемой базы и сообщите преподавателю.

Домашняя работа (задания 9 и 10 выполнять на домашнем компьютере)


Суммарная предполагаемая длительность двух заданий на дом – от 15 до 30 минут.

Задание 9: проконтролировать загруженность дисков


- настроить perfmon ("Системный монитор") на сбор счётчиков согласно нашей инструкции http://gilev.ru/hardwaresetup/ , только собирать не в SQL, а в файл. Включить сбор счётчиков.

- настроить process monitor на сбор событий с фильтрами "Operation=ReadFile, WriteFile", "duration >0.02"

- кроме того, добавить фильтр по «Process Name» is «DiskMark.exe», «Action = include»

- найти у себя на компьютере медленный диск (не SSD) с >10 гигабайт свободного места, а на нём, например, папку с несколькими гигабайтами файлов размером от 0 до 50 мегабайт каждый (неважно каких, можно музыку или фотографии)

- запустить архивацию архиватором 7zip (можно бесплатно скачать с http://7-zip.org) этой папки на этот же диск (с параметром "скоростное сжатие" или "без сжатия", чтобы минимизировать влияние процессора)

- пронаблюдать в process monitor в динамике время выполнения дисковых операций;

- через минуту включить Crystal DiskMark версии 3.0 (можно бесплатно скачать с http://crystalmark.info/download/archive/CrystalDiskMark/CrystalDiskMark3_0_4.zip ) на медленный диск (не SSD) с параметрами "4 прохода по 1000 мегабайт"

- опять пронаблюдать в process monitor время выполнения дисковых операций

- по окончании теста Crystal DiskMark через минуту прервать архивацию

- снова пронаблюдать в process monitor время выполнения дисковых операций

- остановить сбор счётчиков в Process monitor (зайти в меню File и снять флажок с Capture events)

- остановить сбор счётчиков perfmon, открыть полученный файл замеров (обычно он в папке c:\PerfLogs\, и дальше по имени сборщика счётчиков, который вы настраивали), посмотреть на графиках и в цифрах изменение времени отклика дисков и размеров очереди к диску в зависимости от уровня нагрузки.

Объяснить по результатам наблюдения за process monitor: что делает тест Crystal Diskmark.

Задание 10: проконтролировать загруженность процессоров


- настройте process monitor на сбор событий с фильтром "duration >0.02", убедитесь в том, что в настоящее время таких событий мало.

- запустите архиватор 7-Zip (можно бесплатно скачать с http://7-zip.org), в нём "Сервис - Тестирование производительности", размер словаря оставьте 32 мегабайта, число потоков поставьте максимально возможное (обычно это в 2 раза больше, чем выбрано по умолчанию).

- запустить ещё один 7-Zip, в нём запустить ещё одно "Тестирование производительности"

- если сейчас курсор по экрану перемещается рывками - поздравляем, вы достигли цели.
Если нет - запустите ещё 1‑2 экземпляра 7-Zip.

- переключиться на process monitor, пронаблюдать прирост событий с длительностью > 0.02 сек.

- через минуту остановите и выключите все экземпляры 7-Zip

- ещё через минуту остановите сбор счётчиков, откройте получившийся файл замеров (обычно он в папке c:\PerfLogs\, и дальше по имени сборщика счётчиков, который вы настраивали), посмотрите на графиках и в цифрах изменение параметров "длина очереди процессора" (Processor Queue Length) и "контекстных переключений в секунду" (Context Switches/sec) в зависимости от нагрузки.

- переключитесь на process monitor и убедитесь, что новых событий с длительностью > 0.02 секунды стало меньше.

Задание 11: анализируем ожидания MS SQL


Запустите MS SQL Management Studio, подключитесь к серверу SQL STUDY2 с логином UserForBase1C и паролем UserForBase1C. Запустите Activity monitor (правой кнопкой мыши на корневом элементе сервера СУБД), разверните пункты: Overview, Resource Waits и Data File I/O.

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

Задание 12: анализ статистики и фрагментации

Статистика, теория


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

При создании индекса, статистика на индекс создается автоматически.
Статистика создается и обновляется автоматически, но не всегда этого достаточно.

Статистика, практика


1. Откройте в тонком клиенте 1С серверную часть базы сервиса SQLSize с вашим логином UserH и паролем UserH567

2. Откройте закладку «Индексы» — «Актуальность статистики» и оцените состояние статистики таблиц, постарайтесь определить – является ли текущее состояние хорошим или плохим, а если плохим – то насколько.

Фрагментация, теория


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

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

Фрагментация, практика


1. Откройте в тонком клиенте 1С серверную часть базы сервиса SQLSize с вашим логином UserH и паролем UserH567

2. Откройте закладку «Фрагментация» и оцените состояние статистики таблиц, постарайтесь определить – является ли текущее состояние хорошим или плохим, а если плохим – то насколько.

Задание 13: настройка сервиса Latch, воспроизведение проблемы в тестовой базе

Настройка сервиса анализа ожиданий на блокировках (Latch):


1) Создать новую базу на сервере 1С:Предприятия, со следующими параметрами:

Кластер серверов 1С:Предприятия - study2:30841, имя информационной базы в кластере – Latch_08, тип СУБД – MS SQL Server, сервер баз данных - STUDY2, имя базы данных – Latch_08, пользователь базы данных - UserForBase1C, пароль пользователя - UserForBase1C.
Отметить пункт «Создать базу данных в случае ее отсутствия», версия 1С:Предприятия 8.3, остальные параметры оставить по умолчанию.

2) В терминальной сессии найдите на диске C: папку C:\1с\сервисы, в ней клиентскую часть сервиса LatchClient82.cf.

3) Загрузить файл конфигурации LatchClient82.cf в созданную базу данных.

4) Определить идентификатор исследуемой базы данных на сервере SQL:

a. Открыть SQL Server Management Studio

б. Соединиться с сервером STUDY2 под пользователем UserForBase1C с паролем UserForBase1C

в. Создать запрос в текущем соединении (нажать Ctrl+N)

г. Написать запрос: select name, database_id from sys.databases;

д. Выполнить запрос (нажать F5)

е. В результатах выполненного запроса найти строку с исследуемой базой. В нашем случае это Base_08, её database_id – это идентификатор базы данных на сервере SQL.

5) Открыть базу Latch_08 в режиме предприятия.

6) Создать один элемент в справочнике «Параметры сервера SQL» со следующими параметрами:

Код – оставить пустое значение.
Имя сервера SQL – адрес сервера SQL. В нашем случае: STUDY2.
База данных – Base_08
Идентификатор БД – database_id исследуемой базы на сервере SQL, полученный в пункте 4.
Аутентификация Windows – в нашем случае не включать.
Логин – имя пользователя на сервере SQL. В нашем случае - UserForBase1C.
Пароль – пароль пользователя сервера SQL. В нашем случае - UserForBase1C.

Каталог файлов логов трассировки – каталог на сервере SQL, доступный учетной записи, из‑под которой работает служба MS SQL Server. В нашем случае - F:\study\Trace\TraceLatch_08 (это путь на сервере СУБД, вам этот диск не виден).

После заполнения всех настроек нажать «Записать и закрыть».

7) Создать один элемент в справочнике «Настройки» со следующими параметрами:

Версия платформы – в нашем случае «1С: Предприятие 8.3.8 и старше»
Учётная запись в сервисах Gilev.ru – в нашем случае UserH
Путь к конфигурационному файлу – адрес каталога, в котором находятся конфигурационные файлы сервера приложений 1С. В нашем случае - \\study2\Conf_08
Путь к файлам логов технологического журнала – адрес каталога, доступного учетной записи, из-под которой работает служба сервера приложений 1С. В нашем случае \\study2\Log_08
Сервер SQL – выбрать элемент, созданный в предыдущем пункте – STUDY2
Имя информационной базы 1С – имя исследуемой базы на сервере приложений 1С. В нашем случае – Base_08

Остальные настройки оставить по умолчанию.

После заполнения всех настроек нажать «Записать и закрыть».

8) В области меню «Сервис» (справа сверху в главном окне) выбрать обработку «Включение (выключение) мониторинга». В ней нажать кнопку «Включить мониторинг блокировок». Закрыть клиентскую часть сервиса.

9) Воспроизведение проблемы в тестовой базе:

а. Открыть исследуемую базу в режиме предприятия. В нашем случае: сервер study2:30841, база – Base_08, логин – admin, без пароля.

б. Открыть клиентскую часть Latch, убедиться в наличии надписи «Мониторинг включен» в заголовке окна 1С. Если мониторинг не включен – проверить настройки.

в. В исследуемой базе выбрать раздел «Тестирование», в области «Сервис» выбрать обработку «Обработка тестирования».

г. Если в заголовке клиентской части Latch (созданной вами только что в пункте 5 данного задания) надпись «Мониторинг включен» - флажок «Пауза перед выполнением» ставить не надо, просто нажмите кнопку «Запустить тест №2 (блокировки)».

д. Дождаться выполнения теста. Приблизительное время теста составляет от 3 до 5 минут.

Задание 14: настройка сервиса Lock, воспроизведение проблемы в тестовой базе


Настройка сервиса анализа ожиданий на взаимных блокировках ( Lock, он же Deadlock ):

1) Создать новую базу на сервере 1С:Предприятия, со следующими параметрами:

Кластер серверов 1С:Предприятия - study2:30841, Имя информационной базы в кластере – deadlock_08, тип СУБД – MS SQL Server, Сервер баз данных - STUDY2, имя базы данных – deadlock_08, пользователь базы данных - UserForBase1C, пароль пользователя - UserForBase1C.
Отметить пункт «Создать базу данных в случае ее отсутствия», остальные параметры оставить по умолчанию.

2) В терминальной сессии найдите на диске C: папку C:\1с\сервисы, в ней файл uDeadlockClient8.cf.

3) Загрузить конфигурацию uDeadlockClient8.cf в созданную базу данных.

4) Определить идентификатор исследуемой базы данных на сервере SQL:

a. Открыть SQL Server Management Studio

б. Соединиться с сервером STUDY2 под юзером UserForBase1C с паролем UserForBase1C

в. Создать запрос в текущем соединении (нажать Ctrl+N), написать текст:

select name, database_id from sys.databases;

г. Выполнить запрос (нажать F5)

д. В результатах выполненного запроса найти строку с исследуемой базой. В нашем случае это Base_08. database_id – это идентификатор базы данных на сервере SQL.

5) Открыть базу deadlock в режиме предприятия.

6) Создать один элемент в справочнике «Параметры сервера SQL» со следующими параметрами:

Код – оставить пустое значение.
Имя сервера SQL – адрес сервера SQL. В нашем случае: STUDY2.
База данных – Base_08.
Идентификатор БД – идентификатор исследуемой базы данных на сервере SQL, полученный в пункте 4.
Аутентификация Windows – в нашем случае не включать.
Логин – имя пользователя на сервере SQL. В нашем случае - UserForBase1C.
Пароль – пароль пользователя сервера SQL. В нашем случае - UserForBase1C.
Каталог файлов логов трассировки – каталог на сервере SQL, доступный учетной записи, из-под которой работает служба MS SQL Server. В нашем случае - F:\study\Trace\TraceDeadlock_08 (это локальный путь на сервере СУБД, вам этот диск не виден).

После заполнения всех настроек нажать «Записать и закрыть».

7) Создать один элемент в справочнике «Настройки» со следующими параметрами:

Версия платформы – в нашем случае «1С:Предприятие 8.3.8 и старше».
Идентификатор базы – имя учетной записи в сервисах Gilev.ru. В нашем случае – UserH.
Путь к конфигурационному файлу – адрес каталога, в котором находятся конфигурационные файлы сервера приложений 1С. В нашем случае - \\study2\Conf_08
Путь к файлам логов технологического журнала – адрес каталога, доступного учетной записи, из-под которой работает служба сервера приложений 1С. В нашем случае - \\study2\Log_08
Имя информационной базы 1С – имя исследуемой базы на сервере 1С. В нашем случае – Base_08

Сервер SQL – выбрать из списка элемент, созданный в предыдущем пункте. В нашем случае -STUDY2.

Остальные настройки оставить по умолчанию. После заполнения всех настроек нажать «Записать и закрыть».

8) В области меню «Сервис» выбрать обработку «Включение (выключение) мониторинга». В ней нажать кнопку «Включить мониторинг взаимоблокировок».

9) Воспроизведение проблемы в тестовой базе:

а. Открыть исследуемую базу в режиме предприятия. Реквизиты: база – Base_08, логин – admin, без пароля.

б. Открыть клиентскую часть Deadlock, убедиться в наличии надписи «Мониторинг включен» в заголовке окна. Если мониторинг не включен – проверить настройки.

в. Выбрать раздел «Тестирование», в области «Сервис» выбрать обработку «Обработка тестирования».

г. Если в заголовке клиентской части Latch (созданной вами только что в пункте 5 данного задания) надпись «Мониторинг включен» - флажок «Пауза перед выполнением» ставить не надо, просто нажмите кнопку «Запустить тест №3 (взаимоблокировки)».

д. Дождаться выполнения теста. Приблизительное время теста составляет не больше минуты.

Задание 15: анализ собранной в Latch и Lock информации

Анализ Latch


Подключитесь тонким клиентом 1С к серверной части сервиса Latch с вашим логином UserH и паролем UserH567

Период по умолчанию выбран «с начала по конец текущего дня», он как раз и нужен. Нажмите кнопку «обновить данные»:



В разделе «Контекст блокировок» должны появиться данные, собранные в результате выполнения задания 12. Выберите в верхнем окне лидирующий контекст, внизу должны появиться детали блокировок по нему. Раскройте в нижнем окне контекст виновника, посмотрите на конкретные экземпляры блокировок. Двойным кликом мыши на строке конкретного экземпляра блокировок откройте окно расшифровки конкретного экземпляра блокировки. В верхнем окне должны быть показаны строки виновника и жертвы, обратите внимание на колонки «Таблица», «Индекс», «Гранулярность» и «Режим». После этого по очереди выделите в верхнем окне строки виновника и жертвы, при этом в нижнем правом окне пронаблюдайте значения ресурсов блокировок.

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

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

Анализ Lock


Подключитесь тонким клиентом 1С к серверной части базы сервиса Deadlock с вашим логином UserH и паролем UserH567

Период по умолчанию выбран «с начала по конец текущего дня», он как раз и нужен. Нажмите кнопку «обновить данные»:



В разделе «Общие данные ранжирования» должны появиться данные, собранные в результате выполнения задания 13. Выберите в верхнем окне лидирующий контекст, внизу должны появиться детали взаимоблокировок по нему. Раскройте в нижнем окне контекст виновника, посмотрите на конкретные экземпляры взаимоблокировок.

Двойным кликом мыши на строке конкретного экземпляра откройте окно расшифровки конкретного экземпляра взаимоблокировки. В открывшемся окне должно быть три вкладки: «Анализ взаимоблокировки», «Блокировки» и «Граф взаимоблокировки»:

- во вкладке «Анализ взаимоблокировки» обратите внимание на порядок захвата ресурсов в ходе выполнения транзакций участвующими процессами (их может быть два и более), и ниже – эти же действия, но сведённые в единый временной поток;
- во вкладке «Блокировки» - показаны детали конкретных установленных блокировок, в том числе индекс, по которому они установлены, установивший их процесс, гранулярность блокировки, идентификатор ресурса, режим и состояние. Снизу показаны контекст, в котором произошла блокировка, и текст установившего их запроса;
- во вкладке «Граф взаимоблокировки» показан собственно граф взаимоблокировки, позволяющий расследовать сложные случаи.

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

Задание 16: проконтролировать состояние бэкапов

Теория


Никакие схемы отказоустойчивости не отменяют необходимости выполнять регулярное резервное/архивное копирование данных. При демонстрации свойств акцент сделан на наличие бэкапов и факторов производительности. В разделе «Параметры СУБД» — «Параметры баз» колонка last backup показывает период, за который будут потеряны данные в случае сбоя. Это позволяет быстро и наглядно оценить текущие риски потери данных и при необходимости скорректировать стратегию резервного копирования.

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

Практика


1. Откройте в браузере http://gilev.ru/sqlsize с вашим логином UserH и паролем UserH567
(или можно подключиться тонким клиентом к серверной части базы сервиса SQLSize).

2. Откройте закладку «Параметры баз» - «Последние бэкапы» и найдите вашу базу Base_08.

3. Определите по колонке last_backup текущий период, за который будут потеряны данные в случае сбоя.

4. Обратите внимание на длительность выполнения операции бэкапа.

5. Предложите варианты обеспечения резервного копирования, при которых:
- максимально приемлемый период потерянных данных с момента последнего бэкапа не больше 2 часов, время восстановления данных не больше одного часа;

- максимально приемлемый период потерянных данных с момента последнего бэкапа не больше 5 минут, время восстановления данных не больше 15 минут;

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

Что надо знать администратору о производительности

Есть ряд задач, в которых администратор должен свободно ориентироваться:

  • Организовать контроль производительности и статистики сообщений об ошибках

    • подсказать бизнесу поставить бизнес-задачи по контролю производительности: 
      http://gilev.ru/apdex-teoriya

    • всегда собирать статистику ошибок 1C технологическим журналом и анализировать её, например, http://gilev.ru/status

    • инструменты http://gilev.ru/online облегчают многие задачи;

  • Не забивать сервер всем подряд, пока он не выдержит. Следить, чтобы под каждую новую задачу бизнес выделял новую инфраструктуру

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

  • При небольшом количестве пользователей и данных – проблему производительности как правило ДЕШЕВЛЕ решить наращиванием оборудования, а не кодом;

  • Не экономить на процессоре, нужен баланс максимальной частоты и количества ядер, не забывать включать максимальную производительность:

      • в энергоснабжении http://gilev.ru/systemperfomance

      • в биосе сервера http://gilev.ru/bioshp

      • в биосе виртуалки (если есть).

  • Гипертрединг надо оценивать по ситуации, но в виртуалках может увеличить стоимость владения: http://gilev.ru/hyper-threading

  • При развертывании нового сервера по возможности избегать виртуалок.
    Но если избежать не удалось – каков план действий?  http://gilev.ru/virtual

  • При небольшом количестве пользователей совмещать роли сервера 1С и сервера СУБД, чтобы использовать обмен напрямую через память Shared Memory: http://gilev.ru/sqland1c

  • При подборе диска не ориентируйте только на iops http://gilev.ru/iops, старайтесь минимизировать время отклика и максимизировать линейную скорость записи, глубину очередей

  • Необходимо все интенсивно используемые файлы перенести на NVMe SSD, подробнее http://gilev.ru/linkdir/#nvme (особенно для tempdb и журнала регистрации 1C, если он в «новом формате» SQLite);

  • В редких случаях при миграции на старшую версию СУБД бывает необходимо включить «старый» алгоритм оптимизатора запроса флагами трассировки http://gilev.ru/legacy_query_optimizer

  • Для терминального сервера Windows Server 2012 и более новых версий – бывает потребность выключить DFSS: http://gilev.ru/dfss

  • Обеспечить возможность разработчикам писать код именно в той среде, в которой потом этот код будет эксплуатироваться, но при этом держать выделенную изолированную среду от продуктивных баз

  • Организовать контроль загруженности оборудования и типов ожиданий на СУБД:

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

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

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

  • При возникновении массивных блокировок на чтение – проанализировать использование версионирования http://gilev.ru/snapshot1c

  • При ожиданиях pagelatch_xx проанализируйте добавление файлов tempdb: http://gilev.ru/pagelatch_xx

  • Включаем быструю инициализацию файлов http://gilev.ru/se_manage_volume_name

  • Разносим нагрузку по дискам, если возникают ожидания pageiolatch, а также анализируем отсутствующие индексы, например с помощью сервиса http://gilev.ru/sqlsize

  • Текущую картину ожиданий видно в Мониторе Активности СУБД, а блокировки и транзакции в консоли сервера 1С – в сеансах базы, просто так делать «потому что соседу помогло» не стОит, можно «устать», не добравшись до действий, которые окажут наибольшую пользу

  • отслеживать историю регламентных заданий на СУБД по обеспечению резервного копирования, обновления индексов и статистики; бывают нюансы: http://gilev.ru/trace2371

  • помогать программисту обнаруживать проблемные запросы с помощью инструмента анализа долгих запросов QueryTJ http://gilev.ru/querytj, 3 запроса в месяц, выявленных нашим инструментом и затем ускоренных – позволят говорить о сохранении производительности на высоком уровне;

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

  • Как быстро понять, что пришла пора апгрейдить сервера: http://gilev.ru/upgrade

  • Про диски для 1С (статья плюс сборник дополнительных линков): http://gilev.ru/ssd1c

  • Выясняем нормативы потерь при сбоях: http://gilev.ru/rpo и http://gilev.ru/rto

  • Параметры BIOS, влияющие на производительность: http://gilev.ru/?s=bios

  • Про динамическое обновление 1С: http://gilev.ru/dynamicupdate1c

  • Частота и производительность RAM зависят от того, как она воткнута: http://gilev.ru/ram

  • Про терминальный сервер «для 1С»: http://gilev.ru/rdponly

  • Общесистемные и групповые замедления в 1С, причины: http://gilev.ru/groupslowdown

  • Неожиданное поведение платформы 1С в динамических списках: http://gilev.ru/hiddenfields

  • Приоритет ipv4 над ipv6: http://gilev.ru/2net

  • Пример методики выявления проблем блокировок в 1С: http://gilev.ru/timeoutlock

  • Выявление ошибок нехватки прав службы сервера 1С: http://gilev.info/2019/02/1.html

  • Мониторить происходящее в консоли сервера 1С можно с помощью конфигурации Session Monitor: https://infostart.ru/public/1329606/

  • Одна тонкость при обновлении сервера 1С: http://gilev.ru/when_updating_the_1c/

  • Как установить несколько служб 1С: http://gilev.ru/multiple1cservers/

  • Как отправлять данные в сервисы Gilev.ru через HTTPS в условиях санкционных ограничений:
    http://gilev.info/2022/06/gilevru-https.html



Check list администратора 1С

Ежедневно:


  • проверять актуальность бэкапов (как копии на локальных ресурсах, так и копии на сетевых);

  • проверять логи ОС на серверах на предмет ошибок (на windows – это application log, security log и system log);
    вариант автоматизации парсинга логов: связка ELK (ElasticSearch, LogStash, Kibana) или аналог:OpenSearch+Filebeat/Winlogbeat

  • проверять логи СУБД на предмет ошибок;

  • проверять логи веб-сервера на предмет ошибок;

  • убедиться, что работает мониторинг серверных ресурсов (потребление памяти, процессора, свободное место на дисках, температуры проце ссоров и дисков);

  • проверить логи ЖР 1С продуктивных баз 1С на предмет ошибок;

  • проверить доступность всех продуктивных веб-сервисов;

Ежедневно, при наличии учётки сервисов gilev.ru:


  • проверить статистику ошибок и блокировок в сервисе Status http://gilev.ru/status

  • проверить статистику долгих запросов в сервисе QueryTJ http://gilev.ru/querytj

  • проверить состояние СУБД (состояние статистик, фрагментация, размеры таблиц) в сервисе SQLSize http://gilev.ru/sqlsize

Постоянный мониторинг (с высокой частотой, каждые 1-15 минут):


  • мониторинг серверных ресурсов (потребление памяти, процессора, свободное место на дисках, время обслуживания дисковых операций, температуры процессоров и дисков);

  • проверить доступность всех продуктивных веб-сервисов;

Еженедельно:


  • проверять развёртывание баз из бэкапов продуктивных баз на тестовых серверах;

Ежемесячно:


  • тренировка по отработке отказов системных ресурсов (проводится на тестовых серверах);

  • при возможности: контроль SMART на дисках продуктивных серверов, контроль ресурса на SSD продуктивных серверов;

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

Регламенты обслуживания оборудования (замена дисков каждые n лет, пылесос каждые n месяцев, замена батарей UPS каждые n лет) и прочие – в данный чеклист не включены





© Gilev.ru 2022 UserH


написать администратору сайта