Почему у карты 1GBit вывод ограничен до 80 MiB?

80 МБ / с - это действительно неплохо! Это примерно 640 Мбит / с, что чертовски близко к гигабитной пропускной способности сетевой карты. Если принять во внимание накладные расходы TCPIP и скорость диска, вы, вероятно, используете максимальную скорость.

Попробуйте поместить это в свой /etc/sysctl.conf

# General 10gigabit/LFP tuning
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_max_orphans=1048576
net.ipv4.tcp_orphan_retries=2

# Removes some internal buffering
net.ipv4.tcp_low_latency=1

# Time-wait sockets
# Do not turn on unless you know what you are doing!
#net.ipv4.tcp_tw_recycle=1
#net.ipv4.tcp_tw_reuse=1

# If PMTUD ICMP blackhole appears use
# RFC 4821, Packetization Layer Path MTU Discovery
net.ipv4.tcp_mtu_probing=1

# Netfilter's conntrack
# NB! For high-performance concerns you probably don't want to use `--state` rules at all 
#net.ipv4.netfilter.ip_conntrack_max=1048576
#net.nf_conntrack_max=1048576

# SACKs are an optimization to TCP which in normal scenarios improves considerably performance. 
# In Gigabit networks with no traffic competition these have the opposite effect. 
# To improve performance they should be turned off with: 
#net.ipv4.tcp_sack=0 

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout=15
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time=1800

# Increased backlog (default: 100/1000 depending on kernel)
net.core.netdev_max_backlog=10000
net.core.somaxconn=10000

# Timestamps adds additional 12 bytes to header and uses CPU
# NB! It caused massive problems for me under benchmark load
# with a high count of concurrent connections.
# ( http://redmine.lighttpd.net/wiki/1/Docs:Performance )
#net.ipv4.tcp_timestamps=0

# Portrange for outgoing connections
# (increase the ephemeral port range)
# NB! After that tuning you probably do not want to listen on port >= 1024
net.ipv4.ip_local_port_range=1024 65535

# Fixing 'Too many open files', Second useful on nginx+aio workloads
fs.file-max=16777216
fs.aio-max-nr=65536

# If you are under DDoS you can
kernel.panic=10
# Lower following values
#net.ipv4.tcp_synack_retries=2
#net.ipv4.tcp_syn_retries=2
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=15
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=15
# If you under ping flood
#net.ipv4.icmp_echo_ignore_all=1

Для каждого устанавливаемого нами соединения требуется временный порт и, следовательно, файловый дескриптор, и по умолчанию он ограничен 1024. Чтобы избежать проблемы «Слишком много открытых файлов», вам необходимо изменить ulimit для вашей оболочки. Это можно изменить в /etc/security/limits.conf, но требует выхода / входа. На данный момент вы можете просто выполнить sudo и изменить текущую оболочку (su для вашего непривилегированного пользователя после вызова ulimit, если вы не хотите запускаться от имени root):

ulimit -n 999999

Еще одна вещь, которая может помочь увеличить пропускную способность TCP, - это увеличить размер очереди интерфейса. Для этого сделайте следующее:

ifconfig eth0 txqueuelen 1000

Вы можете поиграть с контролем перегрузки:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control=htcp

Также есть настройка низкого уровня, например параметры модуля ядра

# /sbin/modinfo e1000
..snip...
parm:           TxDescriptors:Number of transmit descriptors (array of int)
parm:           TxDescPower:Binary exponential size (2^X) of each transmit descriptor (array of int)
parm:           RxDescriptors:Number of receive descriptors (array of int)
parm:           Speed:Speed setting (array of int)
parm:           Duplex:Duplex setting (array of int)
parm:           AutoNeg:Advertised auto-negotiation setting (array of int)
parm:           FlowControl:Flow Control setting (array of int)
parm:           XsumRX:Disable or enable Receive Checksum offload (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive 

И даже аппаратные настройки более низкого уровня, доступные через ethtool(1).

PS. Прочтите ядро ​​документацию, особенно Документация / сеть / scaling.txt

PPS. При настройке производительности TCP вы можете проконсультироваться с RFC6349

PPPS. D-Link - не самое лучшее сетевое оборудование. Попробуйте оборудование Intel с pci-x или pci-64

Ваша 32-битная шина PCI с частотой 33 МГц может передавать максимум 1067 мегабит в секунду (Мбит / с) или 133,33 мегабита в секунду (Мбит / с).

Gigabit Ethernet может передавать 116 мегабайт в секунду (МБ / с).

Итак, хотя вы карта должен Если вы сможете полностью заполнить линию, вы фактически сможете использовать только около 90% из-за различных накладных расходов.

В любом случае, если вы получаете 80 мегабайт в секунду (МБ / с), то вы не за горами, и я был бы достаточно доволен этим на данный момент.

Гигабитный Ethernet составляет чуть более 1 миллиарда биты в секунду. При кодировке 8/10 это дает максимум около 100 МБ в секунду. 32-битная шина PCI должна иметь возможность пропускать 133 МБ / с, и вы должны иметь возможность ее насыщать (я могу продемонстрировать насыщение шины PCI с помощью карты оптоволоконного канала и получить цифру, близкую к теоретической пропускной способности шины), поэтому маловероятно, что это будет причиной узкого места, если нет другого автобусного движения.

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

Узкие места на скоростях GigE могут возникать в разных местах.

• Дисковая подсистема: требуется как минимум 3-4 жестких диска в RAID-массиве того или иного типа, чтобы достичь скорости GigE. Это верно для отправляющей и получающей стороны.
• ЦП: GigE может использовать гораздо больше ЦП, чем вы думаете. Учитывая, что он находится в слоте PCI 33 МГц, я собираюсь рискнуть и сказать, что эта система довольно старая и может иметь более медленный процессор.
• Накладные расходы TCP / IP: некоторые биты, которые передаются по сети, не являются полезными данными, а являются другими служебными битами. Это говорит о том, что у меня была система, которая стабильно работала со скоростью 115 МБ / с с одним каналом GigE.
• Шина PCI: является ли сетевой адаптер единственным устройством на этой шине PCI или используется совместно с другим устройством.
• Другие факторы: существует слишком много других факторов, чтобы упоминать их все, но одними из самых важных будет то, что происходит другая активность дискового ввода-вывода. Это сочетание чтения / записи, множества небольших запросов ввода-вывода и т. Д.

Насколько вы уверены, что узким местом является карта? Возможно, это лучшая скорость, которую он может согласовать с устройством на другом конце, поэтому он застрял в ожидании. Другое устройство могло зависнуть на скорости 10/100, поэтому 80 будет примерно правильным с небольшими накладными расходами.

После долгих исследований я публикую свои выводы:

1. Сходство процесса и сродство irq сетевого адаптера должны быть фиксированными и равными. Следует остановить процесс irqbalance (Linux).
2. Карта должна работать в режиме PCIe, например. х4. Если слот PCIe не поддерживает этот режим, карта будет работать в режиме x1, что приведет к узкому месту.

По моему опыту, 80 МБ / с - это неплохо. Я не видел намного более высоких скоростей, независимо от того, какая комбинация сетевых адаптеров и коммутаторов используется. Я помню, что 100 Мбит / с показали примерно то же поведение. Использование 70-80% - это почти все, о чем вы могли мечтать, хотя в наши дни я вижу, что гигабитное оборудование работает выше 90% в режиме 100 Мбит / с.

Для сравнения, моя самая первая домашняя гигабитная конфигурация, основанная на коммутаторах SMC и интегрированных сетевых адаптерах Broadcom, едва могла управлять скоростью 400 Мбит / с. Теперь, годы спустя, используя управляющие коммутаторы Netgear вместе с сетевыми картами Intel и Marlin, я обычно нахожусь в диапазоне устойчивой передачи 70-80 Мбайт / с.

Если вам нужно больше, рассмотрите возможность объединения нескольких интерфейсов.

вы получаете очень хорошую скорость, если можете проверить на своем конце переключателя

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml