Как я могу ограничить кеш, используемый при копировании, чтобы еще сохранилась память для другого кеша?
Основная ситуация:
Я копирую некоторые диски NTFS в openSuSE. Каждый из них составляет 2 ТБ. Когда я это делаю, система работает медленно.
Мои предположения:
Я считаю, что это, скорее всего, связано с кэшированием. Linux решает отказаться от полезного кеша (например, kde4 bloat, виртуальных машин, двоичных файлов LibreOffice, двоичных файлов Thunderbird и т.д.) И вместо этого заполнить всю доступную память (всего 24 ГБ) материалами из копирующих дисков, которые будут прочитаны только один раз, затем пишется и никогда не используется снова. Таким образом, в любое время, когда я использую эти приложения (или kde4), диск должен быть снова прочитан, а чтение раздувания с диска снова заставляет замораживать/икать.
Из-за исчезновения кэша и того факта, что эти раздутые приложения нуждаются в большом количестве кеша, это делает систему ужасно медленной.
Так как это USB, контроллер диска и диска не является узким местом, поэтому использование ионитов не ускоряет работу.
Я считаю, что кеш, а не только материнская плата идет слишком медленно, потому что, если я прекращу все копирование, она по-прежнему работает прерывисто, пока она не перескакивает все. И если я перезапущу копирование, это займет минуту, прежде чем он снова портится. Но также я могу ограничить его примерно до 40 Мбайт/с, и он работает быстрее (не потому, что он имеет правильные вещи в кэше, а потому, что шины материнской платы имеют большую дополнительную пропускную способность для системных дисков). Я могу полностью согласиться с потерей производительности, из-за которой полностью потребляется моя способность IO материнской платы (которая используется на 100%, что означает 0% потерянной мощности, что делает меня счастливым), но я не могу согласиться с тем, что этот механизм кэширования работает так ужасно в этом конкретном использовании случай.
# free
total used free shared buffers cached
Mem: 24731556 24531876 199680 0 8834056 12998916
-/+ buffers/cache: 2698904 22032652
Swap: 4194300 24764 4169536
Я тоже пробовал то же самое на Ubuntu, что и приводит к зависанию всей системы.;)
И чтобы уточнить, я не спрашиваю, как оставить память свободной для "системы", но для "кеша". Я знаю, что кэш-память автоматически возвращается в систему по мере необходимости, но моя проблема в том, что она не зарезервирована для кэширования определенных вещей.
Вопрос:
Есть ли способ сообщить этим операциям копирования ограничить использование памяти, поэтому некоторые важные вещи остаются кешированными, и поэтому любые замедления являются результатом нормального использования диска и не перечитывают те же наиболее часто используемые файлы? Например, существует ли настройка максимальной памяти для каждого процесса/пользователя/файловой системы, которую можно использовать в качестве кеша/буферов?
Ответы
Ответ 1
Команда nocache - это общий ответ на эту проблему! Смотрите https://github.com/Feh/nocache или найдите его в Debian и Ubuntu 13.10 (дерзкий).
Спасибо, Питер, за то, что предупредил нас о опции -drop-cache в rsync. Но это было отклонено вверху (Ошибка 9560 - опция кэширования кэша), в пользу более общего решения для этого: новая команда "nocache", основанная на работе rsync с fadvise.
Вы просто добавляете "nocache" к любой команде, которую хотите. Он также имеет приятные утилиты для описания и изменения состояния кеша файлов. Например. вот эффекты с и без nocache:
$ ./cachestats ~/file.mp3
pages in cache: 154/1945 (7.9%) [filesize=7776.2K, pagesize=4K]
$ ./nocache cp ~/file.mp3 /tmp
$ ./cachestats ~/file.mp3
pages in cache: 154/1945 (7.9%) [filesize=7776.2K, pagesize=4K]\
$ cp ~/file.mp3 /tmp
$ ./cachestats ~/file.mp3
pages in cache: 1945/1945 (100.0%) [filesize=7776.2K, pagesize=4K]
Так надеемся, что это сработает для других программ резервного копирования (rsnapshot, duplicity, rdiff-backup, amanda, s3sync, s3ql, tar и т.д.) и других команд, которые вы не хотите уничтожать кеш.
Ответ 2
Kristof Provost был очень близок, но в моей ситуации я не хотел использовать dd или писать свое собственное программное обеспечение, поэтому решение заключалось в использовании опции "-drop-cache" в rsync.
Я использовал это много раз с момента создания этого вопроса, и, похоже, проблема полностью устранена. Единственным исключением я использовал rsync для копирования с компьютера FreeBSD, который не поддерживает "-drop-cache". Поэтому я написал оболочку, чтобы заменить команду /usr/local/bin/rsync, и удалите эту опцию, и теперь она также работает с копированием.
Он по-прежнему использует огромное количество памяти для буферов и, похоже, почти не имеет кэш-памяти, но работает в любом случае.
$ free
total used free shared buffers cached
Mem: 24731544 24531576 199968 0 15349680 850624
-/+ buffers/cache: 8331272 16400272
Swap: 4194300 602648 3591652
Ответ 3
Невозможно, если вы используете простой старый cp, но если вы захотите повторно реализовать или исправить его, настройка posix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE) как на входном, так и на выходном файле, вероятно, поможет.
posix_fadvise() сообщает ядру о вашем предполагаемом шаблоне доступа. В этом случае вы будете использовать данные только один раз, поэтому нет смысла его кэшировать.
Ядро Linux чтит эти флаги, поэтому больше не нужно кэшировать данные.
Ответ 4
попробуйте использовать dd вместо cp.
Или mount файловая система с флагом sync.
Я не совсем уверен, что эти методы обходят своп, но, возможно, стоит попробовать.
Просто мой 2c.
Ответ 5
Я копирую некоторые диски NTFS [...] система работает медленно. [...] Так как это USB [...]
Замедление является известной проблемой управления памятью.
Используйте более новое ядро Linux. У старых есть проблема с данными USB и "прозрачными огромными страницами". Смотрите эту статью LWN. Совсем недавно эта проблема была решена, см. "Управление памятью" в LinuxChanges.
Ответ 6
Ядро не может знать, что вы не будете использовать кэшированные данные при повторном копировании. Это ваше информационное преимущество.
Но вы могли бы установить swapiness в 0: sudo sysctl vm.swappiness = 0. Это приведет к тому, что linux отбросит кеш до того, как библиотеки и т.д. Будут записаны в swap.
Работает хорошо для меня тоже, особенно очень эффектно в сочетании с hugh ram (16-32 ГБ).
Ответ 7
Хорошо, теперь, когда я знаю, что вы используете rsync, и я мог бы копать немного больше:
Кажется, что rsync неэффективен при использовании с несколькими файлами в то же время, есть запись в их FAQ, это не проблема с linux/cache, проблема с rsync заключается в том, что слишком много ОЗУ.
Поиск в Google кто-то рекомендовал разделить синхронизацию в нескольких rsync invocations
Надеюсь, что это поможет.
