Как сделать отступ в выводе grep? [duplicate]
Вполне возможно, что данные не были сброшены на диск во время первой операции cp, но были во время второй.
Попробуйте установить для vm.dirty_background_bytes что-то маленькое, например 1048576 (1 МБ), чтобы проверить, так ли это; запустите sysctl -w vm.dirty_background_bytes=1048576, и тогда ваш первый cp сценарий должен показать ввод-вывод.
Что здесь происходит?
За исключением случаев синхронного и/или прямого ввода-вывода, записи на диск буферизируются в памяти до тех пор, пока не будет достигнуто пороговое значение, после чего они начинают сбрасываться на диск в фоновом режиме. У этого порога нет официального названия, но он контролируется vm.dirty_background_bytes и vm.dirty_background_ratio, поэтому я буду называть его «Порог грязного фона». Из документации ядра:
vm.dirty_background_bytesСодержит объем грязной памяти, при котором потоки фоновой очистки ядра начнут обратную запись.
Примечание:
dirty_background_bytesявляется аналогомdirty_background_ratio. Одновременно может быть указан только один из них. Когда один sysctl записывается, он немедленно учитывается для оценки пределов грязной памяти, а другой отображается как 0 при чтении.
dirty_background_ratioСодержит в процентах от общей доступной памяти, которая содержит свободные и восстанавливаемые страницы, количество страниц, при которых потоки фоновой очистки ядра начнут записывать грязные данные.
Общий объем доступной памяти не равен общему объему системной памяти.
vm.dirty_bytes и vm.dirty_ratio
Существует второй порог, помимо этого.Ну, это скорее предел, чем порог, и он контролируется vm.dirty_bytes и vm.dirty_ratio. Опять же, у него нет официального названия, поэтому мы назовем его «Грязный лимит». Как только достаточно данных будет «записано»,но не привязаны к базовому блочному устройству, дальнейшие попытки записи должны будут дождаться завершения записи ввода-вывода. (Точные детали того, какие данные им придется ждать, мне неясны, и это может быть функцией планировщика ввода-вывода. Я не знаю.)
Почему?
Диски работают медленно. В частности, вращающаяся ржавчина, поэтому, пока головка чтения/записи на диске перемещается для удовлетворения запроса на чтение, никакие запросы на запись не могут обслуживаться до тех пор, пока запрос на чтение не завершится и не будет запущен запрос на запись. (И наоборот)
Эффективность
Вот почему мы буферизуем запросы на запись в память и кэшируем прочитанные данные; мы переносим работу с медленного диска на более быструю память. Когда мы в конце концов перейдем к фиксации данных на диске, у нас будет достаточно данных для работы, и мы можем попытаться записать их таким образом, чтобы минимизировать время поиска. (Если вы используете SSD, замените концепцию времени поиска диска на перепрошивку блоков SSD; перепрошивка потребляет срок службы SSD и является медленной операцией, которую SSD пытаются — с разной степенью успеха — скрыть своей собственной записью. кэширование.)
Мы можем настроить объем буферизуемых данных перед тем, как ядро попытается записать их на диск, используя vm.dirty_background_bytes и vm.dirty_background_ratio.
В буфере слишком много данных для записи!
Если объем данных, которые вы записываете, слишком велик для того, как быстро они достигают диска, вы в конечном итоге используете всю системную память.Во-первых, ваш кеш чтения исчезнет, а это означает, что меньшее количество запросов на чтение будет обслуживаться из памяти и должно обслуживаться с диска, что еще больше замедлит вашу запись! Если ваше давление записи все еще не ослабевает, в конечном итоге, например, выделения памяти должны будут ждать, пока ваш кеш записи освободится, и это будет еще более разрушительным.
Итак, у нас есть vm.dirty_bytes (и vm.dirty_ratio); это позволяет нам сказать: «Эй, подождите минутку, нам действительно пора записать данные на диск, пока не стало еще хуже».
По-прежнему слишком много данных.
Жесткая остановка ввода-вывода, однако, очень разрушительна; диск уже медленный с точки зрения процессов чтения, и для сброса этих данных может потребоваться от нескольких секунд до нескольких минут; рассмотрите значение vm.dirty_bytes по умолчанию, равное 20. Если у вас есть система с 16 ГБ ОЗУ и без свопа, вы можете обнаружить, что ваш ввод-вывод заблокирован, пока вы ждете, пока 3,4 ГБ данных будут сброшены на диск. . На сервере с 128 ГБ ОЗУ? У вас будет тайм-аут служб, пока вы ждете 27,5 ГБ данных!
Таким образом, полезно держать vm.dirty_bytes (или vm.dirty_ratio, если хотите) достаточно низким, чтобы, если вы нажмете это жесткое пороговое значение , это будет минимально мешать работе ваших служб.
Что такое хорошие ценности?
С помощью этих настраиваемых параметров вы всегда балансируете между пропускной способностью и задержкой. Буферизируйте слишком много, и у вас будет отличная пропускная способность, но ужасная задержка. Буфер слишком мал, и у вас будет ужасная пропускная способность, но большая задержка.
На рабочих станциях и ноутбуках только с одним диском я предпочитаю устанавливать для vm.dirty_background_bytes значение около 1 МБ, а для vm.dirty_bytes — от 8 до 16 МБ. Я очень редко нахожу выигрыш в пропускной способности выше 16 МБ для однопользовательских систем, но зависания с задержкой могут стать довольно серьезными для любых синхронных рабочих нагрузок, таких как хранилища данных веб-браузера.
Для чего-либо с чередующимся массивом четности я считаю, что некоторое значение, кратное ширине полосы массива, является хорошим начальным значением для vm.dirty_background_bytes; это снижает вероятность необходимости выполнения последовательности чтения/обновления/записи при обновлении четности, повышая пропускную способность массива.
Для vm.dirty_bytes это зависит от возможной задержки ваших служб. Лично мне нравится вычислять теоретическую пропускную способность блочного устройства, использовать ее, чтобы вычислить, сколько данных оно может передать за 100 мс или около того, и соответствующим образом установить vm.dirty_bytes. Задержка в 100 мс огромная, но не катастрофическая (в моей среде).
Однако все зависит от вашей среды; это только отправная точка для поиска того, что хорошо работает для вас.