vm.swappiness не относится к tmpfs, Сервер Ubuntu 16.04.5

Потребность в некотором эксперте советует, принес мне здесь.

Наблюдение: ОС запирается во время высокого Использования оперативной памяти, очень низко подкачайте использование (много доступное), высокое tmpfs использование.

Моя установка:

1. Сервер Ubuntu 16.04.5 с 4.4.0-131-универсальным ядром.
2. 64 ГБ RAM, 200 ГБ подкачивают раздел на NVMe на 1 ТБ SSD.

3. 64 ГБ tmpfs раздел со следующей fstab записью

   tmpfs  /my-tmp  tmpfs  rw,size=64G,noexec,nosuid,nodev,noatime 0 0
   

4. следующие записи в/etc/sysctl.conf

   vm.overcommit_memory=2
   vm.overcommit_ratio=100
   vm.swappiness=40
   

^ Я попробовал swappiness значения 1, 20, 40 и значение по умолчанию 60 без большого успеха.

Установка похожа на это для поддержки нескольких высокопроизводительных сервисов, для которых нужен высокоскоростной временный доступ к файловой системе, а также большой объем RAM.

Все хорошо работает, и до Использование оперативной памяти и до tmpfs использование близко к тому, чтобы истратить, и ОС просто запирается (никакой ssh ответ, никакая способность к Ctrl+Alt+F2/3/4, Num Lock не переключается и т.д.) в течение длительного промежутка времени (как 20 минут), и один из моих катастрофических отказов процессов, если это происходит.

Я зарегистрировал свободную память и tmpfs использование в файл и заметил, что, когда это происходит, использование подкачки является очень низким, вероятно, потому что tmpfs использование не считается против Использования оперативной памяти, так как "используемая" Мадам показывает такое маленькое значение.

Изображение использования памяти выглядит примерно так, когда система запирается

              total        used        free      shared  buff/cache   available
Mem:            62G        1.2G        324M         60G         61G         75M
Swap:          186G        4.0G        182G

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           6.3G  9.1M  6.3G   1% /run
tmpfs            32G   20M   32G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            32G     0   32G   0% /sys/fs/cgroup
tmpfs           8.0G  8.0K  8.0G   1% /tmp
tmpfs            64G   61G  3.4G  95% /my-tmp
tmpfs           6.3G  4.0K  6.3G   1% /run/user/1001

Позвольте мне вытеснить некоторые комментарии о создании моих сервисов, более эффективных... они уже. Это - просто очень очень требовательное приложение. И я фигурировал с таким большим разделом подкачки, он будет в порядке.

Поиск и устранение неисправностей выполняется до сих пор:

1. Прочитайте tmpfs документацию ядра здесь (много раз)

http://man7.org/linux/man-pages/man5/tmpfs.5.html

Это говорит, что tmpfs может использовать область подкачки во время давления верхней памяти, но я видел мало ни к какому использованию подкачки, когда система запирается, вместо того, чтобы начать подкачивать.

2. Считайте многочисленные страницы справки, включая этого

https://unix.stackexchange.com/questions/271211/do-tmpfs-and-devtmpfs-share-the-same-memory-region/271235#271235

Гипотеза:

Если у меня могло бы быть tmpfs количество использования как использование памяти, то, возможно, vm.swappiness параметр сыграет роль перед такой ситуацией тупика.

Или, если бы я мог бы независимо установить swappiness tmpfs, затем это добилось бы цели также.

Другие предложения приветствуются также.

Спасибо за то, что заняли время для чтения этого.

Редактирование 11.10.2018 9:00 PDT:

Поблагодарите Вас все за свои полезные ответы. Я попробовал несколько комбинаций размера раздела подкачки и tmpfs размера раздела в прошлом. Каждый раз я наблюдал то же. tmpfs израсходовал всю RAM, которая не считается как Использование оперативной памяти (и следовательно vm.swappiness не относился к нему), и вызвал ОС к тупику. Если я делаю свой tmpfs раздел меньшим, чем поршень скажем 50 ГБ, то тупиков не происходит.

Это противоречит документации ядра для ramfs и tmpfs (который является, почему я никогда не использовал ramfs),

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

Нижняя строка, если общая виртуальная память в моей системе (RAM + ПОДКАЧКА) больше, чем общий размер всех tmpfs разделов в моей системе, не должно быть никаких тупиков ОС. Это - ожидание, если я не пропускаю что-то. Я понимаю, что вещи могут замедлиться из-за свопинга, но не должен тупик.

Редактирование 25.10.2018 9:15 PDT:

Удар. Исходный вопрос не разрешен.

Сокращение размера tmpfs раздела не является "решением", которое я искал. Я ожидал, что способ максимизировать размер tmpfs раздела к пределам доступной виртуальной памяти в моей системе (RAM + подкачка - другой размер tmpfs разделов) и системе управляет свопингом данных по tmpfs разделу без запирания согласно документации ядра.