To add to what Kris stated, we have several databases that are a bit over a 3rd of a Tera-Byte on a single instance. That instance has 8 - 2GB MDF/NDF files and 1 - 2GB LDF file. We do some seriously heavy lifting in all of those databases in the form of batch files on top of one of them being the primary OLTP database. We've never needed more than 2GB of TempDB on any given run.

My point about having larger problems before is that you REALLY need to check code that causes TempDB growth over that for accidental Cross Joins in the form of many-to-many joins and, perhaps, use some "Divide'n'Conquer" methods to take control over large monolithic queries that have more than 10 joins. And it's not just for the sake of TempDB... it's for the sake of performance and the overall reduction of what is usually gross unnecessary use of resources such as memory, TempDB, CPU, and I/O.

If, as a DBA, you're just killing long running or high resource usage SPIDs, then you're not really doing your job as a DBA. Yes, I know it's because someone hasn't done THEIR job as an intelligent/skilled developer but, quite literally, "forgive them for they know not what they do" and then start teaching them a better way. Simply killing SPIDs will drive an even bigger wedge between you and the people who don't know what they're doing. [font="Arial Black"]HELP THEM[/font] instead of just sitting in an ivory tower killing SPIDs as they crawl by. It'll be good for you, good for them, and good for the company that's paying all of you to work smarter.