re: How It Works: CMemThread and Debugging Them

Lonny Niederstadt — Tue, 26 Mar 2013 18:59:21 GMT

Excellent! Used this information to assist in diagnosing and remedying a spinlock convoy on two different systems - an AMD server and an Intel server. Both systems were hitting 100% CPU utilized with very few logical reads. Trace flag 8048 resolved the issue.

In Bod Borr's post about trace flag 8048, he said: "Remember this requires more memory overhead..."

Where would this overhead show up - in the operation of the memory clerks? Is there something from the DMVs or perfmon that I can capture before and after to indicate the cost of trace flag 8048 on a given system?

Cross-posted the question at Bob's post as well.

blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus-presented-per-numa-node-may-need-trace-flag-8048.aspx

re: How It Works: CMemThread and Debugging Them

J. Granden — Mon, 14 Jan 2013 17:29:36 GMT

Awesome post!

I'm currently fighting a spinlock issue, and I was able to use the XEvent callstack histogram + windbg technique to identify temp table statistics as the culprit.

With this knowledge, I switched to table variables, and it eliminated the issue. Now I've got a band-aid in place, and a head-start for the CSS support incident i'm opening.

Thanks!