We got approx 80 mio entries in the file table and I confirm Alan. Before, we had MySQL 5.5 with 24GB buffer ram, but attribute insertions took ages. Then we migrated the DB to PostgreSQL and the issue resolved.
1 year ago, we migrated the physical backup Server to a vCenter VM and lowered the memory of the VM dramatically to 4GB (not kidding). No issues since then. Speed is still really good. We do B2D2T. > Am 17.12.2015 um 12:34 schrieb Uwe Schuerkamp <uwe.schuerk...@nionex.net>: > > On Tue, Dec 15, 2015 at 05:16:42PM +0000, Alan Brown wrote: >> >> MySQL works ok for small sites but doesn't scale well. PostgreSQL is a >> heavy load on small installations but will keep running long after MySQL >> has decided to use all your system ram and swap too. The breakeven point >> is about 10-15 million entries. Beyond that point MySQL needs endless >> tuning and PostgreSQL doesn't. > > > Hm, I cannot confirm your observation here. Our largest catalog has > 600,000,000 file table entries on a 64GB server that also runs the > director with about half of that allocated to the innodb buffers, and > while it's not exactly a speed daemon when restoring stuff it's also > no slouch, backing up over 300 clients and about 10TB of data on > average every day. I doubt postgres would perform much better with a > similar sized catalog on the same hardware. > > We're using MariaDB 5.5x if that has anything to do with it. > > All the best, > > Uwe > > > > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
