Günlük blog | Aşırı CPU% 100 ve Tam GC süreleri için sorun giderme
Çevrimiçi problemlerle uğraşan öğrenciler temelde ani yavaş sistem çalışması,% 100 CPU ve aşırı Tam GC süreleri problemleriyle karşılaşacaklardır. Tabii ki, bu sorunların sonuçta yol açtığı sezgisel fenomen, sistemin yavaş çalışması ve çok sayıda alarm olmasıdır. Bu makale, sistemin yavaş çalışması sorununa odaklanır ve sorunun kod noktasını bulmak için sorun için sorun giderme fikirleri sağlar ve ardından sorunu çözmek için fikirler sunar.
Çevrimiçi sistemin aniden yavaş çalışması sorunu için, sorun çevrimiçi sistemin kullanılamaz hale gelmesine neden olursa, yapılacak ilk şey jstack ve bellek bilgilerini dışa aktarmak ve ardından sistemin mümkün olan en kısa sürede kullanılabilirliğini sağlamak için sistemi yeniden başlatmaktır. Bu durumun iki ana nedeni var:
- Koddaki belirli bir konum büyük miktarda veri okur, bu da sistem belleğinin tükenmesine yol açar, bu da çok fazla Tam GC süresine ve yavaş sisteme yol açar;
- Kodda daha fazla CPU tüketen, CPU'nun çok yüksek olmasına ve sistemin yavaş çalışmasına neden olan işlemler vardır;
Nispeten konuşursak, bunlar en sık görülen iki çevrimiçi sorundur ve doğrudan sistemin kullanılamamasına neden olurlar. Ek olarak, bir işlevin yavaş çalışmasına neden olabilecek, ancak sistemin kullanılamaz olmasına neden olmayacak birkaç durum vardır:
- Kodun belirli bir konumunda engelleme işlemleri vardır, bu da işlev çağrısının bir bütün olarak daha fazla zaman almasına neden olur, ancak görünüm daha rastgele olur;
- Bir iş parçacığı, bazı nedenlerden dolayı BEKLEME durumuna giriyor Şu anda, işlev bir bütün olarak mevcut değildir, ancak yeniden üretilemez;
- Kilitlerin yanlış kullanımı nedeniyle, birden çok iş parçacığı bir kilitlenme durumuna girerek genel olarak daha yavaş bir sisteme neden olur.
Bu üç durum için, CPU ve sistem belleği koşullarını kontrol ederek belirli sorunları bulmak imkansızdır, çünkü bunlar nispeten engelleyici işlemlerdir, CPU ve sistem belleği kullanımı yüksek değildir, ancak işlevler çok yavaştır. Aşağıda, yukarıda belirtilen sorunları adım adım belirlemek için sistem günlüğünü kontrol edeceğiz.
1. Çok fazla Tam GC süresi
Nispeten konuşursak, bu durumun özellikle yeni özellikler çevrimiçi olduğunda ortaya çıkması daha olasıdır. Daha fazla Tam GC durumu için, esas olarak aşağıdaki iki özelliğe sahiptir:
- Satırdaki birden çok iş parçacığının CPU'su% 100'ü aşıyor. Jstack komutu aracılığıyla, bu iş parçacıklarının çoğunlukla çöp toplama iş parçacıkları olduğunu görebilirsiniz.
- GC durumunu izlemek için jstat komutu aracılığıyla, Tam GC sayısının çok büyük olduğunu ve sayının arttığını görebilirsiniz.
İlk olarak, sistem CPU kullanımını görüntülemek için top komutunu kullanabiliriz.Aşağıda daha yüksek bir sistem CPU'su örneği verilmiştir:
üst-08: 31: 1030 dk yukarı, 0 kullanıcı, yükleme ortalaması: 0.73, 0.58, 0.34 KiB Mem: 2046460 toplam, 1923864 kullanılmış, 122596 boş, 14388 tampon KiB Swap: 1048572 toplam, 0 kullanılmış, 1048572 ücretsiz. 1192352 önbelleğe alınmış Mem PID KULLANICI PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND 9 kök 200 255716028897615812 S 98.014.10: 42.60 javaGördüğünüz gibi şu anda% 98,8 CPU kullanımına sahip bir Java programı var. Şu anda işlem id9'u kopyalayabilir ve işlemin her iş parçacığının çalışma durumunu görüntülemek için aşağıdaki komutu kullanabiliriz:
üst -Hp 9Bu işlem altındaki her iş parçacığının çalışma durumu aşağıdaki gibidir:
üst-08: 31: 1630 dk yukarı, 0 kullanıcı, ortalama yük: 0.75, 0.59, 0.35 Konular: Toplam 11, 1 koşu, 10 uyku, 0 durdurulmuş, 0 zombi % Cpu (s): 3.5 us, 0.6 sy, 0.0 ni, 95.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 2046460 toplam, 1924856 kullanılmış, 121604 boş, 14396 tampon KiB Swap: 1048572 toplam, 0 kullanılmış, 1048572 ücretsiz. 1192532 önbelleğe alınmış Mem PID KULLANICI PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND 10 kök 200 255716028982415872 R 79,314,20: 41,49 java 11 kök 200 255716028982415872 S 13,214,20: 06,78 javaGördüğünüz gibi, Java programındaki her bir iş parçacığının CPU doluluğu 9 işlemle, sonra jstack komutunu kullanarak iş parçacığı kimliği 10 olan iş parçacığının en çok CPU'yu neden tükettiğini görebiliriz. Jsatck komutu tarafından görüntülenen sonuçlarda, iş parçacığı kimliğinin onaltılık biçime dönüştürüldüğüne dikkat edilmelidir. Dönüştürme sonucunu görüntülemek için aşağıdaki komutu kullanabilir veya dönüştürme için bilimsel bir hesap makinesi bulabilirsiniz:
root @ a39de7e7934b: / # printf "% x \ n" 10 aBuradaki yazdırılan sonuç, jstack'teki iş parçacığının görüntü formunun 0xa olduğunu gösterir ve aşağıdaki bilgileri jstack komutu aracılığıyla görebiliriz:
"ana" # 1 prio = 5 os_prio = 0 tid = 0x00007f8718009800 nid = 0xb çalıştırılabilir java.lang.Thread.State: ÇALIŞTIRILABİLİR com.aibaobei.chapter2.eg2.UserDemo.main (UserDemo.java:9) "Sanal Makine İş Parçacığı" os_prio = 0 tid = 0x00007f871806e000 nid = 0xa çalıştırılabilirBuradaki VM İş Parçacığı satırının sonu nid = 0xa'yı gösterir; burada nid, işletim sistemi iş parçacığı kimliği anlamına gelir. VM İş Parçacığı, çöp toplanan iş parçacığını ifade eder. Burada temel olarak, mevcut yavaş sistemin ana nedeninin, çöp toplamanın çok sık olması ve bunun da uzun bir GC duraklama süresine yol açması olduğunu belirleyebiliriz. GC durumunu aşağıdaki komutla görüntüleyebiliriz:
root @ 8d36124607a0: / # jstat -gcutil 9100010 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.000.000.0075.0759.0959.6032590.91965177.7158.6350.000.000.000.0859.0959.6033060.93066117.8228.7520,000,000,000,0859,0959,6033510,94367017,9248,8670.000.000.000.0859.0959.6033970.95567938.0298.984Gördüğünüz gibi, burada FGC burada 6793'e kadar yüksek olan Full GC sayısını ifade ediyor ve hala artıyor. Bu ayrıca bellek taşması nedeniyle sistemin yavaş olduğunu doğruladı. Daha sonra bellek taşması burada onaylanır, ancak hangi nesnenin bellek taşmasına neden olduğunuzu nasıl kontrol edersiniz? Bu, bellek günlüğünün dökümünü alabilir ve ardından onu tutulmanın mat aracıyla görüntüleyebilir. Aşağıda gösterilen bir nesne ağaç yapısı gösterilmektedir:
Mat aracıyla analiz ettikten sonra, temel olarak bellekteki hangi nesnenin daha fazla bellek tükettiğini belirleyebilir ve ardından nesnenin oluşturulma konumunu bulabilir ve sonra işleyebiliriz. Buradaki en önemli şey PrintStream, ancak bellek tüketiminin sadece% 12,2 olduğunu da görebiliyoruz. Başka bir deyişle, çok sayıda Full GC'ye neden olmak yeterli değildir, şu anda başka bir durumu, yani kodda bir display System.gc () çağrısı veya üçüncü taraf bağımlı bir paket var. Bu durumda, bellek dökümüyle elde edilen dosyayı kontrol ederek karar verebiliriz, çünkü GC nedenini yazdıracaktır:
