Система высвапливает процессы, чтобы отдать память под буферы i/o

Выстави vm.dirty_background_bytes и vm.dirty_bytes в какое-нибудь разумное количество мегабайт (напр 16)

ищу нормальное решение.

Установить FreeBSD и не мучиться больше.

Покажи что именно и как ты делаешь и с чего именно ты взял, что

Разница «пишется» в буферы ввода-вывода.

и

Через некоторое время ради этого система начинает вытеснять в свап рабочие процессы

Создайте файл /etc/sysctl.d/60-drity.conf с текстом:

vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432

Создайте файл /etc/sysctl.d/60-drity.conf с текстом:

А, почему в /etc/sysctl.conf не добавить?

Можно и туда, не принципиально. /etc/sysctl.conf обычно дистрибутивом используется, и рекомендуется в дополнительные файлы вносить изменения, а не в этот основной, т.к. некоторые пакетные менеджеры его может заменить при определенных условиях.

простая семантика. если у тебя файл называется n+1-dirty_bytes.conf - вроде как понятно, что там за настройки.
в отличии от длинного конфига на 150 строк с кучей комментариев-разделителей внутри, выполняющих те же цели.

Свап ненужен.

Покажи что именно и как ты делаешь и с чего именно ты взял, что

Разница «пишется» в буферы ввода-вывода.

Тут я, возможно, погорячился. Может это и не всё кеш записи, потому что при чтении (rsync с опцией --no-whole-file, когда изменений в большом файле немного) поведение примерно то же самое. Но разница всё же есть, при чтении все буферы хотя бы «чистые», их не нужно сбрасывать на диск, это облегчает последствия, но проблема всё равно наблюдается.

Что делаю? Вот это: cp -av /mnt/usb-hard-disk/ /mnt/luks-encrypted-internal-disk/

и

Через некоторое время ради этого система начинает вытеснять в свап рабочие процессы

Тут просто: top показывает, что растёт количество буферов, и используемого swap-пространства. Ну и «отзывчивость» всего хозяйства явно намекает. swapoff проблему лечит.

Отвечу также остальным: ваши советы опробовал, не помогает. Конкретно vm.dirty_bytes и vm.dirty_background_bytes - оно ведь не лимитирует количество буферов, а задаёт порог, после которого система начинает шевелится с их записью. Но они и так постоянно пишутся, так что тут никакого эффекта. А при буферизации чтения эти параметры вообще роли не играют. Также пробовал уменьшить swapiness и vfs_cache_pressure. Чуть-чуть помогает, но только чуть-чуть. Замещение памяти процессов буферами ввода-вывода протекает медленнее, но так же неотвратимо. Ещё какой-то redhat-специфический параметр нагуглил, именно для буферов чтения, но, видимо, его выпилили, потому что его просто нет (названия не помню). Пока всё.

У тебя сколько в системе оперативной памяти? И сколько памяти обычно занято под «полезные» данные процессов?

swapoff проблему лечит.

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

Отвечу также остальным: ваши советы опробовал, не помогает.

А ты не пробовал убирать вообще все кастомизации параметров ядра и работать с дефолтными настройками?

И систему ещё неплохо бы обновить.

И кстати,

Свап на отдельном диске

Насколько этот диск быстрее при рандомном доступе, чем диск, на котором стоит система?

Теперь я понял, в чем у вас проблема, и что вы хотите. Вам нужно каким-то образом копировать файлы с O_DIRECT или fadvice POSIX_FADV_DONTNEED. Я не знаю, как это сделать стандартными средствами cp или rsync, но есть патченный rsync.

У тебя сколько в системе оперативной памяти? И сколько памяти обычно занято под «полезные» данные процессов?

24Г всего, занято 16

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

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

А ты не пробовал убирать вообще все кастомизации параметров ядра и работать с дефолтными настройками?

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

Вам нужно каким-то образом копировать файлы с O_DIRECT или fadvice POSIX_FADV_DONTNEED. Я не знаю, как это сделать стандартными средствами cp или rsync, но есть патченный rsync.

Ну, в общем, да. Про патченный rsync я в курсе, но не очень хочется (поддерживать сложнее), к тому же rsync не все задачи решает. Хотелось бы решение на системном уровне.