On 23/09/16 19:12, Miguel Gila wrote: > We also do this, run a number of Slurm clusters attached to a single > slurmdbd. One issue with this is setup is that once you decommission > a cluster, it needs to be removed from the DB somehow, otherwise your > DB grows beyond reasonable size...
For accounting reasons we can't do that, consequently our slurmdbd is around 17GB in size. To give you an idea the largest table is the job step table for our BlueGene/Q which takes almost 7GB for pushing 19 million job steps. The next largest is the job step table for one of our x86 clusters which is around 3GB for 8 million job steps. Neither cause us any issues these days (we used to have a problem when, for complicated historical reasons, slurmdbd was running on a 32-bit VM and could run out of memory). Admittedly we do have beefy database servers. :-) All the best, Chris -- Christopher Samuel Senior Systems Administrator VLSCI - Victorian Life Sciences Computation Initiative Email: [email protected] Phone: +61 (0)3 903 55545 http://www.vlsci.org.au/ http://twitter.com/vlsci
