LINUX.ORG.RU
ФорумAdmin

Померимся размером свопа!

 ,


0

3

Настало время измерить размер самого главного органа линуксоида - свопа! Многие говорят, что размер не важен. А некоторые даже, что и без свопа можно прожить. Но одно верно: каждый раз, когда кто-то выставляет свой своп на всеобщее обозрение ЛОРа, его всегда обсуждают на повышенных эмоциях. Так давайте же раз и навсегда решим этот вопрос. Каким должен быть идеальный своп?

Перемещено hobbit из polls

★★★★★

Каким должен быть идеальный своп?

Это сильно зависит от объёма оперативной памяти и задач.

И что не менее важно, в Linux со свопом проблемы.

Настало время измерить размер самого главного органа линуксоида - свопа!

Я не линуксоид.


У меня везде FreeBSD, но на каждой машине объём свопа разный:

  • КПК: 1G RAM (распаяно), один PATA SSD на 32G, своп хоть и нужен, но во-первых диск слишком мал, а во-вторых совсем не быстр.
  • Ноут: 16G RAM, один SSD не самого большого объёма, своп отсутствует, да и не особо нужен. Единственный случай, когда у меня по OOM убило что-то — попытка получить очень длинный листинг файлов в свежем Nextcloud в браузере.
  • Десктоп: 16G RAM, куча дисков, 32G swap, редко когда в него вымещается больше четырёх гигабайт (опять же, если не пытаться получить очень длинный листинг файлов в свежем Nextcloud в браузере, лол).
  • Домашний сервер: 48G RAM, 64G swap, на самом сервере крутится только гипервизор, всё остальное раскидано по виртуалкам и контейнерам. Занятость свопа очень сильно варьируется (на данный момент своп пуст), но больше 20G я пока не замечал.
mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Это сильно зависит от объёма оперативной памяти

This. Раньше вообще говорили, что оптимальный размер свопа — это удвоенный объём ОЗУ. В любом случае голосование по абсолютному размеру свопа без привязки к объёму памяти некорректно.

Скорее всего, перенесу эту тему в форум.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Раньше вообще говорили, что оптимальный размер свопа — это удвоенный объём ОЗУ.

А сейчас рекомендуют не менее 2×RAM если RAM <= 4G, а дальше всё равно от задачи зависит.

В любом случае голосование по абсолютному размеру свопа без привязки к объёму памяти некорректно.

Именно это я и хотел изначально донести, но меня понесло. (%

mord0d ★★★★★
()

Своп ровно такой, чтобы работал гибернейт.

$ free -h
\              всего        занято        свободно      общая  буф./врем.   доступно
Память:        31Gi        13Gi       610Mi       252Mi        16Gi        16Gi
Подкачка:        30Gi       2,2Gi        28Gi
Psilocybe ★★★★
()
Последнее исправление: Psilocybe (всего исправлений: 1)
$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15915        1292        5916          23        8706       14259
Swap:           8191           0        8191

$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            8G   4K   58B    4K       4 [SWAP]

При том zram ограничен по потреблению памяти на 2GB через mem_limit, чтобы зря не засирать память несжимаемыми данными. Впрочем, в своп весьма редко что-то попадает, так что он просто для подстраховки на случай, если какая-нибудь софтина потечет (у меня было такое несколько раз с Firefox в прошлом).

Kron4ek ★★★★★
()

Может он и в самом деле не нужен?

 $ stat /swapfile
  File: /swapfile
  Size: 2147483648	Blocks: 4194312    IO Block: 4096   regular file
Device: 8,1	Inode: 17          Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-11 11:22:26.797404405 +0300
Modify: 2021-03-11 11:22:26.834069528 +0300
Change: 2021-03-11 11:22:26.834069528 +0300
 Birth: 2021-03-11 11:22:26.797404405 +0300

dmitry237 ★★★
()
Ответ на: комментарий от Suntechnic

Затем чтобы комп не завис при исчерпании памяти. Когда полезет в своп, то начнёт тормозить и я успею убить жрущий процесс. Без свопа комп просто неожиданно зависает. Инфп сотка. Проверено на практике.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Экшуали, без свопа ядрёный oom-killer сразу прибивает самый жирный процесс. А со свопом тебе нужен либо early-oom, либо systemd-oomd, чтобы вовремя среагировать и недопустить замораживание системы. Инфа 146%.

я успею убить жрущий процесс

🤦

rupert ★★★★★
() автор топика

В своп, думаю, гадит либо docker с minecraft server, либо qbittorrent-nox с libtorrent-rasterbar. А нужен ли мне такой своп не знаю…

$ free -m
               total        used        free      shared  buff/cache   available
Mem:            7885        2213         173           1        5499        5369
Swap:           3942         763        3178

$ zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       3,9G 763,5M 305,6M 322,2M       2 [SWAP]
NyXzOr ★★★
()
Последнее исправление: NyXzOr (всего исправлений: 3)
Ответ на: комментарий от rupert

Экшуали, без свопа ядрёный oom-killer сразу прибивает самый жирный процесс.

Нет. Нихера он не работает. Может через пол часа и отработает, но у меня нет желания тратить столько времени.

🤦

Я же специально написал, что проверено на практике.

ox55ff ★★★★★
()
Ответ на: комментарий от Aceler

По канонам опенсорца: потому, что лично ты не поправил.

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

token_polyak ★★★★
()
Ответ на: комментарий от ox55ff

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

rupert ★★★★★
() автор топика
Ответ на: комментарий от hateWin

Раньше было нужно для работы suspend on disk. Правда, в последние годы, на каком бы железе не пробовал использовать этот режим, он никогда не работает (либо виснет, либо не восстанавливается никогда из suspend, а грузится по новой), так что даже перестал пробовать.

emorozov
()
Ответ на: комментарий от ddidwyll

Странно, я наоборот последний раз видел чтобы он не работал году в 10м, постоянно пользуюсь.

В каких ситуациях он нужен? Собственно, потому и не стал разбираться детально, почему не работает, потому что толку от него особо нет. На ноуте обычно в режиме suspend to ram можно дожить до следующей розетки практически всегда.

emorozov
()
Ответ на: комментарий от rupert

На «облаках» (например, AWS)

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

ox55ff ★★★★★
()