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:
[EMAIL PROTECTED]:/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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
