Date: Tue, 10 Sep 2002 23:30:08 -0400 (EDT) From: hackers@d.sparks.net To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Dell 2650 SMP perf question Message-ID: <Pine.BSF.4.21.0209102323270.95205-100000@search.sparks.net> In-Reply-To: <20020910214001.GB84648@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Sep 2002, Dan Nelson wrote: > In the last episode (Sep 10), hackers@d.sparks.net said: > > I'm stumped at how little improvement using an SMP kernel gives in a > > Dell 2650. System is dual 2400 xeon processors, 2 GB ram. It's > > intended to be used as a database processor, among other things. A > > perl process that read and input file and updates simple records in a > > mysql database actually run much more slowly: processing ~2million > > records takes 817 seconds with SMP enabled and 262 seconds with it > > disabled. > > > > Simple things like some_program.pl < some_big_file | another_program.pl > > > > seem to take full advantage of the second processor, but this system > > is supposed to run mysql. > > Mysql is a threaded database, and FreeBSD's pthreads are user-space. > This means that mysql will only ever use one CPU, and disk I/O in one > thread will block all other threads. I'd be happy to see perl running on one CPU and mysqld on the other. What I understand that mysql is thread based and that it will only run on one CPU at a time. What I don't understand is why it take 3.5 times as long to run the same job when I enable SMP. > You can try: > > * Rebuilding the mysql port with USE_LINUXTHREADS=yes. This will help > lots if your mysql process is CPU-bound, and will help some if you > are heavily I/O bound. It's definately CPU bound. I'm building mysql independently of the ports, but I can figure out what that does. > * Switching to InnoDB tables, which cache much better than MyISAM > tables so you are more likely to get your data from RAM instead of a > blocking disk read. That's not a problem - disk IO is on the order of tens per second, tops. > * Splitting your single perl program into multiple ones that hit the > database simultaneously. You might be seeing a synchronization > effect where your perl and mysql processes are competing for a SMP > lock or something and the wrong one always wins. Now that would be interesting. Running multiple tasks on a single CPU system always slowed things down, but it's worth a try:) Thanks for the suggestions! --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0209102323270.95205-100000>