On 4/2/12 3:33 PM, Phil Stracchino wrote: > On 04/02/2012 06:06 PM, Stephen Thompson wrote: >> >> >> First off, thanks for the response Phil. >> >> >> On 04/02/2012 01:11 PM, Phil Stracchino wrote: >>> On 04/02/2012 01:49 PM, Stephen Thompson wrote: >>>> Well, we've made the leap from MyISAM to InnoDB, seems like we win on >>>> transactions, but lose on read speed. >>> >>> If you're finding InnoDB slower than MyISAM on reads, your InnoDB buffer >>> pool is probably too small. >> >> This is probably true, but I have limited system resources and my File >> table is almost 300Gb large. > > Ah, well, sometimes there's only so much you can allocate. > >>> --skip-lock-tables is referred to in the mysqldump documentation, but >>> isn't actually a valid option. This is actually an increasingly >>> horrible problem with mysqldump. It has been very poorly maintained, >>> and has barely developed at all in ten or fifteen years. >>> >> >> This has me confused. I have jobs that can run, and insert records into >> the File table, while I am dumping the Catalog. It's only at the >> tail-end that a few jobs get the error above. Wouldn't a locked File >> table cause all concurrent jobs to fail? > > Hmm. I stand corrected. I've never seen it listed as an option in the > man page, despite there being one reference to it, but I see that > mysqldump --help does explain it even though the man page doesn't. > > In that case, the only thing I can think of is that you have multiple > jobs trying to insert attributes at the same time and the last ones in > line are timing out. > > (Locking the table for batch attribute insertion actually isn't > necessary; MySQL can be configured to interleave auto_increment inserts. > However, that's the way Bacula does it.) > > Don't know that I have any helpful suggestions there, then... sorry. > > >
Thanks again for the response, just bouncing this issue off someone is of help. You idea about the jobs simply running into contention for locks sounds reasonable, though I never saw this happening with MyISAM (in the 3+ years we've run bacula, and I see it the 2nd night into running InnoDB). If so, I wouldn't mind estimating the maximum time my jobs might have to wait for a lock, based on their size and concurrency, but I really hate just tweaking settings in the DB without knowing why I'm doing so, you know. I'd like to get to the bottom of what's causing the timeout. thanks, Stephen -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu 215 McCone Hall # 4760 404.538.7077 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
