Linux использует весь своп, становится невосприимчивым, в то время как есть много свободной оперативной памяти
Это не совсем красиво, но все это можно спрятать в сценарии:
SSH может отправлять произвольные переменные среды через туннель; и клиент, и сервер должны быть настроены для этого. Клиент легко сделать с опцией -o ; сервер, который необходимо указать в файле sshd_config . Принимать произвольные - плохая идея, но должно сработать что-то вроде этого:
BACKUP_PROVIDER_VAR1=val1 rsync -e 'ssh -o SendEnv=BACKUP_PROVIDER_*' …
Затем вам нужно будет поместить AcceptEnv LANG LC_ * BACKUP_PROVIDER _ * в свой sshd_config (который, насколько я знаю, может быть ограничен только определенным пользователем / группой с блоком Match ). На самом деле, вам, вероятно, не нужны LANG или LC _ * из ваших клиентов резервного копирования, поэтому вам просто нужны ваши собственные пользовательские переменные окружения.
shared Память, используемая (в основном) tmpfs (Shmem в /proc/meminfo, доступно на ядрах 2.6.32, отображается как ноль, если не доступно)>
Таким образом, определение Shared в manpage не так полезно, как могло бы быть :(. Если использование tmpfs не отражает это высокое значение Shared, то значение должно представлять некоторый процесс(ы), "который сделал mmap() с MAP_SHARED|MAP_ANONYMOUS" (или общей памятью System V).
6 Гб общей памяти на 8 Гб системе - это все еще много. Серьезно, вам это не нужно, по крайней мере, на настольном компьютере.
Странно, что это, кажется, также способствует "buff/cache". Но я провел быстрый тест с помощью python, и это именно то, как это работает.
Чтобы показать процессы с наибольшим количеством общей памяти, используйте top -o SHR -n 1.
Общая память системы V
Наконец, возможно, у вас есть ужасное устаревшее программное обеспечение, которое использует сегменты общей памяти системы V. Если они утекают, они не отображаются в top :(.
Вы можете перечислить их с помощью ipcs -m -t. Надеюсь, что самый недавно созданный все еще используется. Возьмите номер shmid и, например,
$ ipcs -m -t
------ Shared Memory Attach/Detach/Change Times --------
shmid owner attached detached changed
3538944 alan Apr 30 20:35:15 Apr 30 20:35:15 Apr 30 16:07:41
3145729 alan Apr 30 20:35:15 Apr 30 20:35:15 Apr 30 15:04:09
4587522 alan Apr 30 20:37:38 Not set Apr 30 20:37:38
# sudo grep 4587522 /proc/*/maps
-> тогда номера, показанные в путях /proc, будут pid процессов, которые используют SHM. (Таким образом, вы можете, например, погреть вывод ps для этого номера pid).
Очевидные противоречия
В Xorg отображено 8G. Даже если у вас нет отдельной оперативной памяти видеокарты. У него только 150M резидентной. Это не значит, что остальное вытеснено, потому что у вас недостаточно места для подкачки.
Сегменты SHM, показанные
ipcs, все прикреплены к двум процессам. Поэтому ни один из них не просочился, и все они должны отображаться в колонке SHR вtop(даже с двойным подсчетом). Ничего страшного, если количество использованных страниц меньше размера сегмента памяти, это просто означает, что есть страницы, которые не были использованы. Ноfreeговорит, что нам нужно учесть 6 ГБ выделенной общей памяти, а мы не можем этого найти.
общаяПамять, используемая (в основном) tmpfs (Shmem в /proc/meminfo, доступно на ядрах 2.6.32, отображается как ноль, если не доступно)
tmpfs является свопируемой. У вас есть файловая(ые) система(ы) tmpfs, которая(ые) заполняется(ются) сверх безопасных пределов. Для сравнения, система, на которой я это печатаю, имеет 200M общего пространства. 6 Гб - это слишком много для 8-гигабайтной системы, на которой работает настольный компьютер с такими вещами, как dropbox и Steam одновременно.
Вы можете использовать обычные инструменты, чтобы найти, какие файлы вызывают проблему. Хотя теоретически возможно, что файлы исчезают при завершении X-сессии.
$ df -h -t tmpfs
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.9G 1.7M 1.9G 1% /dev/shm
tmpfs 1.9G 1.6M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 1.9G 80K 1.9G 1% /tmp
tmpfs 376M 20K 376M 1% /run/user/42
tmpfs 376M 20K 376M 1% /run/user/1000
Ограничьте монтирование tmpfs, чтобы пережить проблемы, получить возможность их проанализировать и, возможно, даже вызвать полезное сообщение об ошибке от программы, которая их заполняет.
По умолчанию каждый tmpfs ограничен 1/2 доступной оперативной памяти.
Поэтому желательно не размножать множество монтируемых tmpfs с ограничениями по умолчанию. Дистрибутивы не так хороши в этом, как должны быть, как вы можете видеть выше, для моей системы с 4 ГБ.
По-видимому, можно изменить ограничения во время выполнения с помощью mount -oremount,size=10% /tmp.
Вы можете поместить ваши команды remount куда-нибудь, где они будут выполняться во время загрузки, например, /etc/rc.local (может потребоваться systemctl enable rc-local). Обратите внимание на /run/user/*, которые, скорее всего, будут смонтированы после выполнения вашего скрипта; надеюсь, они уже имеют разумные пределы.
Монтируемые по умолчанию tmpfs, как правило, не указаны в /etc/fstab. Под systemd вы можете изменить монтирование /tmp, например, с помощью systemctl edit tmp.mount. В противном случае вы можете просмотреть системные скрипты, чтобы найти, где они монтируют /tmp; возможно, для этого используется конфигурационный файл, который вы можете отредактировать. Другим вариантом для /tmp может быть полное отключение монтирования tmpfs (systemctl disable tmp.mount), позволяя программам писать в корневую файловую систему.