... Наша компания давно работает с операторами связи. Несмотря на то что мы пишем софт, нам часто приходится помогать решать проблемы с оборудованием.
И пришли к выводу: *категорически запрещено использовать* *D-Link* */* *Realtek{*}* и другие дешёвые сетевые карты в сервере Carbon Reductor\!*
Возможно как железо они не так уж и плохи, но дело в их драйвере:
# Одна очередь на rxtx, вне зависимости от числа доступных ядер процессора.
# Отсутствие возможности задать параметры размеров ring-буферов сетевой карты (маленький буфер приводит к потерям)
# Отсутствие возможности задания coalesce-параметров, нам важен rx-usecs, за счёт его уменьшения можно снизить нагрузку с сетевой карты, увеличив нагрузку на процессор.
# Отсутствие поддержки NAPI драйвером.
|| Вендор || Модель || Тип || Число \\
очередей \\
(макс.) || Размер \\
буфера \\
(макс.) || Макс. наблюдавшаяся \\
нагрузка {color:#000000}{*}на 1 порт *{color}с \\
отсутствием потерь и \\
др. проблем || Проблемы ||
| Intel | 80003ES2LAN, 82541GI \\
82541PI, 82574L, 82540EM \\
82545EM, 82579LM, 82578DM \\
|
... \\
Для рабочей станции эти сетевые карты подходят, \\
но для сервера фильтрации - не очень. |
| 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. Материнские карты
|
