71–80 of 84 posts
>and stolen time (by other guests, or with Xen, the guest's own isolated driver domain).
This isn't necessarily true. If there is any sort of credit scheduler interaction ( http://wiki.xen.org/wiki/Credit_Scheduler ) resulting in the CPU being throttled, it will show as steal. Steal actually just means the CPU was not in a runnable state, which can be caused by multiple things, but predominately throttling by the CPU scheduler.
Is there any way to analyze memory bandwidth usage? I've had a couple of programs over the years that I wondered if we were just hitting memory bandwidth limitations but I couldn't find any way to prove that, or even particularly gather evidence.
perf can record hardware counter events - use "perf list" to see the list - including those that count frontend and backend stalls (stalls in the instruction decoding and execution stages respectively). A high stall ratio / low instructions per cycle throughput is an indicator that you're running into memory bandwidth limitations.
Is there any way to analyze memory bandwidth usage? I've had a couple of programs over the years that I wondered if we were just hitting memory bandwidth limitations but I couldn't find any way to prove that, or even particularly gather evidence.
It will show up like CPU usage - the hyperthread that is waiting for memory will appear busy executing. perf can record hardware counter events - use "perf list" to see the list - including those that count frontend and backend stalls (stalls in the instruction decoding and execution stages respectively). A high stall ratio / low instructions per cycle throughput is an indicator that you're running into memory bandwi…
I'm wondering if there's a way to automate this kind of analysis to give you condensed, interesting points of a system performance status. À la powertop for power management.
Collectd + Graphite / InfluxDB + Grafana. You shoudn't need to ssh on a host to see those metrics.
This is pretty cool because back in the dot com days I got paid huge amounts of money to do what they did in the first 60 seconds. I started at $1000/day and the phone rang off the hook. Talked to a friend and he said "double your rates" and I said "WTF? I'm not worth $2000/day, that's crazy". He said "double your rates". So I did, phone still rang like crazy. I got up to $4000/day and had 5 days/week work. Went to $…
Did the money dry up because you got too expensive or because the dot com bubble burst?
I stopped because I had enough money for payroll and wanted to work on my startup.
Is there any way to analyze memory bandwidth usage? I've had a couple of programs over the years that I wondered if we were just hitting memory bandwidth limitations but I couldn't find any way to prove that, or even particularly gather evidence.
They are also a PITA to work with.
As another person said, it shows up as CPU utilization. So I check that along with IPC (instructions per cycle), and if IPC is low (what "low" is depends, but say, ... but of course, I want actual throughput (usage), bandwidth (maximum), and utilization (ratio), which is more digging with the PMCs.
Earlier quoted context omitted.
It will show up like CPU usage - the hyperthread that is waiting for memory will appear busy executing. perf can record hardware counter events - use "perf list" to see the list - including those that count frontend and backend stalls (stalls in the instruction decoding and execution stages respectively). A high stall ratio / low instructions per cycle throughput is an indicator that you're running into memory bandwi…
You've also reminded me that while they do show up as CPU time, they wouldn't be 'user' time (for example in the output of the command 'time')
Is there any way to analyze memory bandwidth usage? I've had a couple of programs over the years that I wondered if we were just hitting memory bandwidth limitations but I couldn't find any way to prove that, or even particularly gather evidence.
I've identified a memory bandwidth issue in the past by keeping an eye on truss/strace output and "counting" mem operations. After that, I compiled and ran a tiny executable called Stream[1] and got the numbers I needed in order to explain why one machine was twice as slow as another. [1] http://www.cs.virginia.edu/stream/
Earlier quoted context omitted.
xperf/wpr. Launch wprui, select First Level Triage and Disk I/O and File I/O, make sure logging mode is set to Memory, then click Start. Let it run for a minute, click Stop, then open up the generated ETL in WPA. From there it's hard to tell you what to do in WPA. Documentation isn't the greatest, but this link is close to what you're trying to do: http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/03/19/trou... Drag…
Thank you!!