J
James Palmer
Guest
There's a lot of levers here but myself and Paul Koufalis (actually mostly Paul) have done a bit of research here for a workshop we held at EMEA PUG last year. Here's a quick summary of what we found. -B - bigger is not better. 512 should suffice. -TB 64 -TMB 64 -TM 32 -thread 1 (default for Enterprise but no harm specifying) -datascanthreads - you can happily increase this until it doesn't go any faster. Usually 1-2x CPUs is the limit. -SG always use 64 -threadnum -mergethreads These 2 have an interesting relationship. You don't want to have too many threads as a result of these, but we think that in general you want to have one small, the other big. But experiment. You don't want to have more threads than 2x CPUs though. So in your case 8. Try using 2 for one and 4 for the other, then switch and see which is better. -TF 80 - use 80% of RAM available. The more RAM you make available the better, but you can't allocate all of it as the system needs to run still. If you can persuade the sys admins to make more RAM available for the actual build it will help HUGELY. -z -rusage - these add extra logging to the output. In particular you want to aim for 0 writes to disk during sort/merge. That's the holy grail anyway. The more RAM you make available the more likely it is. Hope that helps! Let us know if it makes any difference.
Continue reading...
Continue reading...