On 15/12/15 13:20, Heitor Faria wrote: > Suggestion: http://bacula.us/tuning/
Whilst that page is a good starting point, a couple of points are flat out wrong: EG: setting maximum block size in tapes - DON'T SET THIS - EVER (unless the driver manufacturer advises it) Compression should only _ever_ be used on disk backups (tapes generally have their own hardware compression engines) and not at all if the underlaying filesystem uses compression (eg: ZFS) LTOs run so fast that disk spooling needs to be solid state (ramdisk or SSD) on SATA3/SAS2 Hardware RAID controllers are generally a waste of time on modern systems. Stick with MD-raid (This applies to Linux and BSD) 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. Define non-transparent huge pages. MySQL and PostGreSQL will both use them better than transparent ones. Enough memory is a critical factor. Put in as much as you think you need and then double it. 300 million file entries will need 48GB for PostgreSQL and at least double that for MySQL if you want to avoid swapping and keep the system usable for actual backups as well as database activities. A fast CPU isn't important until you do lots of database work. It's more important to keep the ram base speed as fast as possible - 1333MHZ instead of 800MHz, etc. If this means paying more for 8*32GB dimms instead of 16*16GB dimms, that's a worthwhile investment. The tuning recommendations for PgSQL are long-outdated. See postgresql.org for better ones (shared buffers should be much larger on large systems for starters) None of the above stuff is going to make any difference to the primary problem the OP has: - Extremely poor backup speed across the network to disk before attribute despooling takes place which also has extremely poor speeds. Something, somewhere is badly compromising disk and/or network throughput. The cause must be found/resolved before any other work can have meaningful results. ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
