LinuxMint.com.ru

Последние времена:

- RAM Linux обязательно перевалили минимум за 1Gb (ещё не так давно 256Mb было "за глаза"), нормой стало 4Gb, очень часто на типовом десктопе 8Gb или 16Gb ... про сервера здесь не говорим...
- многие переходят на быстрые твёрдотельные SSD диски.

В связи с этим очень говорят и пишут, даже очень авторитетные люди и источники, утверждают (и именно в такой формулировке):

У меня много оперативной памяти и диск SSD и именно поэтому у меня вообще нет swap и нет в нём нужды.

Я думаю (IMHO :!: ), что это принципиально неверно. И поэтому в деталях хотелось бы уточнить (и собрать из разных мест) всё о swap в этой теме:

• 1. обязателен ли swap?
  2. какие есть способы (варианты) организации swap?
  3. связано ли как-то использование swap с SSD?
  4. какой размер выбирать для swap?
  5. как управлять (оптимизировать) работой swap.

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

Olej писал(а): Если у кого есть соображения, наблюдения, опыт использования на этот предмет - поделитесь.

Здесь эта замечательная тема была затронута, но только мельком и не получила продолжения:

В-третьих, swap такого размера нужен лишь тогда, когда требуется использовать гибернацию (suspend to disk). См. здесь: https://help.ubuntu.com/community/SwapFaq

Вообще советы с отключением swap, вынесением разных разделов на HDD и всем таким прочим попросту вредны: если вы боитесь испортить SSD и старательно выносите как можно больше всего на HDD, жертвуя производительностью, то зачем вообще было его покупать? Современные SSD живут довольно долго даже при интенсивной записи.
Подробности (несмотря на то, что блог о Windows, многое применимо и к другим ОС):
http://www.outsidethebox.ms/14402/
http://www.outsidethebox.ms/14432/
http://www.outsidethebox.ms/18156/

!	Сообщение из: symon2014
	За неуёмное пристрастие пользователя пофлудить и поспамить выдана "заслуженная" награда - БАН.

Наверное начать стоит с того, что изначально swap - это отделенное место на ПЗУ (файлом или разделом), предназначенное в основном для двух целей:

• перемещать туда наборы страниц памяти для предотвращения выхода за доступные объёмы, во избежание Out of memory
• для использования режима гибернации (сна), когда содержимое оперативной памяти временно записывается в своп, для возможности снизить энергопотребление в простое

Если режим сна планируется использовать - то все рекомендации сводятся к хотя бы 1,5Х размеру свопа относительно ОЗУ
Исходя из этого - необходимость в свопе зависит от объема ОЗУ в разрезе на возлагаемые к системе ресурсоёмкие до оперативной памяти задачи, и от профиля использования режимов энергосбережения.

Для примера - свежий скайп в процессе работы без труда выходит к планке в 1Гб, браузеры могут за 2-3Гб при полусотне вкладок, плюс системные нужды от 300-500 Мб, офисные приложения, почтовые клиенты, виртуальные машины, Steam... Оперативы на всех не напасешься

На случай 4-х Гб ОЗУ - зная прожорливость десктопных приложений и игр - я предпочту выделить хотя бы пару гб под своп.

При 8 Гб и выше - мне обычно хватает оперативной памяти, особо не отслеживая запущенные приложения и спустя три-четыре дня аптайма - утилизация обычно не превышает 5,5Гб и система продолжает шевелиться.
Но под чьи-то типовые задачи не хватит и этого объема, например несколько виртуалок парралельно (еще и без balooning'а), Java разработчикам запуск и отладка приложений с высоким -Xmx, JMC из этой же серии... Есть немало сценариев забить и 16 и 32 Гб, с серверами - так вообще отдельная история...

При любой аппаратной конфигурации - обращение к своппированным данным это явная просадка по производительности. Поэтому при наличии свопа в системе - превый важный твик это vm.swappiness, о нем уже тоже упоминали неожнократно, дефолтное значение в 60 означает что использование свопа начнется уже при 40% утилизации ОЗУ, что в подавляющем большинстве случаев не будет эффективным сценарием распределения ресурсов. При типовых десктопных задачах - этот параметр лучше держать ближе к нулю.

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

Olej писал(а): Здесь эта замечательная тема была затронута, но только мельком и не получила продолжения:

Раз уж сослались на ветку, созданную мной, то вставлю свои пять копеек.
У меня как раз SSD, оперативки хватает для полноценной работы без свапа, но полностью отключать не стал, т.к. есть специфические задачи, которые легко съедают всю оперативку. Поэтому сделал vm.swappiness=10
ИМХО swap лучше ставить на SSD. Ибо на кой черт его покупать, если не использовать. У меня за 10-12 месяцев использования на Windows 10 и 1,5-2 на Mint ресурс по TBW 2,9 из 35. Если ничего не изменится, то ещё 10 лет будет жить. За свою жизнь нельзя быть настолько уверенным, чтоб SSD беречь Вообще, чтоб сберечь SSD нужно его не подключать.

А так согласен с Chocobo.

Chocobo писал(а): превый важный твик это vm.swappiness

Здесь нужно добавить эту строчку, и нужно ли перед vm.swappiness=1 поставить #, а то в этом файле все строки начинаются с #?
gksu gedit /etc/sysctl.conf

sana-555, те что с решетки - прописаны там как примеры некоторых конфигураций и не учитываются при парсинге конфига.

При каких значениях(%) занятой оперативной памяти должен заработать swap, если я поставил vm.swappiness=1?
Или какое значение прописать, если я хочу чтобы swap начал работать только при привышении 90% оперативной памяти, а лучше 95%?

sana-555, при значении vm.swappiness=10 должен свапиться, если оперативки занято 90%, т.е. осталось 10%.

Что то я не могу понять, получается если я поставил vm.swappiness=1, то по идее должен свапиться, если оперативки занято 99%? А у меня сработал, при использованной оперативке всего 60%?

Это значение не привязано к процентам заполнения памяти Swappiness

di_mok писал(а): ↑

29 янв 2018, 12:59

Это значение не привязано к процентам заполнения памяти

Хорошо, какое тогда значение оптимально, чтобы swap включался при большем значении использованной оперативки, 1 или 10?

Я на буке ставлю 10. На десктопе вообще свап не использую. sana-555, а сколько памяти на этом копмпьютере?

12 гГб, просто у меня 2 виртуалки еще на нем...

Мне кажктся - по уши, что-бы совсем отказаться

di_mok писал(а): ↑

29 янв 2018, 13:32

Мне кажктся - по уши, что-бы совсем отказаться

Удалением раздела swap, и записи в sudo gedit /etc/fstab? Может быть есть возможность пока программно отключить, чтобы проверить?
---
Еще заметил странную особенность поведения swap... У меня было значение: vm.swappiness=1, не заметил, на каком значении оперативной памяти он включился. Но, при отключении поочередно всех приложений, вплоть до того, что оперативная память стала около 10%, но подкачка так и не отключилась... Получается если подкачка однажды сработала, то она уже не отключается вплоть по перезагрузки, если даже оперативка занята всего на 10-15%?

di_mok писал(а): ↑

29 янв 2018, 12:59

Это значение не привязано к процентам заполнения памяти

На самом деле все еще интересней:
https://access.redhat.com/documentation ... y-tunables

swappiness
A value from 0 to 100 which controls the degree to which the system favors anonymous memory or the page cache.

Исходя из этого определения - управление swappiness относится больше к контролю своппинга anonimous memory
https://techtalk.intersec.com/2013/07/m ... ory-types/
https://www.thomas-krenn.com/en/wiki/Li ... che_Basics

Поэтому эффективность swappiness получается зависит от профиля использования памяти конкретными приложениями. И также стоит учитывать, что vm.swappiness=0 не значит, что своп не будет использоваться совсем, но с большей долей вероятности он будет задействован ближе к риску ООМ. Для гипервизора может быть не лишним.

sana-555 писал(а): ↑

29 янв 2018, 13:49

Получается если подкачка однажды сработала, то она уже не отключается вплоть по перезагрузки, если даже оперативка занята всего на 10-15%?

Ядро постепенно выгрузит то что попало в своп при очередных обращениях к этим наборам памяти. А т.к. туда складывают в первую очередь наборы памяти с наименьшей интенсивностью обращения - может пролежать N-времени до востребования.
Принудительно выгрузить своп обратно в оперативку можно с swapoff -a; swapon -a

Chocobo писал(а): ↑

29 янв 2018, 14:24

Принудительно выгрузить своп обратно в оперативку можно с swapoff -a; swapon -a

Работает , а если опять понадобится, то своп снова включится (я имею ввиду автоматически)?

sana-555, Ага, он включен. и также будет подхвачен системой при необходимости вновь складывать туда данные.

Я в свое время много игрался с различными настройками свопа, и пришел к выводу... настройки по умолчанию далеко не дураки делали.

vm.swappiness=60 (по умолчанию) для десктопа хорошо подходит, при условии что своп вообще нужен.

Дело в том, что если поставить 1 или 10 - обычно получается ситуация из разряда "пожар в борделе во время наводнения" - память программе начинается требоваться "ПРЯМО СЕЙЧАС ВДРУГ И СРОЧНО!" а ее нету. Система резко бросается выгружать что-то в своп, но пока не закончит - выделить ничего не может. Все становится колом, и ждет пока диск прожует то что ему отдали и можно будет таки освободить часть памяти под ожидающую задачу. Часто при
этом вообще ничего делать невозможно - даже окно переключить не получается. Полный ступор DE.

А если vm.swappiness=60 - такого не происходит. Система выгружает часть памяти в своп заранее, процесс этот проходит фоном. Может где притормозки заметны и будут, но уж точно не такой общий ступор. Т.е. ставить 1 или 10 имеет смысл только тогда, когда профиль использования предполагает что выгрузка в своп - это фактически редчайшая аварийная ситуация. И нужен только как альтернатива ошибке "Out of memory". В остальных случаях, когда своп может быть использован - эта настройка больше вредит чем помогает.

slant писал(а): ↑

29 янв 2018, 17:48

vm.swappiness=60

Разрабы никогда не знают на какое железо будет установлена ОС и какие задачи будут решаться. Это значение идёт со времён, когда кто-то ещё у папы в яйцах шевелился и объём ОЗУ измерялся в Мб, а не в Гб. Значения 40% занятого при 4Мб и при 4Гб ооочень отличаются. К тому же планировщики умнее стали.
В каждом конкретном случае каждый сам решает. Рекомендацию можно дать только зная железо и что будет на нём работать. Остальное - это бестолковая болтовня.