Sampling

該模式會定期的訪問棧，評估出運行較慢的代碼。該模式沒有方法的調用次數記錄，僅有cpu時間。該模式是在進行提供瓶頸分析中最好的模式，對服務器額外開銷最小。

在該模式中可以進行相關配置。（Simpling和tracing都可以進行相關配置）

在上圖中，可以對要監控的類或者方法進行系統時間監控。
在上面的對話框中，可以輸入多行代碼，格式如下：

walltime=<fully qualified class name> : <method name> ( <comma-separated parameter types> ) or walltime=<fully qualified class name>

這樣配置完成后，在配置中的方法將會顯示系統時間（walltime），其他方法還是顯示CPU時間。
在上述配置中支持通配符*，

walltime=com.foo.bar： print*(*)

上面的代碼意思是，記錄com.foo.bar中的以print開頭的所有方法的系統時間（walltime）
PS：在simpling模式中，默認使用系統時間記錄的只有I/O methods

采樣時間的設置也是通過上面的對話框設置的

sampling_period_ms=<time in milliseconds>

sampling_period_ms=20 20毫秒一采樣

上述配置存儲在了
/.yjp/sampling.txt

Tracing

應用Tracing模式，被監控應用的每一個方法都會被轉化成字節碼記錄其消耗CPU的情況。方法調用次數和CPU時間都被記錄下來。
但是tracing模式對服務器影響較大。
被檢測服務的方法越多，對服務器性能影響越大

該模式的設置除了包含了Sampling模式的設置外，還有一些其他的配制方法，具體如下：

adaptive tracing 模式是開啟的
adaptive = ture

默認存儲在/.yjp/tracing.txt

Call counting

最輕量級的CPU性能分析模式，對服務器的性能影響幾乎為零

該模式技術不一定完全精確。為了能夠保證對服務器機會為零的性能影響，

該模式沒有應用任何locks和test-and-set 的atomic操作。因此如果同一個方法是多線程的，同時在不同CPU的不同核上調用的時候，就出發生計數錯誤。

該模式不支持調用計數的auto activity mode，不收集hight-level-statistics

開始監控后，實時看到的結果只是CPU的基本信息，要想查看詳細信息，保存快照后，查看快照

總結

以上是生活随笔為你收集整理的Yourkit 学习笔记-Start CPU profiling. Sampling, tracing, call counting.的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。