I’m continuing my experiments with different OS and today I tested FreeBSD 6.0 on my box.
(more details about box and benchmark see here https://www.percona.com/blog/2006/06/13/quick-look-at-ubuntu-606/).
Initially I was very pessimistic about FreeBSD, as results were (in transactions/sec, more is better.
for comparison the results from Suse 10.0):
| InnoDB | |||
| threads | FreeBSD 6 | Suse 10.0 | Suse/ FreeBSD ratio |
| 1 | 436.97 | 536.91 | 1.23 |
| 4 | 322.08 | 816.27 | 2.53 |
| 16 | 519.94 | 639.05 | 1.23 |
| 64 | crash | 547.07 | |
| 256 | 357.09 | ||
| MyISAM | |||
| threads | FreeBSD 6 | Suse 10.0 | Suse/ FreeBSD ratio |
| 1 | 335.56 | 429.89 | 1.28 |
| 4 | 165.16 | 863.23 | 5.23 |
| 16 | 322.66 | 537.67 | 1.67 |
| 64 | crash | 516.00 | |
| 256 | 346.65 |
The crash with many threads in FreeBSD is known problem and is not MySQL fault. More info is available in FreeBSD bug report
I’m not big expert in FreeBSD and did not saw http://wikitest.freebsd.org/MySQL before. This page recommends to use libthr instead of libthreads.
The results with libthr looks better:
| InnoDB | |||
| threads | FreeBSD 6 | Suse 10.0 | Suse/ FreeBSD ratio |
| 1 | 483.22 | 536.91 | 1.11 |
| 4 | 852.21 | 816.27 | 0.96 |
| 16 | 748.89 | 639.05 | 0.85 |
| 64 | 644.45 | 547.07 | 0.85 |
| 256 | 273.99 | 357.09 | 1.30 |
| MyISAM | |||
| threads | FreeBSD 6 | Suse 10.0 | Suse/ FreeBSD ratio |
| 1 | 344.72 | 429.89 | 1.25 |
| 4 | 531.6 | 863.23 | 1.62 |
| 16 | 494.19 | 537.67 | 1.09 |
| 64 | 451.72 | 516.00 | 1.14 |
| 256 | 215.84 | 346.65 | 1.61 |
Interesting thing with 4-64 threads FreeBSD is better than Suse in InnoDB benchmark. I think it is related to InnoDB’s implementation of syncronious primitives. For MyISAM Suse is stable better.
Configuration params:
Box: Dual Core Athlon 3800+, 1Gb of RAM, Motherboard ASUS A8N-E
MySQL 5.0.22
params for InnoDB:
–innodb-buffer-pool-size=500M –max-connections=500
params for MyISAM:
–key-buffer-size=500M –max-connections=500 –skip-innodb
Suse 10.0:
kernel-smp-2.6.13-15.x86_64
NTPL
Schedulers comparsion.
By request I made tests with 4BSD scheduler:
| InnoDB | |||
| threads | FreeBSD 6 ULE | FreeBSD 6 4BSD | 4BSD / ULE |
| 1 | 483.22 | 438.1 | 0.91 |
| 4 | 852.21 | 819.14 | 0.96 |
| 16 | 748.89 | 712.77 | 0.95 |
| 64 | 644.45 | 639.2 | 0.99 |
| 256 | 273.99 | 330.11 | 1.20 |
| MyISAM | |||
| threads | FreeBSD 6 ULE | FreeBSD 6 4BSD | 4BSD / ULE |
| 1 | 344.72 | 324.9 | 0.94 |
| 4 | 531.6 | 518.96 | 0.98 |
| 16 | 494.19 | 476.57 | 0.96 |
| 64 | 451.72 | 444.77 | 0.98 |
| 256 | 215.84 | 258.42 | 1.20 |
Interesting with 256 threads BSD scheduler looks better.
Both servers was just cleanly installed, or something was tuned (except libthr switching)?
Suse is not cleanly installed, it is my everyday test server, but I did nothing special to tune it.
FreeBSD was recompiled to support 2 CPU and with ULE scheduler.
So out of curiosity what was the mysql configuration, and how much memory on the machine?
suse 10 has nptl or linuxthreads ? and what kernel version ?
Added more info about box and Suse
from http://wikitest.freebsd.org/MySQL
> There have been several reports that running with the 4BSD > scheduler offers better scheduling for MySQL workloads
> over the ULE scheduler.
Added tests ULE vs 4BSD schedulers
Which my.cnf was used ? There is big difference between default my.cnf and my-huge.cnf when
benchmarking with super-smack and myisam
R_T_F_M,
Yes, params inluences a lot.
I used next configs:
–port=3306 \
–socket=/tmp/mysql.sock \
–user=root $LOGERR \
–datadir=$FSPATH \
–basedir=$BASEPATH \
–max_connections=3000 \
–max_connect_errors=10 \
–table_cache=2048 \
–max_allowed_packet=1M \
–binlog_cache_size=1M \
–max_heap_table_size=64M \
–sort_buffer_size=64K \
–join_buffer_size=1M \
–thread_cache=16 \
–thread_concurrency=16 \
–thread_stack=196K \
–query_cache_size=0 \
–ft_min_word_len=4 \
–default_table_type=MYISAM \
–transaction_isolation=REPEATABLE-READ \
–tmp_table_size=64M \
–skip-locking \
–server-id=1 \
–innodb_status_file=0 \
–innodb_data_home_dir=$FSPATH \
–innodb_data_file_path=ibdata1:100M:autoextend \
–innodb_log_group_home_dir=$FSPATH \
–innodb_buffer_pool_size=256M \
–innodb_additional_mem_pool_size=20M \
–innodb_log_file_size=900M \
–innodb_log_files_in_group=2 \
–innodb_log_buffer_size=8M \
–innodb_flush_log_at_trx_commit=1 \
–innodb_lock_wait_timeout=300 \
–innodb_locks_unsafe_for_binlog=1 \
–innodb_thread_conurrency=0
What about testing 6.1 and/or the upcomming 6.2 (beta versions are available)?
Alexander,
We do not use FreeBSD 6.1 and 6.2 on our servers.
Maybe somewhen when we have access to such servers we will test it.
I am very disappointed, as we are using Linux and always I heard FreeBSD is more faster, more better vs..
What to be disappointed about ? If you’re using Linux and it looks faster you should be happy with your choice 🙂
Also there are newer versions of FreeBSD which show serious performance gains for some workloads.
Look here for more info
http://jeremy.zawodny.com/blog/archives/000697.html