問題タブ [sar]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - 異なる JVMS から呼び出されると、システムの CPU 使用率が異なる「SystemCpuLoad」
1 つの JVM (JVM 1) が軽量で、別の JVM (JVM 2) が重いタスクを実行する 2 つの JVM があります。「SystemCpuLoad」を取得して JVM からシステム使用率を取得しようとすると、JVM 1 は正しい CPU 値 (SAR 値に一致) を提供し、重い作業を行う別の JVM は SAR 値に一致しない高い CPU 使用率を提供します。以下のアプローチに従いました:
JVMプロセスが重いタスクを実行するか軽いタスクを実行するかに関係なく、システムのCPU使用率を正しく取得するにはどうすればよいですか?
linux - ssystat sar utility: Output file doesn't change for different options
I'm using SYSSTAT 12.2.1 built on a generic Linux 5.4 kernel (Yocto build) for STM32MP (Cortex-A7). I've used this utility in the past to do system profiling: Collect data for a time, dump to file, convert file, plot the output in excel. After adding this utility to the Yocto build and loading on the Discovery board, I set about collecting various statistics. The initial CPU Usage (-u) seemed to work just fine, data collected, converted, plotted. All Good. Next I collected data for 13 other characteristics (-q, -b, -B, -w, -v, etc). After converting the files for CSV output to be read by Excel, imagine my surprise when the output file for -q is filled with data for a -u output. The commands work OK interactively. The -o will create the file OK, but the output in the file is ALWAYS for the -u command. Example:
This is supposed to be a "stable" release. I'm really kind of at my wits end here trying to figure this out. Different parameter orders. The documented version to run in the background produces similar results.
So I'm thinking that something internally in the application is having an issue possibly with the kernel?
I've send this information to sysstat, but have not yet received a response, hoping someone here has encountered this issue before??
Thanks for your expertise and time.
Regards,
Stephen Beckwith