Hi guys,
Still using 3.1 here. At any given time we have about 200 to 300 jobs in the queue,
with fast render times and full verbosity in logging. So the current repository setup
is getting thrashed and interaction in the Monitor is s-l-o-w…
We’re looking into moving our repository onto a dedicated disk set (currently running off the mirrored system partition).
Should I treat our Deadline server as a type of webserver, ie. many small transactions?
I’d like to know what would be the optimal configuration (ie. disk type, stripe size and cluster size)
for such a busy production environment. Anyone with (good or bad) experience with a specific setup?
Cheers!
Dennis
We’ve made some significant performance improvements in Deadline 4.0, so if upgrading is a possibility, we would definitely recommend it.
Solid state drives help a lot. Two of our three offices switched to SSDs back when we were using 3.1, and there was a major performance improvement. Now that we’re on 4.0 and SSDs, it’s even better. Here is a quote from one of our IT guys about our setup:
Hope this information is helpful.
Cheers,
Hi Ryan,
Thanks for the pointers. So I take it Deadline mostly benefits from io peformance over raw throughput?
Just checked princing for the x25-e’s. In Europe they’re completely overpriced, so I’m looking into
getting a couple of 15k rpm Cheetah’s instead.
In terms of cluster size when formatting the disk, is there a sweet zone?
Cheers!
Dennis
Yeah, most of Deadline’s operations are file read/writes to the repository, so hi IO performance helps a lot. Our lead IT guy has been working on a whitepaper about backends for Deadline, but it’s low priority with regards to all the other things he needs to deal with on a day to day basis. 
I’ll check with him and see if I can get more information for you.
Cheers,
Hey Dennis,
Here’s what our IT guy recommends:
Not advisable to mess with cluster size use the native block size of the device only. For stripe size, lower is better as there will be a whole lot of small writes and reads. Use a hardware controller with real cache memory and directly supports the write caching and ncq (for sata) will pay off.
If he can swing it putting the jobs folder in a ram based filesytem will net huge performance gains though they would need to delete/archive more frequently.
Faster the Ethernet link the better the overall perf. Doing port teaming and trunking will pay off as will poor man trunking which is multiple nics each with different IP and dns name round robin resolution to balance (will not be ‘balanced’ but is better than a single link).
Hope that helps!