Система отстает при выполнении крупных операций R / W на внешних дисках

Сначала вы должны проверить пути к двоичным файлам:

    #which bin   
    #which fritzing

Также вторая строка должна быть такой, предположим, что путь правильный.

   /home/salman/fritzing/Fritzing

не должно быть точки. в начале

5
09.10.2018, 14:57
1 ответ

How can I remedy it?

Когда вы записываете образ диска, используйте ddс oflag=direct. Запись O _DIRECT позволяет избежать записи данных через кеш страницы.Примечание oflag=directпотребует большего размера блока, чтобы получить хорошую производительность. Вот пример:

dd if=/dev/usbdisk1 of=/dev/usbdisk2 oflag=direct bs=32M status=progress

ПРИМЕЧАНИЕ. :Иногда вам может понадобиться передать образ диска из другой программы, например gunzip. В этом случае хорошая производительность также зависит от iflag=fullblockи передачи через другую команду dd. В ответе есть полный пример :. Почему конвейер gunzip в dd замедляется в конце?

(Альтернативным решением является использование oflag=syncвместо oflag=direct. Это работает за счет того, что не создается много незаписанных страниц кэша ).

My understanding is that each disk has its own IO queue, so what's going on here?

Да. Однако записанные данные сначала сохраняются в кэше системных страниц (в ОЗУ ), а затем помещаются в очередь операций ввода-вывода...


РЕДАКТИРОВАТЬ:

Поскольку этот ответ был принят, я предполагаю, что вы -тестировали с помощью oflag=direct, и это решает вашу проблему, когда «система просто начинает ползать». Здорово.

Самым безопасным вариантом было бы добавить еще и iflag=direct. Без этой опции ddпо-прежнему считывает данные из системного кэша страниц. Я предполагаю, что вы не добавили эту опцию, не сказав мне. Это один намек на вашу конкретную проблему.

Должно быть ясно, что чтение слишком большого объема данных через кэш страниц может повлиять на производительность системы. Общий объем данных, которые вы проталкиваете через кеш страниц, в несколько раз превышает объем оперативной памяти вашей системы :-). В зависимости от схемы чтения ядро ​​может принять решение о том, чтобы начать удаление (или замену )других кэшированных данных, чтобы освободить место.

Ядро не обладает непогрешимым предвидением. Если вам нужно использовать данные, которые были удалены из кеша, их придется повторно -загрузить с вашего диска/SSD. Улики , похоже, говорят нам, что это не ваша проблема.

Ограничения кэша грязных страниц

Однако,скорее всего, ваша проблема связана с записью данных через кэш страниц. Незаписанный кеш, также известный как «грязный» кеш страниц, ограничен. Например, вы можете представить, что общий кеш грязных страниц ограничен 20% оперативной памяти. (Это удобная ложь для воображения. Правда коряво написано тут ).

Если вашей ddкоманде (с )удастся заполнить максимальный кэш грязных страниц, они будут вынуждены «заблокировать» (ожидание ), пока часть данных не будет записана.

Но в то же время любая другая программа, которая хочет писать, также будет заблокирована (, если только она не использует O _DIRECT ). Это может привести к остановке многих ваших настольных программ, например. когда они пытаются писать лог-файлы. Даже если они пишут на другое устройство.

Общий предел загрязнения называется dirty_ratioили dirty_bytes. Но полная история намного сложнее. Предполагается, что между грязным кешем для разных устройств должен быть некоторый уровень арбитража. Существуют более ранние пороговые значения, которые срабатывают и пытаются ограничить долю максимального грязного кеша, используемого каким-либо одним устройством. Хотя сложно понять, насколько хорошо все это работает.

Кажется, вы упомянули, что у вас возникла проблема при создании образа «более одного USB-диска». Например, возможно, пороговые значения для -устройств хорошо работают, когда вы пытаетесь записать один из ваших дисков, но ломаются, когда вы записываете более одного одновременно. Но это только мысль; Я не знаю точно, что происходит.

Связанные:

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

Почему в 2013 году сообщалось о проблемах с зависанием USB-накопителя -? Почему эта проблема не была решена существующим кодом «Нет -грязного регулирования ввода-вывода»?

Является ли «регулирование обратной записи» решением «проблемы с зависанием USB-накопителя -»?

6
27.01.2020, 20:38

Теги

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