Скажите macOS использовать только подкачку и сжатую память, когда это действительно необходимо (macOS 10.14 Mojave)


9

Поскольку отключение подкачки и / или сжатия памяти не рекомендуется, а также не является стабильным вариантом после 10.9 Mavericks (несмотря на то, что параметр vm существует), я обречен после нескольких дней работы моего Mac с записью моей памяти в далеко от оптимального страницы памяти. Поскольку все становится так просто, что я могу заменить или сжать память, мне нужно перезагружать мою систему относительно часто (несмотря на 16 ГБ ОЗУ).

Я ищу решение, которое спасет меня от этих замедлений.

Например, в Linux zramswap не является обязательным. Также Linux имеет значение перестановки от 0 до 100, например, переменная

vm.swappiness=5

Также я могу рассмотреть решение о файловом кеше (который обычно беспорядочно пожирает тонны памяти без уважительной причины и не сбрасывает его до того, как оперативная память превращается в менее оптимальные чистые места сжатой памяти и подкачки). Например, здесь у ZFS есть опция для FreeBSD, чтобы максимизировать размер файлового кэша в памяти:

vfs.zfs.arc_max="1536M"

В macOS работает самый известный способ решения проблемы с файловым кешем

# /usr/sbin/purge

Который даже "cronnable". Так что это очищает файловый кеш, но вряд ли будет оптимальным. Это сбрасывает слишком много вещей. Кроме того, если что-то уже есть в подкачке и / или в сжатой памяти, несмотря на очистку, оно остается там, поэтому программы, использующие их, остаются медленными (и я чувствую эту медлительность, поверьте мне).

Есть ли какое-либо решение, чтобы снизить вероятность использования macOS кеша файлов, сжатой памяти или подкачки (но все равно оставьте первое для производительности, а второе для аварийного)?


3
Проблема с условием «когда это действительно необходимо» состоит в том, что все мозги в Купертино уже решили, когда это должно быть. То, что вы на самом деле имеете в виду, это «когда я думаю, что должно», что совершенно другое.
Тецудзин

В Linux я сам управляю им, и он работает намного лучше. Есть своп и используется только в экстренных случаях. Это не так просто, как «когда я думаю, что должно». Это больше похоже на «когда я испытал это должно» и «когда я испытал это не должно». То, как его нельзя настроить, является огромным недостатком macOS.
дзакал

1
Хорошо, тогда скажите мне, как вы добавляете больше оперативной памяти к MacBook Pro 15 до 2018 года или любому другому MacBook (Pro, Air и т. Д.). 16 ГБ - максимум с 2010 года в большинстве из них (за исключением Macbook Pro 158 дюймов 2018 года). А также ОС решает поменяться и сжать, когда оперативная память даже не заполнена. (То же самое с Linux, если вы не понизите значение подкачки, но, по крайней мере, можете). Пожалуйста, перестаньте пытаться убедить меня в том, что Apple приняла здесь правильные решения, связанные с управлением памятью, как они этого не сделали, а также, пожалуйста, перестаньте предлагать невозможные решения, которые практически ни для кого не работают.
dszakal

Вы уверены, что проблема не в самих приложениях?
Адиб

Да, я уверен :)
dszakal

Ответы:


3

У меня та же проблема и я полностью сочувствую. Ненужная замена перед другими опциями (например, сокращение области кэшированных файлов) была проблемой в течение многих лет. В Мохаве все еще хуже, когда есть свободная память - даже не дисковая кеша, а полностью свободная - но система все равно решает использовать своп. На SSD каждая запись приводит к износу оборудования, так что это на самом деле (хотя и незначительным образом) наносит физический ущерб. Поскольку твердотельные накопители в современных компьютерах Mac припаяны к основной плате, ситуация является ужасной.

Мне много раз говорили очень уверенные постеры на таких сайтах, как это, что свободная память - плохая идея, потому что она сидит там, потребляя энергию и не имея никакой другой пользы. Дисковый кеш (как минимум) должен его потреблять. Я согласен с этим; Мохаве этого не делает, сжимая данные и выгружая их на диск, даже когда присутствуют гигабайты свободной памяти. На моем домашнем ноутбуке циклы сна делают его еще хуже. Прямо сейчас, после пробуждения, на машине свободно 11 ГБ, используется 5 ГБ и 6 ГБ. Цвет тарабарщины «давление памяти» - зеленый, что бы это ни значило. Это совершенно абсурдно и неоправданно сломано.

Раньше я думал, что должно быть что-то, что я устанавливал или делал неправильно, но на совершенно новых компьютерах Mac, работающих без дополнительной установки, потребление оперативной памяти при открытии большого количества вкладок в Safari достаточно скоро покажет использование пространства подкачки, несмотря на большое количество свободной памяти.

И да, это отстает - время от времени плохо. Это определенно влияет на производительность.

Я не знаю решения. Apple Engineering утверждает, что «работает как задумано».


1
Люди продолжают утверждать, что «исправление приложения, которое приводит к утечке памяти, исправит это». Но если вы включите Macbook Air с оперативной памятью 8 ГБ и оставите там только рабочий стол на 3 дня, он уже начнет меняться. Вы еще ничего не открыли. То, что они утверждают, больше не верно. Управление памятью macOS работает не так безупречно, как это было 10-15 лет назад.
dszakal

Не делай этого на Каталине. Каталина уже осуществляет управление памятью, о которой вы все мечтали.
Прадо

4

Я говорю это с добротой, но нет, нет, нет.

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

Теперь - у вас может быть очень веская причина, по которой вы хотите изменить виртуальную память, но микроядро macOS не предназначено для того уровня настройки, который есть в Linux, и если вам действительно нужно управлять виртуальными машинами так плотно, я бы рекомендовал Вы можете либо разместить этот код на отдельном сервере, поместив его в облако, на второе локальное устройство или даже виртуализировать гостевую ОС Linux поверх MacOS.

Тогда у вас будет лучшая память для реальной ОС и виртуального программного обеспечения (VMWare Fusion - моя первая общая рекомендация, но посмотрите Parallels или даже некоторые бесплатные опции, если у вас есть время и желание), чтобы вы могли поместить нужный код железный кулак, управляющий виртуальной памятью в Linux и позволяющий приложениям Mac быть приложениями Mac.

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

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


Когда вы говорите также о виртуализации Linux, становится довольно непонятно, когда вы пишете VM: о VirtualMachine или VirtualMemory, которые «нуждаются» в настройке. (Я считаю, что управление памятью в macOS иногда кажется довольно сумасшедшим, и, как правило, лучше управляется в Linux, с довольно большим количеством глупостей, чем столь же вопиющие исключения; но как добавить Linux-Vmachine с собственным преимуществом управления Vmemory (используя еще больше памяти и как вы исправляете управление памятью / утечки всего этого закрытого программного обеспечения, от которого вы можете зависеть? За исключением подачи отчетов о том, что это.)
LangLangC

Поскольку мы сравниваем подходы: и macOS, и Linux поставляются с алгоритмами и настройками по умолчанию, которые были определены для работы с определенным подмножеством приложений. Они не могут охватывать все сценарии одинаково хорошо, и оба имеют предположения для определенного значения по умолчанию. Это означает, что для того, чтобы Linux хорошо работал на ноутбуках, вы действительно получаете выгоду от настроек по умолчанию. Для macOS вы в основном извлекаете выгоду из нескольких настроек, которые вы можете использовать, чтобы использовать его как железо (сервер). AFAIK, на Mac доступно всего несколько опций, и главное, что вы правильно отметили, это то, что выигрыш невелик.
LangLangC

3

Первая и лучшая линия защиты - убивать процессы или службы, которые не нужны.

Тогда вы можете контролировать сжатие vm:

$ sysctl -a vm.compressor_mode
vm.compressor_mode: 4 

Установите эти переменные с помощью команды nvram:

Режим 0x1, VM_PAGER_DEFAULT, отключает компрессор памяти и подкачку, что, как оказалось, вредно для стабильности системы. Режимы 0x8, 0x10 и 0x20 - это так называемые режимы «заморозки», которые мгновенно «замораживают» ОС, когда память находится под давлением. Вы не хотите их пробовать.

Режим 0x2, VM_PAGER_COMPRESSOR_NO_SWAP, является лучшим выбором здесь. Это обеспечивает сжатие памяти с отключенной подкачкой. Другими словами, когда память находится под давлением, macOS будет пытаться сжать активную, но не проводную память, освобождая часть памяти обратно в систему. macOS использует алгоритм WKdm для сжатия и распаковки памяти, что быстро и экономно расходует заряд аккумулятора. Тем не менее, паника ядра все еще возможна, если нет больше сжимаемой памяти. Чтобы перейти из режима 0x4 в 0x2, используйте эту команду и перезагрузите компьютер:

$ sudo nvram boot-args = "vm_compressor = 2"

При использовании режима 0x2 необходимо внимательно следить за давлением памяти, чтобы избежать паники ядра. Как только объем сжатой памяти увеличится почти до 50% от общего объема памяти, вы захотите либо закрыть некоторые из запущенных приложений, либо просто перезагрузить систему.

Избегайте сжатия
памяти Несмотря на то, что сжатие памяти быстрое и предназначено для уменьшения нагрузки на память, наилучшая производительность может быть достигнута только тогда, когда память не сжимается. Используйте Activity Monitor или следующую команду, чтобы следить за использованием памяти:

$ top -o CMPRS

По моему опыту, macOS начинает сжимать память, когда использование памяти приближается к 80%. Попробуйте ограничить число запущенных приложений небольшим числом и перезапустите или уничтожьте приложения, которые занимают слишком много памяти. Тогда ваш Mac должен работать так же быстро, как и должен. Используйте Activity Monitor или следующую команду, чтобы увидеть, какие приложения используют большую часть памяти:

$ top -o MEM

через среду

Есть больше настроек, с которыми можно поиграть и которые доступны аналогичным образом, но все они, похоже, не стоят того


Отключение свопинга через vm.compressor_mode работало до 10.9, но зависло до 10.10 и более поздних версий OS X / macOS. :(
dszakal

@dszakal Настройки compressor_mode были введены только вместе с vm – compress 10.9, и настройки присутствуют также в 10.12. Я не могу сейчас выполнить загрузочную проверку машины 10.14, но настройка также в 10.14 ... Что не работает с этим в вашей настройке?
LangLangC

10.10 он замерз через час, а 10.11 замерз при нажатии кнопки выключения. Поэтому я не рискнул попробовать после 10.12, так как никто не осмелился ответить на это: apple.stackexchange.com/questions/275303/…
dszakal
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.