TempDB and SSDs

Question

TempDB and SSDs

Lexa

Hall of Fame

Points: 3314
More actions
December 21, 2012 at 7:32 am

#268509

Has anyone noticed a significant boost in performance from running their TempDB on SSDs?

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

MyDoggieJessie SSC-Forever Points: 44484 More actions · Answer 1

I can't say for tempdb specifically but have noticed improvements for IO operations from other DB's running on SSD, I recommend you run some testing using IOMeter or similar tool to simulate tempdb activity

______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

Lexa Hall of Fame Points: 3314 More actions · Answer 2

MyDoggieJessie (12/21/2012)
I can't say for tempdb specifically but have noticed improvements for IO operations from other DB's running on SSD, I recommend you run some testing using IOMeter or similar tool to simulate tempdb activity

IOMeter - are you referring to this? http://www.iometer.org/

Seems kind of old...

MyDoggieJessie SSC-Forever Points: 44484 More actions · Answer 3

Yep that's the one. It may be old but it works. "Electricity" is quite old, but still works all the same 😀

______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

Lexa Hall of Fame Points: 3314 More actions · Answer 4

MyDoggieJessie (12/22/2012)
Yep that's the one. It may be old but it works. "Electricity" is quite old, but still works all the same 😀

I'm trying to measure performance of two storage arrays. One is not doing anything and the other has production system on it. When I run IOMeter on the system that has production on it, are the numbers going to be skewed because it already has a load on it? Is the comparison going to be accurate in my scenario?

Also what is the proffered setting for # of Outstanding I/Os per target? I've seen posts where people use 16 or 32. Is this setting supposed to be our average queue length?

Thanks

MyDoggieJessie SSC-Forever Points: 44484 More actions · Answer 5

Yes it will be skewed. These types of tools need to be run for bench-marking purposes prior to anything being put on the disks (so the numbers can be more true). Yes that represents the queue length and from what I've read, I don't believe there's any benefit going beyond 32

The # of Outstanding I/Os control specifies the maximum number of outstanding asynchronous I/O operations per disk the selected worker(s) will attempt to have active at one time. (The actual queue depth seen by the disks may be less if the operations complete very quickly.) The default value is 1.
Note that the value of this control applies to each selected worker and each selected disk. For example, suppose you select a manager with 4 disk workers in the Topology panel, select 8 disks in the Disk Targets tab, and specify a # of Outstanding I/Os of 16. In this case, the disks will be distributed among the workers (2 disks per worker), and each worker will generate a maximum of 16 outstanding I/Os to each of its disks. The system as a whole will have a maximum of 128 outstanding I/Os at a time (4 workers * 2 disks/worker * 16 outstanding I/Os per disk) from this manager.

The user's guide for IOMeter can be viewed here

______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience