Analisis contoh kegagalan pelayan

1. Ada masalah

Memandangkan kita berada dalam industri IT, kita perlu menghadapi kegagalan dan masalah setiap hari, jadi kita boleh dipanggil bomba, berlari-lari untuk menyelesaikan masalah. Walau bagaimanapun, skop kerosakan kali ini agak besar, dan mesin hos tidak boleh dibuka.

Nasib baik, sistem pengawasan meninggalkan beberapa bukti.

Bukti mendapati bahawa CPU, memori dan pemegang fail mesin terus meningkat dengan pertumbuhan perniagaan... sehingga pemantauan tidak dapat mengumpul maklumat.

Apa yang menyedihkan ialah terdapat banyak proses Java yang digunakan pada hos ini. Atas sebab lain selain untuk menjimatkan kos, permohonan itu bercampur-campur. Apabila hos mempamerkan anomali keseluruhan, sukar untuk mencari puncanya.

Memandangkan log masuk jauh telah tamat tempoh, kakitangan operasi dan penyelenggaraan yang tidak sabar hanya boleh memilih untuk memulakan semula mesin dan mula memulakan semula aplikasi selepas dimulakan semula. Selepas menunggu lama, semua proses kembali kepada operasi normal, tetapi selepas hanya dalam tempoh yang singkat, mesin hos tiba-tiba terhempas.

Perniagaan telah berada dalam keadaan merosot, yang benar-benar menjengkelkan. Ia juga membuatkan orang ramai cemas. Selepas beberapa percubaan, operasi dan penyelenggaraan runtuh, dan pelan kecemasan dilancarkan: Kembalikan

Terdapat banyak rekod dalam talian terkini, dan terdapat pembangun yang pergi ke dalam talian dan digunakan secara peribadi keliru: yang mana satu?

find /apps/deploy -mtime +3 | grep jar$

Jika anda tidak tahu arahan cari, ia benar-benar bencana. Nasib baik ada yang tahu.

Saya melancarkan sedozen pakej balang Mujurlah, saya tidak menemui sebarang perubahan skema pangkalan data, dan sistem akhirnya berjalan seperti biasa.

2. Cari sebabnya

Tiada cara lain, semak log dan jalankan semakan kod.

Untuk memastikan kualiti kod, skop semakan kod hendaklah dihadkan kepada perubahan kod dalam 1 atau 2 minggu lepas, kerana sesetengah kod berfungsi memerlukan masa tertentu untuk matang sebelum ia boleh bersinar dalam talian.

Melihat rekod penyerahan "OK" memenuhi skrin, wajah pengurus teknikal bertukar menjadi hijau.

"xjjdog berkata, "80% pengaturcara tidak boleh menulis rekod komit", saya rasa 100% daripada anda tidak boleh menulisnya."

Semua orang diam, menahan kesakitan dan menyemak perubahan sejarah. Selepas usaha tanpa henti semua orang, kami akhirnya menemui beberapa kod bermasalah di pergunungan najis. Kumpulan yang dicipta oleh CxO sendiri, dan semua orang membuang kod yang boleh menyebabkan masalah ke dalamnya.

"Perkhidmatan sistem telah terganggu selama hampir sejam, dan kesannya sangat teruk." >okokok, dengan Nail Dengan bantuan paku, gerak isyarat semua orang menjadi seragam.

3. Parameter kumpulan benang

Terdapat banyak kod, dan semua orang telah lama membincangkan kod yang bermasalah. Ayat ini boleh ditulis semula seperti berikut: Kami memeriksa beberapa kod kompleks menggunakan aliran selari dan bersarang dalam ungkapan lambda, memberi perhatian khusus kepada penggunaan kumpulan benang.

Akhirnya, semua orang memutuskan untuk menyemak semula kod kumpulan benang. Salah satu petikan mengatakan ini.

RejectedExecutionHandler handler = new ThreadPoolExecutor.DiscardOldestPolicy(); ThreadPoolExecutor executor = new ThreadPoolExecutor(100,200,                 60000,                 TimeUnit.MILLISECONDS,                 new LinkedBlockingDeque(10),                 handler);

Apatah lagi, parameternya adalah baik, malah strategi penolakan juga dipertimbangkan.

Kolam benang Java menjadikan pengaturcaraan sangat mudah. Parameter ini tidak boleh disemak tanpa melaluinya satu demi satu, seperti yang ditunjukkan dalam imej di atas.

corePoolSize: bilangan utas teras, utas teras akan bertahan selepas penciptaan
maxPoolSize: bilangan maksimum utas

• pengendali: strategi penolakan

• Yang berikut akan memperkenalkan hubungan mereka.
• Jika bilangan utas kurang daripada bilangan utas teras dan tugasan baharu tiba, sistem akan mencipta utas baharu untuk mengendalikan tugas itu. Jika bilangan utas semasa melebihi bilangan utas teras dan baris gilir menyekat tidak penuh, tugas akan diletakkan dalam baris gilir menyekat. Apabila bilangan utas lebih besar daripada bilangan utas teras dan baris gilir menyekat penuh, utas baharu akan dibuat untuk disiarkan sehingga bilangan utas mencapai saiz maksimumPoolSize. Pada masa ini, jika terdapat tugasan baharu, dasar penolakan akan dicetuskan.
  Mari kita bincangkan lagi tentang strategi penolakan. JDK mempunyai 4 dasar terbina dalam, yang lalai ialah AbortPolicy, yang secara langsung memberikan pengecualian. Beberapa yang lain diperkenalkan di bawah.

• DiscardPolicy lebih agresif daripada membatalkan tugas secara langsung tanpa maklumat pengecualian

• Pemprosesan tugasan dilakukan oleh urutan panggilan. Inilah Cara CallerRunsPolicy dilaksanakan. Apabila sumber kumpulan benang bagi aplikasi web penuh, tugas baharu akan diberikan kepada benang Tomcat untuk dilaksanakan. Dalam sesetengah kes, kaedah ini boleh mengurangkan tekanan pelaksanaan beberapa tugasan, tetapi dalam lebih banyak kes, ia akan menyekat secara langsung jalan utas utama

DiscardOldestPolicy membuang bahagian hadapan tugasan baris gilir , dan kemudian cuba laksanakan tugas sekali lagi

Kod kumpulan benang ini baru ditambahkan, dan tetapan parameter juga munasabah, dan tiada masalah besar. Menggunakan dasar penolakan DiscardOldestPolicy adalah satu-satunya risiko yang mungkin. Apabila terdapat banyak tugasan, dasar penolakan ini akan menyebabkan tugasan beratur dan permintaan tamat masa.

• Sudah tentu kita tidak boleh melepaskan risiko ini Sejujurnya, ia adalah kod risiko yang paling mungkin ditemui setakat ini.

  "Tukar DiscardOldestPolicy kepada AbortPolicy lalai, bungkus semula dan cuba dalam talian." Guru teknikal berkata dalam kumpulan.

  4. Apakah masalahnya?

  Akibatnya, selepas perkhidmatan skala kelabu dilancarkan, tuan rumah meninggal dunia tidak lama kemudian. Sebab tak lari, tapi kenapa?

  Saiz kolam benang, minimum 100, maksimum 200, tiada yang terlalu banyak. Kapasiti baris gilir menyekat hanya 10, jadi tiada apa yang akan menyebabkan masalah. Jika anda mengatakan ia disebabkan oleh kumpulan benang ini, saya tidak akan percaya anda walaupun sampai mati.

  Tetapi jabatan perniagaan melaporkan bahawa jika kod ini ditambah, ia akan mati, tetapi jika ia tidak ditambah, ia tidak mengapa. Pakar teknikal menggaru kepala dan tertanya-tanya tentang adiknya.

  Akhirnya, seseorang akhirnya tidak dapat menahannya lagi dan memuat turun kod perniagaan untuk nyahpepijatnya.

  Apabila dia membuka Idea, dia keliru dan faham serta-merta. Dia akhirnya faham mengapa kod ini menyebabkan masalah.

  

  Kolam benang sebenarnya dicipta dalam kaedah!

  Apabila setiap permintaan datang, ia akan mencipta kumpulan benang sehingga sistem dimulakan semula Sumber tidak boleh diperuntukkan .

  Sungguh mendominasi.

  Semua orang memberi perhatian kepada cara parameter kumpulan benang ditetapkan, tetapi tiada siapa yang pernah meragui lokasi kod ini.

Atas ialah kandungan terperinci Analisis contoh kegagalan pelayan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!