Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Стратегия многопроцессорной обработки

Джон Д. Рули

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

При тестировании измерялась производительность серверов с различными показателями быстродействия процессора, числом процессоров, объемом оперативной памяти и величиной рабочей нагрузки. Была смоделирована работа информационной системы вымышленного банка под названием New Technology Bank of Modesto. Наш “банк” получился близкой к реальной жизни моделью для тестирования возможностей симметричной многопроцессорной обработки (SMP).

Случай первый

Предположим, группа инвесторов решила внедрить последние достижения информационных технологий для поддержания деятельности New Technology Bank of Modesto — банка, где все транзакции осуществляются через банкоматы или другие электронные средства. Наша цель — решить, какое для этого потребуется аппаратное и программное обеспечение.Относительно выбора операционной системы (ОС) можно сказать следующее: предпочтение будет отдано системе, подобной Windows NT Server. Вы спросите: почему? NT Server масштабируемая ОС, поддерживающая огромные дисковые массивы (до 408 млн. терабайт), большие объемы оперативной памяти (до 4 Гбайт), а так же SMP, причем при использовании как процессоров Intel, так и процессоров RISC. Наш банк может начинать с малого, однако при выборе NT есть уверенность, что его запросы не превысят возможностей этой ОС. Такая предусмотрительность в будущем предохранит вас от дорогостоящих изменений программного обеспечения и связанного с этим переобучения сотрудников. Конечно, выбор ОС не единственная задача. Для банка очень важен контроль за постоянно изменяющимися клиентскими счетами. В случае, если клиент снимает деньги через банкомат, то перед завершением транзакции необходимо выяснить сумму вклада на счету данного клиента, затем изменить ее и записать результат на диск. Подобные операции являются жизненно важными для банка: потеря какой-либо информации о счете клиента или всей базы данных может привести к банкротству.

К счастью, существует несколько неплохих многопользовательских баз данных, работающих на платформе NT Server. Нами была выбрана Microsoft SQL Server 6.0, полностью использующая свойства масштабируемости NT.

Можно ли ожидать, что комбинация SQL Server и NT предоставит приемлемую производительность для нашего банка? Тесты, опубликованные фирмой Microsoft, показывают производительность свыше 100 транзакций в секунду (т/с) для сервера с одним процессором Pentium. На многопроцессорных системах она возрастает до величины более 1000 т/с. До-статочно ли этого?

Каждая операция, осуществляемая клиентом при помощи банкомата, представляет собой одну транзакцию. Такие операции включают просмотр счетов, снятие, вклад и перевод денежных сумм. Клиент очень редко проводит больше нескольких транзакций в минуту. Следовательно, выполнение транзакций со скоростью 1 т/с на банкомат может считаться надежным даже в наихудшем случае. При условии, что наш банк начнет свое развитие с двадцати банкоматов, система, обеспечивающая производительность 20 т/с, будет более чем достаточной.Очевидно мощности сервера с одним процессором Pentium с избытком хватит для выполнения данной работы. Но каковы должны быть объемы его оперативной и дисковой памяти?

Начиная с малого

Фирма Microsoft определяет объем оперативной памяти 16 Мбайт в качестве минимального как для SQL Server 6.0, так и для NT Server 3.51. С этого минимального объема мы и начали. Что касается объема дисков, то здесь все зависит от числа клиентов. Если предположить, что банк имеет 10 тыс. клиентов, каждый из которых в среднем осуществляет одну транзакцию в день, то потребуется разместить 3650 тыс. записей базы данных в год. При объеме каждой транзакции примерно 1 Кбайт база данных займет 3,7 Гбайт. В действительности наша тестовая установка не имела столь большого диска (см. врезку “Методика тестирования SQL Server”), однако его объема, равного 2 Гбайт, было вполне достаточно для проведения начальных экспериментов.

Теперь нам осталось решить следующее: сколько клиентских систем мы хотим запустить и как подсоединить их к серверу. Придерживаясь нашего сценария развития New Technology Bank of Modesto, начнем с 20 клиентских систем, каждая из которых является банкоматом. Поскольку известно, что скорость передачи данных для каждого клиента составляет 1 т/с и меньше, то можно использовать недорогое низкоскоростное (38,4 Кбит/с) подключение через последовательный порт. Обычно NT Server имеет встроенные службы удаленного доступа (Remote Access Services — RAS), поддерживающие подобные соединения. Прогон системы с 20 банкоматами на сервере с минимальной конфигурацией показал производительность всего лишь 16,9 т/с, т. е. ниже требуемого минимума в 20 т/с.

Обнаружение узкого места

Почему же мы получили всего 16,9 т/с? Ведь процессор способен и на большее. Очевидно, достижению необходимой производительности препятствует какой-то другой компонент, играя роль узкого места.Вместе с NT поставляется очень мощное средство — Performance Monitor, способное определять узкие места системы. Оно представляет собой встроенный анализатор, при помощи которого можно узнать много интересного о NT и ее приложениях. Таким образом, нет необходимости гадать, что же мешает работе системы, определить это можно при помощи Performance Monitor.

Поработав с Performance Monitor, мы отметили два интересных момента. Сетевой трафик составлял чуть более 10 Кбит/с, т. е. ниже теоретического максимума в 38,4 Кбит/с, а сброс страниц (при недостатке памяти NT приходилось сбрасывать на диск страницу в 4 Кбит для освобождения дополнительной памяти) происходил от 50 до 100 раз в секунду. Все это навело на мысль, что системе не хватает памяти, или полосы пропускания, или того и другого вместе. Чтобы определить, какой именно компонент сдерживает производительность, мы изменили их оба — увеличили оперативную память до 32 Мбайт и заменили соединение через последовательный порт (38,4 Кбит/с) на канал Ethernet (10 Мбит/с), примерно в 300 раз быстрее. Результат, приведенный в табл. 1, оказался весьма интересным.

Как видно из таблицы, увеличение полосы пропускания сети при сохранении объема оперативной памяти имело небольшой эффект. Увеличение оперативной памяти до 32 Мбайт при сохранении каналов связи со скоростями 38,4 Кбит/с было несколько эффективнее, однако только увеличение обоих параметров позволило получить впечатляющий результат —почти пятикратное увеличение производительности.

Это типичный случай влияния узких мест на работу системы. При объеме памяти 16 Мбайт наша платформа способна лишь на 17,5 т/с, независимо от ширины полосы пропускания (38,4 Кбит/с или 10 Мбит/с). При полосе пропускания 38,4 Кбит/с система может достичь производительности 27 т/с, независимо от объема памяти (16 или 32 Мбайт). Удаление одного узкого места приводит к активизации другого.

Ликвидировав оба узких места, мы в конце концов добились ожидаемой производительности. Полученные результаты позволяют сделать малоприятный вывод. Поскольку подводить каналы Ethernet ко всем банкоматам очень дорого, придется ограничиться увеличением объема памяти сервера, обеспечивающим производительность 27 т/с. Это отвечает нашим требованиям: по сценарию необходимо лишь 20 т/с. Но что будет, если мы немного изменим масштабы системы?

Случай второй

Давайте расширим нашу модель до масштабов страны. Легко представить себе тысячу банков-филиалов, подобных описанному выше, в каждом из которых установлено 20 банкоматов. Достаточно ли масштабируема платформа NT/SQL Server для подобной системы? Чтобы ответить на этот вопрос, мы перешли к двухпроцессорной конфигурации (табл. 2).

Любопытно, что, несмотря на удвоение процессорной мощности, дела улучшились незначительно. Было похоже, что мы наткнулись на еще одно узкое место. Для его нахождения пришлось вновь обратиться за помощью к Performance Monitor. Быстрая проверка показала, что сетевой трафик заметно ниже 10 Мбит/с (предел Ethernet), т. е. проблема не связана с сетью. Памяти тоже вполне хватало. В первом случае использовалось 70% ресурсов процессора, во втором — 35%, следовательно, добавление второго процессора не очень помогло.

Мы исключили память, сеть и процессоры, и оставалось только проверить работу дисковой подсистемы. Тут мы обнаружили, что диск работает в условиях стопроцентной загрузки, обеспечивая производительность 350 Кбайт/с. Итак, узкое место найдено.

Для его ликвидации был использован тот факт, что SQL Server осуществляет доступ к двум отдельным логическим устройствам базы данных: устройству данных и устройству журнала транзакций. Перенос последнего на отдельный диск существенно поправил дело (см. табл. 2).

Однако это не решило проблему полностью. С добавлением второго процессора ожидалось удвоение производительности. Этого не произошло, и мы вновь обратились к Performance Monitor. Было обнаружено, что при одном процессоре (его загрузка в конце концов составила 100%) два диска обеспечивали передачу данных на уровне 360 Кбайт/с. В случае с двумя процессорами коэффициент использования их ресурсов составил 75% (это означает, что максимальная возможность двухпроцессорной системы ограничена пределом в 400 т/с), однако мы получили стопроцентное использование ресурсов дисков: производительность дисковой подсистемы составила 600 Мбайт/с. Иными словами, возможности дисковой подсистемы были снова исчерпаны. Установка дополнительных дисков (возможно, в составе дисковых массивов, подобных RAID) может решить эту проблему, давая 400 т/с, что действительно похоже на предел производительности сервера.

Закон уменьшения отдачи

Избавившись от узкого мес-та, связанного с работой диска, мы получили на нашем сервере с одним процессором Pentium (90 МГц), производительность примерно 250 т/с. Это наводит на мысль, что добавление второго процессора позволит достичь приблизительно 500 т/с. Однако этого не происходит: даже в идеальных условиях производительность достигает лишь величины 400 т/с. Конечно, мы намеренно выдерживали последовательную тяжелую загрузку сервера, намного большую той, что существует в реальных условиях. Почему же дела обстоят именно так? Вероятно, это происходит вследствие феномена конфликтной ситуации, регулируемого законом Амдала, суть которого сводится к отрицанию существования бесплатного завтрака.

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

В идеале добавление второго процессора улучшает производительность системы примерно на 60%. Третий процессор сможет прибавить не более 60% от того, что предоставил второй. И так далее.Положительный эффект значительно уменьшается при добавлении более четырех процессоров. Кроме того, в этом случае необходимо учесть возможность возникновения других узких мест. Как было показано выше, для получения производительности, намного превышающей 150 т/с, необходимо добавить второй диск, который в свою очередь расширяет границы производительности до 300 т/с. Следовательно, для получения 600 т/с необходим, по крайней мере, массив из четырех дисков. Возможно, для достижения таких результатов надо будет решить проблему и с шириной полосы пропускания сети.

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

Теперь, что касается New Technology Bank, работающего в масштабах страны. Мы определили, что банку-филиалу с 20 банкоматами необходим сервер, обеспечивающий производительность 20 т/с. Но сколько подобных филиалов может быть у нашего банка? Хотя это, впрочем, не имеет большого значения. Ведь достижение производительности более нескольких сотен транзакций в секунду просто не возможно при использовании одного сервера, при этом не важно, сколько процессоров в нем установлено.

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

А что случится, если клиент попытается осуществить транзакцию через банкомат не своего филиала? Если каждый филиал работает независимо, то это будет серьезной проблемой. В этом случае банку придется либо отказаться от проведения таких транзакций — однако тогда и клиент может отказаться от услуг вашего банка — либо пойти на риск и завести несколько копий счета клиента с вероятностью их рассогласования.Во избежание этого банку-филиалу необходимо выполнить двухэтапную комбинацию (при нахождении счета клиента в местном филиале транзакция выполняется напрямую): если счет клиента находится в удаленном филиале, то местный филиал должен скопировать его оттуда, а затем, после выполнения транзакции, вернуть уже обновленный счет. Все эти операции будут зависеть от сети, связывающей все филиалы, которая сама может стать узким местом.

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

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


распечатать статью




  
2 '1996
СОДЕРЖАНИЕ

колонка редактора

• Сладкие сети

локальные сети

• Сценарии входа в сеть

• Высокоскоростные сетевые адаптеры

• Службы NetWare и новые средства разработки приложений

• Cisco и 3Com в одном проекте

• Массивы RAID: емкость и производительность

корпоративные сети

• "Штормящая" сеть

• Суперсерверы широкого пользования

• Catalyst 5000 фирмы Cisco

• Сетевая ловушка, или Платформы управления

• Установка и настройка средств удаленного доступа Windows 95

услуги сетей связи

• Пейджеры

• Беспроводные мосты

приложения клиент-сервер

• Стратегия многопроцессорной обработки

• Доступ к базам данных по низкоскоростным каналам

открытые системы

• Мир TCP/IP. Протоколы UDP и TCP

• Как улучшить Web-страницу?

защита данных

• Руководство по выбору ИБП

• Голосование без обмана

новые продукты

• Семейство BayStack, Цветные струйные принтеры DeskJet 1600C и DeskJet 1600CM, Дисковый массив StorageWorks RAID Array 230 ...



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх