Building a new workstation - dual or quad-core CPU for FreeBSD 7?

[Kris Kennaway]

Philip M. Gollucci wrote:
> 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 ?

libthr has been around (and performing better than libkse) since the 5.x 
days and has been recommended for use since 6.0.

> 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 at 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

Should be swap backed, but it won't make much difference on your workload.

> 	(I'm thinking of using tmpfs in 7.0 when I switch)

tmpfs is not yet production-ready even though it performs better.

> 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

You want '0' or performance will suck.  There's a basic architectural 
flaw in how mysql handles non-zero concurrency values here (innodb 
accesses are serialized by a global mutex that protects a counter to 
check if it should try to allow more innodb concurrency.  Duh.)

Anyway, assuming your disks can keep up you should see a big performance 
boost when you switch to 7.0.  This is a fairly big "if" though: I don't 
know if it's even feasible for a write-heavy database to saturate 8 CPUs 
instead of being bottlenecked by disk speeds and leaving the CPUs mostly 
idle.

Kris