While researching some performance issues at a Dynamics GP customer, I noticed that the SQL Server tempdb had been setup with four separate files. I hadn't seen that before, so I looked it up, and apparently it's a thing. I would have thought I would have come across this info before, but I'm pretty sure it's been a very, very long time since I looked into tempdb optimization.
- Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage contention and yields significantly better scalability. However, do not create too many files because this can reduce performance and increase management overhead. As a general guideline, create one data file for each CPU on the server (accounting for anyaffinity mask settings) and then adjust the number of files up or down as necessary. Note that a dual-core CPU is considered to be two CPUs.
- Make each data file the same size; this allows for optimal proportional-fill performance.
- Put the tempdb database on a fast I/O subsystem. Use disk striping if there are many directly attached disks.
- Put the tempdb database on disks that differ from those that are used by user databases.
His points get pretty technical, so I don't follow all of the details. But it seems that multiple tempdb files are generally a good idea, so you may consider monitoring performance before going nuts and creating 8 tempdb files.
And yes, the fact that I'm reading this stuff, with interest, after 8pm on a Thursday evening does concern me as well.