Вопросы Теги

Почему моя пропускная способность TCP намного больше, чем пропускная способность UDP?

Шаг "форматирования" в установке не совсем точен с процентами (на самом деле, это просто делит 100% на количество разделов для создания), поэтому когда это, кажется, зависает, это могло бы действительно работать правильно.

Я соглашаюсь, что 16 часов кажутся чрезмерными, даже для известно медленной ext3 инициализации (пишущий в блочные устройства происходит синхронно, и ext3 инициализация требует, чтобы много данных было записано в маленьких блоках, расположенных с интервалами далеко друг от друга, который является о худшем случае), однако имейте в виду, что одновременно инициализация RAID также работает с определенной минимальной пропускной способностью (т.е. диски перегружаются в большой степени).

Как я могу помочь:

  • думайте о своей схеме разделения:
    • Если / раздел является реальным разделом, а не объемом LVM, нет никакой потребности в отдельном /boot, и Вы почти наверняка хотите свою область подкачки посреди диска, а не в конце.
    • 2 ТБ / раздел черт, потому что он берет возрасты, чтобы проверить, идет ли что-нибудь когда-нибудь не так, как надо, и Вы ничего не можете сделать об этом.
  • инициализируйте RAID с --assume-clean. Это означает, что RAID не будет первоначально синхронизировать диски, который прекрасен, если Вы уже записали им как нули
  • создайте файловую систему из командной строки (таким образом, Вы видите больше детализированного прогресса).

Если бы Вы изменяете свою схему разделения, я предложил бы что-то как

  • раздел 1: /boot (500 МБ)
  • раздел 2: LVM PV
    • LV 1: / (500 МБ)
    • LV 2: /usr (8 ГБ)
    • LV 3: /var (4 ГБ)
    • LV 4: /home (размер согласно персональному предпочтению, 100 ГБ - то, что я использую),
    • LV 5: swap
    • LV 6: /srv/ (размер согласно персональному предпочтению и цели машины)

Это должно полностью хорошо оставить большую часть пространства освобожденной, можно изменить это позже, когда система установлена, и можно также добавить дополнительные файловые системы для определенных сервисов, которые используют много пространства, что означает, что, если один из этих сервисов неправильно функционирует и начинает заполнять диск, он только заполнит свой собственный раздел (это также, почему Вы имеете отдельный /var - вход может работать, когда корневой раздел полон.

15
31.03.2014, 00:07
1 ответ
[119119] Кроме того, что вы не получили подробной информации о вашей тестовой установке, основная проблема, похоже, заключается в том, что вы используете сообщение размером 64 байта. Это далеко от обычного MTU размером 1500 байт и делает UDP весьма неэффективным: в то время как TCP объединяет несколько сообщений в один пакет на проводе (за исключением случаев, когда установлен TCP_NODELAY) для эффективного использования соединения, каждое UDP-сообщение будет приводить к отдельному пакету. В числах: около 23 сообщений размером 64 байта будут объединены в один TCP пакет размером MTU, в то время как для UDP сообщения потребуется 23 единичных пакета на тот же объем данных. Каждый из этих пакетов означает накладные расходы, связанные с отправкой с хоста, передачей по проводам и получением коллегами. И, как видно в вашем случае, около 80% UDP-пакетов теряются, потому что ваше аппаратное обеспечение не достаточно быстро передает и принимает все эти пакеты. 

select * from questionresults into outfile 'c:/test/training.txt'

Итак, что Вы можете узнать из этого эталона:
UDP ненадежен (потеря 80% пакетов)

UDP неэффективен, если используется с размерами пакетов намного ниже MTU
TCP сильно оптимизирован для наилучшего использования соединения

Что касается Ваших ожиданий, то UDP должен быть лучше: Вы когда-нибудь задумывались, почему все основные передачи файлов (ftp, http,...) выполняются по протоколам, основанным на TCP? Эталон показывает Вам причину.

mysql db_name < query.sql > training.txt
Так почему люди вообще используют UDP?

С данными в реальном времени (например, голос по IP) Вас не волнуют старые сообщения, поэтому Вы не хотите, чтобы отправитель объединял сообщения в большие пакеты, чтобы эффективно использовать ссылку. И вы скорее смиритесь с тем, что пакет теряется, чем с тем, что он приходит слишком поздно.

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

enter image description here

"выбрасывать" данные: иногда более важно отправить данные и не заботиться о потере пакетов, например, с помощью сообщений журнала (syslog)

Кратковременные взаимодействия: с TCP Вам необходимо установить соединение и поддерживать его состояние, что стоит времени и ресурсов на клиенте и сервере. Для коротких взаимодействий (таких как короткий запрос и ответ) это может быть слишком накладным. Из-за этого DNS обычно делается с помощью UDP, но имеет встроенные повторные попытки поверх UDP.

29
27.01.2020, 19:49

Теги

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