July 25, 2014

FreeBSD tests

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 http://www.mysqlperformanceblog.com/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
threadsFreeBSD 6Suse 10.0Suse/ FreeBSD ratio
1436.97536.911.23
4322.08816.272.53
16519.94639.051.23
64crash547.07
256357.09
MyISAM
threadsFreeBSD 6Suse 10.0Suse/ FreeBSD ratio
1335.56429.891.28
4165.16863.235.23
16322.66537.671.67
64crash516.00
256346.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
threadsFreeBSD 6Suse 10.0Suse/ FreeBSD ratio
1483.22536.911.11
4852.21816.270.96
16748.89639.050.85
64644.45547.070.85
256273.99357.091.30
MyISAM
threadsFreeBSD 6Suse 10.0Suse/ FreeBSD ratio
1344.72429.891.25
4531.6863.231.62
16494.19537.671.09
64451.72516.001.14
256215.84346.651.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
threadsFreeBSD 6 ULEFreeBSD 6 4BSD4BSD / ULE
1483.22438.10.91
4852.21819.140.96
16748.89712.770.95
64644.45639.20.99
256273.99330.111.20
MyISAM
threadsFreeBSD 6 ULEFreeBSD 6 4BSD4BSD / ULE
1344.72324.90.94
4531.6518.960.98
16494.19476.570.96
64451.72444.770.98
256215.84258.421.20

Interesting with 256 threads BSD scheduler looks better.

About Vadim Tkachenko

Vadim leads Percona's development group, which produces Percona Clould Tools, the Percona Server, Percona XraDB Cluster and Percona XtraBackup. He is an expert in solid-state storage, and has helped many hardware and software providers succeed in the MySQL market.

Comments

  1. Both servers was just cleanly installed, or something was tuned (except libthr switching)?

  2. Vadim says:

    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.

  3. So out of curiosity what was the mysql configuration, and how much memory on the machine?

  4. stanojr says:

    suse 10 has nptl or linuxthreads ? and what kernel version ?

  5. Vadim says:

    Added more info about box and Suse

  6. johnny says:

    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.

  7. Vadim says:

    Added tests ULE vs 4BSD schedulers

  8. R_T_F_M says:

    Which my.cnf was used ? There is big difference between default my.cnf and my-huge.cnf when
    benchmarking with super-smack and myisam

  9. Vadim says:

    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

  10. What about testing 6.1 and/or the upcomming 6.2 (beta versions are available)?

  11. Vadim says:

    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.

  12. clipfish says:

    I am very disappointed, as we are using Linux and always I heard FreeBSD is more faster, more better vs..

  13. peter says:

    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.

  14. james says:

Speak Your Mind

*