Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Sep 2007 16:30:37 -0400
From:      "Philip M. Gollucci" <philip@ridecharge.com>
To:        Kris Kennaway <kris@FreeBSD.org>
Cc:        "josh.carroll@gmail.com" <josh.carroll@gmail.com>, Maxim Khitrov <mkhitrov@gmail.com>, Aryeh Friedman <aryeh.friedman@gmail.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>
Subject:   Re: Building a new workstation - dual or quad-core CPU for FreeBSD 7?
Message-ID:  <46EEE3ED.6080304@ridecharge.com>
In-Reply-To: <46EC55B8.2090107@FreeBSD.org>
References:  <26ddd1750709141351i3646e9bdg8d8b7e93461167f9@mail.gmail.com>		<bef9a7920709141441r5c228a8bu1fcf2ea15868c3c@mail.gmail.com>		<26ddd1750709151014x2112b022r9bcb999fbf1e7e49@mail.gmail.com>		<46EC270A.3020100@FreeBSD.org>		<8cb6106e0709151421h7bfdeb6fo7dc671820294e9c7@mail.gmail.com>		<46EC4F59.7070104@FreeBSD.org>		<8cb6106e0709151435p72cd328by63895421f3a63ea4@mail.gmail.com>		<46EC50DA.6000104@FreeBSD.org>	<8cb6106e0709151446x4c54a520u2d5cd543ba1541e@mail.gmail.com> <46EC55B8.2090107@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote:
> Josh Carroll wrote:
>>> That's good to know.  You should be using libthr for threaded
>>> performance though :)  That benchmark is probably almost all userland
>>> though, so performance may not suffer much from libpthread.
>> Oh I wasn't sure if libthr was the preferred thread library for 6.2
>> also (I'd heard that was the case for -CURRENT).
>>
>> I should look into whether ffmpeg can be built with libthr instead and
>> compare performance. Somewhat off topic, so I'll leave it at that, but
>> thanks again for the great info. I'm really looking forward to
>> 7.0-RELEASE, obviously :)
> 
> Yeah, it is preferred on 6.x too (libkse has truly atrocious
> performance).  It's trivial to change it over, just add an entry to
> /etc/libmap.conf:
Really?  I didn't you you were supposed to switch until 7.0 -- were the
libthr chnages MFC'd and I missed it ?

I've read
http://people.freebsd.org/~kris/scaling/mysql.html
and
http://wiki.freebsd.org/MySQL

I've been following the discussions on this pretty closely on lists.

PU: Intel(R) Xeon(R) CPU           E5310  @ 1.60GHz (1597.53-MHz
K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f7  Stepping = 7

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x4e33d<SSE3,RSVD2,MON,DS_CPL,VMX,TM2,<b9>,CX16,<b14>,<b15>,<b18>>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 4
real memory  = 9395240960 (8960 MB)
avail memory = 8291323904 (7907 MB)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs

uname -a
FreeBSD hobbes.dca2.prod.rws 6.2-RELEASE FreeBSD 6.2-RELEASE #0:
root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP  amd64

I'll recompile the kernel eventually to slim it down.

using 4BSD scheduler since its 6.2

ls -1d /var/db/pkg/mysql*
mysql-client-5.0.45
mysql-scripts-5.0.45
mysql-server-5.0.45

ldd /usr/local/libexec/mysqld
mysqld:
        libz.so.3 => /lib/libz.so.3 (0x800a5c000)
        libwrap.so.4 => /usr/lib/libwrap.so.4 (0x800b70000)
        libcrypt.so.3 => /lib/libcrypt.so.3 (0x800c79000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x800d92000)
        libm.so.4 => /lib/libm.so.4 (0x800f89000)
        libpthread.so.2 => /lib/libpthread.so.2 (0x8010a5000)
        libc.so.6 => /lib/libc.so.6 (0x8011d0000)


sysctl kern.timecounter.choice
       kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0)
dummy(-1000000)

sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC

Disks are:
	1) RAID1(2 disks) OS array with mysql logs, replication logs,
		and innodb logs.
	2) RAID1+0(6disks) innodb mysql data.
	3) /tmp is a md0 malloc backed device
	(I'm thinking of using tmpfs in 7.0 when I switch)

using libmap.conf to use libc_r, libpthread, and libthr were all about
equal actually for insert heavy operations.

my.cnf
innodb_thread_concurrency = 8

At 16 aka core*2 'show innodb status' showed too much mutex locking and
dropping it had drastic improvements -- despite mysql recommending the
2x value.

innodb_flush_log_at_trx_commit = 0
Also helped about 7% but thats due to disk speeds.

I can run an oltp sysbench on it if you would like.



------------------------------------------------------------------------
Philip M. Gollucci (philip@ridecharge.com) c:323.219.4708 o:703.749.9295x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EEE3ED.6080304>