Сравнение методов

Оценить
(0 голоса)

Временами кажется, что использовались правильные показатели и были зафиксированы правильные данные, но все-таки проблема существует. Так произошло несколько лет тому назад в производственной группе автора этого издания, когда многие из коллег сравнивали результаты проведенных измерений масштабируемости. Была определена максимальная производительность OLTP для различного количества центральных процессоров на одной и той же аппаратной платформе и под управлением одной и той же версии Solaris. Но при этом использовались различные продукты РСУБД. В каждом случае сначала была установлена максимальная производительность со всеми включенными центральными процессорами, затем некоторые центральные процессоры были отключены и определено новое значение максимальной производительности. После этого было отключено еще некоторое количество центральных процессоров, и этот эксперимент повторялся до тех пор, пока в системе не остался единственный работающий ЦП. Конечным результатом стала кривая масштабируемости, начиная с одного центрального процессора и до максимального количества центральных процессоров на данной аппаратной платформе.

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

•             Команда 1: По мере уменьшения количества центральных процессоров объем памяти, используемый для кэша БД, оставался неизменным. Более емкие кэши означают меньшее количество физических операций дискового ввода/вывода, уменьшение затрат ресурсов ЦП на одну транзакцию и более высокую производительность. Для меньшего количества центральных процессоров размер кэша относительно производительности был большим, что привело к более высокой производительности на нижнем конце кривой и соответственно к плохой масштабируемости по мере того, как увеличивалось количество центральных процессоров.

•             Команда 2: По мере уменьшения количества центральных процессоров размер кэша БД уменьшался в той же самой пропорции. Следовательно, производи-

тельность меньшего количества центральных процессоров была более низкой, однако масштабируемость была лучше.

•             Команда 3: Чтобы исключить любые изменения в плане влияния размера кэша БД, размер этого кэша изменялся экспериментально на каждом уровне измерения для того, чтобы гарантировать, что количество физических операций дискового ввода/вывода на одну транзакцию оставалось в точности одним и тем же для всех измерений. И вновь таки результатом была относительно низкая производительность при небольшом количестве центральных процессоров, но оставалась хорошая масштабируемость.

Поразмыслив, можно прийти к выводу, что Команда 3 применяла самый лучший метод, хотя каждый подход, конечно, имел свои достоинства. Основным, однако, является тот факт, что результаты различных команд непосредственно не могли быть сравнимы. Уроком для всех должно быть следующее правило - не принимать ничего на веру и задавать больше вопросов.

Противоречия интервалов
Противоречия накопления и представления данных
Законченная картина
Четкая картина
Выводы и рекомендации

Добавить комментарий


Защитный код
Обновить