Я прочитал множество тем о кешировании памяти, и стандартный ответ: «большой кеш - это хорошо, это не должно влиять на производительность», «ядро знает лучше».
Я недавно обновился с 12.04 до 12.10 и перешел с VirtualBox на VMware Workstation, и различия в производительности очень серьезные (я подозреваю, что это из-за последнего).
Когда я запускаю свою виртуальную машину, график мониторинга загрузки системы показывает менее 50% использования памяти в целом. Индикатор загрузки системы показывает мне, что остальная часть моей ОЗУ постоянно используется в кеше.
Простое и понятное сравнение:
ДО
ПОСЛЕ
Итак, в принципе, есть ли какие-либо предложения о том, как вернуть мою производительность к тому, как она была до , сохранив мои текущие настройки?
Мое подозрение - VMWare - это p проблема, но как мне увидеть, что связано с использованием кеша? Конечно, есть способ контролировать это поведение в программном обеспечении, столь же хорошо, как и VMware?
Спасибо
РЕДАКТИРОВАТЬ: Также может быть важно отметить, что поведение отличается в зависимости от того, VMware открыт или закрыт. Если VMware открыт, то оперативная память блокируется на 50% и 50% кеша и переходит в полную блокировку, упомянутую выше. И наоборот, если VMware закрывается (после того, как он открыт), то объем ОЗУ будет продолжать расти по мере необходимости / кэш будет оставаться в качестве полного оставшегося объема памяти, и заметного снижения производительности не будет.
РЕДАКТИРОВАТЬ 2: Я поменял свою перестановку на 5, как предлагалось, без изменений (также были те же проблемы с перестановкой 10 и 60 до публикации этого вопроса). При ближайшем рассмотрении что-то действительно запуталось. Системный монитор (и подтвержденный предложенными терминальными командами - а именно free -m ) показывает следующее:
ben@ben-HPdv6:~$ free -m
total used free shared buffers cached
Mem: 3945 3827 117 0 42 2770
-/+ buffers/cache: 1014 2931
Swap: 1905 0 1905
, который говорит, что используется только ~ 1 ГБ моей ОЗУ и ~ 3 ГБ находится в дисковом кеше, НО моя ВМ работает и имеет 1,5 ГБ ОЗУ. Когда я загрузил виртуальную машину, объем используемой оперативной памяти не увеличился, но кэш подскочил. Системный монитор (подтвержденный с помощью ps -aux ) действительно показывает, что vmware имеет правильное звучание 1,8 ГБ ОЗУ, но очевидно, что free -m показывает иное. Результаты также свидетельствуют об обратном, так как моя система изо всех сил пыталась даже открыть эту страницу Chrome, чтобы опубликовать ответ (у меня есть только рабочая станция vmware и открытый терминал). Как будто память не объявляется правильно как использование оперативной памяти (в отличие от кеша), и тогда ядро, очевидно, не отвечает должным образом на основании этого? Например, он пытается освободить кеш-память так, как требуется, но не может, потому что фактически использует память / не кеш.
Я сейчас просто плевался здесь, действительно ищу некоторую помощь о том, как разобраться в этом. Любая идея узнать, что происходит? Есть ли способ подтвердить, что это проблема VMware, а не Ubuntu?
Установка swappiness
в 0 НЕ рекомендуется в производственной среде, особенно для хоста, на котором работает несколько виртуальных машин. Я видел странные проблемы на серверах и на моих собственных рабочих станциях, когда для swappiness
установлено значение 0, если изменить его на 5 или выше, оно снова станет нормальным, просто не устанавливайте его на ноль, если только вы не уверены на 100%, что вы делают и следствие, обходной путь.
Я не доверяю системному монитору GNOME. Обычно используют free
, vmstat
или dstat
.
free
Доступная системная память = свободная + буферы + кэшированные или + буферы / кэш в выходных данных free
. vmstat
в основном используется для мониторинга страниц (своп) out / in. Вам нужно устранить неполадки, если произойдет много страниц. dstat
более продвинут, чем vmstat Вы пытались проверить известные проблемы VMware Workstation? Убедитесь, что вы используете последнюю версию: 9.0.1?
Управление памятью в Linux:
https://serverfault.com/questions/449296/why-is-linux-reporting-free-memory-strangely
Решение было решено с будущими обновлениями ядра. Для записи, ядро-нарушитель, вызвавшее эту проблему, было 3.5.0-17-generic