Вопросы Теги

Задержка на 200 мс между TCP отправляет и tcpdump только с большими сообщениями

PAM LDAP против Active Directory должен хорошо работать.

3
09.02.2012, 01:49
2 ответа

Вы передаете слишком мало байтов в каждом вызове к send или write. Необходимо попытаться передать по крайней мере 2 КБ за вызов, или лучше, 4 КБ за вызов. Если возможно, накопите все логическое сообщение и отправьте его сразу. Это будет сохранять системные вызовы, упаковывать Ваши пакеты более эффективно и препятствовать, задержал ACK уничтожить Вашу задержку.

2
27.01.2020, 21:29
  • 1
    1 138 байтов или 512 байтов в трассировке MQ являются полными логическими сообщениями и отправляются сразу согласно этой той же трассировке MQ. Так или иначе я не понимаю, как большие сообщения могли устранить проблему задержки, так как задержка для маленьких сообщений прекрасна. Где Вы видите отложенный ACK в tcpdump выше? Я не вижу никого. Ваше объяснение, кажется, не соответствует tcpdump и трассировке MQ, которую мы получаем. –  pba 10.02.2012, 01:21
  • 2
    Это соответствует tcpdump отлично. У Вас есть шаблон 40-байтовых пакетов, сопровождаемых сразу большими пакетами в том же направлении. Что-то заставляет те пакеты не быть консолидированными. –  David Schwartz 10.02.2012, 01:26
  • 3
    Если Вы обращаетесь к 40-байтовому пакету в 12:13:05.884718, который является на самом деле просто заголовком TCP для ACK, это намного ранее, чем следующий большой пакет в 12:13:12.697572. Итак, почему они должны быть консолидированы? –  pba 10.02.2012, 02:01
  • 4
    @pba на 12,708367 пакетов и 12,708865 пакетов. Посмотрите на 12,716154 пакетов и 12,717202 пакетов. –  David Schwartz 10.02.2012, 02:12
  • 5
    Как записано в этом вопросе, я знаю, что окно TCP, больше, чем 1 024 с другой стороны, побрило бы приблизительно 10 миллисекунд от задержки. Этот вопрос о задержке на 200 мс между 12.488690 MQ, отправляют и 12,697572 пакетов TCP. Может поведение TCP после 12.69757 объясняет это? Задержка на 200 мс всегда восстанавливаема для больших сообщений (например, 1 138 байтов) и никогда восстанавливаема для маленьких сообщений (например, 512 байтов), и на тестовых и рабочих серверах, и в течение многих месяцев. –  pba 10.02.2012, 03:40

Согласно настройке Linux: экспертное руководство от базы знаний производительности сети ESnet:

Примечание: Кажется, существуют ошибки и в контроллере магистрального интерфейса и в кубические для многих версий 2.6.18 ядер, используемых Redhat Enterprise Linux 5.3 - 5.5 и его варианты (Centos, Научный Linux, и т.д.) Мы рекомендуем использовать htcp с 2.6.18.x ядро для сейфа.

Я не мог найти детали о тех контроллером магистрального интерфейса или кубическими ошибками на базе данных ошибки Red Hat или больше нигде, таким образом, нет никакого доказательства, что это - фактический ответ.

0
27.01.2020, 21:29

Теги

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