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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EEE3ED.6080304>