Агрегация связи (склеивание) для пропускной способности не работает при групп агрегации канала (LAG), установленные на Smart Switch
Попробуйте это, если в вашем распоряжении gawk или mawk :
gawk -v "RS='''" 'FNR%2==0' file
Предполагается, что других '' -s в файле.
Объяснение: Устанавливает разделитель записей в три одинарные кавычки и печатает, если номер записи четный.
К сожалению, он не будет работать со всеми реализациями awk , поскольку многосимвольные разделители записей не являются частью POSIX awk .
Как я упоминал в моем последнем редактировании, причина, по которой я не могу получить более высокую пропускную способность с помощью циклического -связывания, когда на коммутаторе установлены группы агрегации каналов, заключается в том, что группы агрегации каналов коммутатора не выполняют цикл -. robin чередует пакеты по одному TCP-соединению, в то время как связывание linux делает это. Это упоминается в документации kernel.org :
.https://www.kernel.org/doc/Documentation/networking/bonding.txt
12.1.1 MT Bonding Mode Selection for Single Switch Topology
This configuration is the easiest to set up and to understand, although you will have to decide which bonding mode best suits your needs. The trade offs for each mode are detailed below:
balance-rr: This mode is the only mode that will permit a single TCP/IP connection to stripe traffic across multiple interfaces. It is therefore the only mode that will allow a single TCP/IP stream to utilize more than one interface's worth of throughput. This comes at a cost, however: the striping generally results in peer systems receiving packets out of order, causing TCP/IP's congestion control system to kick in, often by retransmitting segments.
It is possible to adjust TCP/IP's congestion limits by altering the net.ipv4.tcp_reordering sysctl parameter. The usual default value is 3. But keep in mind TCP stack is able to automatically increase this when it detects reorders.
Note that the fraction of packets that will be delivered out of order is highly variable, and is unlikely to be zero. The level of reordering depends upon a variety of factors, including the networking interfaces, the switch, and the topology of the configuration. Speaking in general terms, higher speed network cards produce more reordering (due to factors such as packet coalescing), and a "many to many" topology will reorder at a higher rate than a "many slow to one fast" configuration.
Many switches do not support any modes that stripe traffic (instead choosing a port based upon IP or MAC level addresses); for those devices, traffic for a particular connection flowing through the switch to a balance-rr bond will not utilize greater than one interface's worth of bandwidth.
If you are utilizing protocols other than TCP/IP, UDP for example, and your application can tolerate out of order delivery, then this mode can allow for single stream datagram performance that scales near linearly as interfaces are added to the bond.
This mode requires the switch to have the appropriate ports configured for "etherchannel" or "trunking."
Последнее замечание о том, что порты настроены для «транкинга», кажется странным, поскольку, когда я создаю порты в LAG, все исходящие Tx от коммутатора проходят через один порт. Удаление LAG заставляет его отправлять и получать половину и половину на каждом порту, но приводит к большому количеству повторных отправок, я полагаю, из-за пакетов порядка -из -. Тем не менее, я все еще получаю увеличение пропускной способности.
В вашем тексте есть несколько моментов, по которым, я думаю, я могу немного пояснить ваши мысли:
- Тот факт, что вы так небрежно упомянули, что переключаетесь между обычными кадрами и кадрами Jumbo, меня беспокоит. Вы не можете смешивать одни и те же кадры Jumbo сети/сетевого блока и обычные кадры. Либо вся эта сеть передает Jumbo-кадры, либо обычные кадры, и я имею в виду все интерфейсы в этой сети.
- Если у вас есть агрегированный канал, он должен быть с обеих сторон, как со стороны коммутатора, так и со стороны системы; другие неприятные вещи могут и будут происходить; если повезет, в лучшем случае коммутатор обнаружит петлю и просто отключит одну из ссылок;
- Если вам нужна скорость, вам нужна агрегация каналов, а не балансировка нагрузки -;
- одно соединение UDP и, в основном, TCP не будет сильно масштабироваться после определенного порога; вам нужно протестировать несколько одновременных подключений.
iperfпозволяет это сделать; - на таких скоростях вы можете столкнуться с другими ограничивающими факторами при работе с агрегацией каналов на двух каналах вместо одного, особенно при обработке прерываний.
Что касается коммутатора, я не очень хорошо разбираюсь в TP -ССЫЛКА, и это не тема -здесь, чтобы попасть в темы коммутатора. Я просто оставлю в стороне идею о том, что если вы работаете профессионально, вам лучше использовать более высокоуровневое -оборудование для достижения лучших результатов в более эзотерических функциях или высокопроизводительных сетях.
См. как узнать, должны ли мои серверы использовать большие кадры (MTU)и связанные Можно ли установить большие кадры -MTU=9000 на машинах VM?
Что касается смешивания 9000 и 1500 в одной и той же VLAN/группе интерфейсов:
If the server transmits a packet to the client that is greater than 1500 bytes in the given configuration, it will simply be dropped and not processed, which is different to fragmentation
Make sure that your NICs exist in separate netblocks when doing this. If you use Linux, packets are routed via the first NIC in the system in the netblock, so, even though eth1 has an MTU of 9000, it could end up routing those packets through eth0.
We set up a separate VLAN to our storage network and had to set up a separate netblock on eth1 to avoid that behavior. Increasing the MTU to 9000 easily increased throughput as that particular system deals with streaming a number of rather large files.