Results of CPU power saving survey

At the end of December I showed you how to discover if power saving is enabled on your server, which can lead to variable and often degraded performance. I also included a survey to let me know what you found after running the free CPU-Z tool on your servers. See here for the original post.

I want to do a quick post to show you the results of the survey.

 

The five 'other' results were:

  • "As part of my server build scripts I disable power management"
  • "I thought I had power savings on and it was. However, I had never confirmed. (Personal Computer)"
  • "I thought we had power saving OFF and it was OFF. Good deal."
  • "Not sure if power saving is on — "Core Speed" is 75% of rated speed"
  • "Told IT that they need to change the bios settings and reboot. have they ? have they hell!"

As you can see, almost 40% of the people who tried the tool AND took the time to fill in the survey reported that they discovered power saving was erroneously enabled.

Have you tested your system yet?

Thanks!

T-SQL Tuesday #012 : Summary of why DBA skills are necessary

Last Tuesday I hosted T-SQL Tuesday #012 (see here for the call for participation) and posed the question "why are DBA skills necessary?" This month broke the participation record with 46 people contributing posts – fabulous! Lots of people contributed for the first time too. And what I think is also really cool is that 45 out of these 46 are on Twitter too.

The downside of so many people participating is that it's taken me quite a while to read through all the posts to compile this summary – maybe I should have picked something obscure and boring instead! One of the most interesting things about doing this wrap-up was experiencing a huge variety of blog themes and fonts – a few of which actually made my eyes hurt!

A HUGE thank you to everyone that participated, T-SQL Tuesday doesn't work without you. I really enjoyed reading through everyone's posts and seeing the passion out there for the DBA role. As I've summarized the posts I've added my own comments too.

Here are the posts from all the participants in the order in which their links appeared in my blog post comments (or I dug out additional posts using Google).

Matt Whitfield (blog | @atlantis_uk): T-SQL Tuesday #12 – Why are DBA skills necessary?

Matt tells the story of himself as a database designer making a plethora of hard-to-remedy mistakes 9 years ago before he had DBA skills that would have helped him not make those mistakes. His take is that it's essential to have someone with DBA skills involved in system design as newbie DBAs or developers don't know the impact of design choices on SQL Server. I love this line from his post: "There is a whole world of epic-database-fail out there, and that world needs us."

Noel McKinney (blog | @NoelMcKinney): T-SQL Tuesday #012 – DBA Skill or Nil?

Noel takes a look at different RDBMS platforms and how the need for DBA skills could change – from Oracle to MySQL to the cloud to NoSQL. Even with automated solutions, he still thinks you wouldn't want to just apply all the default policies and walk away. I'd have to agree. 

Pinal Dave (blog | @PinalDave): SQL SERVER – Are you a Database Administrator or a Database Developer?

Pinal's short post focuses on how the line is often blurred between being a database administrator and a database developer. He has a survey in the post which is currently showing 60% of respondents believe they're more a dev than a DBA.

Audrey Hammonds (blog | @Datachix2): T-SQL Tuesday: Why are DBA Skills Necessary? – A Datachix Perspective

Audrey's post is about how some of the knowledge a DBA has is essential for a database developer to have too – but does that make you a DBA? No. I love her medical analogy: "See, asking me, a non-DBA, to attempt to be a DBA is like asking a psychiatrist to perform heart surgery". DBAs are essential to look after SQL Server.

Erik Bitemo (blog): T-SQL Tuesday #12 – Why are DBA skills necessary?

Erik's post explains some of the knowledge DBAs should have as a way of illustrating the problems that can occur if they don't. He also reminds us that one of the major causes of SQL Server being regarded as not requiring a DBA was the marketing around the 7.0/2000 time-frame that proclaimed how easy SQL Server was to use. IMHO that really hurt the image of SQL Server and SQL Server DBAs.

Rob Farley (blog | @rob_farley): Why bother with database professionals?

Rob's argument is that you don't necessarily need DBA skills – you need people who can apply the right paradigm to their work. For database work that paradigm is set based.

Aaron Bertrand (blog | @AaronBertrand): T-SQL Tuesday : Are hotshot DBA skills necessary?

Aaron (one of my favorite MVP friends) makes a great point that many small business *don't* need a full-time rockstar DBA and that many of the defaults will allow them to continue along happily. But at some point as the business grows and the data/transaction volume grows with it, you cross a line and then a DBA really *is* necessary. I totally agree. When I'm teaching about index fragmentation I always say that at the low end, rebuilding all your indexes every night is probably fine, but as things get larger and downtime becomes important, DBA skills are needed to take a more analytical approach.

Robert Hartskeerl (blog | @rhartskeerl): T-SQL Tuesday #12–Why are DBA skills necessary?

Robert explains how even though there are tools to assist with managing SQL Server, someone has to interpret what the tool is saying and no how to fix the problem. And the tools can be wrong – like the RESTORE bug in SSMS in SQL 20008. Robert also used my favorite phrase… "it depends!"

Erin Stellato (blog | @erinstellato): TSQL Tuesday #012: Why are DBA Skills Necessary?

Erin (my favorite stalker :) recounts some of the problems she's helped with on customer systems that affected business continuity. Her take is that if the data is really important, you need a DBA to make sure it doeesn't get irretrievably damaged or destroyed.

Grant Fritchey (blog | @GFritchey): TSQL Tuesday: Why Are DBA Skills Necessary

Grant (who scares me sometimes) tells some good stories and preaches the same mantra: at some point you need a DBA who knows how to protect and recover data, perform tuning etc. Even with NoSQL – you're still storing data and you still need to be able to restore it, get at it quickly, etc. Hear, hear.

Steve Jones (blog | @way0utwest): T-SQL Tuesday #12 – Why Do You Need a DBA?

Steve (who scares me most of the time with his pink cowboy hat) joins the chorus that DBAs aren't always required, but when they are they can save a company a lot of time and money and hence can be a really worthwhile investment.

Jes Borland (blog | @grrl_geek): T-SQL Tuesday #012: Why Are DBA Skills Necessary?

Jes explains why DBAs should market their skills as a problem-solvers and money-savers, and that a DBA isn't an IT function, it's a business need. Oh yes, and she says that we should all wear super-hero capes!

Bob Pusateri (blog | @SQLBob): T-SQL Tuesday #12: DBA Skills

Bob tells some stories from his DBA past but says that one of the most important DBA skills is to know when to ask others for help. He goes on to say that "presence of DBA skills can make a big difference between just getting something done, and doing something exceptionally well."

Mike Reigler (blog | @RMikeReigler): TSQL Tuesday #12 – I’m not a DBA, But I Got DBA Skills

Mike lists a bunch of SQL knowledge that most developers wouldn't know or care about, but makes the point that *someone* has to know and care about it, or people are going to get annoyed when performance tanks. He also explains how knowing some DBA skills sets him apart from other developers.

Mark Blakey (blog | @Blakmk): T-SQL Tuesday #12 – Why are DBA skills necessary?

Mark's the first poster to bring up the fact that developers and DBAs often have different priorities – with devs churning out code quickly while DBAs are trying to preserve resources.

Oscar Zamora (blog | @ZamoraO): Who needs DBA Skills? [#TSQL2sDay]

Oscar (who I just met at SQL PASS on Monday) lists 14 reasons why DBA skills are necessary and throws down the gauntlet by stating he thinks "most developers have no business in the DB world".

Tamera Clark (blog | @tameraclark): TSQL Tuesday – Why are DBA skills necessary?

Tamera explains how some DBA skills can help write better T-SQL as you'll know more about how SQL Server is handling the T-SQL you casually throw at it.

Jeremy Carter (blog): TSQL Tuesday – Why are dba skills necessary?

Jeremy explains that even with small databases, sometimes a DBA needs to be involved from the get-go, before the hardware is even provisioned.

Kerry Tyler (blog | @AirborneGeek): T-SQL Tuesday #12: Why are DBA Skills Necessary?

Kerry explains that databases are hard, and that it takes many different roles to look after a corporations data properly – the DBA being just one of them.

Andy Lohn (blog | @SQLQuill): T-SQL Tuesday #012 – Smart, Technologically Up-to-date, Well-Meaning Application Developers

Andy explains how he picked up DBA skills when he became a database developer and how useful they've been for his company.

Ricardo Leka (blog | @BigLeka): Por que habilidades de DBA são necessárias?

Portuguese? Google Translate to the rescue! Hmm – Google Translate didn't do such a good job, but I think the gist of Ricardo's post is that too many companies that think that SQL Server doesn't need a DBA.

Andrew Vogel (blog | @sqlreader): T-SQL Tuesday: Why Are DBA Skills Necessary?

Andrew makes a very interesting point that consultants know what's best about a product, but only you know what's best for your environment. Totally true – so many clients expect us (consultants) to provide the best answer for them straight away.

Wendy Pastrick (blog | @wendy_dance): Who Needs DBA Skillz?

Wendy (who I just met at SQL PASS on Monday) says anyone who works with a database needs some DBA skills. And if you don't have anyone with DBA skills, check out the #sqlhelp tag on Twitter. Hear hear!

Pat Wright (blog | @SqlAsylum): T-SQL Tuesday, Why are DBA skills necessary?

Pat (who I just met at SQL PASS on Monday) introduces me to an expansion of the DBA TLA I've never heard before: Default Blame Acceptor. While I've never heard it, I totally get it. DBAs are the unsung heroes of countless nasty situations caused by others.

Cade Roux (blog | @caderoux): T-SQL Tuesday: Why are DBA skills necessary? I pick the most important one…

Cade focuses on the skills a DBA has and explains why he thinks troubleshooting is the number-one skill he looks for in a DBA.

Tim Ford (blog | @sqlagentman): T-SQL Tuesday – Sometimes DBAs Are Required – Even for the Amish

Tim (who looks great in a Utilikilt) manages to unite Amish people and brothels in the same post. That takes a different kind of skill.

Geoff Hiten (blog | @SQLCraftsman): Why DBA skills are important (T-SQL Tuesday)

Geoff's short post tells the tale of someone attempting to use replication as a DR solution without understanding what replication does and does not provide. And that person was a 'DBA', but without DBA skills.

Jason Strate (blog | @StrateSQL): Why are DBA skills necessary? #TSQL2sDay

Jason gives some examples of why "what you don't know can hurt you" and then explains three critical things you should know if you're a DBA.

Jason Brimhall (blog | @sqlrnnr): T-SQL Tuesday #012 – Skills

Jason departs from the norm and discusses the NON-technical skills that a successful DBA needs to have. I particularly like the emphasis on a sense of community. I'm a huge community guy and I really like to see those that benefit from the SQL community eventually starting to give back in the form of things like blog posts, tweets, and user group presentations. People really ARE interested in what you've experienced as that will help them when they have the same problem.

Gill Rowley (blog | @SQLGill): T-SQL Tuesday #012: Why Are DBA Skills Necessary?

Gill tells a story of trying to get an IT department out of the dark ages and under control using his DBA skills.

Brent Ozar (blog | @BrentO): T-SQL Tuesday: Why Do You Need DBA Skills?

Brent (our very own Mr Wonderful) talks about when saying 'whoops' isn't code for "oh no, I dropped the database" and how real DBAs need to know enough to fix the junior DBA's "fixes"…

Matt Velic (blog | @mvelic): November’s T-SQL Tuesday: Importance of DBA Skills

Matt went as far as recording his T-SQL Tuesday message, describing how valuable DBA skills are.

Gethyn Ellis (blog | @SQLGRE): TSQL2SDAY #12 – Why are DBA Skills Necessary?

Gethyn explains some of the problems that can cause business continuity to suffer, all of which could be solved with backups, being taked by someone with DBA skills.

Jack Corbett (blog | @unclebiguns): T-SQL Tuesday–Why are DBA Skills Necessary?

Jack (whose Twitter alias I've been afraid to ask about…) tells a story if disaster and data loss that would have been prevented had someone with DBA skills been involved.

Chris Shaw (blog | @SQLShaw): T-SQL Tuesday

Chris gives some examples of why companies need databases today to stay competitive, and hence need DBAs to keep those databases healthy.

Sal Young (blog | @EmpiricalDataMa): We don’t need no stinking DBAs! (T-SQL Tuesday #12)

Sal describes some of the different DBA specialties there are, and how you need to be prepared to be dealt a hard knock by clueless executives bent on saving company money by laying off employees.

Robert L Davis (blog | @SQLSoldier): T-SQL Tuesday #012 – the DBA as a Modern-day Specialist

Robert (DBM book writer extraordinaire) tells a *really* interesting story of a high-school injury that nearly left him paralyzed because it was mis-diagnosed by GPs rather than a specialist – and draws the analogy to under-qualified people trying to diagnose problems affecting an important database.

Kimberly L Tripp (blog | @KimberlyLTripp): TSQL Tuesday – Why DBA skills are important

Kimberly (lovely wife) highlights a couple of areas where you can get bitten without DBA skills, and explains why *someone* in the organization has to have DBA skills because SQL Server is a *general purpose* RDBMS, and so it needs to be tweaked to work best for your environment.

Kendra Little (blog | @Kendra_Little): TSQL Tuesday #12: Why Are DBA Skills Necessary? Fido, Please Turn Your Head And Cough.

Kendra draws a very clever analogy between DBAs and veterinarians, saying that both look after birth, death, growth, prevention of illness, and so on.

Jeremiah Peschka (blog | @PeschkaJ): T-SQL Tuesday – Why Are DBA Skills Necessary?

Jeremiah (who has quite amazing tattoos) says that DBA skills aren't necessary, but instead the ability to learn is what sets the successful apart from the unsuccessful.

Josh Feierman (blog | @awanderingmind): Who needs a DBA? – TSqlTuesday #12

Josh recalls how he started out as an involuntary DBA, and thinks about all the mistakes he made that a real DBA would have picked up on. One thing I think we sometimes lose sight of is that *everyone* started with zero SQL Server knowledge…

Josef Richberg (blog | @sqlrunner): T-SQL Tuesday 12: Why are DBA skills necessary?

Josef laments that developers are seen as THE all-knowing entities, which can lead unsuitable designs making it into production and causing problems – which then leads to angst about the database platform which fuels the NoSQL movement.

Jonathan Kehayias (blog | @SQLSarg): T-SQL Tuesday #12 – Why are DBA skills necessary?

Jonathan (extended events expert) uses some examples from his work to illustrate some of the problems facing companies without DBAs, and explains how it can take time for a new DBA to earn the respect of the incumbent IT staff.

Cameron Mergel (blog | @CameronMergel): T-SQL Tuesday – Why Are DBA Skills Necessary?

Cameron reiterates that as the operations you want to do on your database become more advanced, you need someone with higher skills – just like there's a point at which you stop doing maintenance on your car yourself and trust it to a mechanic.

Kelly Martinez (blog | @GreeleyGeek): Why are DBA skills necessary? #TSQL2sDay

Kelly talks about some of the things a DBA should know, but the most interesting point in his post is about how some vendors seem to have no clue about the database they're running on.

Sean Gallardy (blog | @SeanGallardy): T-SQL Tuesday – Why are DBA skills necessary?

Last but not least, Sean makes the very good point that DBA skills are really necessary when searching for problem solutions on the Internet. Without DBA skills, how do you tell if the advice/solution you're reading is correct and appropriate?

Benchmarking: Introducing SSDs (Part 3: random inserts with wait stats details)

Last time I posted about SSDs I presented the findings from sequential inserts with a variety of configurations and basically concluded that SSDs do not provide a substantial gain over SCSI storage (that is not overloaded) – see this blog post for more details.

You can see my benchmarking hardware setup here, with the addition of the Fusion-io ioDrive Duo 640GB drives that Fusion-io were nice enough to lend me. (For the next set of benchmarks I've just upgraded to 16GB of memory and added the second 640GB Fusion-io Duo, for a total of 1.2TB… watch this space!).

In this set of tests I wanted to see how the SSDs behaved for random reads and writes. To do this my test harness does the following:

  • Formats the SSDs in one of three ways:
    • Fusion-io basic format (each 320GB drive has 300GB capacity)
    • Fusion-io improved write performance format (each 320GB drive has only 210GB capacity, 70% of normal)
    • Fusion-io maximum write performance format (each 320GB drive has only 151GB capacity, 50% of normal)
  • The SSD format is performed using Fusion-io's ioManager tool, with their latest publicly-released driver (1.2.7.1).
  • Creates 1, 2, 4, 8, or 16 data files, with the file sizes calculated to fill the SSDs
  • My table structure is:

CREATE TABLE MyBigTable (
    c1 UNIQUEIDENTIFIER ROWGUIDCOL DEFAULT NEWID (),
    c2 DATETIME DEFAULT GETDATE (),
    c3 CHAR (111) DEFAULT 'a',
    c4 INT DEFAULT 1,
    c5 INT DEFAULT 2,
    c6 BIGINT DEFAULT 42); 
GO

CREATE CLUSTERED INDEX MyBigTable_cl ON MyBigTable (c1);
GO

  • I have 16 connections each inserting 2 million records into the table (with the loop code running server-side)

Now before anyone complains, yes, this is a clustered index on a random GUID. It's the easiest way to generate random reads and writes, and is a very common design pattern out in the field (even though it performs poorly) – for my purposes it's perfect.

I tested each of the five data file layouts on the following configurations (all using 1MB partition offsets, 64k NTFS allocation unit size, 128k RAID stripe size – where applicable):

  • Data round-robin between two RAID-10 SCSI (each with 4 x 300GB 15k and one server NIC), log on RAID-10 SATA (8 x 1TB 7.2k)
  • Data on two 320GB SSDs in RAID-0 (each of the 3 ways of formatting), log on RAID-10 SATA (8 x 1TB 7.2k)
  • Log and data on two 320GB SSDs in RAID-0 (each of the 3 ways of formatting)
  • Log and data on two 320GB SSDs in RAID-1 (each of the 3 ways of formatting)  

  • Log and data on single 320GB SSD (each of the 3 ways of formatting)
  • Log and data on separate 320GB SSDs (each of the 3 ways of formatting)
  • Log and data round-robin between two 320GB SSDs (each of the 3 ways of formatting)

That's a total of 19 configurations, with 5 data file layouts in each configuration – making 95 separate configurations. I ran each test 5 times and then took an average of the results – so altogether I ran 475 tests, for a cumulative test time of just less than 250 thousand seconds (2.9 days) at the end of July.

The test harness takes care of all of this except reformatting the drives, and also captures the wait stats for each test, making note of the most prevalent waits that make up the top 95% of all waits during the test. The wait stats will be presented in the following format:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       26833.45       26822.85          10.60      867558      75.88
WRITELOG                              7097.77        6647.26         450.51     3221475       20.0

The columns are:

  • WaitType – kind of obvious
  • Wait_S – cumulative wait time in seconds, from a thread being RUNNING, going through SUSPENDED, back to RUNNABLE and then RUNNING again
  • Resource_S – cumulative wait time in seconds while a thread was SUSPENDED (called the resource wait time)
  • Signal_S – cumulative wait time in seconds while a thread was RUNNABLE (i.e. after being signalled that the resource wait has ended and waiting on the runnable queue to get the CPU again – called the signal wait time)
  • WaitCount – number of waits of this type during the test
  • Percentage – percentage of all waits during the test that had this type

On to the results…

Data on SCSI RAID-10, log on SATA RAID-10

 

Once again this shows what I've shown a few times before – on SCSI having multiple data files on the two RAID arrays gives a performance boost. The two-file case is going from a single RAID array to two RAID arrays – bound to get a performance gain – and it gets a 35% performance boost – 6 times the boost I got from messing around with multiple files for the sequential inserts case last time (see here and here for details).

The best performance I could get from having data on the SCSI arrays was 1595 seconds.

Representative wait stats for a run of this test – one file:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       28993.08       28984.66           8.42      647973      75.53
WRITELOG                              7333.36        6883.82         449.54     3223809      19.10
SLEEP_BPOOL_FLUSH                     1786.18        1781.94           4.24     1147596       4.65

Representative wait stats for a run of this test – two files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       15306.22       15296.67           9.55      679281      63.87
WRITELOG                              7762.25        7270.79         491.47     3215377      32.39

Representative wait stats for a run of this test – four files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       26833.45       26822.85          10.60      867558      75.88
WRITELOG                              7097.77        6647.26         450.51     3221475      20.07

Representative wait stats for a run of this test – eight files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       27556.79       27547.83           8.96      674319      75.09
WRITELOG                              7545.40        7118.93         426.47     3221841      20.56

Representative wait stats for a run of this test – sixteen files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
PAGEIOLATCH_EX                       37716.72       37705.87          10.85      792189      80.13
WRITELOG                              7150.01        6699.36         450.64     3228609      15.19

These numbers are showing the majority of waits are for data pages to be read into the buffer pool – random reads, and the next most prevalent wait is for log block flushes to complete. The more PAGEIOLATCH_EX waits there are, the worse the performance is.

Data on 640GB RAID-0 SSDs, log on SATA RAID-10

 

Don't let this graph fool you – the top and bottom of the scale are only 30 seconds apart. Basically moving the data files from the SCSI arrays to the RAID-0 SSD got around a 3-5x performance gain, no matter how the SSDs are formatted.

Representative wait stats for a run of this test – one file:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              8459.65        7789.91         669.73     3207448      94.48
PAGEIOLATCH_EX                         440.27         392.51          47.77      828420       4.92

Representative wait stats for a run of this test – two, four, eight, or sixteen files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              7957.35        7356.01         601.34     3206855      95.75

The log is the obvious bottleneck in this configuration. 

Data and log on 640GB RAID-0 SSDs

 

And again – high and low values are only 25 seconds apart. Moving log off to the same SSD gave a further 45%-ish improvement across the board, with little difference according to how the SSDs were formatted.

Representative wait stats for a run of this test – any number of files:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              2955.69        2184.99         770.69     3203957      89.24
PAGEIOLATCH_EX                         330.11         288.89          41.23      653147       9.97

The percentages fluctuate up and down a few percent depending on write format and number of files, with the maximum write performance format tending to have a slightly higher percentage of WRITELOG waits than the other two formats.

Note that moving the log to the SSD as well as the data files drastically cuts down the number of WRITELOG waits – what we'd expect.

Data and log on single 320GB SSD

 

The performance numbers for having everything on a single 320GB SSD are only a tiny amount slower than those for two 320GB SSDs – which is what I'd expect.

Representative wait stats for a run of this test – one file with basic format or improved write performance format:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              2911.22        2121.05         790.17     3204459      81.44
PAGEIOLATCH_EX                         602.11         546.56          55.55      758271      16.84

And for one file with maximum write performance format:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              3363.11        2523.63         839.48     3204110      87.54
PAGEIOLATCH_EX                         428.68         406.77          21.92      412081      11.16

You can see that the higher amount of PAGEIOLATCH_EX waits leads to lower overall performance. This makes sense to me.

Data and log on two 320GB RAID-1 SSDs

 

Now, I have an issue with people using SSDs in RAID-0 because it's a single point of failure. In an environment that's going all out on high-availability, if I was using SSDs for performance, depending on the criticality of the data I'd want to at least double-up to RAID-1. For all the various configurations, moving from a single 320GB SSD to two of them in RAID-1 resulted in no more than a 10-15% drop in performance and it's still 3-5x faster than the SCSI setup.

Here's a representative set of wait stats for the entire set of tests:

WaitType                       Wait_S         Resource_S     Signal_S       WaitCount   Percentage
—————————— ————– ————– ————– ———– ———-
WRITELOG                              3949.44        3031.14         918.30     3204694      85.68
PAGEIOLATCH_EX                         608.62         555.98          52.65      692934      13.20

In general the RAID-1 configuration had more waits of both types than the single drive configuration.

Data and log on separate 320GB SSDs

 

Splitting the data and log make for a 5-20% improvement over having everything on a single 320GB SSD.

The wait stats for these configurations show the same trends that we've seen so far – slightly slower performance = slightly more PAGEIOLATCH_EX waits.

Data and log round-robin between separate 320GB SSDs

 

This confused me – the single file case is exactly the same configuration as the test case above, but the results (for each test being run 5 time and then averaged) were almost 10% faster for the first two formats. No significant differences for the other configurations.

The wait stats for these configurations show the same trends that we've seen so far – slightly slower performance = slightly more PAGEIOLATCH_EX waits.

Best-case performance for each number of data files

 

 

 

Well big surprise – the SSDs outperform the SCSI storage for all these tests. The improvement factor varied by the number of data files:

  • 1: SSD was 7.25x faster than SCSI
  • 2: SSD was 4.74x faster than SCSI
  • 4: SSD was 6.81x faster than SCSI
  • 8: SSD was 7.64x faster than SCSI
  • 16: SSD was 9.03x faster than SCSI

The configuration of 4 data files on one SSD and the log on the other SSD, with basic format for both, was the best overall performer, beating the best SCSI configuration (2 data files) by a factor of 4.96.

Summary

Reminder: this test was 32 million inserts with no reads or updates (i.e. no random IO). It is very important to consider the limited scenario being tested and to draw appropriate conclusions.

My conclusions are as follows:

  1. For a random read+write workload, the method of formatting the Fusion-io drives doesn't make much difference. I'd go for the basic format to get the higher capacity, but I'd always to a representative load test to make sure.
  2. For a random read+write workload, the SSDs give at least a 5x performance gain over iSCSI storage
  3. Once again, having multiple data files outperforms having a single data file in most configurations
  4. I can easily correlate IO-subsystem related wait stats to the varying performance of the various configurations

Compared to the sequential insert workload that I benchmarked in the previous set of tests, the random read+write workload makes it worth investigating the investment of moving to SSDs.

Just like last time, these results confirm what I'd heard anecdotally – random operations are the sweet-spot for SSDs.

Brent's playing with the server over the next 4 weeks so I won't be doing any more benchmarking until mid-September at least.

Hope these results are interesting to you!