Как вы помните, не так давно мы рассматривали вопрос очистки оперативной памяти в случае, когда она через чур забита дисковым кэшем. Сегодня мы продолжаем урок уличной магии... издевательства над системой... работы с памятью, но на этот раз уделим внимание не столько ей, сколько всеми нами горячо любимому свопу.
Обычно рано или поздно у всех возникает вопрос: "А какого черта у меня начинает заполняться своп, когда у меня еще свободной оперативной памяти как грязи?". И вот тут нам приходит в помощь такой параметр, как vm.swappiness. Для начала в консоли выполним команду:
cat /proc/sys/vm/swappiness
Поумолчанию результат будет 60.
Вы, конечно же спросите: "И что это означает?". Отвечаю: это параметр, который контролирует количество свободной памяти, который контролирует, при какой загруженности у нас начнется сброс страниц в swap. Ну а дальше простая формула: 100%-60%=40%, т.е. уже при 40% загруженой ОЗУ данные начинают активно сливаться на жетский диск, что, как мне кажется, не есть хорошо. И вероятнее всего вы спросите, нельзя ли сделать так, чтобы слив начался хотя бы при 90% занятой памяти. И я вам отвечу: да, можно. Сначала в конфиг /etc/sysctl.conf добавим запись:
vm.swappiness=10
Затем, дабы не перезагружать комп, выполним с правами суперпользователя команду:
sysctl -p
Теперь параметр оперативная память будет выгружаться в своп при достижении 90% занятости.
А сейчас мы снова вернемся к теме, рассмотреной в прошлый раз - к дисковому кэшу. То, о чем пойдет речь дальше, делайте на свой страх и риск, я за последствия нести ответственность отказываюсь. =)
Существует такой параметр, как vfs_cache_pressure. Этот параметр определяет, на сколько ваша операционная система готова держать кэши в оперативной памяти или же сливать их своп. Посмотреть значение можно такой командой:
cat /proc/sys/vm/vfs_cache_pressure
Параметры vm.vfs_cache_pressure:
Знатоки рекомендуют устанавливать значение 1000 и больше для обычных винчестеров и около 50 для SSD дисков. Чем выше значение vm.vfs_cache_pressure тем отзывчивей будет система (тем больше будет кэширование), но это при условии что у Вас достаточно оперативной памяти (более 2Гб).
Если кому-то будет интересно на практике определить, какое значение ему лучше подходит, то рекомендую ознакомиться с этой буржуйской статьей.
Если вы остановились в выборе на каком-то определенном значении, то впишем его туда же, куда раньше мы прописывали параметр vm.swappiness - в конфиг /etc/sysctl.conf:
vm.vfs_cache_pressure=1000
Ну и чтобы значения вступили в силу, выполним с правами суперпользователя команду:
sysctl -p
.
На этом тюнинг можно считать законченым. Но у вас наверняка может возникнуть вопрос: "У меня дофига свободной оперативы, но при этом в свопе что-то лежит, а я хочу его освободить. Как мне очистить своп?" И на этот вопрос есть ответ.
Для начала убедитесь, что содержимое свопа не превышает размер свободной оперативной памяти. Если свободной памяти больше, чем свопа, то на какое-то время своп просто отключаем командой:
swapoff -a
После чего дожидаемся, когда содержимое свопа перельется в оперативную память. Обязательно промониторьте это дело любой предпочитаемой вами утилитой (виджетом, командой free, командой top/htop или что вам больше по душе). Когда из свопа все перелилось, снова его включаем:
swapon -a
На этом мы и закончим наш урок. Наслаждайтесь!
Комментарии (38)
Да здравствуют вредные советы!
(Я лично убедился, что Кубунту собирают не дураки, и всё отлично оптимизировано. Разве что в весьма специфических ситуациях нужно регулировать эти настройки)
Если бы еще эти перцы знали, сколько оперативы будет у юзера и какой набор одновременно работающих приложений использоваться - цены бы их оптимизации не было =)
хорошо быть недураком и знать, как дела обстоят у всех, правда? =)
"Хотите перессорить системных администраторов?
Спросите их о разделе подкачки. Какого размера он должен быть? Нужен ли он вообще?"
Это заголовок одной статьи, посвящённой свопу :-)
Ребятушки. Истина для всех одна спросите у любого можно я Вам сделаю плохо? - ответ очевиден Нет (кроме аномалий) Истинный критерий - Истинный ? Kde - уже давно Очень качественен и стабилен - Истина !!!!.
Сайт жить Обязан, и если админы, вспомнили что есть еще какой-нибудь нюанс и написали о нем в Поддержку сайта
- отреагируйте с добротой и без эмоций! Но я процетирую vm.swappiness=10 - как удар молотом по голове в определенные моменты. У меня vm.swappiness=60 по дефолту с учетом, что 1,5 gb оперативки на одном из ноутбуков. Отдельным разделом swop, и он почти всегда свободен. Нужно ценить то что сделано Хорошо, и не оценивать тех кто это хорошо делает, и тем более не думать вот Балваны vm.swappiness=10 - не догадались. Ха ха ха.?????!!!! Они это проектировали, думали продумывали передумывали а не Вы. Конечно если у вас оперативки больше >= 8 gb вся эта ... с кешем вообще не уместна. Но молодежь стращать Не Стоит!
Любишь употреблять исключительно то, что дают, не задумываясь, из чего и как это сделано? Что я могу сказать... Это тоже выбор.
Люблю употреблять то - что имеет критерий Достаточности, а не избыточности.
Любые отношения должны строится на Доверии (отнюдь не на слепом). :)
Вы пищу солите до необходимой нормы или до соленого вкуса? А соусы добавляете?
Одежду используете только ту, которая выполняет свое функциональное значение или, все же, чтобы было удобно и выглядело как хочется?
Картинку на рабочий стол ставите? Это же бесполезная трата оперативки.
Тариф на интернет выбираете самый дешевый? Очередь на закачку рулит, результат тот же.
А машина у вас только такая, чтобы ездила, комфорт неважен? Да и автобус же есть...
А телефон только чтобы звонил?
Я могу долго продолжать =)
А случайно не на том, когда интересы взаимно учитываются?
Простите, по чьей голове и в какие такие моменты?)
Что до свопа - свободен он будет в, данном случае, только до превышения отметки resident size ОС и приложений в 600 Мб. Дальше каждое действие будет теребить диск, что положительно никак не скажется. Зато система будет держать эти 60% свободной оперативки готовыми к запуску прожорливого приложения... История умалчивает о том, какой дикий своп начнется после.
А если учесть, что большинство современных программистов не умеют работать с памятью и даже в душе не чают, как происходит работа с ней, распределение и сколько дополнительных операций вызывает...
Помимо необходимости, достаточности и избыточности есть еще такая штука, как эффективность. Именно для нее данный параметр не захардкодили, а оставили доступным для настройки, ибо универсального решения нет и любые холивары о нем не имеют смысла.
Установки по умолчанию сделают сбои системы более незаметными и позволят вам во множестве бытовых случаях - хотя бы корректно сохранить свою работу, пока не пошло все наперекосяк, безвозвратно.
Когда Вы установите vm.swappiness=10, практически без свопа, то ядро в случае сбоя - бесцеремонно будет уничтожать процессы, и всю Вашу не сохраненную работу вместе с ними.
Нет идеальных настроек для всех.
Хотя бы один пример с техподробностями можно?)
Своп при vm.swappiness=10 останется точно таким же и такого же размера. Ядро вначале будет лить страницы неактивных/наименее активных приложений в своп и только после его переполнения начнет работу OOM killer.
Настройка не для всех, а лишь для тех, у кого активный resident size начал стабильно превышать 40%, а старенький HDD начал трещать так, что хочется взять и у****ь. Явный пример - криво собранная пятая плазма под бубунтой в 15.04, которая кушает в полтора-два раза больше оперативки, чем на гусях или в сьюс.
ух ты. Сказочная версия конечно, но увы, абсолютно неверная.
В данном случае указывается процент от свободной памяти, при которой приложения будут загонять в своп.
В любом случае своп продолжает работу как обычно, просто его использование начнается при меньшей свободной памяти.
Не все так однозначно - https://yadi.sk/d/g_Ll6zBysdU7P
Из скринов все поймете.
ОС на тот момент Ububuntu 12.04 i386. Железо: 2.6х2 Гц от Intel, 4 Гб ОЗУ.
wm.swappiness = 10
Насколько помню Запущены одновременно 14 vlc с разными фильмами (все они проигрываются), 2 браузера с 20-ю сайтами в каждом, системный монитор и то ли qmmp, то ли audacious.
Как видно из последнего скрина, использование ОЗУ достигло 63%. Так что vm.swappiness = 10 очень даже помог иначе тормозов избежать не удалось бы.
В данном случае указывается процент от свободной памяти, при которой приложения будут загонять в своп.
Никто в этом и не сомневался, только когда вместо 90% RAM будет использоваться 90% HDD, тем более когда HDD старенький, понервничаете больше чем при vm.swappiness=60.
Дохтур! читайте первоисточники!
vm.swappiness=10 этокогда осталось свободной 10% памяти, и 90% процентов уже занято!
а не наоборот, как Вы умудрились написать.
Что, как мне кажется, выглядит или нежеланием читать источники, или преднамеренным передергиванием.
И то, и другое очень плохо, но второе таки хуже.
Когда при 10% свободной памяти занятые 90% будут целиком записываться в swop на HD а для работы самой системы RAM вообще будет мало вот тогда и Вы и Ваша система будете ПЕРЕДЕРГИВАНИЕМ ЗАНИМАТЬСЯ ЗАТЯЖНЫМ минуты 3 точно. Пациент!
Ахах... ахах... ухахахаха.
Таки все 90? Разом? Ядро скажет "дай-ка, Вася, я х***у! все 90% на винт! лови топор! чо молчишь, поймал?"
Даже минусить не буду, ибо ржал аки конь.
Если взять и открыть в Audacity хотя бы 5-и часовой звуковой файл начать с ним работать, и потом вдруг тебе не хватит RАМ, Будешь ли ты ржать как конь?, будешь скорей выть как белуга. Все 90 или не все 90 сразу а постепенно,а может 89 или 47 ... Без обид )
Без обид, давай поржом вместе =)
Итак, у нас есть ноут, в котором полтора гига оперативки. Пренебрежем степенями двойки для наглядности. Есть 1500 мегабайт памяти. На ноуте Linux с KDE, Skype, Krusader и прочим софтом. Общий resident size - 1400 мегабайт, своп на 1500 мегабайт.
И вот два случая:
1) vm.swappiness=10: общий resident size - 1400, пустой своп, дисковый кэш примерно 50 мегабайт, 50 мегабайт нетронуто.
2) vm.swappiness=60: общий resident size держится в районе 600, примерно 800 в свопе, дисковый кэш примерно 500 мегабайт, 400 мегабайт нетронуто.
В первом случае работаем довольно комфортно, во втором - каждое обращение к запущенной, но редко используемой программе влечет за собой сброс части кэша, засвопливание данных другого приложения, теперь отошедшего ниже по приоритету использования и вытаскивание из свопа данных приложения, к которому мы обратились.
Запускаем аудиоредактор.
Допустим, что контейнер для данных в нем офигенно требовательный и использует std::vector для хранения данных по фреймам. Опустим сейчас структуры для индексов и прочего. Допустим, файл, который мы открываем требует выделения 1400 мегабайт для нашего вектора.
Как это будет происходить в наших двух случаях?
Для начала, стоит заметить, что аллокаторы, что из libc, что из libstdc++ видят виртуальную память. Для них пространство физической оперативки и свопа - непрерывно. В обоих случаях операция выделения памяти будет представляться успешной.
1) ядро не такое глупое, поэтому попытается перед выделением засвопить часть данных, освободив место под вектор;
2) часть данных и так в свопе, но, скорее всего, перед выделением, туда зальется еще больше, будет сброшен дисковый кэш и выполнена тьма внутренних операций по управлению памятью.
После чего в обоих случаях мы получим следующее: часть вектора в физической оперативке, часть - в свопе.
Когда же мы решим наложить эффект целиком на весь трек, т.е. побежим итератором по вектору, изменяя данные - у нас будет все ок до тех пор, пока не дойдем до границы оперативки и свопа. После - можете выть или хохотать, на свое усмотрение.
Поэтому, если
выть ты будешь вне зависимости от vm.swappiness.
но начнешь выть немного позже, когда начнется активный свопинг. :-)
И на всякий случай - когда я играю в Евротраксимулятор2, у меня своп не появляется. при vm.swappiness=10, при стандартном значении начинался свопинг, что приводило к подтормаживанию игрушки. Да, памяти около 6 гигов занято из 8. Больше не позволяет материнка поставить.
Я так понимаю, вы мой пост не осилили?) Просто ответ явно такой, как будто делался после прочтения одной последней фразы.
Надо прекращать песать многабукаф... =)
такое впечатление, что я отвечал на что-то другое... :-(
В интернетах мне часто приходится видеть диванных экспертов в области экономики, политики, стратегии, авиации и много-много чего еще. Сейчас я наблюдаю диванного линуксоида.
Эмм? Извините, Вы о чем пишите? Вы неадекватно воспринимающий реальность человек?
Что за бред?
Ну, хорошо. Такой пример:
Как известно, софт неидеален и использование памяти в нем тоже не идеально.
Значение "60" позволяет системе более агрессивно использовать свопинг. То есть та память, которая не используется очень долго, будет активнее уходить в своп.
При значении "10" свопинг будет происходить менее агрессивно. То есть всякое bloatware, которое неэффективно использует память, будет висеть в ней до тех пор, пока системе память не понадобится уже срочно.
Вопрос: какая система будет работать эффективнее?
Это мы не учитываем проблемы с файловым кэшем, который может отсутствовать при значении 10, а значит, дисковые операции при таком значении могут работать медленнее (сюрприз)!
Пруф?
Мне кажется, это работает несколько сложнее.
Ну и к чему все эти экзерсисы? Можно подумать, мы тут кого-то заставляем брать в руки напильник и переделывать то, что заложено ментейнерами. =)
Хочется в режиме 24/7 думать о том, а не криво ли использует память всякое блотваре - бога ради. Паранойя - дело сугубо добровольное.
Эта статья - повод прикинуть, что и как можно подкрутить для комфортного пользования, а не приказ к действию.
Ребята, давайте жить дружно! :-)(с)кот Леопольд
Давайте помиримся и поставим значение 32 (не нашим, не вашим) :-)
почему не 33? не очень люблю круглые (или повторяющиеся) цифры. :-)
Установил значения:
vm.swappiness=10
vm.vfs_cache_pressure=1000
Почти все как работало так и работает. Зато ktorrent теперь виснит.
при активном пользовании торрента - да, это может стать проблемой. торрент оперирует большим колличеством мелких кусочков файлов, поэтому лучше верни как было, если пользуешься торрентом часто и активно.
Уже вернул =) Я погорячился сразу обвинять эти настройки.. У меня и при стандартных настройках глюки. При том что проблема только при скачивании и сохранение на раздел с ntfs.
а, у линкса традиционная аллергия на ntfs, это норма =)
и не у линукса(который знать не знает об нтфс), а у драйверов, и все благодоря политике фирмы мелких и мягких...(которая до сих пор не открыла полностью спецификацию этой файловой системы) :-)
Проблема не в спеках, а в том, что теоретическая лицензия ядерного (а не fuse) драйвера будет несовместима с лицензией ядра. По этой же причине есть и проблемы с полностью открытой zfs, например.
Уж поверь мне, дело именно в спецификации, опубликованной МС.
И именно поэтому
Ибо получена под НДА (протокол о неразглашении для разработчиков)
Я именно о парагоновском драйвере говорю. Ибо общался лет семь-восемь назад лично...
Есть проприетарный (и, кажется, платный) драйвер ядерный, мужики пишут, что работает как родное.
Стало интересно, нагуглил решения от Paragon и Tuxera (есть бенчмарк, правда, под ARM).
Последние вообще основатели ntfs-3g и понаписали много прикольной проприетарщины, включая быструю реализацию SMB.
ты хотел сказать, что разработчики (большая часть) ntfs-3g основали tuxera? :-)
Зачем что-то говорить, если на сайте все рассказано? =)
Tuxera уходит корнями в разработку открытой NTFS'ной файловой системы в конце 90-тых. Szabolcs Szakacsits основал проект NTFS-3G, созданный как Финская компания NTFS-3G Technology в 2008 году. Между тем, Антон Альтапармаков развивал и занимался сборкой файловой системы NTFS для ядра Linux. В 2009 году компания была переименована к Tuxera Inc. с Mikko Välimäki в качестве генерального директора, Szabolcs в качестве президента и технического директора, и Антона, как ведущего разработчика файловой системы. Имя Tuxera было выбрано, чтобы отразить веру компании в то, что "Tux" (имя пингвина Linux) будет в новую "эру" в каждом устройстве. Имя также отражает, что компания будет работать над другими файловыми системами и программными технологиями, начиная с нового стандарта exFAT.
на 14 ГБ, хром с 10+ открытыми ютубовскими вкладками, + опера с 20+ вкладками, + всяко-разно. стало более отзывчато. Ксонотик вообще забегал, недостаточная скорость отрисовки вообще вылезла :(
Отправить комментарий