Application Real-Time Monitoring Service:FAQ

Mengaktifkan Continuous Profiling tidak menghasilkan data

Apakah wajar jika penggunaan memori dari pemantauan heap memory berbeda dengan penggunaan memori yang terdeteksi oleh memory hot spots dalam continuous profiling?

Continuous Profiling hanya mencatat alokasi memori heap dalam periode waktu tertentu, bukan total penggunaan memori proses.

Diagnostik CPU memiliki data tetapi diagnostik memori tidak memiliki data

Masalah ini biasanya terjadi pada versi agent 3.1.4 dan yang lebih baru.

Kurangnya data dalam diagnostik memori biasanya karena Anda menggunakan image dasar Alpine. Image dasar Alpine menghapus simbol debug JDK untuk mengurangi ukurannya, sehingga continuous profiling tidak dapat bekerja dengan benar. Untuk mengatasi masalah ini, Anda dapat menginstal simbol debug JDK dalam image Anda atau menggunakan image dasar non-Alpine. Perhatikan bahwa beberapa versi JDK tidak memiliki paket simbol debug yang sesuai, sehingga instalasi mungkin gagal.

Mengapa tidak ada data untuk code hot spots, atau mengapa datanya tidak sesuai ekspektasi?

1. Profiling hot spot tidak didukung untuk aplikasi yang menggunakan virtual threads atau teknologi serupa di JDK, termasuk Alibaba Dragonwell JDK.

2. Fitur code hot spot tidak didukung oleh protokol SkyWalking. Anda dapat mengonfirmasi jenis protokol di detail span suatu trace.

3. Fitur code hot spot memerlukan versi agent 3.1.4 atau yang lebih baru. Versi sebelumnya tidak mendukung fitur ini.

4. Versi agent sebelum 4.2.1 hanya mendukung panggilan sinkron dan mungkin tidak mengumpulkan data secara lengkap. Data mungkin hilang untuk panggilan asinkron. Misalnya, penggunaan Spring Cloud Gateway, Undertow, atau Lettuce dapat menyebabkan pergantian thread asinkron, yang mengakibatkan pengumpulan data tidak akurat. Versi agent 4.2.1 dan yang lebih baru mencakup optimasi untuk masalah ini. Kami menyarankan Anda untuk upgrade agent ke versi terbaru.

5. Fitur code hot spot hanya didukung untuk trace yang diambil sampelnya dengan laju tetap. Fitur ini tidak didukung untuk trace yang dikumpulkan dengan laju pengambilan sampel non-tetap, seperti pengambilan sampel error (s9) atau pengambilan sampel lambat (s10), karena akan menyebabkan overhead performa yang tinggi. Jenis pengambilan sampel ini hanya dipicu setelah trace selesai. Anda dapat memeriksa bidang sample.reason di atribut span untuk menentukan jenis pengambilan sampel.

   Untuk trace yang dikumpulkan dengan laju pengambilan sampel non-tetap, buka halaman Trace Analysis. Gunakan parameter Traces with Code Hotspots untuk memfilter trace yang berisi code hot spots guna mendiagnosis masalah.

6. Jika Anda menggunakan versi agent 4.2.1 atau yang lebih baru, waktu eksekusi yang dikumpulkan mungkin jauh lebih rendah daripada waktu yang dicatat oleh span luar. Hal ini dapat terjadi jika aplikasi Anda menggunakan framework I/O asinkron non-blocking (NIO), seperti Spring Cloud Gateway. Saat framework ini menerima permintaan dari layanan hulu atau mengirim permintaan ke layanan hilir, thread tidak diblokir jika data belum siap. Sebaliknya, thread segera kembali dan dapat melakukan tugas lain, yang meningkatkan pemanfaatan thread. Karena thread tidak diblokir menunggu I/O, bottleneck performa tidak berada di aplikasi saat ini. Dalam kasus ini, waktu yang dikumpulkan untuk code hot spot bisa jauh lebih rendah daripada durasi span. Anda harus memeriksa bottleneck dalam pemrosesan permintaan aplikasi hulu atau hilir, atau di jaringan.

Berapa overhead performa dari continuous profiling?

• Uji performa menunjukkan overhead berikut untuk continuous profiling: Dalam skenario dengan 500 Transaksi Per Detik (TPS) dan semua fitur diaktifkan pada aplikasi Spring Web standar, overhead CPU meningkat sekitar 5% dan overhead memori off-heap meningkat sekitar 50 MB. Peningkatan dalam garbage collection (GC) dan latensi permintaan tidak signifikan.

• Dalam kasus ekstrem, profiling memory hot spot tidak memiliki batas laju. Jika aplikasi mengalokasikan memori sangat sering, hal ini dapat menghasilkan volume event yang tinggi, seperti puluhan ribu per menit. Hal ini dapat memengaruhi latensi P99. Anda dapat menonaktifkan profiling memori untuk mengatasi masalah ini.

  Masalah ini telah diperbaiki di versi 4.1.10. Anda dapat upgrade agent ke versi 4.1.10 atau yang lebih baru.

Thread terkait JFR dalam aplikasi

• Fitur continuous profiling membuat thread JDK Flight Recorder (JFR). Thread ini terutama ditemukan pada versi agent sebelum 4.1.10. Versi agent 4.1.10 dan yang lebih baru tidak membuat thread JFR.

• Thread ini tidak menyebabkan bottleneck performa dalam aplikasi.

• Jika Anda menonaktifkan sakelar continuous profiling secara dinamis, thread tidak langsung dihapus. Thread tersebut hanya hilang setelah aplikasi direstart.

Continuous profiling untuk waktu startup aplikasi

Continuous profiling dapat memperlambat startup aplikasi. Hal ini dapat terjadi jika JDK tidak memiliki simbol debug dan Classloader memuat banyak metode. Setelah aplikasi dimulai, tidak ada dampak pada performa runtime-nya.

Masalah ini telah diperbaiki di versi agent 4.2.1. Anda dapat upgrade agent ke versi ini untuk mengatasi masalah tersebut.

Mengapa total memori dalam graf flame melebihi batas memori yang dikonfigurasi sebenarnya?

Data dalam continuous profiling tidak secara langsung terkait dengan konfigurasi memori host. Data tersebut menunjukkan jumlah total memori heap yang dialokasikan selama periode analisis. Karena adanya garbage collection, wajar jika jumlah ini lebih besar daripada memori yang dikonfigurasi pada host.

Kegagalan attachment OpenJ9 JDK

Continuous profiling ARMS tidak mendukung IBM OpenJ9. Penggunaan JDK ini dapat menyebabkan kegagalan integrasi dan menghasilkan error. Kami menyarankan Anda menggunakan OpenJDK atau Oracle JDK sebagai gantinya.

Data code hot spot dalam span tidak lengkap

Code hot spots diidentifikasi dengan mengambil sampel stack metode thread dalam trace pada interval tertentu. Jika suatu metode tidak muncul dalam graf flame code hot spot, kemungkinan waktu eksekusinya kurang dari 500 ms. Metode dengan waktu eksekusi sesingkat itu mungkin tidak tertangkap oleh proses pengambilan sampel. Hal ini tidak memengaruhi diagnosis trace lambat karena metode berjalan singkat tidak dianggap sebagai bottleneck performa.

Mengapa graf flame berisi stack .GC_active?

.GC_active menunjukkan bahwa garbage collection (GC) aktif selama pengumpulan data untuk graf flame. Proses GC menjeda semua thread bisnis Java dalam event yang dikenal sebagai "Stop-the-World". Jika .GC_active muncul dalam code hot spot, artinya jeda GC berkontribusi terhadap latensi permintaan.

Mengapa graf flame berisi entri "unknown"?

Pada sistem operasi Alpine, jika JDK tidak memiliki simbol debug dan classloader memuat banyak metode, mengaktifkan continuous profiling dapat memperlambat aplikasi atau menyebabkannya timeout. Untuk mencegah hal ini, versi agent 4.2.1 dan yang lebih baru memantau waktu pemuatan. Ambang batas default adalah 150 ms. Jika pemuatan melebihi waktu ini, agent akan menghentikan beberapa langkah yang memakan waktu. Hal ini dapat mencegah beberapa simbol metode diurai dengan benar, sehingga menghasilkan entri "unknown". Anda dapat menyesuaikan ambang batas ini untuk mengurangi masalah ini. Misalnya, atur variabel lingkungan `AP_JMID_TIME_LIMIT` ke 500 (milidetik): `export AP_JMID_TIME_LIMIT=500`.

Mengapa graf flame berisi entri .no_Java_frame?

Hal ini biasanya terjadi saat Anda menggunakan image dasar Alpine. Alpine menghapus simbol debug JDK untuk mengurangi ukuran image. Hal ini mencegah sistem mengidentifikasi nama fungsi dalam stack metode thread C++ di dalam JDK. Stack ini kemudian ditampilkan sebagai .no_Java_frame. Stack ini sebagian besar merepresentasikan informasi thread non-Java, seperti dari VM Thread atau thread Just-In-Time (JIT) compiler. Jika proporsi entri .no_Java_frame rendah, Anda dapat mengabaikannya. Fokuslah pada stack metode Java lainnya untuk analisis performa. Jika proporsinya tinggi, instal simbol debug untuk JDK di image dasar Anda. Atau, beralihlah ke image dasar non-Alpine. Perhatikan bahwa beberapa versi JDK tidak memiliki paket simbol debug yang sesuai, sehingga instalasi mungkin gagal.

Mengapa item "other" muncul dalam graf flame?

Output log: parse lib sigsegv handler installed

Bagaimana cara mengatasi error "No access to perf events" yang disebabkan oleh pembatasan perf_event_open?

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr'
[ERROR] Failed to start Continuous Profile Collector
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1'

Bagaimana cara mengatasi error "No AllocTracer symbols found. Are JDK debug symbols installed?"?

Error ini, atau kurangnya data, dapat terjadi jika proses Java Anda berjalan dalam kontainer yang menggunakan image dasar Alpine. Image dasar Alpine menghapus simbol debug JDK untuk mengurangi ukurannya, sehingga continuous profiling tidak dapat bekerja dengan benar. Untuk mengatasi masalah ini, lihat solusi untuk kegagalan pengumpulan memory hot spot akibat simbol debug yang hilang.

Bagaimana cara mengatasi error "perf_event mmap failed..."?

Operasi lainnya

from Alpine:3.9
RUN apk add openjdk8