Re: MySQL on an SMP system - exploiting it

From: Jerry Stuckle <jstucklex_at_attglobal.net>
Date: Mon, 22 May 2017 19:59:42 -0400
Message-ID: <ofvtr0$fn$1_at_jstuckle.eternal-september.org>


On 5/22/2017 12:55 PM, bit-naughty_at_hotmail.com wrote:

> On Sunday, May 21, 2017 at 7:56:18 PM UTC+5:30, John Levine wrote:

>> In article <59219546$0$821$e4fe514c_at_news.xs4all.nl>,
>> Luuk <luuk_at_invalid.lan> wrote:
>>> So, installing more RAM and an SSD wil make MySQL use both processors?
>>
>> Well, since you asked, all you have to do is to restructure your
>> applications to make at least two queries in parallel at all times.
>> The more the better.
> 
> Well - if the website gets 2 hits, and MySQL is busy serving hit no. 1 on the first chip, how do I make sure that hit no. 2 will get served by the second chip? Or, also, maybe the second core on the *same* chip?
> 

It sounds like you are shooting blind here. That won't fix your problem.

What you need to do is find the cause of your slow performance and fix it. It might be your code, the database design or any of a number of different things.

Just adding more RAM and an SSD won't necessarily solve your problem, no matter what the know-nothing TNP says. What will solve your problem is finding the cause and solving it.

That might include a lot of things - including the design of your database (often the biggest problem in a database), including indicies and even table design. Also RDBMS configuration can have a huge effect on performance.

[Quoted] [Quoted] What exactly is your performance problem? Is it the query itself? Is it the processing of that query? Or is it something else?

[Quoted] 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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================
Received on Tue May 23 2017 - 01:59:42 CEST

Original text of this message