Почему Swap используется, когда остается много свободной памяти?

35

У меня довольно хороший веб (выделенный) сервер с хорошими ресурсами памяти:

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)   

Как вы можете видеть, мой сервер использует swap, когда доступно много свободной памяти.

Это нормально или что-то не так с конфигурацией или кодировкой?

Примечание.
Процесс MySQL по какой-то причине потребляет более 160% мощности процессора; Я не знаю почему, но у меня не более 70 пользователей одновременно ...

user1179459
источник
Приложения могут использовать более 100% процессора в Linux?
Хм
5
@BlueRaja: Да, потому что в Linux загрузка ЦП измеряется относительно одного ЦП, а не всех ЦП в вашей системе. Таким образом, в машине с 8 процессорами у вас есть максимум 800% доступных процессоров.
Даниэль Приден
Какую версию MySQL вы используете ???
RolandoMySQLDBA
@RolandoMySQLDBA версия 5.5
пользователь1179459

Ответы:

61

Это совершенно нормально.

При запуске системы запускается ряд служб. Эти сервисы инициализируют себя, читают файлы конфигурации, создают структуры данных и так далее. Они используют немного памяти. Многие из этих служб никогда не будут работать снова в течение всего времени работы системы, потому что вы их не используете. Некоторые из них могут работать в течение нескольких часов, дней или недель. Все же все эти данные находятся в физической памяти.

Конечно, система не может выбросить эти данные. Это не может доказать, что к нему буквально никогда не будет доступа. Например, одна из этих служб может предоставлять вам удаленный доступ к устройству. Возможно, вы не использовали его в течение недели, но если вы его используете, он лучше работает.

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

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

Дэвид Шварц
источник
В этом случае вы можете объяснить, почему иногда пространство подкачки вообще не используется. Память: всего 49554484 КБ, использовано 4087592 КБ, свободно 45466892 КБ, 349244 КБ буферов Обмен: всего 94204 КБ, использовано 0 КБ, 94204 КБ свободно, 1113644 Кэшировано
2012 г.
4
@ananthan: там может быть много причин. Скорее всего, система никогда не испытывала какого-либо давления памяти, даже из-за буферизованных записей, поэтому код условного обмена никогда не мог быть запущен. Может также случиться так, что кто-то сочтет, что любое использование свопа является плохим, и поэтому неправильно настроил систему, чтобы она не изменялась оппортунистически (уменьшая своппинг ).
Дэвид Шварц
6

Это может произойти, если в прошлом вам требовалось больше памяти, чем у вас было физической памяти на машине. В это время некоторые данные будут записаны в пространство подкачки.

Когда более поздняя память освобождается, данные из свопинга не считываются автоматически обратно в ОЗУ: это происходит только тогда, когда данные в свопе действительно нужны какому-либо процессу. Это совершенно нормально.

Что касается вашего процесса mysql: все зависит от типа выполняемых вами запросов. В теории 2 очень сложных запросов, вероятно, может быть достаточно, чтобы получить такую ​​нагрузку, независимо от вашего количества пользователей. Вы можете включить медленный журнал запросов, чтобы лучше понять, какие запросы требуют большой нагрузки.

brain99
источник
Нет - использование свопа не является высокой отметкой. Когда замененные страницы отображаются обратно, страницы диска помечаются как неиспользуемые (но могут по-прежнему содержать данные).
Symcbean
Я упомянул только один сценарий, в котором вы можете использовать своп, но на самом деле это не всегда является симптомом нехватки физической памяти - как также объяснил Дэвид Шварц выше
brain99
3

Вы также можете изменить это поведение sysctl -w vm.swappiness=10, что значительно сократит использование свопа, пока он действительно не понадобится.

Что касается MySQL, вы хотя бы выполнили тест базовой конфигурации с помощью сценария tuning-primer.sh ?

Демон Хаоса
источник
1
Это увеличит тенденцию восстановления кеша / буферов. К сожалению, из первоначального вопроса неясно, включает ли цифра 29,53% буферы / кэш - если этого не произойдет, то внесение внесенных вами изменений негативно скажется на производительности. Если эта dbms широко использует innodb, то, вероятно, она плохо настроена (хотя для начала в качестве веб-сервера выбран один 8-ядерный 16-гигабайтный блок для использования в качестве веб-сервера)
symcbean
почему вы говорите, что это плохой выбор для веб-сервера? я не пользуюсь innodb, я все еще предпочитаю myisam, потому что мои чтения составляют 70%, а записи - только 30% ....
user1179459
1

Вероятно, как объяснил Дэвид, это нормальное поведение ядра Linux, но это также может быть проблемой MySQL «swan insanity» . В вашем случае (8 ЦП, 16 ГБ ОЗУ всего, 5 ГБ использовано), чтобы это произошло, ваш компьютер должен быть системой NUMA с 4 узлами (сокетами) и 4 ГБ ОЗУ на узел и буферным пулом MySQL InnoDB из 4 GB.

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

  1. Когда ваша система запускается, процессы распределяются по всем узлам NUMA, используя часть их памяти.
  2. Когда MySQL запускается, он выделяет 4 ГБ для пула буферов InnoDB, заполняя ОЗУ узла NUMA и используя некоторое ОЗУ на других узлах.
  3. Затем ядро ​​Linux, которое не может переместить выделенную оперативную память с одного узла NUMA на другой, считает, что это хорошая идея - выгрузить страницы из голодного узла (или нужно поменять их местами, потому что страницы нужно было поменять местами).

Чтобы избежать этого, измените выделение памяти для MySQL, чтобы распределить ОЗУ по всем ядрам (более подробную информацию см. По ссылке выше).

jfg956
источник