Ubuntu 12.10 и VMware Workstation 9: кэширование ОЗУ приводит к серьезному снижению производительности

Я прочитал множество тем о кешировании памяти, и стандартный ответ: «большой кеш - это хорошо, это не должно влиять на производительность», «ядро знает лучше».

Я недавно обновился с 12.04 до 12.10 и перешел с VirtualBox на VMware Workstation, и различия в производительности очень серьезные (я подозреваю, что это из-за последнего).

Когда я запускаю свою виртуальную машину, график мониторинга загрузки системы показывает менее 50% использования памяти в целом. enter image description here Индикатор загрузки системы показывает мне, что остальная часть моей ОЗУ постоянно используется в кеше.

Простое и понятное сравнение:

ДО

  • Кэш-память использовалась очень редко, практически ни одно из использования моей памяти не было кэш-памятью [ 116]
  • Перестановка была 0 (из-за этого сначала использовалась моя память, а затем только при необходимости)
  • Производительность была довольно хорошей и логичной
    1. Сначала ОЗУ использовалось полностью, кеширование было минимальным , Я мог запустить достаточно программного обеспечения, чтобы использовать мои полные 4 ГБ оперативной памяти без какого-либо снижения производительности.
    2. Затем использовалось пространство подкачки, которое было очевидно медленнее (я на жестком диске), но все еще использовалось, когда текущая программа загружается в память

ПОСЛЕ

  • Кэш используется для заполнения всех 4 ГБ сразу после запуска моей виртуальной машины
  • Swappiness равно 0 (такое же поведение, как и раньше, но кэш-память использует всю память сразу)
  • Производительность ужасна и непригодна для использования при работе программного обеспечения Ubuntu
    1. Основные вещи, такие как смена окон занимает 2 минут +
    2. Смена экранов происходит кадр за кадром, иногда до 5 минут
    3. Невозможно запустить IDE и VM так же легко, как я мог до

Итак, в принципе, есть ли какие-либо предложения о том, как вернуть мою производительность к тому, как она была до , сохранив мои текущие настройки?

Мое подозрение - 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?

4
задан 30 December 2012 в 07:40

2 ответа

Установка swappiness в 0 НЕ рекомендуется в производственной среде, особенно для хоста, на котором работает несколько виртуальных машин. Я видел странные проблемы на серверах и на моих собственных рабочих станциях, когда для swappiness установлено значение 0, если изменить его на 5 или выше, оно снова станет нормальным, просто не устанавливайте его на ноль, если только вы не уверены на 100%, что вы делают и следствие, обходной путь.

Я не доверяю системному монитору GNOME. Обычно используют free, vmstat или dstat.

  1. free Доступная системная память = свободная + буферы + кэшированные или + буферы / кэш в выходных данных free.
  2. vmstat в основном используется для мониторинга страниц (своп) out / in. Вам нужно устранить неполадки, если произойдет много страниц.
  3. dstat более продвинут, чем vmstat

Вы пытались проверить известные проблемы VMware Workstation? Убедитесь, что вы используете последнюю версию: 9.0.1?

Управление памятью в Linux:

http://www.linuxatemyram.com/

https://serverfault.com/questions/449296/why-is-linux-reporting-free-memory-strangely

0
ответ дан 30 December 2012 в 07:40

Решение было решено с будущими обновлениями ядра. Для записи, ядро-нарушитель, вызвавшее эту проблему, было 3.5.0-17-generic

0
ответ дан 30 December 2012 в 07:40

Другие вопросы по тегам:

Похожие вопросы: