Глава 10

Определение проблемы

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

Не вся настройка связана с базой данных. Я помню один особенно сложный случай настройки, когда клиент использовал коммерческое приложение по учету рабочего времени на базе СУБД Oracle. Это приложение уже б]ло установлено в нескольких местах и везде успешно работало. Однако здесь, где пользователей было наибольшее количество, оно полностью разваливалось. Большую часть времени оно работало прекрасно, как и ожидалось. При пиковой нагрузке, например при пересменке или в обеденный перерыв, система периодически зависала. Причем по непонятным причинам. По всем признакам мне было понятно, что проблема связана с блокированием/конфликтами доступа - это б1ло очевидно. А вот понять причины блокирования и конфликтов оказалось непросто. После двух дней поиска в базе данных, просмотра всех представлений V$, изучения кода приложения и признаков проблемы я попросил показать приложение в действии. На концептуальном уровне я понимал, что оно делает, но не знал, как именно делает. Меня привели на склад, где приложение использовали пользователи (фабричные рабочие). Я увидел, как именно они его используют. Они выстраивались в очереди у терминалов и проводили карточкой со штрих-кодом по считывателю, чтобы зафиксировать время прихода. Следующий рабочий в очереди нажимал клавишу Enter, проводил карточкой по считывателю и шел дальше. Неожиданно, пока я там стоял, приложение зависло. Ни одна карточка не считывалась. Потом кто-то подошел к свободному терминалу, нажал клавишу Enter и провел карточкой по считывателю - система заработала! При более детальном анализе приложения стало понятно, что происходит. Оказалось, проблема вообще не была связана с базой данных - это была проблема взаимодействия человека и компьютера. Причиной зависания был интерфейс приложения. Выяснилось, что система создавалась для обработки транзакций следующего вида:

считывается карточка, при этом блокируется строка в таблице и вставляется строка в другую таблицу;

на экран сообщение в]дается о том, что строка вставлена, при этом надо нажать

клавишу Enter;

пользователь нажимает Enter, и приложение фиксирует транзакцию (до этого момента транзакция еще не зафиксирована);

следующий пользователь проводит карточкой по считывателю. На самом деле рабочие делали так:

проводили карточкой по считывателю и уходили;

следующий человек в очереди нажимал Enter вместо предыдущего, фиксируя его

проход, проводил карточкой по считывателю и уходил.

Стратегии и средства настройки 521

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

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

Мораль этих историй в том, что настройка - дело непростое, и решения здесь не всегда интуитивно понятны. Две проблемы настройки не решаются абсолютно одинаково; проблемы не всегда связаны с базой данных, они не всегда находятся в приложении и далеко не всегда вызваны несоответствием архитектуры. Поиск проблем, особенно когда непонятно, как должно использоваться приложение или как оно работает, иногда ведется на удачу . Вот почему некоторые относят настройку к области черной магии . Очень сложно объяснить кому-нибудь, как настраивать систему, если настраивать приходится постфактум. Настройка готового приложения требует опыта расследования, как у хорошего детектива - вы открываете тайну. Для этого требуется соответствующее сочетание технических знаний и опыта работы с людьми (никто не хочет, чтобы на него потом показывали пальцем, и этот аспект надо учитывать). Нет ни простых, ни сложных готовых путей настройки постфактум. Однако я могу рассказать вам, как настраивать по ходу разработки - именно такой стратегии я рекомендую придерживаться. С моей точки зрения, настройкой системы надо заниматься при проектировании. Производительность должна обеспечиваться на всех уровнях системы. Настройка системы постфактум - это фактически не настройка, а переписывание кода и изменение архитектуры.

Глава 10

Мой подход

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

Настройка приложения, часть 1. Настройка изолированного приложения. Обес-

печение его максимально быстрой работы в однопользовательском режиме.

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

Настройка экземпляра/сервера.

Настройка приложения, изолированно и в многопользовательском режиме, требует более 90 процентов всех усилий по настройке. Да, прежде чем обращаться к администратору базы данных мы, разработчики, делаем уже 90 процентов работы. Именно поэтому, я думаю, многие и не понимают, в чем состоит настройка базы данных. Они постоянно просят меня настроить им базу данных и вообще не трогают свои приложения! За исключением экзотических случаев, это физически невозможно. Все ищут то, что я называю магическим параметром инициализации fast=true. Этот магический параметр заставил бы их базу данных работать быстрее. Чем раньше вы смиритесь с тем, что такого параметра нет, тем лучше для вас. Крайне маловероятно, что можно заставить запросы выполняться существенно быстрее простой установкой параметра в файле инициализации. Может потребоваться реорганизация данных, причем я имею в виду не распределение файлов данных по дискам для ускорения ввода/вывода - я говорю об изменении физического порядка столбцов в таблицах, об изменении количества и содержимого таблиц. Это означает переделку приложения.

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

Настройка - непрерывный процесс

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