On Tue, 10 Sep 2002, Dan Nelson wrote: > In the last episode (Sep 10), [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
