Чому 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)   

Як бачите, мій сервер використовує своп, коли є багато вільної пам'яті.

Це нормально чи щось не так з конфігурацією чи кодуванням?

NB
Процес MySQL чомусь використовує понад 160% потужності процесора; Я не знаю чому, але у мене немає більше 70 одночасних користувачів ...

Це цілком нормально.

При запуску системи запускається ряд служб. Ці сервіси ініціалізуються, читають у конфігураційних файлах, створюють структури даних тощо. Вони використовують деяку пам’ять. Багато з цих служб ніколи не працюватимуть за весь час роботи системи, оскільки ви не використовуєте їх. Деякі з них можуть працювати в години, дні чи тижні. І все-таки всі ці дані знаходяться у фізичній пам'яті.

Звичайно, система не може викинути ці дані. Це не може довести, що до нього буквально ніколи не можна буде звернутися. Наприклад, однією з таких служб може бути послуга, яка надає вам віддалений доступ до вікна. Ви, можливо, не використовували його протягом тижня, але якщо ви все-таки користуєтесь ним, це краще спрацює.

Але система знає, що, можливо, захочеться використовувати цю фізичну пам'ять для таких речей, як дисковий кеш, або іншими способами, які підвищують продуктивність. Так відбувається умовно-патогенний обмін. Коли нічого кращого зробити, він записує дані, які не дуже довго використовувались на диску, використовуючи місця для обміну. Однак він все ще зберігає сторінки у фізичній пам'яті. Таким чином, до них можна отримати доступ, не змінюючи їх.

Тепер, якщо пізніше системі потрібна ця фізична пам’ять для чогось іншого, вона може просто викинути ці сторінки, оскільки вона вже написала їх для заміни. Це дає системі найкраще для обох світів. Дані все ще зберігаються в пам'яті, тому до них можна отримати доступ без зчитування з диска. Але якщо система потребує цієї пам’яті з іншою метою, її не доведеться спочатку виписувати. Велика перемога навколо.

Це може статися, якщо певний час у минулому вам було потрібно більше пам’яті, ніж у вас є фізична оперативна пам’ять у машині. Тоді деякі дані будуть записані в простір swap.

Коли пізніша пам'ять звільняється, дані від swap автоматично не зчитуються в оперативну пам’ять: це відбувається лише тоді, коли дані в свопі фактично потрібні певному процесу. Це цілком нормально.

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

Ви також можете змінити таку поведінку sysctl -w vm.swappiness=10, що значно зменшить використання своп, поки це фактично не потрібно.

Що стосується MySQL, чи ви принаймні виконали тест конфігурації базової лінії за допомогою сценарію tuning-primer.sh ?

Це, мабуть, пояснив Девід, нормальна поведінка ядра Linux, але це також може бути проблемою проблеми "swap insanity" MySQL . У вашому випадку (8 процесора, всього 16 ГБ оперативної пам’яті, використано 5 ГБ), щоб це сталося, на вашому комп’ютері має бути система NUMA з 4 вузлами (сокетами) та 4 ГБ оперативної пам’яті на вузол та буферним пулом MySQL InnoDB 4 ГБ.

Якщо коротко (ви повинні прочитати посилання вище для отримання детальної інформації), ось що відбувається:

1. Коли система запускається, процеси поширюються на всі вузли NUMA, використовуючи частину їх пам'яті.
2. Коли MySQL запускається, він виділяє 4 Гб для буфера InnoDB, заповнюючи оперативну пам'ять вузла NUMA та використовуючи деяку оперативну пам'ять на інших вузлах.
3. Тоді ядро ​​Linux, яке не може перемістити виділену оперативну пам’ять з одного вузла NUMA на інший, вважає, що є гарною ідеєю поміняти сторінки з голодуваного вузла (або потрібно поміняти сторінки, тому що сторінки потрібно замінити).

Щоб уникнути цього, змініть розподіл пам'яті для MySQL, щоб розподілити оперативну пам'ять на всіх ядрах (див. Вищенаведене посилання для отримання більш детальної інформації).