Билет 13
-
Проблемы повышения производительности модели fcaps.
-
Дайте требования компании, организующей для вашей организации последнюю милю при помощи xDsl.
1. Проблемы повышения производительности модели fcaps.
Проблема производительности сложна с точки зрения оценки (параметры), как еще называют метрики. Метрики производительности чрезвычайно сложны.
Чтобы говорить о производительности, сначала нужно определить, что это вообще для данной системы, какая производительность считается для нее хорошей. Причем производительность нужно определять тогда, когда наблюдается пиковая нагрузка, т.е. в дневное время.
Измерения нужно производить в течение определенного промежутка времени, нет стандарта на длительность этого промежутка, но обычно говорят об измерениях в течение месяца (хотя реально такой возможности, скорее всего не будет).
Определяются номинальные характеристики: total time, IO time, system time, cpu time и др.
Утилизация канала - % занятости канала в единицу времени.
Дальше необходимо определить, какая есть документация для данной системы (на кабельную систему, на архитектуру, на прикладные задачи).
После этого нужно определить какие параметры и когда нужно измерять.
Определяется 4 шага измерение производительности:
1 шаг: что для данной системы номиналы производительности и какая у нас базовая производительность.
2 шаг: отклонение от номиналов и контроль за ними
3 шаг: создание отчетов провести анализ
4 шаг: корректировка производительности.
1 шаг: baseline – базовая производительность – определение топологию функциональной схему системы. Без этого нельзя определить, что для данной системы хорошая производительность. Если соединение неверно сконфигурировано, то будут ошибки. Хорошие времена для работы ИС, т.е какое приемлемое время для передачи информации по устройствам ИС – это и будет базовый параметр. Например:
-
время инициализации приложения (открывание приложения),
-
время отклика (получение информации),
-
время записи информации на диск.
Эти оценки и есть метрики производительности ИС, которые нужно записать в документе «Оценки готовности информационной системы (или же сети)» обозначают, как NRA. Это субъективные оценки и нужно учитывать, что для моей системы интересно в данный момент. Так же можно записать свои базовые метрики для ИС, например, TCP/IP –эти метрики могут повлиять на время отклика.
Дальше можно говорить, о планирование, анализе метрик.
2 шаг: контролирование от базовых параметров, мы понимает, что есть номинал, предположим записи на диск.
Как такие отклонения контролируются:
-
Решается сетевым способом. На каждое устройство коммутатора ставиться оборудование PROBE – на порт. Работает по протоколу RMON (удаленного управления), аппаратное решение, если софт, то будет всем мешать. Будем передавать на управляющий сервер, который будет собирать с PROBE результат и сохранять. Админ должен PROBE устанавливать, конфигурировать, смотреть, чтобы они не мешались(чтобы не создавали неправильный трафик). Должны регулярно наблюдать и диагностировать результат.
-
Следить на параметрами – это сетевой способ, работающий по протоколу NetFlow (Cisco изобрело). Ставиться программный продукт на станцию, которая называется коллектором он собирает трафик отправляемый NetFlow, это можно делать на зеркалированном порте оборудования (отражение трафика на отдельном порту).
Админ должен пользоваться либо 1, либо 2 способом контроля ошибок.
-среднее(текущее) время отклика
- кол-во вх/вых битов от аппаратуры в секунду
- % потерянных пакетов
- кол-во ошибок интерфейса (порта)
- график сети в пиковом режиме.
Изменение параметров может не приводить к существенным изменениям производительности. Для этого надо производить корреляцию параметров производительности с теми изменениями, которые произошли в системе, отсюда результат, что хранить все параметры в хорошо спроектированной БД.
3 шаг: Создать отчеты для анализа. Есть в управляющих системах Tivoli, Open view. Это полезно делать, если делаю производительность по часам в течение дня. Так как вручную это делать тяжело.
4 шаг: Коррекция производительности – вернуть параметры к номиналу. Предпринять действия, после которых параметры системы, измененные в ходе ее эксплуатации пришли в номинальное состояние к тем базовым параметрам, которые установили первоначально.
Нужно предпринять действия на основании интуиции:
- добавление новых устройств
- добавление каналов вв/выв на сервере
- изменение конфигурации устройств (маршрутизаторы зависят от операторов связи)
- менять параметры загрузки ОС или СУБД
- применение оптимизации СУБД.
Особый способ коррекции – это правильное физическое проектирование БД.
Концептуальная схема БД– представление информации админом системы.
Логическая схема БД - представление прикладного программиста на языке SQL (Create table).
Физическое проектирование – представление системного программиста о том как обращаться к данным.
Будем включать:
- метод доступа к данным, если он выбран не эффективно, то все производительности нашей системы бессмысленны, означает поиск данным не эффективным способом. (ISAM), данные индексируются (create index), плохой из-за переполнения, медленный метод доступа. В современных методах доступа используются бидеревья (B+). Нужно выбирать правильный метод доступа быстрый, эффективный, работающий с методом переполнения. Сортировка данных.
- кластеризация, часто используются должны рядом лежать.
- главный вопрос, где размещается БД (SDB, FS,AS (сервер приложения))
На SDB работает ядро СУБД поддерживает целостность, утилиты, но он не работает с дисковой подсистемой с ней работает ОС.
На FS делает вв/выв (читает и пишет) OC размещается на нем, если мощная подсистема вв/выв, то БД размещается на нем.
НА АS под управлением ядра непосредственно выполняется приложение на сервере.
Основной метод повышение производительности:
- модификация системы вв/выв (многоканальная, иметь скоростные интерфейсы)
- размещение БД под управление ядра AS или работать приложению на рабочей станции. НА AS делаю приложения системно-технологические.
Сервер приближать к пользователю за каналом связи это не всегда возможно и модифицировать подсистему вв/выв!! БД там где мощная подсистема вв/выв.!!! Это нужно делать в любой ИС не меря параметры.
Проблемой производительности нужно заниматься тогда, когда изменились метрики, а именно если производительность основного приложения упала на 20 % (считается, что при этом прибыль также падает на 20%) - бизнес-понятие метрики.
После этого рассматриваем параметры для оценки изменений в системе:
– Время ввода/вывода;
– Среднее время отклика;
– Пиковая нагрузка;
– Процент ошибок;
– Процент потерянных пакетов.
Эти характеристики должны сохраняться и сравниваться с характеристиками годовой давности (т.е. сегодняшнюю производительность сравниваем с производительностью в этот же период в прошлом году). Только в этом случае мы можем утверждать, что имеем дело именно с проблемой производительности, а не с сезонностью бизнеса.
После измерений делаем документирование производительности (графики). При этом нужно учитывать нерабочие часы, ночное время. После этого можно сделать какие-либо выводы.
Только после всего этого будем решать, как бороться с проблемой.
Метрики
-
Бизнес-метрики. Значение этих метрик понятно, но они не будут нас устраивать на этапе коррекции ошибок.
-
Технические метрики (они зависят от технологий).