... h2. Сетевые карты
Наша компания давно работает с операторами связи. Несмотря на то что мы пишем софт, нам часто приходится помогать решать проблемы с оборудованием.
И пришли к выводу: *категорически запрещено использовать* *D-Link* */* *Realtek{*}* и другие дешёвые сетевые карты в сервере Carbon Reductor\!*
Возможно как железо они не так уж и плохи, но дело в их драйвере:
# Одна очередь на rxtx, вне зависимости от числа доступных ядер процессора.
# Отсутствие возможности задать параметры размеров ring-буферов сетевой карты (маленький буфер приводит к потерям)
# Отсутствие возможности задания coalesce-параметров, нам важен rx-usecs, за счёт его уменьшения можно снизить нагрузку с сетевой карты, увеличив нагрузку на процессор.
# Отсутствие поддержки NAPI драйвером.
|| Вендор || Модель || Тип || Число \\
очередей \\
(макс.) || Размер \\
буфера \\
(макс.) || Макс. наблюдавшаяся \\
нагрузка {color:#000000}{*}на 1 порт *{color}с \\
отсутствием потерь и \\
др. проблем || Проблемы ||
| Intel | 80003ES2LAN, 82541GI \\
82541PI, 82574L, 82540EM \\
82545EM, 82579LM, 82578DM \\
82571EB, 82573L, 82573E \\
82578DC, 82546EB, 82546GB \\
I219-V, I217 | 1 Гбит/сек | other=1 | rx=4096 | ? | Хоть мы и рекомендуем Intel, но конкретно эти модели брать \\
не советуем. Только одна очередь, в итоге всем будет заниматься только одно ядро процессора. Автоматическая настройка RPS \\
сглаживает это, но как правило проблемы сохраняются. \\
\\
Для рабочей станции эти сетевые карты подходят, \\
но для сервера фильтрации - не очень. |
| VMware | VMXNET3 | 1 Гбит/сек | combined=? | rx=4096 | 0 мбит/сек | Виртуальные машины не способны предоставлять \\
гарантированную скорость реакции. Тем не менее \\
это один из лучших драйверов для виртуальных \\
сетевых карт. |
| VMware | VMXNET | 1 Гбит/сек | other=1 | ? | | Лучше выберите VMXNET3. |
| Red Hat, Inc | Virtio | ? | ? | ? | ? | ? |
| Broadcom \\
Emulex | NetXtreme BCM5720 | 1 Гбит/сек | rx=4 \(?) | rx=2047 | ? | |
| Broadcom | NetXtreme: BCM5701, BCM5704 \\
BCM5714, BCM5715, BCM5719 \(?) | 1 Гбит/сек | other=1 | rx=511 | ? | 1 очередь, малый буфер \\
Не распределяют нагрузку между ядрами, если поступает \\
тегированный (VLAN, QinQ) или VPN трафик. \\ |
| Broadcom | NetXtreme BCM5708S | 1 Гбит/сек | other=1 | rx=2040 | ? | 1 очередь |
| Broadcom | NetXtreme II: BCM5708, BCM5709 \\
BCM5716, BCM5721, BCM5722 | 1 Гбит/сек | combined=8 \\
? | rx=2040 | ? | Проблема в распределении прерываний при наличии \\
VPN / VLAN / QinQ в трафике, вся нагрузка \\
ложится на первую очередь. |
| NVIDIA | MCP55 | 1 Гбит/сек | | rx=16384 | ? | Несмотря на огромный буфер плохо \\
справляется с нагрузкой, 1 очередь |
| Via Technologies \\
D-Link, Realtek, \\
Qualcomm Atheros \\
3Com, Marvell, \\
QLogic, NC326i, \\
TP-Link | | | | | | |
| Chelsio (cxgb3) | n320e \\ | 10 Гбит/сек | 4 | rx=1024 \\
(потенциально \\
rx=16384) | 900мбит/сек | Не получается увеличить размер буфера до максимально возможного, любые действия направленные \\
на изменение размера буферов с помощью ethtool [всегда возвращают ошибку Device is busy.|https://access.redhat.com/solutions/695443]\\
При превышении нагрузки в 1.2Гбит/сек при задействовании 4 ядер 3.5GHz возникают time squeeze. \\
Нагрузка на CPU при этом довольно высокая, ≈180000 пакетов/сек приводят к ≈55000 прерываний/сек. \\
В top нагрузка от обработки прерываний (%si) отображается пиками, 3-10% поднимаются до 30-45%. \\
В теории решение проблемы с увеличением буфера до максимума должно помочь. \\
Игнорирует параметры ethtool \-C eth0 rx-usecs. \\ | \\ |
h2. Материнские карты
|
