Re: MySQL on an SMP system - exploiting it

From: Gordon Burditt <gordonb.irm6s_at_burditt.org>
Date: Tue, 23 May 2017 20:08:26 -0500
Message-ID: <M7udnaPiYcyXQLnEnZ2dnUU7-d_NnZ2d_at_posted.internetamerica>


>> You can't guarantee which core will be used when a request comes in.
>> Basically it will be whatever core is free at the time. It would be
>> quite inefficient to wait for core 2 to free up from some other
>> operation if core 1 is waiting for I/O, for instance.
>>

> 
> Right - so, if there are 2 cores, and core 1 is busy serving hit
> no. 1,  then when the 2nd hit comes in, it WILL go to core 2, right?

Not necessarily. Remember, core 1 may be busy handling the web server / PHP for hit #1, and core 2 may be busy handling MySQL for hit #1, and core 3 may be handling a running cron job, and core 4 may be handling networking interrupts for the response being sent for hit #1, and core 5 may be handling the web server log messages sent through syslog for hit #1, and core 7 may be handling the mail delivery for the email sent by by hit #1, and core 8 may be handling disk read-ahead for the web server instance for hit #1, and core 9 may be doing DNS lookups for the email sent by hit #1, .... Yes, I know you pre-supposed only two cores, but one hit can pass through many processes or threads and end up briefly using multiple cores simultaneously.

A process may change cores every time it does I/O, such as disk or networking, or when it loses scheduling. On a busy web server with lots of cores, it may be unusual for any single hit to use less than 80% of the cores (not necessarily simultaneously). Received on Wed May 24 2017 - 03:08:26 CEST

Original text of this message