Fail Swap Yang Hilang Yang Membekukan Pelayan Kami

Pada 24 September, salah satu pelayan pengeluaran kami berhenti menjawab. Pengimbang beban menandakannya sebagai tidak sihat dan alat arahan jauh kami tidak dapat mencapainya, tetapi tiada apa yang ranap dan tiada apa yang dibunuh kerana menggunakan terlalu banyak memori. Pelayan itu sedang thrashing: tanpa ruang swap dan dengan kontena dibenarkan menggunakan lebih banyak memori daripada yang ada pada mesin, Linux menghabiskan masanya mengusir dan membaca semula fail yang diperlukannya untuk berjalan, dan hampir tidak membuat kemajuan. Menambah fail swap 2 GB pada setiap pelayan menyelesaikannya. Pengajaran yang lebih menarik adalah tentang pemeriksaan kesihatan.

Rupa "tergantung"

• Pemeriksaan kesihatan pengimbang beban tamat masa pada pelayan itu.
• Arahan yang dihantar melalui AWS Systems Manager kekal dalam status "Pending" dan tidak pernah dijalankan.
• Tiada kill kehabisan memori dalam log. Tiada proses yang mati.

Seminggu sebelum itu kami memindahkan pengeluaran ke pelayan ARM yang lebih kecil dengan 2 GB RAM setiap satu. Pelayan staging kami, yang lebih kecil lagi, pernah beku dengan cara yang sama semasa menyahmampat imej kontena semasa penerbitan.

Mengapa tiada ralat memori?

Linux hanya membunuh proses apabila ia benar-benar kehabisan memori yang boleh dituntut semula. Sebelum tahap itu, ia menuntut semula memori daripada cache halaman, iaitu salinan fail yang disimpannya dalam RAM, termasuk kod setiap program yang sedang berjalan.

Pada pelayan kami, jumlah had memori kontena menambah sehingga kira-kira 3.3 GB pada mesin dengan kira-kira 1.8 GB yang boleh digunakan. Biasanya mereka tidak menggunakan had penuh mereka serentak. Apabila mereka berbuat demikian, kernel terus mengusir kod program daripada cache untuk memberi ruang, dan kemudian perlu membacanya semula dari cakera sebaik sahaja kod itu berjalan lagi. Kitaran itu, iaitu thrashing, boleh menjadikan mesin hampir sepenuhnya tidak responsif sambil ia secara teknikal tidak pernah kehabisan memori. Maka tiada apa yang dibunuh, dan tiada apa yang pulih.

Tanpa swap, kernel tidak mempunyai tempat untuk meletakkan memori yang diperuntukkan tetapi jarang digunakan, jadi ia terpaksa mengambilnya daripada cache.

Pembetulan

Skrip bootstrap pelayan kini mencipta fail swap 2 GB dengan tetapan swappiness yang rendah (10) setiap kali pelayan dihidupkan atau dibaiki. Swappiness yang rendah bermakna kernel masih lebih suka menyimpan memori kerja dalam RAM, tetapi halaman yang jarang disentuh boleh dipindahkan ke cakera dan bukannya memaksa kod program keluar dari cache. Kami memohonnya secara langsung pada kedua-dua pelayan pengeluaran dan staging, dan saluran penerbitan menerbitkan semula skrip bootstrap pada setiap penerbitan pengeluaran supaya pelayan yang digantikan turut mendapatnya.

Bahagian yang lebih membimbangkan kami: pelayan yang tidak sihat itu kekal

Kumpulan pelayan kami menggunakan pemeriksaan kesihatan EC2, iaitu "adakah mesin sedang berjalan?", dan bukannya pemeriksaan kesihatan pengimbang beban, iaitu "adakah ia menjawab permintaan?". Maka pelayan yang telah diabaikan oleh pengimbang beban masih dianggap sihat oleh kumpulan. Ia tidak akan pernah digantikan. Pengeluaran akan berjalan secara senyap pada satu pelayan sahaja sehingga seseorang perasan dan memulakan semula yang satu lagi.

Menukar kumpulan kepada pemeriksaan kesihatan pengimbang beban kelihatan seperti pembetulan yang jelas, tetapi bagi kami ia tidak mudah: semasa penerbitan, pelayan sengaja menjawab titik kesihatan mereka dengan ralat supaya pengimbang mengeluarkan mereka dari edaran (lihat bagaimana kami mencapai penerbitan dengan sifar 502). Kumpulan yang menggantikan pelayan berdasarkan isyarat itu akan menggantikannya di tengah-tengah setiap penerbitan.

Jadi buat masa ini kami menambah satu langkah pada senarai semak penerbitan kami: selepas setiap penerbitan, semak kesihatan setiap sasaran pada pengimbang beban, bukan sekadar sama ada tugas penerbitan lulus. Jika arahan kepada sesuatu pelayan kekal dalam status "Pending", pelayan itu sedang thrashing. Mulakan semula; ia sudah berada di luar edaran.

Apa yang kami pelajari daripadanya

• "Tidak ranap" bukan "sihat". Thrashing tidak menghasilkan ralat, hanya kelembapan yang begitu melampau sehingga mesin berhenti menjawab.
• Pelayan kecil memerlukan swap. Walaupun sedikit, dengan swappiness yang rendah, ia memberi kernel tempat untuk meletakkan memori yang sejuk.
• Had memori yang berjumlah lebih daripada mesin ialah satu pertaruhan. Kadangkala anda kalah. Ketahui bila anda telah membuatnya.
• Ketahui pemeriksaan kesihatan mana yang dipercayai oleh auto-skala anda. Pemeriksaan kesihatan yang hanya bertanya "adakah VM dihidupkan?" tidak akan menggantikan pelayan yang telah berhenti berfungsi.