[GRLUG] FYI - old mysql and new gear

[scott.tanner at comcast.net]

I'm very familiar with nice, but its the taskset command I was referring to, which takes affect at the scheduler: 

http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html 


Regards, 
Scott 

----- Original Message -----
From: "Bob Kline" <bob.kline at gmail.com> 
To: "Mailing List for LUG in greater Grand Rapids, MI area." <grlug at grlug.org> 
Sent: Thursday, September 22, 2011 12:33:05 PM 
Subject: Re: [GRLUG] FYI - old mysql and new gear 

You can alter the "affinity," whatever 
that exactly means, but the scheduler 
apparently does not permit assigning 
a CPU to a task, useful as that sometimes 
seems like it would be. In fact, one's control 
over how CPU's are assigned seems 
rather limited. 


"Nice" - man nice - has long existed, 
starting in Unix, to allow one to alter 
process priority. If I remember 
correctly - if not, that's what man pages 
are for.... - a positive integer, up to 19, 
lowers priority, contrary to one's intuition, 
and can be done by an ordinary user. 
I believe you have to be root to increase 
priority, a.k.a. "niceness." 


Here again, the scheduler has the last 
word, but it's worth a try. 


-- Bob 




On Mon, Sep 19, 2011 at 4:45 PM, Michael Mol < mikemol at gmail.com > wrote: 


On Mon, Sep 19, 2011 at 4:36 PM, < scott.tanner at comcast.net > wrote: 
> Just thought I'd share an interesting discovery with the group. This may be 
> common knowledge to others, but it was a bit of a surprise to me. We're in 
> the process of upgrading the servers which run our primary MySQL DB's 
> (version 5.1): 
> 
> Old Server New Server 
> --------------------------------------------------------- 
> Sun X4200 Silicon Mechanics R516 
> 4 x 2.4GHz 12 x 3.2GHz (+ HT = 24 threads) 
> 16GB Ram 144GB Ram 
> 12 disks - SCSI 24 disks - SAS & SSD 
> 
> 
> After getting the new servers setup and our databases copied over, I ran 
> sysbench to get some performance benchmarks of the new servers. Surprise - 
> performance was nearly identical or slightly worse. I disabled HT, still no 
> real improvement. After a bit of searching on the web, I found the older 
> versions of MySQL had issues with multi-threading beyond 8 threads. I setup 
> an init script to hot-remove CPU's via sysfs, and voila - performance 
> increased substantially. There are patches from Yahoo, Google, and Percona 
> to correct this issue on the older MySQL versions, and the newer versions 
> are supposedly better at handling 32+ threads. 

Very interesting. 

A thought...Rather than removing your extra cores, perhaps there's 
some way to set CPU affinity, so MySQL is only allowed to use eight of 
them? That way, the other processes on your system can stay out of the 
way of your database server, and spend cycles on other cores. 

If you get affinities working, you might also consider running 
multiple instances of mysqld, putting different databases on different 
sets of cores. 


-- 
:wq 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
grlug mailing list 
grlug at grlug.org 
http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner , and is 
believed to be clean. 
_______________________________________________ 
grlug mailing list 
grlug at grlug.org 
http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20110922/10dfdd14/attachment-0001.html>