Вопросы Теги

Это плохо, чтобы иметь файловые системы, почти полные?

Инструменты

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

Если Вы не владеете сетевым элементом, или Ваш сторонний поставщик WAN раскрывает информацию, можно только оценить от начала до конца доступный вход и выходную пропускную способность вдоль сетевого пути. Посмотрите ниже.

Есть ли существуют любой инструмент/утилита/приложение, кто может служить цели.

  • Для пути "доступная оценка пропускной способности", которую я упомянул выше, необходимо рассмотреть архив Sally Floyd сквозных инструментов оценки пропускной способности TCP/IP. Я являюсь самым знакомым с yaz, который основан на одноадресной передаче пакеты UDP.
  • Чтобы видеть, отбрасываете ли Вы пакеты в каком-либо данном транзитном участке (который является Вашей реалистичной проблемой), можно использовать mtr; существует также a win-mtr клиент, который поддерживает Windows. Для наблюдения простого примера того, как я обычно диагностирую отбрасывание пакетов см. мой ответ на SuperUser. Эта техника является самой эффективной при обеспечении видимости к отбрасыванию пакетов в первой точке, где они происходят (так как mtr не дает много видимости нисходящим отбрасываниям, кроме того указывают, пока Вы не исправляете первое).

Простая техника для получения грубой оценки того, где отбрасывания, состоит в том, чтобы установить mtr на Вашем сервере и затем выполненный mtr сессия для трассировки потери пакетов до единственного клиента многоадресной передачи, в то время как Вы передаете Ваш 100M файл. Для более точных измерений Вы могли использовать iperf насыщать сеть вместо Вашего 100M файл (как долго, поскольку Вы координируете время простоя WAN соответственно с другими группами в компании).

Схема

Остальная часть моего ответа собирается использовать следующую схему для ссылки:

Mcast_problem

В схеме:

  • R1 через R5 являются маршрутизаторами IP
  • S1 и S5 являются Ethernet-коммутаторами
  • Синий сервер на 172.16.1.0/24 представляет Ваш сервер многоадресной передачи.
  • C51 через C55 являются примерами многоадресных приемников (могло быть любое количество получателей),

Специфические особенности WAN между R1 и R5 обычно не будут иметь значения очень, нам просто нужна базовая топология, таким образом, мы находимся на той же странице.

Из того, что я могу сказать, Вы говорите, что интерфейс R1 на 172.16.1.0/24 показывает приблизительно 9 Мбит/с, в то время как Вы отправляете файл 100 МБ, и интерфейс R5 на 172.16.5.0/24 показывает приблизительно 4.2 Мбит/с, когда клиенты получают через надежную многоадресную передачу UDP. Когда Вы говорите надежный, я предполагаю, что средство там является некоторым пакетным упорядочиванием, встроенным в услугу многоадресной передачи, и клиентское приложение знает, как запросить повторную передачу с сервера.

Диагноз

Если это описание корректно, существует несколько вероятных причин:

  1. Перегрузка канала где-нибудь после R1, как Вы утверждали в своем вопросе.
  2. Ограничения производительности любого устройства Rx в пути, включая R1 и R5 (такие как удар многоадресного предела производительности репликации)
  3. Вы поражаете ограничение пропускной способности 10M полудуплексный Ethernet.

Причины 1 или 2 были бы показаны при помощи mtr. Однако причина 3 достойна немного большего количества обсуждения. Ссылки 10M/half обеспечивают максимум 10 Мбит/с для однонаправленной передачи. При отправке двунаправленного трафика на ссылке 10M/half Вы будете обычно видеть существенно меньше чем 10 Мбит/с из-за динамики CSMA/CD Ethernet. На полудуплексной ссылке Ethernet не может одновременно передать и получить; если станции попытаются сделать это, то их кадры столкнутся, и обе станции задержат повторную передачу в течение случайного времени.

Я тестирую сети на проживание. Когда я протестировал эффективную двунаправленную пропускную способность ссылок 10M/half, я обычно вижу между 3 Мбит/с и 4 Мбит/с. Числа, которые Вы совместно используете выше, звучат очень похожими. У меня нет достаточного доказательства для создания обвинения, но я не был бы удивлен, являются ли ссылки 10M/half проблемой; особенно, если ссылка между R5 и S5 является 10M/half.

14
05.08.2013, 04:56
7 ответов

Если это - "статическое" устройство хранения данных базы данных нет никакого вреда в заполнении его - особенно, когда авторасширение DB выключено. Что-либо еще было бы тратой ценного пространства SAN. Контроль может или быть выключен для этих файловых систем, или уровень предупреждения должен быть повышен до 99 или даже 100%.

Это только верно для нероста данных, таким образом, журналы должны пойти в другое место. Хранение журналов должно тесно контролироваться все же. И это должно быть достаточно большим так, чтобы администратор мог реагировать на предупреждение от контроля вовремя.

0
27.01.2020, 19:50

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

Более важный потенциальный эффект на систему. Сервер предоставляет жизненную услугу? Какой длины это будет, прежде чем разработка и операционные команды узнают, что сервисы снижаются? Какой длины это будет, прежде чем пользователи становятся сердитыми, когда нет никакого доступного сервиса? Приложения будут часто замораживаться, когда не будет никакого устройства хранения данных для записи в. Могут быть цепные реакции, которые могут вызвать дальнейшие проблемы - добавляющий еще больше времени, прежде чем сервисы будут полностью восстановлены. И когда сервис был восстановлен, состояние системы может быть несбалансированным - например, огромное отставание входящих данных во время сервисных задержек причин времени простоя обработки.

9
27.01.2020, 19:50
  • 1
    +1 для, "Когда диск приближается к полной мощности, существует менее последовательные области диска, чтобы хранить данные в" - даже не думал об этом! –  Suman 30.07.2013, 19:21
  • 2
    Это не диск. Мы говорим о LUN, обеспеченных SAN. Обычно это - чередуемая часть через большое количество физических дисков. –  Nils 01.08.2013, 15:33

Файловая система не повреждается просто, потому что это полно, таким образом, нет никакой проблемы с точки зрения файловой системы. Файлы, более вероятно, фрагментируют, после того как файловая система почти полна, и проблемы производительности возможны в зависимости от файловой системы, но это обычно не очень важно.

Настоящая проблема состоит в том, что в полной файловой системе, любая запись перестанет работать. Таким образом, это зависит от того, что будет пытаться записать в такой файловой системе.

Много программ должны смочь записать / сохраняют данные для функционирования правильно. Таким образом, если Ваша файловая система будет полна, когда что-то попытается записать, Вы испытаете потерю данных или поломку на прикладном уровне. "Я пытался сохранить Ваши данные, но не мог" быть случаем, который много программ не обрабатывают особенно хорошо. Худший случай программа начнет перезаписывать старое, сохранил файл прежде замечающий, что не будет достаточного количества комнаты для нового, сохранили файл, таким образом, Вы потеряли обоих.

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

13
27.01.2020, 19:50

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

Внезапные "едоки пространства" могут включать неожиданно большой файл подкачки (возможно, вызванный утечками памяти, и т.д.), изображение сна, которое может поднять столько пространства жесткого диска, сколько у Вас есть RAM и файлы крупносерийного производства из программ. Просто необходимо всегда быть уверены, что Вы не собираетесь заканчиваться пространство.

Лучший вариант развития событий - когда больше не будет пространства для файла подкачки, и система будет обычно просто отказывать без долгосрочных вредных воздействий.

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

1
27.01.2020, 19:50

Существует три действительно хороших подкаста о файловых системах и если я вспоминаю правильно и как они работают как "автоматически дефрагментация", которая, возможно, помогает Вам понять свою проблему лучше. Я думаю, что те 3 эпизода полностью стоит слушать, если Вы интересуетесь файловыми системами. Но предупредите, это является чрезвычайно гиковским:

1 2 эпизода и треть являются номером 58, который я не могу отправить из-за слишком небольшой репутации \:

Подкаст называют придирчивым, и хостом является John Siracusa.

0
27.01.2020, 19:50

Так как диски были бы полны, привел бы к низкой эффективности Вашего ПК. Я выполняю свой ПК на Ubuntu 12.10 и имел мои полные диски. Мои приложения раньше открывались очень медленно и начальная загрузка, используемая, чтобы быть медленными. Таким образом, я принес внешний жесткий диск и поддержал 50-60%-е использование диска с того времени. Я предложу Вас то же.

0
27.01.2020, 19:50

Вам следует подумать о нескольких вещах:

  1. Потребляете ли Вы данные, которые занимают все это пространство? Может быть много данных, которые вам нужны, но не то, что вам нужно. И если вы решили, что ЗАПРЕЩАЕТСЯ, убедитесь, что вы используете все эти данные. Другими словами, есть ли информация о вашем бизнесе, рынке или клиентах, которую вы можете получить из этих данных? Можете ли вы понять
  2. Если вам нужны данные, то все они считаются самым дешевым способом их хранения. В домашних серверах, удаленном хранении, сжатых, самых последних X% данных. Если у вас нет бюджета на расширение или удаленное хранение, избавьтесь от самых старых 10% данных просто для повышения производительности.

В случае с внешним жестким диском, где нет операционной системы, вы можете безопасно использовать большую часть диска без заметного снижения производительности. Для жесткого диска с ОС существуют файлы кэша, размер которых зависит от ОС и типов выполняемых ею задач.

Для linux посмотрите на это: Как я могу сравнить мой жесткий диск?

Смотрите эти тексты для более подробной экспозиции: http://www.amazon.com/Memory-Mass-Storage-Giovanni-Campardo-ebook/dp/B00F76KCGY/ref=sr_1_4?s=digital-text&ie=UTF8&qid=1420389894&sr=1-4&keywords=hard+drive+performance

http://www.amazon.com/SImple-Choosing-Installing-Upgrading-Super-fast-ebook/dp/B00LNZTXFE/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1420389894&sr=1-2&keywords=hard+drive+performance

0
27.01.2020, 19:50

Теги

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