Apakah yang perlu saya lakukan jika CPU perkhidmatan nod terlalu tinggi? Mari bercakap tentang idea penyelesaian masalah

nod Apakah yang perlu saya lakukan jika CPU perkhidmatan terlalu tinggi? Bagaimana untuk menyemak? Artikel berikut akan menyelesaikan dan berkongsi dengan anda idea penyelesaian masalah untuk CPU perkhidmatan nod yang terlalu tinggi. Saya harap ia akan membantu anda!

Bantu rakan sekerja melihat masalah CPU yang berlebihan

• CPU tidak boleh turun selepas ia meningkat Akhirnya, rakan sekerja mengetahui bahawa ia adalah peningkatan pergantungan Konfigurasi redis awam lalai adalah di luar talian selepas versi utama (projek itu sudah lama dan tidak disentuh untuk masa yang lama), tetapi pihak perniagaan perlu mengkonfigurasi dan menutup perkhidmatan redis itu sendiri. kod. Bahagian perniagaan mempunyai jurang maklumat, jadi mereka tidak tahu untuk menutup redis, yang menyebabkan mereka terus mencuba semula untuk menyambung ke redis selepas pergi dalam talian (satu permintaan lagi bermakna satu lagi cuba)

Akhirnya , kami meringkaskan idea penyelesaian masalah seperti berikut , dialu-alukan untuk menambah

Idea penyelesaian masalah

0 Mulakan semula contoh masalah boleh diselesaikan dengan memulakan semula contoh.

Mulakan semula instance dahulu. Ini adalah langkah yang perlu untuk menyediakan perkhidmatan terlebih dahulu. Jika CPU berikutnya masih melonjak terlalu cepat, anda mungkin perlu mempertimbangkan untuk melancarkan semula kod tersebut terlebih dahulu. Jika lonjakan tidak pantas, anda boleh menyelesaikan masalah secepat mungkin tanpa melancarkan semula

1 untuk menentukan sama ada ia disebabkan oleh proses nod

Arahan 1:

Boleh didapati bahawa proses nod utama sedang menduduki CPU. [Cadangan tutorial berkaitan: toptutorial video nodejs

]

• Arahan 2:

  [root@*** ~]# top
  
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                     
  680 root      20   0 2290976 168176  34976 S  30.3  2.0 103:42.59 node                                                                                                                        
  687 root      20   0 2290544 166920  34984 R  26.3  2.0  96:26.42 node                                                                                                                        
   52 root      20   0 1057412  23972  15188 S   1.7  0.3  11:25.97 ****                                                                                                           
  185 root      20   0  130216  41432  25436 S   0.3  0.5   1:03.44 ****                                                                                                         
  ...

Pertama lihat pada arahan vmstat 2, yang bermaksud Dikumpul setiap dua saat vmstat

procs

[root@*** ~]# vmstat 2
procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu-----
 r  b      swpd  free   buff   cache      si   so    bi    bo   in cs   us sy id wa st
 0  0      0 233481328 758304 20795516    0    0     0     1    0    0  0  0 100  0  0
 0  0      0 233480800 758304 20795520    0    0     0     0  951 1519  0  0 100  0  0
 0  0      0 233481056 758304 20795520    0    0     0     0  867 1460  0  0 100  0  0
 0  0      0 233481408 758304 20795520    0    0     0    20  910 1520  0  0 100  0  0
 0  0      0 233481680 758304 20795520    0    0     0     0  911 1491  0  0 100  0  0
 0  0      0 233481920 758304 20795520    0    0     0     0  889 1530  0  0 100  0  0

r #Mewakili baris gilir yang sedang berjalan (iaitu, berapa banyak proses yang sebenarnya diperuntukkan kepada CPU ), Apabila nilai ini melebihi bilangan CPU, kesesakan CPU akan berlaku. Ini juga berkaitan dengan beban atas Secara amnya, jika beban melebihi 3, ia agak tinggi, jika melebihi 5, ia adalah tinggi, jika melebihi 10, ia tidak normal, dan status pelayan sangat berbahaya. . Muatan atas adalah serupa dengan baris gilir larian sesaat. Jika baris gilir larian terlalu besar, ini bermakna CPU anda sangat sibuk, yang biasanya mengakibatkan penggunaan CPU yang tinggi.

• b #Menunjukkan proses yang disekat, proses menunggu sumber Saya tidak akan bercakap banyak tentang perkara ini, tetapi semua orang tahu bahawa proses itu disekat.

  memori

swpd #Saiz memori maya yang digunakan Jika lebih daripada 0, ini bermakna memori fizikal mesin anda tidak mencukupi punca kebocoran memori program, maka Sudah tiba masanya untuk menaik taraf memori atau memindahkan tugas yang memakan memori ke mesin lain.

• percuma # Saiz memori fizikal percuma

  sistem buff #Linux/Unix digunakan untuk menyimpan kandungan direktori, kebenaran, dll. cache

  cache #cache Ia digunakan secara langsung untuk mengingati fail yang kami buka, menampan fail, dan menggunakan sebahagian daripada memori fizikal percuma untuk menyimpan fail dan direktori untuk meningkatkan prestasi pelaksanaan program Apabila program menggunakan memori, penimbal/cache akan menjadi sangat cepat tanah digunakan.

  tukar

si #Saiz memori maya dibaca dari cakera sesaat Jika nilai ini lebih besar daripada 0, ini bermakna memori fizikal tidak cukup atau ingatan bocor Anda perlu mencarinya Selesaikan proses yang memakan memori. Mesin saya mempunyai banyak memori dan semuanya berfungsi dengan baik.

• jadi #Saiz memori maya yang ditulis ke cakera sesaat Jika nilai ini lebih besar daripada 0, sama seperti di atas.

  io

bi #Bilangan blok yang diterima oleh peranti blok sesaat merujuk kepada semua cakera dan peranti blok lain pada sistem saiz blok lalai ialah 1024bait

• bo #Bilangan blok yang dihantar oleh peranti blok sesaat Contohnya, apabila kita membaca fail, bo mestilah lebih daripada 0. Bi dan bo biasanya hampir kepada 0, jika tidak, IO terlalu kerap dan perlu dilaraskan.

  sistem

dalam #Bilangan gangguan CPU sesaat, termasuk gangguan masa

• cs #Bilangan suis konteks sesaat, seperti apabila kita memanggil fungsi sistem , penukaran konteks, penukaran utas dan penukaran konteks proses diperlukan.

  cpu
  kami masa CPU #Pengguna Saya menggunakan pelayan yang kerap melakukan penyulitan dan penyahsulitan ujian dan prestasinya adalah lemah) .
  sy #System CPU time, kalau terlalu tinggi maknanya masa system call panjang, seperti IO operation yang kerap.
• id #Masa CPU Terbiar, secara amnya, id us sy = 100, secara amnya saya rasa id ialah penggunaan CPU terbiar, kami ialah penggunaan CPU pengguna, dan sy ialah penggunaan CPU sistem.
  wt #Menunggu masa CPU IO.
  Amalan

  procs r: Terdapat banyak proses yang sedang berjalan dan sistem sangat sibuk
  bi/bo: Jumlah data yang ditulis pada cakera adalah lebih besar sedikit. Pada asasnya tidak perlu risau. Jika ia adalah fail kecil, ia sepatutnya berada dalam 2M pada asasnya
  cpu kami: Lebih besar daripada 50% secara berterusan, boleh diterima semasa tempoh perkhidmatan puncak masa, pengoptimuman boleh dipertimbangkan
  cpu sy: Peratusan proses kernel sebenar, nilai rujukan kami sy di sini ialah 80% , jika kami sy lebih besar daripada 80%, bermakna mungkin CPU tidak mencukupi.
  Lajur cpu wa: menunjukkan peratusan masa CPU yang diduduki oleh IO menunggu. Nilai rujukan wa di sini ialah 30%. Jika wa melebihi 30%, ini bermakna penantian IO adalah serius Ini mungkin disebabkan oleh banyak akses rawak ke cakera, atau ia mungkin disebabkan oleh kesesakan lebar jalur cakera atau pengawal capaian cakera (terutamanya menyekat operasi)

Pautan rujukan: https://www.cnblogs.com/zsql/p/11643750.html

2. Lihat perbezaan kod

Jika memulakan semula instance masih tidak menyelesaikan masalah, dan ia ditentukan bahawa masalahnya adalah dengan proses nod,

Semak komit dalam talian dan semak perbezaan kod untuk melihat sama ada masalah boleh ditemui Klik

3 Buka pemprofil CPU masa jalan

Kaedah operasi ini sama seperti artikel saya yang lainCara mencari kebocoran memori pelayan SSR dengan cepat Masalahnya adalah serupa dengan

• Gunakan nod - -periksa untuk memulakan perkhidmatan

• untuk mensimulasikan persekitaran dalam talian secara setempat dan gunakan binaan Selepas kod, binaan langsung mungkin tidak boleh digunakan Kawal pembolehubah persekitaran dan matikan mampatan hodoh

  • Sebagai contoh, biarkan beberapa pembolehubah persekitaran (nama domain CDN, dll.) menghala ke Setempat, kerana pakej itu setempat dan tidak dimuat naik ke CDN

• Jana pemprofil CPU

Bagaimana jika persekitaran dalam talian tidak boleh disimulasikan secara setempat?

Sebagai contoh, jika RPC hiliran diasingkan daripada tempatan, maka anda hanya boleh menambah kod dan membuat profil nodejs.org/docs/latest…

Selepas mendapat fail profil, buka dengan chrome devtool

4. Analyze CPU profiler

• Gunakan profiler dan code diff untuk mencari punca

• Anda juga boleh memuat naik fail profil ke www. speedscope.app/ (Muat naik fail), anda boleh mendapatkan graf nyala profil cpu (pengenalan penggunaan yang lebih terperinci: www.npmjs.com/package/spe...

5. Pengesahan ujian tekanan

Anda boleh menggunakan ab, atau alat ujian tekanan lain

Ringkasan

• Mulakan semula kejadian

• Pastikan ia disebabkan oleh proses nod

• Lihat perbezaan kod

• Jana pemprofil CPU masa jalan

• Pemprofil gabungan dan perbezaan kod untuk mencari punca

• Pengesahan ujian tekanan

Untuk lebih banyak pengetahuan berkaitan nod, sila lawati: tutorial nodejs!

Atas ialah kandungan terperinci Apakah yang perlu saya lakukan jika CPU perkhidmatan nod terlalu tinggi? Mari bercakap tentang idea penyelesaian masalah. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!