Как mtr работает / интерпретирующий болевые точки с помощью mtr
Если база данных будет установлена использовать "Полный" режим восстановления, то Вы не сможете уменьшить его, пока Вы не создали резервную копию журналов транзакций.
Если Вы не требуете восстанавливаемости, обеспеченной этим режимом восстановления, устанавливаете его на Простой, и необходимо смочь уменьшить базу данных, не требуя резервного копирования журнала.
1) Отбрасывается ли пакет на ХОСТЕ n = Сумма отброшенных пакетов для пакетов, отправленных исключительно для ХОСТа n?
Да, они предназначены специально для этого хоста. MTR полагается на отправку пакета с фиксированным TTL и ожидает получить ответ ICMP «время истекло» на первоначально отправленное эхо ICMP, которое будет исходить от маршрутизатора, время жизни которого превышено.
Насколько безопасно это предполагать. , что пакеты, отправленные, чтобы сказать HOST 7, имели бы те же предыдущие переходы?
Это довольно безопасно, я не могу говорить обо всех сетях, но это невероятно необычно для межсегментного маршрута - ожидать, что трафик будет маршрутизироваться по нескольким путям - это может случиться, но это скорее исключение, чем норма.
2 ) В Примере 1, на HOST 3 и 4, потеря пакетов одинакова (10%). Можно ли предположить, что вся потеря пакетов, таким образом, произошла на узле 3?
Нет, вероятно, нет. Можно было бы ожидать, что после этого будут производные потери для всех других переходов (т.е. потеря около 10% на переходах 5, 6, 7, 8 и 9), если это был случай, когда узел 3 действительно отбрасывал пересылаемые пакеты.
3) В Пример1. Когда происходит потеря пакетов на HOST 4 на 10%, не должны ли следующие прыжки также влиять на производительность? Если у меня 10% потеря пакетов в одном из промежуточных узлов, узлы после него также должны испытать некоторую потерю пакетов, верно?
Да, если вы получаете настоящую потерю пакетов. К сожалению, все намного сложнее.
4) В примере 2 некоторые узлы имеют более высокое значение StDev. Следует ли их интерпретировать как точки ненадежности?
mtr действительно может дать вам лишь приблизительную цифру. Многие маршрутизаторы отбрасывают пакеты ICMP в рамках режима качества обслуживания (icmp менее важен для него, чем трафик TCP / UDP). Другие могут задерживать трафик или делать то и другое.
Все, что вы действительно можете сказать, это то, что отправка ICMP-трафика, на который должен отвечать этот маршрутизатор, может привести к ненадежной производительности, но вы не можете сказать, что то же самое верно для других типов трафика, например TCP.
Подводя итог, если у вас есть реальная потеря пакетов в конкретный пункт назначения, вызванная промежуточным переходом маршрутизатора, вы увидите <= loss% на всех последующих этапах.
Если ваш узел назначения отвечает при потере 0% вы не отбрасываете пакеты.
Некоторые маршрутизаторы намеренно отбрасывают трафик ICMP, на который они отвечают, поэтому вы можете получить «дополнительную потерю», ограниченную только этим переходом. Если этот переход - ОБА выполняет некоторую форму формирования трафика И действительно теряет трафик, все становится ужасно запутанным, потому что вы не можете сказать, сколько у вас действительно потерь.
Короче говоря, маршрутизаторы ставят более высокий приоритет на обработку трафика, чем на ответы на пакеты с 0 ttl. Такие инструменты, как mtr и traceroute, полезны для определения пути, который вы используете. Они бесполезны для определения производительности этого пути. Я подробно рассказал об этом в своем ответе на . Какая задержка в сети «типична» для восточно-западного побережья США?