Уточнение, пожалуйста, на медленном диске трюк

У меня возникают проблемы, когда мои разные диски замедляются от скоростей передачи от около 25 МБ / с до 0,3 МБ / с. Иногда перезагрузка помогает, но не обязательно долго. Я имел это с Ubuntu Mate, заменил его на Xubuntu, но не повезло.

Поэтому, в поисках, еще раз, в произвольном порядке, я нашел поток Massive, непредсказуемое падение производительности ввода-вывода в Linux

Автор сказал, что

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' 

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

Но, честно говоря, я совершенно не понимаю, что я здесь делаю. Что такое /proc/sys/vm/drop_caches ? После эха этот файл остается пустым. Почему это работает, и есть ли какие-либо проблемы с этим? Означает ли это аппаратную проблему?

Добавление 1: Я реализовал это, вызвав скрипт, выполняющий синхронизацию, и эхо в корневом crontab, который запускает задания резервного копирования. Основное задание резервного копирования начинается в 3:30 утра, и я вызываю скрипт непосредственно перед ним, а также в 4:00 и 5:00. Кажется, что резервная копия только ускорилась после 4-часового скрипта, поэтому реализовать это не так просто. Но теперь я могу разумно запустить ночные резервные копии системы снова.

Добавление 2: Возможно, я должен также указать, что в какой-то момент я видел скорость передачи данных 0,3 МБ / с, а IIRC, копируя 30 ГБ или около того файловой структуры из Интернета на внутренний жесткий диск системы. Поэтому для меня не очевидно, что проблема заключается в медленных жестких дисках USB (которые, кстати, не очень медленны, на мой взгляд, со скоростью 30 Мбит / с или более, когда система работает правильно, например, после записи в / proc / sys / VM / dropped_caches.)

Добавление 3: изменение vm.dirty_background_ratio, vm.dirty_ratio, vm.dirty_expire_centisecs и vm.dirty_writeback_centisecs на то, что они на моем ноутбуке OK, не повлияло.

Добавление 4: По-видимому, это известная ошибка, https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-trusty/+bug/1333294 . Полезная ссылка отсюда: http://flaterco.com /kb/PAE_slowdown.html . Установка GRUB_CMDLINE_LINUX = "mem = 8192M" в / etc / default / grub, запуск update-grub и перезагрузка, похоже, вернули запись на диск с разумной скоростью без использования drop_caches. (При потере 8 ГБ памяти.)

  • Почему некоторые кеши не отбрасываются?
  • Как очистить кэш кэша Bash от исполняемых файлов?
  • OpenLDAP как только кеш-прокси, ни одна локальная база данных
  • Не является ли страницей режима кэширования серьезной ошибкой?
  • Искусственно первичный буферный кеш?
  • Увеличение ограничения размера для / var / cache / apt / archives
  • Уменьшите размер кеша флеш-накопителей
  • Есть ли у bash встроенная команда кэширования (вроде как mktemp или sponge)?
  • 3 Solutions collect form web for “Уточнение, пожалуйста, на медленном диске трюк”

    Похоже, вы переживаете то, что описано здесь :

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

    Это также обсуждается в этой статье LWN . В основном ваш медленный USB-накопитель может обрабатывать записи с постоянной малой скоростью записи, но при выполнении задания резервного копирования он заполняет vm-кеш и теперь вы получаете медленную синхронную запись на некоторое время. «echo 3> / proc / sys / vm / drop_caches» удаляет из этих кэшей чистые объекты, позволяя I / O использовать кеш, тем самым повышая производительность.

    Как было предложено в эксперименте ссылок с изменением значений для «vm.dirty_ *». Например, vm.dirty_background_ratio и vm.dirty_ratio.

    https://www.kernel.org/doc/Documentation/sysctl/vm.txt

    Написание этого приведет к тому, что ядро ​​будет удалять чистые кеши, а также восстанавливаемые объекты слябов, такие как зубцы и иноды. Когда они упали, их память становится бесплатной.

    Чтобы освободить объекты slab и pagecache: echo 3 > /proc/sys/vm/drop_caches

    «Чистый кеш» – это кеш, который является таким же, как один на диске, поэтому вы можете просто отказаться от него и перечитать его с диска позже.

    Кэш страницы – это кеш страниц памяти, считанных с диска: https://en.wikipedia.org/wiki/Page_cache

    Slab – непрерывный фрагмент памяти: https://en.wikipedia.org/wiki/Slab_allocation

    Усовершенствования ввода-вывода после того, как ядро ​​Linux сообщило о необходимости сбросить / освободить память, выделенное для кэшей, вероятно, является контрольным сигналом, который вы пытаетесь использовать больше ОЗУ, чем тот, который у вас есть.

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

    Я бы расследовал:

    • настройка системы может быть оптимизирована;
    • или если вам нужно больше физической ОЗУ.

    См. Настройка / proc / sys / vm / drop_caches, чтобы очистить кеш, чтобы увидеть более подробное объяснение того, что вы можете сделать при отбрасывании кешей.

    Linux и Unix - лучшая ОС в мире.