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

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

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 пользователей одновременно ...

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

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

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

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

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

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

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

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

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

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

Вероятно, как объяснил Дэвид, это нормальное поведение ядра 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, чтобы распределить ОЗУ по всем ядрам (более подробную информацию см. По ссылке выше).