Its def disk IO on the client OR disk/database io on the bacula director. Its all a symptom of too much VM on not enough hardware.
Jeff. > On Oct 30, 2014, at 2:26 PM, John Lockard <jlock...@umich.edu> wrote: > > Yes, but which IO? > > Disk IO on the client? > Network IO from the client to the network? > Network IO from the network to the Bacula Director? > Network IO from the Bacula Director to the Bacula SD? > Disk IO on the Bacula SD? > Database IO on the Bacula Director? > > > Seems like you have more work to do than just saying "it's the IO". Not sure > of the tools on Windows to interrogate IO at disk or network, but on > Linux/Unix a good place to start is the sar (sysstat) utilities. > > -John > > On Thu, Oct 30, 2014 at 12:20 PM, Jeff MacDonald <j...@terida.com > <mailto:j...@terida.com>> wrote: >>> >> Just be aware that you might not see a dramatic increase in speed just >> moving Bacula itself! >> >> If you are using VMWare with VMDK files on a VMFS volume you need to be >> aware that any IO by a guest requires a reservation of the entire VMFS >> volume. Locking is happening at the SCSI layer - if one guest wants to >> read one byte of data nobody else can do anything until its IO operation >> is complete. Remembering that you probably are only going to get around >> 75 IOPs you can see how a VMFS volume with more than a handful of >> virtual machines on it can very quickly end up performing very poorly, >> especially with spinning rust underneath it. A good RAID card with a >> LOT of cache memory can help with overall system performance, but >> backups by definition are going to be touching lots of areas of data >> that aren't likely to be in cache. >> >> What I'm getting at is you might actually need to focus your efforts and >> dollars on the storage underneath your VMs before you do too much with >> your backup system. A great big nice happy dedicated Bacula server >> would be nice, but if the VMs are still IOP constrained ESPECIALLY if >> they are actively in use while being backed up you probably won't see >> that much of an improvement. >> >> An easy way to validate this would be to ensure you have attribute >> spooling turned on and to set up the attribute spooling to write to your >> NAS rather than to local storage. That will get the VM storage >> infrastructure out of your backup pathway. >> >> Bryn > > This has been a fantastic education. Thanks. I’ll recommend to the client > that their IO is slow.. and I’ll get told “Oh! It seems fine to us!” :) > > > I googled and found documentation about turning on Data Spooling, but not > indepnedantly turning on Attribute Spooling. > > Could you point me at that please.. ( I know I Know.. I’ll keep looking :) ) > > Jeff. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > <https://lists.sourceforge.net/lists/listinfo/bacula-users> > > > > > -- > ------------------------------------------------------------------- > John M. Lockard | U of Michigan - School of Information > Unix Sys Admin | 105 South State St. | 4325 North Quad > jlock...@umich.edu <mailto:jlock...@umich.edu> | Ann Arbor, MI > 48109-1285 > www.umich.edu/~jlockard <http://www.umich.edu/%7Ejlockard> | > 734-936-7255 | 734-764-2475 FAX > ------------------------------------------------------------------- > - The University of Michigan will never ask you for your password - >
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
