Вопросы Теги

Локальный сокет unix - приблизительное представление о пропускной способности

Другой способ - использовать ipset с iptables. ipset доступен в большинстве базовых репозиториев Linux.

Вы можете создать набор IP-адресов, используя, например ,- 

ipset create serverblacklist hash:net
ipset -A serverblacklist 192.168.1.24

... и добавить такое правило для блокировки IP-адресов serverblacklist в таблице ipset- 

iptables -A INPUT -p tcp -m set --match-set serverblacklist src -j DROP

Аналогичным образом вы можете создать белый список IP-адресов для allow и запись IPtables, чтобы явно разрешить их, в зависимости от того, что наиболее целесообразно.

9
28.11.2016, 10:31
2 ответа

Вы можете использовать socat для простого теста скорости сокета UNIX.

Ниже приведены результаты, которые я получил на своем ноутбуке: 

#Generate 1GB random file in the "shared memory" (i.e. RAM disk) 
>dd if=/dev/urandom of=/dev/shm/data.dump bs=1M count=1024

Память на диск (SSD) через сокет UNIX 

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock ./data.dump &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.96942 s, 545 MB/s

Память в память через сокет UNIX 

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/shm/data.dump.out &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.927163 s, 1.2 GB/s

Память на / dev / null (сбросить) через Сокет UNIX 

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.720415 s, 1.5 GB/s

/ dev / zero в / dev / null, через сокет UNIX 

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/zero bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.491179 s, 2.2 GB/s

Как вы можете видеть, даже тестовая пропускная способность «память на диск» составляет 545 МБ / с (т.е. ~ 4360 МБ / с), что намного превышает максимальная теоретическая пропускная способность для Ethernet-соединения 1 ГБ (что составляет ~ 1000/8 = 125 МБ / с, даже без учета накладных расходов протокола).

P.S.

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

22
27.01.2020, 20:05

Мой "ответ" длинный - главное не путать 'пропускную способность' и 'пропускная способность' - хотя 'пропускная способность' может быть ограничивающим фактором

Короче говоря, ваша пропускная способность может быть ограничена, даже если ваша пропускная способность не насыщена.

Мне приходилось помогать людям понять влияние многоуровневых стеков приложений.

Для аспекта TCP-коммуникаций я использую разницу в RTT (round-trip-time).

Для одноуровневых приложений вы можете сравнить локальный IP-адрес (на сетевой карте) с lo0 (loopback).

Для многоуровневых вы сравниваете/вычисляете "более удаленные" адреса, например, многоуровневыми могут быть либо две VM на одном хосте, либо разные хосты в одном дата-центре, либо они могут быть в разных дата-центрах (может быть расстояние всего 500 метров, но все равно разное).

К сведению: для многих приложений разница в RTT незначительна, но для приложений, которые делают 10-100 тысяч небольших сообщений для приложения, время RTT может стать узким местом.

(Я видел ситуации, когда "пакет занимал почти 6 часов в многоуровневой системе, когда RTT был на .25 миллисекунд больше, по сравнению с одноуровневой)

Итак, простой тестовый стенд:

The

for host in 127.0.0.1 192.168.129.63 192.168.129.72 192.168.129.254 192.168.129.71 p5.aixtools.net
do
    wget -q http://${host}/ -O - >/dev/null
    sleep 1
done

И моя программа мониторинга - tcpdump - с опцией -ttt

 -ttt
 Печатает дельту (в микросекундах) между текущей и предыдущей строкой в каждой строке дампа.

Микросекунда - это единица времени СИ, равная одной миллионной (0.000001 или 10-6 или 1/1,000,000). То есть, 1000 микросекунд == 1 миллисекунда.

Итак, в двух разных окнах у меня запущен tcpdump:

Для "локального" времени: tcpdump -i lo0 -n -ttt port 80 И для "удаленного" tcpdump -I en1 -n -ttt port 80

В данных ниже - цель не в проведении анализа, а в том, чтобы показать, как можно определить "различия" во времени, необходимом для завершения транзакций. Когда пропускная способность приложения представляет собой последовательные транзакции - на пропускную способность в "сек|мин|час" влияет общее время, необходимое для "ответов". Мне проще всего объяснить это с помощью понятия RTT - round-trip-time.

Для реального анализа есть дополнительные вещи, на которые нужно обратить внимание. Поэтому я покажу только начальное рукопожатие TCP, первый исходящий пакет и возвращающийся ACK. Для сравнения сравните дельту времени до возвращения "ответа".

127.0.0.1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type 0, capture size 96 bytes
00:00:00.000000 IP 127.0.0.1.42445 > 127.0.0.1.80: S 1760726915:1760726915(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 0>
00:00:00.**000035** IP 127.0.0.1.80 > 127.0.0.1.42445: S 3339083773:3339083773(0) ack 1760726916 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 1482096651>
00:00:00.000013 IP 127.0.0.1.42445 > 127.0.0.1.80: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>
00:00:00.**000014** IP 127.0.0.1.80 > 127.0.0.1.42445: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>

192.168.129.63

обратите внимание на 01.XXXXXX - для секундного сна на интерфейсе "lo0"

00:00:01.006055 IP 192.168.129.63.42446 > 192.168.129.63.80: S 617235346:617235346(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 0>
00:00:00.**000032** IP 192.168.129.63.80 > 192.168.129.63.42446: S 1228444163:1228444163(0) ack 617235347 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 1482096653>
00:00:00.000014 IP 192.168.129.63.42446 > 192.168.129.63.80: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>
00:00:00.**000010** IP 192.168.129.63.80 > 192.168.129.63.42446: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>

192.168.129.72

виртуальная машина на том же хосте - обратите внимание, время начинается с 00. 000000 - отображается первый пакет (и 01.XXXXXX для двух других адресов ниже)

root@x063:[/]tcpdump -i en1 -n -ttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
00:00:00.000000 IP 192.168.129.63.42447 > 192.168.129.72.80: S 865313265:865313265(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096655 0>
00:00:00.**000125** IP 192.168.129.72.80 > 192.168.129.63.42447: S 916041515:916041515(0) ack 865313266 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1481318272 1482096655>
00:00:00.000028 IP 192.168.129.63.42447 > 192.168.129.72.80: . ack 1 win 32761 <nop,nop,timestamp 1482096655 1481318272>
00:00:00.**000055** IP 192.168.129.72.80 > 192.168.129.63.42447: . ack 1 win 65522 <nop,nop,timestamp 1481318272 1482096655>

192.168.129.254

мой маршрутизатор - вне хоста, не виртуальная машина. 

00:00:01.005947 IP 192.168.129.63.42448 > 192.168.129.254.80: S 2756186848:2756186848(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096657 0>
00:00:00.**000335** IP 192.168.129.254.80 > 192.168.129.63.42448: S 2327415811:2327415811(0) ack 2756186849 win 5792 <mss 1460,nop,nop,timestamp 44854195 1482096657,nop,wscale 2,nop,opt-14:03>
00:00:00.000022 IP 192.168.129.63.42448 > 192.168.129.254.80: . ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>
00:00:00.**000090** IP 192.168.129.63.42448 > 192.168.129.254.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>

192.168.129.71

то же соединение, что и 192.168.129.72, но оно "занято", в то время как "72" простаивает. Я надеюсь, что начальные рукопожатия почти идентичны

00:00:01.005093 IP 192.168.129.63.42449 > 192.168.129.71.80: S 249227688:249227688(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096659 0>
00:00:00.**000072** IP 192.168.129.71.80 > 192.168.129.63.42449: S 1898177685:1898177685(0) ack 249227689 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1482096104 1482096659>
00:00:00.000022 IP 192.168.129.63.42449 > 192.168.129.71.80: . ack 1 win 32761 <nop,nop,timestamp 1482096659 1482096104>
00:00:00.**000050** IP 192.168.129.71.80 > 192.168.129.63.42449: . ack 1 win 65522 <nop,nop,timestamp 1482096104 1482096659>

несколько хопов

это тот же хост, тот же результат apache, но теперь через внешний интерфейс (6 IP хопов, а не напрямую) - теперь вы можете увидеть эффект дальнего RTT. (p.s., я немного изменил IP-адрес). Что еще более важно - обратите внимание, что после начального квитирования есть два исходящих пакета до первого ACK после возврата квитирования.

Итак, вместо 25 мс RTT, считайте, что RTT составляет 250 микросекунд по сравнению с 25 микросекундами - и у вас 500 тысяч транзакций (что составляет всего 120-125 секунд дополнительно по сравнению с локальным, и пропускная способность, имхо, сопоставима. Но при 50M транзакций (как у меня было в реальной ситуации) вы получаете дополнительные 12500 секунд - что добавляет около 3,5 дополнительных часов для "буквально" той же работы. (и частью решения для этого случая было сделать пакеты больше - средний размер изначально был 400-450 байт).

Напомним, что я хочу показать здесь довольно простой способ учета различия в общем времени выполнения приложения (пакетного задания) при сравнении многоуровневой и одноуровневой архитектур. 

00:00:01.162974 IP 192.168.129.63.42450 > XX.85.86.223.80: S 1331737569:1331737569(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096661 0>
00:00:00.**023962** IP XX.85.86.223.80 > 192.168.129.63.42450: S 3130510306:3130510306(0) ack 1331737570 win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 1482096106 1482096661,nop,opt-14:03>
00:00:00.000025 IP 192.168.129.63.42450 > XX.85.86.223.80: . ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.000062 IP 192.168.129.63.42450 > XX.85.86.223.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.**024014** IP XX.85.86.223.80 > 192.168.129.63.42450: . ack 1 win 65522 <nop,nop,timestamp 1482096107 1482096661>

Еще одна вещь, которая мне "нравится" в использовании tcpdump - это то, что это общедоступная программа. Ничего дополнительного устанавливать не нужно.

3
27.01.2020, 20:05

Теги

Похожие вопросы

  • 16
    rpc.statd, работающий на системе, не используя NFS 09.09.2011
    У меня есть машина Debian, которая получает предупреждения (через Tiger автоматический аудитор), что rcp.statd слушает на таком-то и таком-то сокете. Поиск с помощью Google шоу rpc.statd является демоном, используемым NFS. Насколько я знаю, я'...
  • 12
    "Сохранить" удаленный сеанс SSH? 24.11.2019
    Я пытаюсь сделать это в сценарии. Мне нужно запустить некоторые команды на удаленном хосте. В настоящее время я делаю это: ssh root@host 'bash -s' < command1 ssh root@host 'bash -s' < команда2 ssh (скрытый)
  • 19
    Почему длина пути сокета ограничена сотней символов? 25.05.2017
    В системах Unix имена путей обычно практически не имеют ограничений по длине (ну, 4096 символов в Linux) ... за исключением путей к файлам сокетов, которые ограничены примерно 100 символов (107 символов на ...
  • 2
    gzip * .txt vs gzip test.txt & gzip test2.txt & 12.07.2017
    Я хочу ускорить процесс gzip. (сервер - AIX 7.1) Более конкретно, текущая реализация - это gzip * .txt, и ее выполнение занимает до 1 часа. (извлечение файлов довольно велико, и мы получили ...
  • 1
    Правило Udev, устанавливающее сокет SocketCAN, работает правильно только при запуске вручную 31.05.2016
    Я хочу запустить slcand (демон пользовательского пространства для драйвера интерфейса CAN последовательной линии), когда мой Lawicel CanUSB ключ подключен. Я следовал пошаговому руководству Паскаля Уолтера, и все вроде работает (...
  • 57
    Тире или некоторая другая оболочка “быстрее”, чем удар? 03.08.2014
    Я всегда думал, что единственное преимущество использования тире вместо удара было то, что тире был меньшим, и поэтому много экземпляров тире запустятся быстрее во время начальной загрузки. Но я провел некоторое исследование...
  • 1
    Увеличение выполнения чтений файла открытого текста 17.10.2014
    В нашем приложении биоинформатики у нас есть большие файлы (до 900 МБ, обычно 100 МБ). Эти файлы содержат представление открытого текста генома и являются по существу 1 файлом строки с последовательностью...