On 8/1/2012 9:38 PM, Jason Newton wrote: > The system has a single slot of SODIMM. We have an 8GB DDR3 stick in it. > I've added a circular buffer for each frame and limit it to some number of > frames (so far 2 seconds, I haven't had time to experiment with it yet). > The serialization thread is now separate and consumes the circular buffer > so we're effectively talking about the same thing sans files. This solves > the problem but as I mentioned before... Same idea, but your solution is far more elegant I think. > I do have a desire to seek out the > sources of the latency and cpu usage... I'm not really sure of how to go > about it though. We already gave you the biggest cause of your latency, which is garbage collection/wear leveling. You can't see inside the SSDs, but you can see the latency jump with either top (%wa) or iostat (await, milliseconds). Run iostat -x -d 1 20 and you get 20 reports 1 second apart. 1s is minimum granularity. This should clearly show the latency spikes caused by the SSDs. Maybe even execute it for 60 seconds and pipe to a file. Regarding CPU burn, the quickest, and probably least exact, way to see this is with top. On Linux sorting top by CPU usage should be the default. If not just hit Shift+P to toggle to that sort method. This should be sufficient to find out who is eating the cycles. I'd think running top and iostat while pushing 3 streams should do the trick. But I'm sure you've already looked at top. Which makes me wonder why you were unable to see what's burning the cycles. > Agreed that it's the easiest and cheapest solution. Average performance > probably won't change but burst of cpu will as it compensates for the high > latency writes in future cycles... this is undesirable but I think OK (the > important stuff is at high priority on SCHED_RR, these serialization > threads are high priority SCHED_OTHER). Again, I haven't had time to test > it as I've been putting out other fires. Keep us posted. BTW, do you mind sharing the make/model of that mobo, and exactly which model that i7 is? -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
