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

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

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

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

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


Rambler's Top100

  

Базы данных как источник сетевых заторов

Дон Маквитти

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

Если учесть стремительный прогресс технологий в области баз данных (БД) и аппаратных средств, то нет ничего необычного в том, что современная СУБД использует восемь ЦП, память объемом 2 Гбайт и два или четыре запараллеленных сетевых адаптера. Сеть может стать “узким” местом для такой сверхмощной БД, особенно если она не была рассчитана на большой пользовательский трафик.

Особенность функционирования БД состоит в том, что она порождает неравномерный сетевой трафик, поскольку выдает результаты по мере поступления запросов. До недавнего времени ограничения, связанные с операциями чтения и записи в файловой системе СУБД, скоростью ЦП, доступом к памяти и сети, не позволяли базам данных с их неравномерной активностью чрезмерно перегружать сеть. Подобная неравномерность трафика характерна и для некоторых других серверов, таких, например, как FTP.

Полную версию данной статьи смотрите в 10-ом номере журнала за 2003 год.

Чтобы сгладить “взрывную” нагрузку от БД, лучше всего найти оптимальный способ обращения к ней клиентских приложений. Существует два подхода в формировании клиентских запросов к базе данных: “предоставить мне все данные по всем нашим заказчикам, а потом я на месте разберусь с ними” и “предоставить информацию по заказчикам, удовлетворяющим условию X, причем только их имена, адреса и номера телефонов”.

При разумном формулировании SQL-запроса объем пересылаемых данных сокращается. Чем больше пользователей, тем сильнее воздействие их запросов на приложения и сеть. Один или два пользователя вряд ли обременят сеть даже запросом, по которому выбираются, например, все 25 тыс. записей длиной 100 байт. Но если сделать это попытаются 300 пользователей, то у вас возникнут проблемы. Тогда вам придется оптимизировать запросы или базу данных и пересматривать организацию сети и ее пропускную способность.

Если у вас имеется всего одно-единственное активное соединение с БД, то оно будет пропускать через себя лишь минимальный объем трафика, что неэффективно с точки зрения использования СУ БД, но хорошо для сети. При наличии у вас большого числа активных соединений, которые подолгу простаивают, вы, возможно, напрасно нагружаете сеть, поскольку большинство технологий БД включает обмен сообщениями для удержания соединений открытыми. Тогда, вам, вероятно, следует сократить число активных сеансов, учитывая тип холостых соединений, которые используются в конкретной СУБД.

Критерии благополучия

Чтобы оценить влияние трафика БД на сеть, вы должны измерить его с помощью сетевого анализатора. Мы использовали для этой цели Ethereal, программу с открытым исходным кодом, предназначенную для перехвата пакетов, хотя для этого годится любое другое средство сетевого мониторинга. Сообщив приложению Ethereal необходимую информацию о сервере БД, мы запустили его и проанализировали полученные результаты.

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

Кроме того, сетевой анализатор позволяет вам определить количество соединений с БД. База данных, которую мы исследовали, получала и отправляла множество пакетов, когда устанавливала соединение. То и дело открывающиеся заново соединения увеличивают трафик.

И наконец, измерьте объемы данных, которые БД возвращает клиенту в ответ на запрос. Мы исследовали результаты запросов и определили качество кода поставщиков приложений. Если вы обнаруживаете, что определенное приложение пересылает большие объемы данных через вашу сеть, поработайте с поставщиком приложения над усовершенствованием этого ПО. При возникновении проблем с мониторингом трафика определенной БД мы рекомендуем установить зеркальный порт на коммутаторе. Это даст гарантию, что вы будете получать трафик только той машины, которая вас интересует.

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

Контролируйте соединения

Теперь, когда у вас имеются данные о том, как трафик БД влияет на вашу сеть, вы можете попытаться его снизить. Как при любой настройке БД, здесь большую роль играет качество SQL-запросов к ней. Решение проблем с SQL-запросами обычно приводит к решению проблем с производительностью БД.

Следующее, о чем необходимо позаботиться, — это использование пула соединений. Идея проста — нужно поддерживать несколько постоянных открытых соединений между БД и приложением или сервером приложений, тогда вы сможете использовать их неоднократно, но в этом случае вам придется решить несколько вопросов.

Наиболее важным из них является безопасность. Соединения с базой данных кэшируются на уровне приложения или потока (thread). Некоторые технологии СУБД с кэшированием на уровне приложения оставляют возможность получить несанкционированный доступ к данным. Однако технологии с кэшированием на уровне потоков избавлены от подобной проблемы, поскольку не используют совместно соединения внутри приложения — каждый поток имеет свою собственную защиту.

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

В случае, когда вам доступен исходный код ваших программ и эти программы используют средства доступа ODBC или JDBC (Java Database Connectivity), вы можете включить в ваш код пулинг соединений (на уровне приложения). Лучше всего, если ваши приложения работают на сервере приложений, так как большинство серверов приложений поддерживают в той или иной форме пулинг соединений.

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

Изменения пойдут на пользу

Организация пула соединений — это лучшее решение на ближайшую перспективу. Путем внесения нескольких простых изменений в файлы конфигурации сервера приложений или небольшой модификации программного кода вы можете получить огромную экономию в расходовании полосы пропускания. Эффективность этого подхода во многом зависит от моделей доступа ваших пользователей. Если большое число пользователей многократно обращаются к БД, то улучшение производительности будет существенным, поскольку прекратятся многократные возобновления соединений. Но при небольшом числе пользователей, обращающихся к БД с длительно выполняющимися запросами, улучшение окажется минимальным.

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

Если вам все же не удалось уменьшить сетевой трафик с помощью вышеописанных методов, для соединения коммутатора с БД и сервером приложений используйте Gigabit Ethernet. Стоимость этой технологии снизилась, поэтому увеличение пропускной способности с помощью данного оборудования уже вполне реально и станет хорошим решением в случае, когда ваши проблемы возникают из-за перегрузки сети на участке между БД и сервером приложений. Но если ваше приложение использует “толстый” клиент для обращения к базе данных, вам придется модернизировать еще и магистраль, поскольку уже все коммутаторы должны будут поддерживать технологию Gigabit Ethernet.

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

Даже при корректной реализации Web-сервисы создают более напряженный сетевой трафик, чем традиционные запросы, по двум причинам — из-за добавления служебных данных протокола SOAP (Simple Object Access Protocol) и трансляции результатов в формат XML или текстовый. При некорректной реализации накладные расходы могут быть немалыми — около 250 байт на обращение, плюс разница в размере между представлением данных в вашей БД и в текстовом формате.

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





  
10 '2003
СОДЕРЖАНИЕ

электронная Россия

• Нижегородский форум инфокоммуникаций

бизнес

• Собеседование: как правильно оценить кандидата

инфраструктура

• ИБП в параллель

• Тестируем адаптеры iSCSI

• Сканируя эфир

информационные системы

• Как бороться с текучкой в call-центрах

• Корпоративные системы мгновенного обмена сообщениями

• Корпоративный контакт-центр

• Базы данных как источник сетевых заторов

сети связи

• Сети сигнализации будущего

• Процедура предварительного уведомления как один из путей усовершенствования протокола RSVP

• Хот-споты набирают силу

• Поставщики услуг хот-спотов: общие цели, уникальные достоинства

кабельные системы

• Высокоскоростной доступ по нескольким медным парам

• Маркирование кабельных систем по стандарту TIA/EIA-606-A

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

• Сделайте свою сеть безопасной

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

• Switch 7700: возврат на рынок корпоративных решений


• Калейдоскоп



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