EmergencyEMERGENCY? Get 24/7 Help Now!

FreeBSD tests

 | June 15, 2006 |  Posted In: Benchmarks

PREVIOUS POST
NEXT POST

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.

PREVIOUS POST
NEXT POST
Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.

15 Comments

  • 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.

  • 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

  • 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.

  • 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.

Leave a Reply

 
 

Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.

Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.

No, thank you. Please do not ask me again.