Mengapa Swap digunakan ketika banyak memori kosong yang tersisa?

35

Saya memiliki server web (khusus) yang cukup bagus dengan sumber daya memori yang baik:

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)

Seperti yang Anda lihat, server saya menggunakan swap ketika ada banyak memori bebas yang tersedia.

Apakah ini normal atau ada yang salah dengan konfigurasi atau pengkodeannya?

NB
Proses MySQL saya menggunakan lebih dari 160% daya CPU untuk beberapa alasan; Saya tidak tahu mengapa, tetapi saya tidak memiliki lebih dari 70 pengguna secara bersamaan ...

linux mysql php

— pengguna1179459
sumber

Aplikasi dapat menggunakan lebih dari 100% CPU di Linux? Erm ...

— BlueRaja

5

@BlueRaja: Ya, karena di Linux penggunaan CPU diukur relatif terhadap satu CPU, tidak semua CPU di sistem Anda. Jadi di mesin dengan 8 CPU, Anda memiliki maksimum 800% CPU yang tersedia.

— Daniel Pryden

Apa versi MySQL yang Anda gunakan ???

— RolandoMySQLDBA

@RolandoMySQLDBA versi 5.5

— user1179459

61

Ini sangat normal.

Pada startup sistem, sejumlah layanan mulai. Layanan ini menginisialisasi diri mereka sendiri, membaca file konfigurasi, membuat struktur data dan sebagainya. Mereka menggunakan beberapa memori. Banyak dari layanan ini tidak akan pernah berjalan lagi selama sistem dinyalakan karena Anda tidak menggunakannya. Beberapa dari mereka dapat berjalan dalam hitungan jam, hari, atau minggu. Namun semua data ini ada dalam memori fisik.

Tentu saja, sistem tidak dapat membuang data ini. Itu tidak dapat membuktikan bahwa itu benar-benar tidak akan pernah diakses. Salah satu layanan itu, misalnya, mungkin adalah layanan yang memberi Anda akses jarak jauh ke kotak. Anda mungkin tidak menggunakannya dalam seminggu, tetapi jika Anda menggunakannya, itu berfungsi lebih baik.

Tetapi sistem tahu bahwa itu mungkin suka menggunakan memori fisik itu untuk hal-hal seperti cache disk atau dengan cara lain yang akan meningkatkan kinerja. Jadi itu bertukar oportunistik. Ketika tidak ada yang lebih baik untuk dilakukan, ia menulis data yang belum pernah digunakan dalam waktu yang lama untuk disk, menggunakan ruang swap. Namun, masih menyimpan halaman dalam memori fisik. Jadi mereka masih dapat diakses tanpa harus menukar mereka.

Sekarang, jika sistem nanti membutuhkan memori fisik untuk sesuatu yang lain, ia dapat dengan mudah membuang halaman-halaman itu karena telah menulisnya untuk ditukar. Ini memberikan sistem yang terbaik dari kedua dunia. Data masih disimpan dalam memori, sehingga dapat diakses tanpa harus membacanya dari disk. Tetapi jika sistem membutuhkan memori itu untuk tujuan lain, ia tidak perlu menuliskannya terlebih dahulu. Kemenangan besar di sekitar.

— David Schwartz
sumber

Jika demikian, tolong jelaskan mengapa terkadang ruang swap tidak digunakan sama sekali. Mem: 49554484k total, 4087592k digunakan, 45466892k gratis, 349244k buffer Tukar: 94204k total, 0k digunakan, 94204k gratis, 1113644k di-cache

— ananthan

4

@ Alananthan: Mungkin ada banyak alasan. Yang paling mungkin adalah bahwa sistem tidak pernah berada di bawah tekanan memori sama sekali, bahkan karena penulisan buffer, sehingga kode swap oportunistik mungkin tidak pernah dipicu. Bisa juga seseorang berpikir bahwa penggunaan swap buruk dan sistemnya tidak disetel untuk tidak bertukar secara oportunis (dengan mengurangi swappiness ).

— David Schwartz

6

Ini bisa terjadi jika pada suatu waktu di masa lalu Anda membutuhkan lebih banyak memori daripada RAM fisik di mesin. Pada saat itu beberapa data akan ditulis ke ruang swap.

Ketika memori kemudian dibebaskan, data dari swap tidak secara otomatis dibaca kembali ke dalam RAM: ini hanya terjadi ketika data dalam swap sebenarnya diperlukan oleh beberapa proses. Ini sangat normal.

Adapun proses mysql Anda: ini semua tergantung pada jenis kueri yang Anda jalankan. Dalam teori 2, kueri yang sangat kompleks mungkin cukup untuk mendapatkan beban seperti itu, terlepas dari jumlah pengguna Anda. Anda bisa mengaktifkan log kueri lambat untuk mendapatkan lebih banyak wawasan tentang kueri mana yang memuat banyak.

— otak99
sumber

Tidak - penggunaan swap bukan tanda air tinggi. Ketika halaman yang ditukar dipetakan kembali halaman disk ditandai sebagai tidak digunakan (tetapi mungkin masih berisi data).

— symcbean

Saya hanya menyebutkan satu skenario di mana Anda dapat menggunakan swap, tetapi ini memang tidak selalu merupakan gejala tidak memiliki cukup memori fisik - seperti juga dijelaskan oleh David Schwartz di atas

— brain99

3

Anda juga dapat mengubah perilaku ini dengan sysctl -w vm.swappiness=10, yang akan sangat mengurangi penggunaan swap sampai benar-benar dibutuhkan.

Sedangkan untuk MySQL, apakah Anda setidaknya melakukan tes konfigurasi dasar menggunakan skrip tuning-primer.sh ?

— Daemon of Chaos
sumber

1

Ini akan meningkatkan kecenderungan cache / buffer untuk direklamasi. Sayangnya tidak jelas dari pertanyaan awal apakah angka 29,53% termasuk buffer / cache - jika tidak, maka membuat perubahan yang Anda suggeast akan berdampak buruk pada kinerja. Jika dbms ini menggunakan innodb secara luas, maka itu mungkin telah dikonfigurasi dengan buruk (walaupun kotak 8 core 16gb tunggal untuk digunakan sebagai server web adalah pilihan deisgn BAD untuk memulai)

— symcbean

mengapa Anda mengatakan itu pilihan yang buruk untuk server web? saya tidak menggunakan innodb, saya masih lebih suka myisam karena bacaan saya adalah 70% dan hanya menulis 30% ....

— user1179459

1

Ini mungkin, seperti yang dijelaskan David, perilaku normal dari Kernel Linux, tetapi bisa juga merupakan masalah MySQL “swap insanity” . Dalam kasus Anda (8 CPU, total 16 GB RAM, 5 GB digunakan), untuk itu, komputer Anda harus menjadi sistem NUMA dengan 4 node (soket) dan 4 GB RAM per node dan kumpulan buffer MySQL InnoDB dari 4 GB

Singkatnya (Anda harus membaca tautan di atas untuk rincian lengkap), inilah yang terjadi:

Ketika sistem Anda mulai, proses tersebar di semua NUMA node menggunakan sebagian dari memori mereka.
Ketika MySQL dimulai, ia mengalokasikan 4 GB untuk pool buffer InnoDB, mengisi RAM dari NUMA node dan menggunakan beberapa RAM pada node lain.
Kemudian, kernel Linux, yang tidak dapat memindahkan RAM yang dialokasikan dari satu NUMA node ke yang lain, berpikir itu ide yang baik untuk bertukar halaman dari node yang kelaparan (atau perlu bertukar halaman karena halaman perlu ditukar).

Untuk menghindarinya, ubah alokasi memori untuk MySQL untuk mengalokasikan RAM pada semua core (lihat tautan di atas untuk lebih jelasnya).

— jfg956
sumber