Petang semalam, tiba-tiba saya menerima makluman e-mel daripada bahagian operasi dan penyelenggaraan, yang menunjukkan bahawa kadar penggunaan CPU pelayan platform data adalah setinggi 98.94%. Sejak kebelakangan ini, kadar penggunaan ini terus melebihi 70%. Pada pandangan pertama, nampaknya sumber perkakasan telah mencapai kesesakan dan perlu dikembangkan. Tetapi selepas memikirkannya dengan teliti, saya mendapati bahawa sistem perniagaan kami bukanlah aplikasi yang sangat serentak atau intensif CPU. Kadar penggunaan ini terlalu keterlaluan, dan kesesakan perkakasan tidak dapat dicapai dengan begitu cepat. Pasti ada masalah dengan logik kod perniagaan di suatu tempat.
2. Idea penyelesaian masalah
2.1 Cari pid proses beban tinggi
Mula-mula log masuk ke pelayan dan gunakan arahan teratas untuk mengesahkan situasi khusus pelayan, dan kemudian menganalisis dan menilai berdasarkan situasi tertentu.
Dengan memerhatikan purata beban dan piawaian penilaian beban (8 teras), ia boleh disahkan bahawa pelayan mempunyai beban yang tinggi
Memerhatikan penggunaan sumber setiap proses, kita dapat melihat bahawa proses dengan proses ID 682 mempunyai nisbah CPU yang lebih tinggi
2.2 Cari perniagaan luar biasa tertentu
Di sini kita boleh menggunakan perintah pwdx untuk mencari laluan proses perniagaan berdasarkan pid, dan kemudian mencari orang yang bertanggungjawab dan projek:
Boleh disimpulkan bahawa proses ini sepadan dengan perkhidmatan web platform data.
2.3 Cari benang tidak normal dan baris kod tertentu
Penyelesaian tradisional biasanya 4 langkah:
1. urutan teratas dengan dengan P: 1040 // Isih mengikut beban proses dahulu untuk mencari maxLoad(pid)
2 atas -Hp proses PID: 1073 // Cari PID beban yang berkaitan
3. printf “0x%x” Thread PID: 0x431 // Tukarkan thread PID kepada perenambelasan untuk bersedia untuk mencari log jstack nanti
4. proses jstack PID |.
Tetapi untuk lokasi masalah dalam talian, setiap detik penting, dan 4 langkah di atas masih terlalu rumit dan memakan masa, Oldratlee, yang memperkenalkan Taobao sebelum ini, merangkumkan proses di atas ke dalam alat: show-busy-java-threads.sh. Anda boleh mencari jenis masalah ini dengan mudah dalam talian:
Boleh disimpulkan bahawa CPU pelaksanaan kaedah alat masa dalam sistem adalah agak tinggi Selepas mengesan kaedah tertentu, semak sama ada terdapat masalah prestasi dalam logik kod.
※ Jika masalah dalam talian lebih mendesak, anda boleh meninggalkan 2.1 dan 2.2 dan terus melaksanakan 2.3 Analisis di sini adalah dari pelbagai sudut hanya untuk memberikan anda idea analisis yang lengkap.
3. Analisis punca akar
Selepas analisis dan penyelesaian masalah sebelum ini, kami akhirnya menemui masalah alat masa, yang menyebabkan beban pelayan yang berlebihan dan penggunaan CPU.
-
Logik kaedah pengecualian: adalah untuk menukar cap masa ke dalam format tarikh dan masa tertentu yang sepadan
-
Panggilan lapisan atas: Kira semua saat dari awal pagi hingga waktu semasa, tukarkannya ke dalam format yang sepadan dan masukkannya ke dalam set untuk mengembalikan hasilnya
-
Lapisan logik: Sepadan dengan logik pertanyaan laporan masa nyata platform data Laporan masa nyata akan datang pada selang masa tetap, dan akan terdapat berbilang (n) panggilan kaedah dalam satu pertanyaan.
Maka boleh disimpulkan bahawa jika masa semasa ialah pukul 10 pagi, bilangan pengiraan untuk satu pertanyaan ialah 106060n kali = 36,000n pengiraan, dan apabila masa bertambah, bilangannya pertanyaan tunggal menjadi lebih dekat ke tengah malam akan meningkat secara linear. Memandangkan sebilangan besar permintaan pertanyaan daripada modul seperti pertanyaan masa nyata dan penggera masa nyata memerlukan panggilan kaedah ini beberapa kali, sejumlah besar sumber CPU telah diduduki dan dibazirkan.
4
Selepas mengesan masalah, pertimbangan pertama ialah mengurangkan bilangan pengiraan dan mengoptimumkan kaedah pengecualian. Selepas penyiasatan, didapati bahawa apabila digunakan pada lapisan logik, kandungan koleksi set yang dikembalikan melalui kaedah ini tidak digunakan, tetapi nilai saiz set hanya digunakan. Selepas mengesahkan logik, mudahkan pengiraan melalui kaedah baru (saat semasa - saat pada awal pagi hari), gantikan kaedah yang dipanggil, dan selesaikan masalah pengiraan yang berlebihan. Selepas pergi ke dalam talian, kami memerhatikan beban pelayan dan penggunaan CPU Berbanding dengan tempoh masa yang tidak normal, beban pelayan dan penggunaan CPU menurun sebanyak 30 kali dan kembali normal Pada ketika ini, masalah telah diselesaikan.
![Petang semalam, saya tiba-tiba menerima amaran e-mel daripada bahagian operasi dan penyelenggaraan, menunjukkan bahawa kadar penggunaan CPU pelayan platform data adalah setinggi 98.94%. Sejak kebelakangan ini, kadar penggunaan ini terus melebihi 70%. Pada pandangan pertama, nampaknya sumber perkakasan telah mencapai kesesakan dan perlu dikembangkan. Tetapi selepas memikirkannya dengan teliti, saya mendapati bahawa sistem perniagaan kami bukanlah aplikasi yang sangat serentak atau intensif CPU. Kadar penggunaan ini terlalu keterlaluan dan kesesakan perkakasan tidak dapat dicapai dengan begitu cepat. Pasti ada masalah dengan logik kod perniagaan di suatu tempat.
2. Idea penyelesaian masalah
2.1 Cari pid proses beban tinggi
Mula-mula log masuk ke pelayan dan gunakan arahan teratas untuk mengesahkan situasi khusus pelayan, dan kemudian menganalisis dan menilai berdasarkan situasi tertentu.
Dengan memerhatikan purata beban dan piawaian penilaian beban (8 teras), ia boleh disahkan bahawa pelayan mempunyai beban yang tinggi
Memerhatikan penggunaan sumber setiap proses, kita dapat melihat bahawa proses dengan proses ID 682 mempunyai nisbah CPU yang lebih tinggi
2.2 Cari perniagaan luar biasa tertentu
Di sini kita boleh menggunakan perintah pwdx untuk mencari laluan proses perniagaan berdasarkan pid, dan kemudian mencari orang yang bertanggungjawab dan projek:
Boleh disimpulkan bahawa proses ini sepadan dengan perkhidmatan web platform data.
2.3 Cari benang tidak normal dan baris kod tertentu
Penyelesaian tradisional biasanya 4 langkah:
1. Susunan teratas mengikut P:
1040 // Isih mengikut beban proses dahulu untuk mencari maxLoad(pid)
2 atas -Hp proses PID:
1073 // Cari PID beban yang berkaitan
3. printf “0x%x” Thread PID:
0x431 // Tukarkan thread PID kepada perenambelasan untuk bersedia untuk mencari log jstack nanti
4. proses jstack PID |.
Tetapi untuk lokasi masalah dalam talian, setiap detik penting, dan 4 langkah di atas masih terlalu rumit dan memakan masa, Oldratlee, yang memperkenalkan Taobao sebelum ini, merangkumkan proses di atas ke dalam alat: show-busy-java-threads.sh. Anda boleh mencari jenis masalah ini dengan mudah dalam talian:
Boleh disimpulkan bahawa CPU pelaksanaan kaedah alat masa dalam sistem adalah agak tinggi Selepas mengesan kaedah tertentu, semak sama ada terdapat masalah prestasi dalam logik kod.
※ Jika masalah dalam talian adalah lebih mendesak, anda boleh meninggalkan 2.1 dan 2.2 dan terus melaksanakan 2.3 Analisis di sini adalah dari pelbagai sudut hanya untuk memberikan anda idea analisis yang lengkap.
3. Analisis punca akar
Selepas analisis dan penyelesaian masalah sebelum ini, kami akhirnya menemui masalah alat masa, yang menyebabkan beban pelayan yang berlebihan dan penggunaan CPU.
- Logik kaedah pengecualian: adalah untuk menukar cap masa ke dalam format tarikh dan masa tertentu yang sepadan
- Panggilan lapisan atas: Kira semua saat dari awal pagi hingga waktu semasa, tukarkannya ke dalam format yang sepadan dan masukkannya ke dalam set untuk mengembalikan hasilnya
- Lapisan logik: Sepadan dengan logik pertanyaan laporan masa nyata platform data Laporan masa nyata akan datang pada selang masa tetap, dan akan terdapat berbilang (n) panggilan kaedah dalam satu pertanyaan.
Maka boleh disimpulkan bahawa jika masa semasa ialah pukul 10 pagi, bilangan pengiraan untuk satu pertanyaan ialah 10
6060n kali = 36,000n pengiraan, dan apabila masa bertambah, bilangannya pertanyaan tunggal menjadi lebih dekat ke tengah malam akan meningkat secara linear. Memandangkan sebilangan besar permintaan pertanyaan daripada modul seperti pertanyaan masa nyata dan penggera masa nyata memerlukan panggilan kaedah ini beberapa kali, sejumlah besar sumber CPU telah diduduki dan dibazirkan.
4
Selepas mengesan masalah, pertimbangan pertama ialah mengurangkan bilangan pengiraan dan mengoptimumkan kaedah pengecualian. Selepas penyiasatan, didapati bahawa apabila digunakan pada lapisan logik, kandungan koleksi set yang dikembalikan melalui kaedah ini tidak digunakan, tetapi nilai saiz set hanya digunakan. Selepas mengesahkan logik, mudahkan pengiraan melalui kaedah baru (saat semasa - saat pada awal pagi hari), gantikan kaedah yang dipanggil, dan selesaikan masalah pengiraan yang berlebihan. Selepas pergi ke dalam talian, kami memerhatikan beban pelayan dan penggunaan CPU Berbanding dengan tempoh masa yang tidak normal, beban pelayan dan penggunaan CPU menurun sebanyak 30 kali dan kembali normal Pada ketika ini, masalah telah diselesaikan.
5
Semasa proses pengekodan, selain melaksanakan logik perniagaan, kita juga mesti menumpukan pada mengoptimumkan prestasi kod. Keupayaan untuk merealisasikan keperluan perniagaan dan keupayaan untuk mencapainya dengan lebih cekap dan lebih elegan sebenarnya adalah dua manifestasi yang sama sekali berbeza kebolehan dan alam jurutera, dan yang terakhir juga merupakan daya saing teras jurutera.
Selepas kod ditulis, lakukan lebih banyak ulasan dan fikirkan lebih lanjut sama ada ia boleh dilaksanakan dengan cara yang lebih baik.
Jangan terlepas sebarang butiran kecil dalam soalan dalam talian! Perincian adalah syaitan pelajar teknikal perlu mempunyai kehausan untuk ilmu dan semangat mengejar kecemerlangan Hanya dengan cara ini mereka boleh terus berkembang dan bertambah baik. -
Atas ialah kandungan terperinci Biar saya pergi, CPU sistem Linux 100% penuh!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!