☰

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

tag-icon • tag-icon linux mysql php
Почему используется своп, если свободной памяти достаточно?

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

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)

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

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

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

решение1

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

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

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

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

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

решение2

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

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

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

решение3

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

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

решение4

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

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

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

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

Связанный контент