DeepEdit!

Многие АБД имеют привычку заниматься настройкой до тех пор, пока не бу­дут исчерпаны все возможности. При этом они не только доводят себя (и своих

пользователей) до сумасшествия многочасовой работой допоздна и длительными простоями системы, но и не получают ожидаемого выигрыша в производи-
тельности. Мы абсолютно уверены, что имеется растущее        АБД,
страдающих болезнью принудительной настройки (CTD, Compulsive Tuning Di-
sorder). Мы намерены приложить все усилия, чтобы добиться выделения федерального гранта на проведение продвинутого изучения и исследования
подобных индивидуумов. Если у кого-либо из ваших знакомых наблюдается
CTD — мужайтесь, помощь уже в пути!

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

количественно 

оце­нивать и цели настройки, и результирующее увеличение производительности. Однако в какой-то момент времени любая система попадает в зону действия за­кона об уменьшении возврата инвестиций и прекращает реагировать на любые попытки настройки производительности.

Закон уменьшения возврата инвестиций гласит, что "по мере того, как потре­бители используют дополнительные количества продукта/услуги/ресурса, вы­годы, приобретаемые в результате этого, увеличиваются во все меньшей степени". Говоря обычным языком, если продолжать потреблять нечто, выгода

или удовлетворение, получаемые от этого потребления, в прогрессирующей

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

А теперь зададим провокационный вопрос! Насколько весомой будет разни­ца в производительности системы Oracle (и можно ли будет вообще ее заметить и измерить), .если коэффициент попаданий в кэш (cache-hit-ratio) вырастет с

2 Зак.281

99 до 99,99%? Правдивый ответ будет следующим: очень маленькой! Можно силь­но удивиться, узнав, что производительность системы поддерживается практи­чески на оптимальном уровне даже при 

низком 

(скажем, на уровне 70%) значении коэффициента попадания в кэш. Необходимо периодически задавать самому себе вопрос: "Что в данный момент является узким местом настраивае­мой системы?"

Если система не страдает от узких мест, связанных с вводом/выводом или размерами блока буфера, это значит, что коэффициент попадания в кэш выбран

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

дальнейшего увеличения производительности, следует обратить внимание на другие подсистемы. Настройка — это не конкурс для выяснения, у кого самый высокий коэффициент попадания в кэш или самый низкий коэффициент попа­дания/промаха (get/miss). Это согласованные попытки добиться приемлемой производительности системы.

Мораль

ЕСЛИ узкое место отсутствует, значит, этот компонент не нуждается в на­стройке. Или, как говорят в Техасе, не лечи то, что не болит. Для настройки компонента системы следует сначала измерить разницу в производительности и стоимость своих усилий. Будет ли возврат инвестиций достоин затраченных усилий? Ответить на этот вопрос сможет только сам пользователь.