>>>>> "Rick" == Rick Moore <rick@stripped> writes:
Rick> Hi Monty! <snip>
>> FreeBSD has also some problems with mutexs handling and will easily
>> do a full context switch if two threads hits the same mutex at the
>> same time (which gets ever more likely as you get more threads).
>> One way to fix this would be to introduce 'fast' mutex that lets a
>> thread steal a mutex if no-one has the mutex, even if someone is
>> waiting for it. This could give you a boost of 10-30 % on FreeBSD,
>> as FreeBSD has very slow context switch handling!
Rick> I'll never have more than 15 threads.
Rick> Sounds great; are you proposing a MySQL code change, or is this
Rick> an existing compile or tuning option? In other words, is there
Rick> something I can do?
No, this is something that has to be done in the FreeBSD thread
package. If some FreeBSD developer wants to talk to me about adding a
very fast mutex, feel free to drop me a line.
>> I don't want to start a WAR here, but it would be really
>> interesting to know how Linux would work in your situation; FreeBSD
>> may be faster in handling disks, but Linux should be better to
>> context switch. I don't really know which thing is more important
>> for you :( (Linux is much better than FreeBSD on handling multiple
>> CPU:s, but at least for the moment the CPU doesn't seem to be your
Rick> Funny you should mention it. I did switch to Linux for the past
Rick> month, but I didn't run any serious benchmarks. Sorry.
Ouch:) It would have been very interesting to know the difference in
your setup :(
Rick> I can say this: For my application, MySQL is more stable on
Rick> FreeBSD 3.4 than it was on RedHat Linux 6.?, plus I get a
Rick> time-tested 64bit file system. I wish it supported kernel
Rick> threads for SMP, but oh well. Linux certainly has an advantage
Rick> in that respect. Both are great OS's though.
>> Another issue, have you taken a look at the HEAP tables in 3.23 ?
>> Can you have any use of these?
Rick> Yep, I use one to cache info out of a very slow query so I don't
Rick> need to execute it very often. Works great!
Rick> There is another possibility, but it involves massive changes in
Rick> code and I most certainly would need to get more RAM before
Rick> trying it: I might be able to create "mini-tables" on the heap,
Rick> and then merge them into the main table on a periodic basis.
Rick> Off the top of my head, it would cause 50% more queries, but 66%
Rick> would be on the heap. I'd cut the queries to the disk table in
Rick> half with the exception of some kind of occasional INSERT ...
INSERT should work good on MySQL 3.23, as long as you don't do a
deletes on this table; While MySQL fils in 'wholes' for old deleted
rows, it can't use concurrent inserts.
Rick> I need to give this more thought.