FreeBSD tests

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 http://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
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.

PREVIOUS POST
NEXT POST

Comments

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

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

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *