[DJ Mogarych]

А что произойдёт, если память кончится, а свопа нету?
"Нынешние объёмы РАМ", к сожалению, есть не у всех.

Вот люди тоже задаются тем же вопросом, что и я:
https://askubuntu.com/questions/1059...tition-or-file
https://askubuntu.com/questions/9043...n-vs-swap-file
Оказывается, в Убунте, начиная с версии 17.04, используется своп-файл вместо раздела. Это объясняется тем, что фрагментация как негативное влияние на файл сейчас становится неактуальной, а ещё - что своп плохо влияет на продолжительность жизни SSD.

[Jula0071]

А что произойдёт, если память кончится, а свопа нету? »

Придёт OOM-killer и пристрелит процесс, который сочтёт "плохим". "Плохость" вычисляется по специальному алгоритму. "Плохим" может оказаться и что-то важное, чем не хотелось бы жертвовать, например СУБД. Статья.

а ещё - что своп плохо влияет на продолжительность жизни SSD. »

Как будто своп на фс влияет хорошо.
Вообще там говорят, что главный резон это лёгкость расширения свопа, в случае если просчитался с его размером. Ну... пожалуй, хотя с LVM это тоже не сложно, хотя конечно нужно больше телодвижений. Хотя моё мнение по поводу наращивания свапа я уже высказывал, нужно не растить свап, а решать проблему иначе. Также никто не запрещает не расширять имеющийся, а добавлять новый свап.

[DJ Mogarych]

Всем спасибо, пожалуй, я остановлюсь на файле, а не на разделе, тем более что, убунта и вправду создаёт /swapfile в ходе установки.
В принципе, действительно, если уже своп используется всерьёз на серверной системе, то тут надо срочно что-то решать, ибо долго так всё равно продолжаться не может.

[Jula0071]

Если уже есть как есть - с файлом, то заморачиваться переделкой точно не стоит. А вот если ставить что-то новое с нуля, то можно и сделать покрасивее. Но опять же, если эта красота никому не нужна, то и заморачиваться нечего.

[DJ Mogarych]

Ну а как покрасивее? Раздел на LVM?

[Jula0071]

DJ Mogarych, красота понятие отвлечённое. Нужно соотносить затраченные усилия, риски и результат. LVM полезен, доводы приводил (кстати забыл ещё один - возможность делать снапшоты томов, например для консистентного бекапа) но его надо знать и уметь готовить (как и практически всё в линуксе - свобода настроек огромная, но никто не гарантирует, что не будет выстрела в ногу). Если не знаете, то в проде лучше ничего не трогать. Не надо чинить то, что не сломано. Изучайте LVM, тренируйтесь на тестовых вмках, если зайдёт, будете сами в какой-то момент удивляться "как я жил без LVM". Но в проде, чувствую, вам рановато (просто не возник бы обсуждаемый вопрос). А не зайдёт, так и бог с ним.

"Нынешние объёмы РАМ", к сожалению, есть не у всех. »

У меня на самых толстых хостах по терабайту RAM, но и там иногда OOM приходит. Там контейнеры вестимо, приходит не из-за того, что физическая память кончилась, а по ограничению контейнера. Случится пик и опа. Раздавать всем память не глядя всё ж расточительно, так что для страховки свап. Если он растёт перманентно, тогда и докинуть памяти.
Ещё есть виртуалки в разных облаках, а там обычно добавить память не так просто, нужно переходить на другой план, который вдвое дороже (например 8ГБ в ДО стоит 20 баксов/мес, а следующий - 16 и уже 40). Из-за редких пиков опять же расточительно, потому свап.

Так что не надо свап со счетов списывать, он полезный. Кушать не особо много просит, 1-8ГБ стореджа для страховки как правило приемлемо. А если хочется чтоб меньше свапилось, можно прикрутить гайку vm.swappinness с умолчальных 60 до 10-20.

[DJ Mogarych]

Я давно уже ставлю LVM в прод, просто авторазметкой. Тут, наконец, захотелось разобраться самому.

[Jula0071]

Насколько я помню авторазметку той же убунты, там не оставляли резервное свободное место на PV.

[DJ Mogarych]

Это да, поэтому я и заинтересовался темой, чтобы размечать диски лучше и правильней.

[Jula0071]

В принципе логические тома можно и укорачивать. Но то, в отличие от расширения, опасная процедура, если на лету. Надо umount, что не всегда возможно, например с рутом.