CC BY
45
Библиографический список 2. Ишлинский, А. Ю. Математическая теория плас-
тичности / А. И. Ишлинский, Д. Д. Ивлев. М. : Физматлит, 1. Смирнов, В. И. Курс высшей математики. В 4 т. Т. 4, 2001
ч. 2 / В. И. Смирнов М. : Наука, 1981.
N.D. Dudinova
TYPE OF THE DIFFERENTIAL EQUATION SYSTEMS CONTAINING FINAL RELATION
The system consisted m - s of first order the differential equations which has «s» final relation on «m» functions and «n» variables, and characteristics for this system has been found.
Принята к печати в декабре 2006 г.
УДК 681.34
Р. И. Никитин, В. Г. Третьяков
ПРОЕКТИРОВАНИЕ И НАСТРОЙКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ РАБОТЫ С СИСТЕМОЙ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ ORACLE
Рассмотрен процесс разработки и проектирования программного обеспечения (ПО) для работы с системами управления базами данных (СУБД) на примере СУБД Огасіе, который касается не только разрабатываемого ПО, но и всей системы в целом: локальной сети, сервера, СУБД, клиентского приложения. Показаны возможные узкие места и способыі их выявления уже на этапе проектирования и разработки. Представленыі методы повышения производительности системы путем настройки ее различных частей.
Очень часто при разработке программного обеспечения (ПО) возникает проблема его низкой итоговой производительности. Во многом это происходит потому, что данная проблема обычно не возникает в среде разработки, поскольку фактор высокой итоговой производительности не рассматривается в качестве одного из технических требований к системе. Кроме того, имеются существенные различия между условиями разработки приложения, характеризуемыми малым объемом данных, использованием современного мощного оборудования и быстротой локальной сети, и условиями его эксплуатации, связанными с большими объемами данных, применением, как правило старого оборудования и медленной работой глобальной сети.
Производительность должна рассматриваться как часть таких важных требований к системе, как функциональные возможности приложения. И если система не выполняет их, то либо она не будет использоваться вообще, либо придется потратить большие средства на увеличение аппаратных ресурсов, чтобы обеспечить ее нормальную работу. Часто приходится сталкиваться с тем, что достижение приемлемого увеличения производительности системы без ее кардинального перепроектирования становится практически невозможным.
Низкий уровень производительности выявляется в реальной среде эксплуатации достаточно быстро. И разница в производительности между средой разработки и средой эксплуатации может оказаться очень большой, что не может не сказаться на производительности системы в целом.
Итоговая производительность зависит не только от качества разработки самого приложения, но и от условий, в которых оно будет работать. Клиентская часть, си-
стема управления базами данных (СУБД), операционная система (ОС) и сеть образуют единую систему, в которой низкая производительность отдельной части может снизить итоговую производительность даже при условии идеальной работы остальных ее частей.
В данной статье представлен метод повышения производительности системы, при котором приложение и условия его работы рассматриваются как одно целое. Процесс настройки параметров ПО продемонстрирован на примере СУБД Огас1е.
Начало работы. Из практики хорошо известно, что дешевле выполнить модификацию системы на ранних стадиях, нежели переделывать или даже перепроектировать ее впоследствии. Те же принципы применимы и к системной производительности.
Прежде чем предпринять какие-либо действия по настройке производительности, необходимо рассмотреть следующий список, иллюстрирующий сравнительную эффективность каждой стадии цикла оптимизации:
- уровень операционной системы;
- уровень базы данных (БД);
- уровень реализации;
- уровень проектирования.
Начинать нужно с самого верхнего уровня - уровня ОС, постепенно перемещаясь вниз. Такой порядок выполнения действий связан со следующими причинами:
- самые важные решения реализуются с наименьшими усилиями на самом верхнем уровне;
- каждый верхний уровень влияет на нижние уровни, поэтому изменения, планируемые на нижних уровнях, могут стать излишними в результате изменений на более высоких уровнях.
Уровень операционной системы обычно состоит из настройки системных параметров ядра или параметров UNIX, разделения дисков, оптимизации использования контроллеров ит.д. Это может дать увеличение производительности примерно на 10% в системах, которые в целом уже хорошо настроены.
Уровень базы данныгх включает настройку и ядра Oracle, установку соответствующих параметров в файле init.ora, что приведет к более эффективному использованию памяти (например, за счет оценки размеров кеша буфера и разделяемого пула) и сокращению конфликтов между процессами (например, при наличии соответствующего количества сегментов отката). Правильная настройка может повысить производительность системы на 20...25 %.
На уровне реализации рассматриваются предложения SQL (Structured Query Language), пути доступа к данным, использование соответствующих индексов и т. д. Оптимизация на этом уровне в отдельных случаях может сократить время реакции от нескольких часов до секунд.
Что касается уровня проектирования, то разработчики, как правило, стремятся к реализации в установленный срок всех функциональных требований к системе, а не к тому, чтобы гарантировать ее удовлетворительную производительность. И к моменту выполнения настройки уровень проектирования находится вне границ рассмотрения, так как обычно считается, что пересматривать весь проект и вносить в него существенные изменения на этом этапе слишком поздно и дорого. Однако польза именно от этих изменений поистине огромна. В качестве примера можно привести систему, запускающую пакет заданий, работающих по 3 часа каждую ночь, для согласования финансовых показателей, которые на самом деле требуются раз в месяц или, возможно, вообще не требуются [1].
В любой большой организации ответственность за работу разных уровней обычно несут различные отделы. И если проблема производительности не рассматривалась до ввода системы в промышленную эксплуатацию, то именно администратору базы данных придется заниматься настройкой системы. Конечно, в настоящее время существует большое количество инструментов мониторинга и настройки, предназначенных для администрирования баз данных. Но даже при использовании самых лучших из этих инструментов результат, которого может добиться администратор баз данных, очень мал по сравнению с выгодой от работ по настройке, предпринятых ранее, в период разработки.
Идеальная команда настройщиков систем должна включать специалистов по всем стадиям жизненного цикла системы, использовать и согласовывать их индивидуальное мастерство, добиваясь целостного подхода к проблеме [1].
Методология настройки. Бессистемный подход к настройке системы вряд ли приведет к удовлетворительному результату. Этот подход характеризуется одновременной модификацией многих параметров, созданием новых индексов, перераспределением данных по дискам, перекон-фигурированием клиентских рабочих станций и т. д. Одновременно происходит изменение манеры работы пользователей и обьемов данных. В результате можно до-
стигнуть кратковременного улучшения производительности, но при этом не будет данных, показывающих, какие именно изменения имели положительное воздействие, а какие, что более важно, оказали отрицательное влияние.
К сожалению, большинство встречающихся систем не имеют какого-либо заданного критерия производительности или запланированного времени реакции, к достижению которых можно было бы направить усилия по настройке. И цель оптимизации обычно сводится к тому, чтобы заставить систему работать быстрее. Гораздо хуже дела обстоят в тех организациях, где никакая форма явного мониторинга уже не представляется возможной, поскольку во время выполнения настройки это ухудшит и без того низкую производительность.
Использование прогрессивного научного подхода, который документирует собранные факты, не только максимально улучшит системную производительность, но и поможет лучше понять, как система функционирует в действительности. При этом возможно определение потенциально узких мест, которые станут проявляться, когда система начнет расширяться для приспособления к большему количеству пользователей, большим объемам данных или изменению бизнес-требований.
При практическом использовании данного подхода для прохода по приложению можно подготовить повторяющиеся контрольные примеры, в которых одновременно должно выполняться только небольшое количество изменений. Одним из таких контрольных примеров может быть отдельная пользовательская сессия, для которой сохраняется и может быть проиграна повторно последовательность нажатых клавиш, либо документ, в котором точно записана последовательность используемых форм ввода-вывода.
Пользователи обычно используют такие формы ввода-вывода и транзакции, которые являются одновременно и медленными, и ключевыми для их бизнеса, осуществляемыми много раз за день. Поэтому нет особой необходимости выполнять многопользовательский тест, кроме тех случаев, когда проблемой является конкуренция между пользователями, поскольку большинство SQL-настроек с таким же успехом могут быть выполнены на отдельной маленькой пользовательской сессии, а в этом случае гораздо легче использовать повторяющийся контрольный тест.
При повторных запусках контрольного примера или любого SQL-предложения в качестве теста будет достигнуто устойчивое состояние, при котором SQL-предложения уже разобраны и помещены в разделяемый пул и все необходимые данные содержатся в буферном кеше, вследствие чего результаты повторных запусков покажут увеличение производительности. Для реальной эксплуатации эта ситуация может быть нетипичной, но она позволит сравнить полученные результаты с известными базовыми значениями и быстро определить разницу в результате системных изменений.
При использовании в качестве контрольных примеров одного из многих SQL-скриптов, предназначенных для наблюдения за внутренней производительностью ядра Огас1е, следует сосредоточиться на разделах, оказывающих реальное влияние на работу системы. Например,
если элемент имеет частоту успешных попаданий в кеш около 50%, но обращение к нему происходит лишь дважды в день, то он, вероятно, не заслуживает того времени, которым необходимо пожертвовать для увеличения его частоты успешных попаданий [1].
Инструменты разработки и их правильное использование. В настоящее время существует множество инструментальных средств разработки, позволяющих значительно упростить и ускорить процесс разработки программного обеспечения для СУБД. Стало возможным разрабатывать приложения, делая упор на внутреннюю логику самой программы, а не на логику взаимодействия программы с операционной системой и СУБД. Многие шаблонные действия можно сделать, не написав и строчки собственного кода, но используя соответствующие инструменты. Несмотря на это, многие разработчики проводят много часов, воспроизводя уже реализованные функции самостоятельно, но со значительно бульшими издержками. Зачастую такая ситуация вызвана незнанием существующих инструментов для разработки или их неумелым применением.
Кроме того, значительно усложнилась внутренняя логика и возможности современных СУБД. В такой ситуации одной и той же цели можно добиться многими способами. Однако достигнутая при этом производительность будет существенно различаться. Одно дело, когда SQL-запрос формируется на компьютере клиента и передается по локальной сети СУБД серверу для обработки, компиляции, исполнения, и совсем другое дело, когда этот же запрос представлен в виде хранимой процедуры на самом сервере БД, причем в уже откомпилированном виде. Поэтому целесообразнее использовать возможности, предоставляемые СУБД, чем реализовывать те же возможности в клиентском приложении, но зачастую с потерей производительности (конечно, если это возможно).
Производительность сети. Пользователям многих систем, которые были разработаны в условиях локальной сети, приходится сталкиваться с проблемой производительности при переходе пользователей в среду глобальной сети, скорость передачи данных в которой значительно меньше. Решение этой проблемы затруднено еще и тем, что специалисты по сети и разработчики приложений не могут найти общего языка: довольно часто пользователи и разработчики требуют обновить сеть, не осознавая, что это, вероятно, мало отразится или вообще никак не отразится на времени реакции клиент-серверных приложений, работающих в сети.
Производительность сети обычно измеряется ее теоретической пропускной способностью. Этот подход неприемлем для приложений «клиент - сервер», использующих SQL. Поскольку каждый пакет должен быть квитирован перед тем, как следующий пакет будет отправлен, то в качестве показателя производительности нужно использовать время прохождения пакета по сети или время ответа удаленного узла. Типичным временем для локальной сети являются 2...3 мкс, в то время для глобальной сети оно составит 50...100 мкс или больше. В зависимости от того, каким образом была разработана клиентская часть приложения, каждый SQL-запрос может генерировать много пакетов, каждый из которых, перед тем как
сервер начнет выполнение транзакции, должен быть передан по сети и квитирован. Это создает значительную задержку в сети, признаком чего является большое количество небольших пакетов (по 20...30 байт). При выборке данных по одной строке порождается большое количество пакетов, а при выборке сразу нескольких записей, наоборот, порождается меньшее количество больших по размеру пакетов. Это имеет массу преимуществ, так как время прохождения пакета не зависит от его размера.
Таким образом, следует уделять больше внимания учету интенсивности использования сети приложением «клиент - сервер» в совокупности с другими программами и задачами. При этом необходимо особо отметить, что плохо спроектированная сеть сможет свести на нет все усилия по настройке и оптимизации системы.
Индексы. План выполнения SQL-предложения часто считается эффективным лишь в том случае, когда используется индекс. Однако индекс не всегда является самым быстрым способом доступа к данным, особенно при извлечении большей части данных или размещении данных в небольшом количестве блоков. В таких случаях полное сканирование таблицы может оказаться более эффективным, поскольку в слабо связанных системах, использующих опцию параллельных запросов, сканирование больших объемов данных может осуществляться быстрее, чем поиск по индексам даже небольших фрагментов информации. Реальное количество извлекаемых данных, для которого эффективнее выполнить полное сканирование вместо использования индексирования, может быть различным (15; 4; 12,7 %), и этот уровень всегда следует обосновывать с особой тщательностью, так как реальные данные в разных случаях будут обрабатываться по-разному.
Рассмотрим случай, когда каждый блок данных содержит большое число небольших строк, например номера отделов и их еженедельный доход; новые данные в каждый блок вставляются один раз в неделю; распределение данных таково, что каждый блок содержит информацию о каждом отделе. Чтобы вычислить общий доход для какого-то конкретного отдела (например, отдела 1), придется обратиться, может быть, только к 1% значений, но при этом будет необходимо просмотреть каждый блок данных. Очевидно, что полное сканирование таблицы в этом случае более эффективно.
Потенциальное использование индекса следует учитывать при его создании. Индексы на столбцы с низкой селективностью не выполняют никаких функций, занимают память и являются причиной ухудшения производительности из-за их модификации после каждого изменения в таблице. Составные же индексы позволяют получить значения требуемых столбцов без просмотра блоков данных таблицы, хотя преимущества составных индексов должны быть сопоставимы со стоимостью их создания и поддержки. Поэтому их особенно полезно использовать при сложном плане выполнения предложения или в том случае, когда в результате просмотра таблицы большинство ее строк отвергается [1].
Размер блока базы данных. В заключение рассмотрим зависимость производительности от размера блока базы данных. Из БД Огас1е записывает данные в файлы
базы данных и считывает их блоками. Следовательно, размер блока данных Огас1е всегда должен быть кратным размеру блока операционной системы.
Если при большинстве обращений к БД происходит полное сканирование таблицы или операции по обработке большей части записей выполняются внутри каждого блока, то число обращений к диску уменьшится за счет большого размера блока и производительность слегка увеличится. Однако при выполнении операций по чтению или изменению небольшой части блока, например единственной строки, производительность системы снизится из-за затрат Огас1е на считывание большого блока данных в память, в то время как требуется считать только эту строку.
Таким образом, следует отметить, что уже с самого начала работ по оптимизации программного обеспечения необходимо избрать правильное направление действий. При разработке приложений должна быть использована научная методология, позволяющая избежать бес-
системности, при этом применение каждого инструментального средства должно соответствовать его возможностям и назначению. Тестирование и оценка производительности всегда должны производиться в условиях реальной эксплуатации. Но простое понимание того, как работают различные части системы, является лишь первым шагом к повышению ее производительности. В процессе оптимизации нужно учитывать взаимодействие этих частей, поскольку плохо спроектированные или настроенные элементы системы могут свести на нет все усилия по настройке и оптимизации всех остальных ее элементов.
Библиографический список
1. Jefferson, A. Top Ten Tuning Tips [Electronic resource] / A. Jefferson. Electronic data. Mode of access : http:// samotlor.nips.ru/docum/Oracle/Favorite/ora043.htm. Title from a display.
R. I. Nikitin, V. G. Tretyakov
PROJECTION AND TUNING SOFTWARE FOR EFFECTIVE FUNCTIONING WHITH DATABASE BY THE EXAMPLE DATABASE ORACLE
It is considered software engineering, projection and tuning process for datatabase. Describable approach touch not only engineering software, but and whole system: local area network, server, database, client part. It is shown possible weak points and means for their revelation on design and engineering phase; and also methods to increase productivity by tuning of different pars of the system.
Принята к печати в декабре 2006 г.
УДК 681.3.07
М. Н. Фаворская
ИНВАРИАНТНЫЕ РЕШАЮЩИЕ ФУНКЦИИ В ЗАДАЧАХ РАСПОЗНАВАНИЯ СТАТИЧЕСКИХ ИЗОБРАЖЕНИЙ
Приведена модель порождения статических изображений из эталонных образов для идеального и реального случаев. Введено понятие инвариантных решающих функций на основе принципа инвариантности статистических решений. Проанализированы способы определения максимальных инвариантных функций в некоторых группах методов распознавания изображений статических сцен.
Неформализованность задач распознавания изображений, заключающаяся в том, что они, как правило, ставятся не в формальном виде, а путем предъявления нескольких примеров с указанием принадлежности изображений тем или иным образам, вызывает трудности не только при создании программного обеспечения и аппаратной реализации, но и при теоретической оценке возможностей того или иного устройства или программы. Было предложено множество методов для решения конкретных задач распознавания, которые формально можно классифицировать на следующие группы: геометрические методы, метод потенциальных функций, метод допустимых преобразований, оптимальные и статистические методы, лингвистические методы, эвристические методы и т. д. Но все они решают, по существу, одну и ту же
задачу- задачу распознавания образов, но в разной формальной постановке. Таким образом, можно рассмотреть все методы распознавания с единой позиции и на основании этого построить некоторую обобщенную модель процесса распознавания.
Множество входных статических изображений очень трудно, т. е. практически невозможно описать с помощью аналитических выражений или достаточно простых и хорошо изученных распределений вероятностей, заданных на этом множестве. В общем случае такое множество можно представить как некоторую сложную, допускающую разрывы и изломы, окруженную облаком точек траекторию в многомерном пространстве входных сигналов. Однако такие представления не соответствуют реальной действительности, так как они не отра-
