Подумал, что необходим небольшой пост, посвященный сетевым адаптерам/интерфейсам, которые устанавливают в своих ИТ-ландшафтах пользователи. Речь пойдет не столько о конкретных моделях, сколько про то, что сеть такой же компонент информационной системы (как и те же диски, память, CPU), и на него нужно обращать не менее тщательное внимание. Многие его просто игнорируют и недооценивают – «Ну сеть и сеть, что там с ней может быть не так? Вот же 10 Гбит/с. Вот график пропускной способности. Всё прекрасно.».

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

С одной стороны, при взаимодействии серверов будет использоваться shared memory, а не IP-протокол. Это вроде как быстрее. Но с другой, у вас может возникать конкуренция за аппаратные ресурсы, которые моментально сведут на нет весь выигрыш. А ещё вы становитесь заложником лишь вертикального расширения системы (добавить памяти или CPU), что может быть даже невозможно. Поэтому с точки зрения стратегического планирования – это путь, скорее, для малых и средних систем, ибо при масштабировании бизнеса вы быстро упретесь в аппаратные ограничения. И ваша задача, как владельцев или администраторов это предвидеть и предупредить.

На этом вступление завершаю.

Что там с IP-трафиком?

Для однородного трафика (например, копирование больших файлов, бекапов) – достаточно такой характеристики сети, как пропускная способность. Но в высоконагруженных системах на базе той же платформы 1С:Предприятие трафик как раз очень неоднородный – запросы очень разные, много коротких и очень коротких запросов.

Это влечет за собой такое требование к сетевому интерфейсу – как отклик. То есть, какое количество запросов в единицу времени может быть передано с сервера приложений 1С к серверу БД (MS SQL или PostgreSQL).

Например, для выполнения отчета серверу 1С необходимо переслать на сервер СУБД 5000 разных запросов. Если отклик сети при проверке достигает всего 500 запросов в секунду, то накладные расходы на сетевой интерфейс будут 10 секунд. Таким образом, для ускорения отчета, не считая других оптимизационных мероприятий, пригодилась бы оптимизация сети. Это может быть как замена сетевой карты, так и замена драйверов и настроек, чтобы повысить показатель отклика.

Продавцы, да и производители, часто указывают в характеристиках сетевых карт лишь пропускную способность. Она, несомненно, важна, но её недостаточно для обоснованного выбора сетевой карты под ваши нужды. И, зачастую, именно показателем отклика сетевой карты обусловлена разница в цене одинаковых по пропускной способности сетевых карт.

Как проверить отклик сетевой карты

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

Для замеров характеристик сети используется кратковременное подключение (в одной сессии) к любой БД на сервере СУБД, в рамках которого в течении одной минуты выполняется простейший запрос:

SELECT 'NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN'

Длина строковой константы 500 символов. Результаты представлены в виде отчета в html-формате.

Синтетические замеры для трех сетевых карт разной пропускной способности

Ниже приведены «эталонные» замеры отклика по 1-, 2.5- и 10 гигабитным карточкам. Сервера физические, одни и те же. На каждом эксперименте просто меняем карты и делаем замеры.

Сетевые карты:

• 10 Гбит/с : Intel[R] Ethernet Controller X540-AT2

• 2,5 Гбит/с: Realtek PCIe 2.5GbE Family Controller

• 1 Гбит/с: Realtek PCIe GbE Family Controller

Замер 1. Контроллер 1Гбит/сек [Realtek PCIe GbE Family Controller]

Нагрузки на сеть почти нет – порядка 3%. Отклик составляет порядка 2500 запросов в секунду. Это идеальные условия, в одной сессии. При реальной загрузке СУБД отклик может быть несколько ниже – на 10-20%.

Замер 2. Контроллер 2,5 Гбит/с [Realtek PCIe 2.5GbE Family Controller]

Для 2,5 гигабитного адаптера загрузка стала меньше – 1,5%, что естественно. Отклик увеличился до 2900 – 3000 запросов в секунду.

Замер 3. Контроллер 10 Гбит/с [Intel[R] Ethernet Controller X540-AT2]

Ну и последний замер провели для 10-гигабитного адаптера. Общая нагрузка на сеть – 0,5%. Отклик стал уже в районе 4000 запросов в секунду.

Замеры отклика на реальных системах

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

Система 1

Вот ситуация за неделю по счетчику количества запросов в секунду от SQL сервера и системному счетчику нагрузки на сетевой интерфейс

По верхнему графику видно, что через SQL-сервер проходит в среднем 1,5-2 тыс. запросов в секунду, а по нижнему графику видно, что гигабитный сетевой интерфейс особо не нагружен (всплески раз в день – это ежедневный бэкап базы). То есть, все нормально и хорошо. Но если получить замеры сетевого отклика от сервера 1С до сервера MS SQL, то результаты катастрофически низкие:

На гигабитном канале связи порядок цифр должен быть порядка ~2…2,5 тыс. запросов/сек., и полученные замеры отстают от них на порядок.

Система 2

Тут ситуация лучше, чем в первом случае, но все равно показатели ниже в 2-2,5 раза, чем должен выдавать сетевой адаптер. Чем более нагружена система, тем больше рисков, что сетевая карта не сможет обеспечить необходимый трафик данных.

Итого

Еще раз повторюсь о том, что сказано в начале.

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

Можно самому написать скрипт. Можете воспользоваться нашей готовой утилитой для связки Windows+MS SQL.

Если замеры не просядут (примерный порядок цифр см. выше в синтетических тестах), значит с сетевой картой все хорошо. Если они будут ниже в разы, то очень вероятно, что одна из проблем падения производительности вашей ИТ-системы – сетевая инфраструктура.

Что с ней может быть не так? Чаще всего – это неверные настройки или не те драйвера, настройки маршрутизации, ну и сама сетевая карта (чип, архитектура). Особенно это распространено среди виртуальных адаптеров, коих в ИТ-ландшафтах становится все больше и больше. А ошибки настройки не так очевидны без подобных замеров.

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