List:General Discussion« Previous MessageNext Message »
From:Jeremy Zawodny Date:December 30 2002 9:21pm
Subject:Re: Replication priority / speed
View as plain text  
On Mon, Dec 30, 2002 at 01:21:49PM -0700, Matt Sturtz wrote:
> Hello, Jeremy, et al--  Thanks for the reply before...  Further questions:
> >> Is it possible to set either set the priority ('nice') of the Slave
> >> thread down so it doesn't do that?
> >
> > The slave thread only?  No, not really.  You could nice MySQL when you
> > start it up.  But I'm not sure how much effect (positive or negative)
> > that'd have.
> When I run "show [full] processlist", there's an "Id" column, but it
> doesn't corrospond with the Unix PID of the process (on OS's that
> use a seperate PID for each thread-- like Linux does)...


> Is there any way to(easilly) figure out which PID is handling the
> slave thread, so that I might re-nice it after it's already been
> started up?

Not that I know of.  From MySQL's point of view there's no way to

> >> Or, alternatly, is there a way to limit the slave thread to only "X"
> >> bin-log transactions per second?
> >
> > There is not.
> Any plan to add this feature?  I would think it'd be useful...

I've not heard of any.  You can always lobby to get it on the MySQL
TODO list.

> > Are your updates already well optimized?  If you're doing enough work to
> > cause noticeable speed problems, I'd double-check that if you
> > haven't already.
> MyTOP says our key efficiency is 97.35%, with an average of 1.24
> q/sec (on the master-- most queries are done directly on the slave,
> with only updates happening on the master).  We've optimized things
> as best we can.  The problem is our customers are allowed to
> bulk-load keywords into our database, which causes about 4 large
> tables to be updated quite a bit.  Whenever this happens, the slaves
> struggle to get caught back up...

Ahh, okay.  I buy that.

Jeremy D. Zawodny     |  Perl, Web, MySQL, Linux Magazine, Yahoo!
<Jeremy@stripped>  |
Replication priority / speedMatt Sturtz26 Dec
  • Re: Replication priority / speedJeremy Zawodny27 Dec
    • Re: Replication priority / speedMatt Sturtz30 Dec
      • Re: Replication priority / speedJeremy Zawodny30 Dec
      • Re: Replication priority / speedDan Nelson30 Dec
        • Re: Replication priority / speedJeremy Zawodny30 Dec
  • Re: Replication priority / speedSimon K. Grabowski30 Dec
    • Re: Replication priority / speedMatt Sturtz31 Dec
  • Re: Replication priority / speedSimon Grabowski1 Jan