Полный курс лекций 2009-го года (1130357), страница 77
Текст из файла (страница 77)
Если такой пакет получили сотни илитысячи машин, то в ответ последует ураган сообщений. Этой проблеме был подвержен протокол UDP дотех пор, пока не было внесено изменение в протокол, разрешающее или запрещающее слатьподтверждение. Другой пример – перезагрузка машин в сети после сбоя питания. Все машины разомринутся на RARP-сервер и файл-сервер за надлежащей информацией.
В результате произойдет коллапссерверов.Другая причина – несоответствующая настройка системы. Например, если машины в сети имеютдостаточно мощные процессоры и достаточно памяти, но под буфера в системе памяти выделено мало. Врезультате пакеты будут теряться из-за переполнения буферов. Аналогично, если планировщик процессовв операционной системе не дает достаточно высокий приоритет процессу обработки TPDU, то пакеты будуттеряться.Другой параметр настройки – время time_out.
Если time_out на подтверждение слишком короток, томного будет повторных посылок, если велик – скорость передачи упадет. Еще один пример - времяожидания попутного сообщения, с которым можно отправить подтверждение о полученном пакете. Еслизначение этого параметра мало, то будет много дополнительных пакетов-уведомлений. Если велико, тополучатель может генерировать запросы по time_out и скорость передачи упадет.Появление гигабитных сетей принесло новые причины потери производительности. Пусть мы хотимпередать пакет из Москвы во Владивосток, и у нас есть линия на 1 Гбит/сек., а у получателя - буфер на64 Кбайт. Задержка на передачу в одном направлении по оптоволоконному каналу будет около 20 мсек.Через 500 мксек все 64 Кбайт будут в канале, и отправитель будет ждать подтверждения, которое придетне ранее чем через 40 мсек с момента отправки первого байта сообщения.
В результате пропускнаяспособность канала будет использована на 1,25%! Дело в том, что буфер у получателя надо устанавливатьравным произведению пропускной способности канала на величину задержки. В данном примере этавеличина равнялась бы 40 млн.бит. А на практике он должен быть даже чуть больше. Получатель покакой-либо причине может не сразу отреагировать на поступившие данные.Рисунок 6-31. Состояние передачи 1 мегабита из Сан Диего в Бостон: (a) t=0;(b) После истечения 500 мксек; (c) После истечения 20 мсек; (d) Послеистечения 40 мсек6.4.2. Измерение производительности в сетиКогда пользователи сети обнаруживают падение производительности их приложений, они идут кадминистратору сети с жалобами.
Последний обязан выяснить, что случилось, и принять необходимыемеры. Типичная последовательность действий при исправлении производительности сети такова:1.Измерить надлежащие параметры сети и производительность2.Постараться понять, что происходит3.Изменить один параметрЭти шаги надо повторять до тех пор, пока либо не удастся повысить производительность, либо нестанет ясно, что имеющимися ресурсами этого сделать нельзя.Измерения можно проводить в разных местах и разными способами. Основная идея всех измеренийсостоит в том, чтобы запустить какую-то активность и измерить, как долго она продолжается, какиесобытия ее сопровождают.
Измерение длительности и сбор информации о событиях таят много подвохов.Ниже перечислены лишь некоторые из них.§Количество испытаний должно быть достаточно велико.Измерить время доставки одного сегмента TPDU не достаточно. Это надо проделать миллионы раз.Тогда вычисление среднего и дисперсии будет свободно от влияния случайных факторов. В курсематематической статистики можно посмотреть, как выполнять такие вычисления.§Выборка испытаний должна быть представительной.Проводить испытания надо в разное время дня и года.
Что толку измерять производительность сети вуниверситете в августе? Если измерения проводятся с 12 до 14, они опять-таки они не точны. В это времячасто уходят на обед.§Надо учитывать разрешающую способность часов.Как правило, таймер машины работает от сети 50 Гц. Поэтому измерять моменты наступлениясобытий, происходящих чаще, чем через 20 мсек., им нельзя. Однако, если измерить интервал, когдапроизошло миллион регулярных событий, то, вычислив среднее, мы получим нужное значение.§Ничего неожиданного во время измерений происходить не должно.Необходимо быть уверенным, что измерения происходят при «типичных» нагрузках. Нет единичныхвсплесков активности, например, лабораторных работ.
Нельзя быть уверенным, что все «тихо» толькопотому, что измерения происходят в 3 часа утра. Хотя бы потому, что программа архивации работаетобычно именно по ночам.§Кэш-память может разрушить ваши измерения.Пусть, например, мы хотим измерить время передачи файла. Для этого надо будет его открыть,передать, закрыть и измерить общее время. Сделать это надо будет много раз. Однако если файл меньшеразмера кэш-памяти, то мы будем измерять скорость кэш-памяти, и только первое измерение будетпоказывать производительность сети. Чтобы избежать этого эффекта, надо выбирать файлы достаточнобольшого размера.Аналогичное влияние может оказывать буферизация.
Например, если UDP получает подтверждениеот сетевого уровня, как только сетевой уровень получил пакет, и на сетевом уровне есть буфер на 1000дейтаграмм, то, проведя 999 испытаний, мы получим скорость передачи выше, чем пропускнаяспособность физического канала.§Нужно четко осознавать, что вы измеряете.Когда вы измеряете время чтения удаленного файла, то ваши измерения зависят от сетевой среды,операционных систем клиента и сервера, их сетевых плат, драйверов и т.п. Если вы хотите настроитьвзаимодействие при конкретной конфигурации, то ваше измерение имеет смысл.
Если эти измерения будутиспользованы для выбора сетевых карт, то собранные таким образом данные не годятся. Например, можетоказаться, что драйвер, используемый в измеряемой конфигурации, работает отвратительно с выбраннойсетевой платой.§Надо быть очень осторожным при экстраполяции результатов.Проведя измерения при определенной нагрузке, надо быть очень осторожным при их экстраполяции.Во многих случаях предположение о линейной экстраполяции может быть неверным (рисунок 6-27).Рисунок 6-32.
Время отклика как функция от нагрузки6.4.3. Правила, улучшающие производительностьПовышать производительность существующей сети можно лишь в определенных пределах. Кудабольшие возможности для этого есть при проектировании сети. Ниже перечислены некоторые правила,сформулированные исключительно на опыте создания многих сетей.§Правило 1: Скорость процессора важнее, чем скорость сети.Опыт показал, что накладные расходы назначительно больше, чем накладные расходы при(удаленный вызов процедуры) на Ethernet должноудается снизить до 1500 мксек. Основные задержкиработу операционной системы и стека протоколовпередаче по физическому каналу. Теоретически RPCзанимать не более 102 мксек. На практике редко егопроисходят в системном программном обеспечении.Аналогично, при использовании высокоскоростных каналов важно повысить скорость доставки байтадо канала и его обработку при получении.
Другими словами, удвоив скорость процессора на хосте, можноудвоить пропускную способность сети. Удвоив емкость сети, можно ничего не получить, так как узкимместом будет программное обеспечение хоста.§Правило 2: Понижай число пакетов, чтобы сократить накладные расходы программногообеспечения.При обработке TPDU часть накладных расходов приходится на обработку самого TPDU, например,заголовка пакета, а часть - на обработку байтов TPDU, к примеру, на подсчет контрольных сумм. Поэтому,посылая TPDU в 128 байт, мы в 32 раза увеличиваем накладные расходы, чем если бы мы использовалиTPDU в 4 Кбайт.На нижних уровнях большое влияние имеют прерывания, сопровождающие поступление пакета.
ВRISC-процессорах они ломают конвейер, вызывают переключение контекста, изменение кэш-памяти и т.д.Заметим, что алгоритмы Нагла и Кларка для «дурацкого окна» сокращают именно число прерываний.§Правило 3: Минимизируй переключение контекста.Минимизировать переключения контекста удается с помощью специальных процедур, позволяющихнакапливать пакеты и сообщения в буферах, прежде чем передавать их процессу более высокого уровня.Пример переключения контекста при размещении процесса сетевого менеджера в адресном пространствепользователя показан на рис.6-48.
Основную неприятность переключения контекста составляет потерякэша.§Правило 4: Минимизируй число копий.Куда больший ущерб производительности, чем переключение контекста, наносит множественноекопирование одного и того же пакета. Обычно пакет, принятый сетевым интерфейсом, буферизуют насетевой плате, потом в ядре на сетевом уровне, затем в буфере транспортного уровня и лишь потом вбуфере приложения!Хорошая операционная система буферизует пословно. Однако типично операция буферизациизанимает на менее 5 команд на слово.
При процессоре с 50 MIPS (миллионов команд в секунду) созданиетрех копий при пяти командах на 32-битовое слово потребует 75 нсек. на байт. Таким образом,максимальная скорость приема данных будет не более 107 Мбит/сек. Учитывая обработку заголовков,прерываний, переключение контекстов, получим не более 50 Мбит/сек. Очевидно, что и речи быть неможет о работе с таким процессором на линии в 1 Гбит/сек.Отметим также, что 50 Мбит/сек. - это скорость без учета обращений в память.
С учетом памяти онабудет раза в три меньше, около 16 Мбит/сек.§Правило 5: Увеличение пропускной способности не сократит задержку.Если вам нужна пропускная способность, вы можете купить ее, например, проложив еще одинкабель. Однако это не сократит задержку при передаче. Это требует улучшения программногообеспечения стека протоколов, системного программного обеспечения и сетевых интерфейсов.§Правило 6: Лучше избегать перегрузок, чем восстанавливаться после них.При перегрузках пакеты теряются, расходуется пропускная способность, возникают бесполезныезадержки и т.п. Восстановление после всего этого требует времени и усилий.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
