From: Date: July 3 2008 8:17pm
Subject: RE: mutex contention for the query cache
List-Archive: http://lists.mysql.com/internals/35780
Message-Id: <82624B02DA0A3C4691069A83007F651D01C1E78D@SNV-EXVS08.ds.corp.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Any clue of how often a thread cannot get to the query cache on first
try?

=20
Rick James
MySQL Geeks - Consulting & Review

=20

> -----Original Message-----
> From: MARK CALLAGHAN [mailto:mdcallag@stripped]=20
> Sent: Thursday, July 03, 2008 10:45 AM
> To: internals@stripped
> Subject: Re: mutex contention for the query cache
>=20
> On Thu, Jul 3, 2008 at 10:28 AM, MARK CALLAGHAN=20
> <mdcallag@stripped> wrote:
> > Things have changed from 5.0.37 to 5.0.62. Someone added spin lock
> > behavior for non-windows platforms. Work is still done to initialize
> > the search key after the lock is obtained. But that work does not
> > include memory allocation.
> >
> > Any chance the inlined spin lock can get put into a class so we have
> > some chance of reuse?
> >
>=20
> And astute readers will notice this isn't a spin lock as it sleeps
> immediately after each failure to get the lock.
>=20
> > From Query_cache::send_result_to_client():
> >
> > #ifdef __WIN__
> >  STRUCT_LOCK(&structure_guard_mutex);
> > #else
> >  stop_time=3D my_clock()+(ulong)lock_time_treshold*CLOCKS_PER_SEC;
> >  while ((lock_status=3D=20
> pthread_mutex_trylock(&structure_guard_mutex)) =3D=3D EBUSY
> >         && spin_count < spin_treshold
> >         && new_time < stop_time)
> >  {
> >    spin_count++;
> >    if (spin_count%5)
> >      new_time=3D my_clock();
> >    my_sleep(0);
> >  }
> >
> >  if (lock_status !=3D 0)
> >  {
> >    /*
> >      Query cache is too busy doing something else.
> >      Fall back on ordinary statement execution. We also mark this
> >      query as unsafe to cache because otherwise this thread will
> >      still be halted when the result set is stored to the cache.
> >    */
> >    thd->lex->safe_to_cache_query=3D FALSE;
> >    goto err;
> >  }
> > #endif
> >
> >
> > On Thu, Jul 3, 2008 at 10:20 AM, MARK CALLAGHAN=20
> <mdcallag@stripped> wrote:
> >> The query cache has a mutex that is locked while it is=20
> searched. This
> >> is not a spin lock, so many threads will go to sleep when there is
> >> contention. And it is made worse because work is done to create the
> >> search key in Query_cache::send_result_to_client() (work =3D=3D =
memory
> >> allocation and other byte copying) after the mutex is locked.
> >>
> >> Are there plans to fix this?
> >> I don't have benchmark results (yet), but I am willing to bet that
> >> this is a problem.
> >>
> >> --
> >> Mark Callaghan
> >> mdcallag@stripped
> >>
> >
> >
> >
> > --
> > Mark Callaghan
> > mdcallag@stripped
> >
>=20
>=20
>=20
> --=20
> Mark Callaghan
> mdcallag@stripped
>=20
> --=20
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:   =20
> http://lists.mysql.com/internals?unsub=3Drjames@stripped
>=20
>=20