Revisiting FreeBSD vs. Linux for MySQL

Dan writes "Jeremy Zawodny, who looks after all of Yahoo!'s MySQL servers says MySQL now runs very well on FreeBSD. He is no longer steering people toward Linux. There are two important things you should do to make the FreeBSD/MySQL combo work well: (1) build MySQL with LinuxThreads rather than FreeBSD's native threads, and (2) use MySQL 4.x or newer."

Comments

or (3) pkg-add -r postgresql7

[DrSkwid]

cos i thinks that's newer than mysql will ever be 8)

Re:or (3) pkg-add -r postgresql7

[Pathwalker]

Personally, I like using "cd /usr/ports/databases/postgresql7 && make install" rather than using a binary package, as that way you have the source code on your system, and you can use all of the wonderful things in the contrib directory.

tsearch is a very nice GIST indexed full text search that does word stemming.
reindexdb is a handy way to regenerate all of the indices in a database without interrupting anything.
earthdistance is far faster than writing the same thing as a SQL function.
ltree is wonderful when you have to deal with a hierarchy.

And those are just the ones I remember offhand...

Re:or (3) pkg-add -r postgresql7

[TheRaven64]

Up to a point this is true. However MySQL does win on one point, namely that if you do not need most of the features of a real RDBMS then it is faster than Postgres. If you are just using it as an information store for a web site, for example, then it may be a better choice. As always, right tool for the right job.

Re:or (3) pkg-add -r postgresql7

[lowmagnet]

And PostgreSQL is easier to work with. And setting up PgSQL is a breeze. And..

I could go on all day about why I don't use MySQL. Just because a great percentage of a particlar market is using something, it doesn't mean they are right. (viz: Microsoft products, on the whole, are a pain in the ass.)

Re:or (3) pkg-add -r postgresql7

[nsayer]

# On PostgreSQL: SELECT relname FROM pg_class WHERE reltype='r'

Or just \d (if you're using psql).

Re:or (3) pkg-add -r postgresql7

[MattRog]

The problem is that, since people don't know the fundamentals of relational theory they don't know they don't need the 'features' (which in my mind, are a requirement).

This is why those of us that do know get flapped when those that don't tell us it is not necessary. See the problem?

Re:or (3) pkg-add -r postgresql7

[ViVeLaMe]

and let's not forget VACUUMDB.
Want to claim back all this space lost when you deleted something? guess what, you'll have to lock your database. greeeaaat.

And it's so sloooooooow that now i have to dump/restore the DB every week.

And don't even mention database replication: you can do that on mySQL (with the logs), while the postgreSQL team is still struggling with this one.

linux threads on freebsd -release or -stable

[JDizzy]

Given that FreeBSD -current 1:1 threads are not 100% yet, the native FreeBSD threads will not grant the optimal performance compared to the linux threads. Yahoo probably uses a RELEASE version, or a -STABLE version of FreeBSD on their production systems, so the KSE probably isn't an option anyways. Once KSE is finished, I'm sure we will reviste the "FreeBSD V. Linux" threads war again. No granted I'm a bit biased toward FreeBSD, but I think that since the same folks control the LIBC taht are also creating the KSE (kernel scheduled Entities, aka kernel aware threads) that FreeBSD will have a bit tighter integration when all things are said and done.

OpenBSD, too

[chrysalis]

Please note that on 3.3-STABLE and -current, MySQL is also finally extremely stable on OpenBSD, with native threads.

A lot of threading-related work has been made during the 3.3 development cycle and there are no more unexpected crashes with this sort of apps. For instance the new threading code solved all issues I had with the Oops proxy, that is now very stable on production servers.

Time to make world

[xA40D]

The article mentions that some things have been fixed in 5.0. Which could make some feel that upgrading to 5.0 would be a smart idea. However, FreeBSD hackers, being a conservative bunch, would disagree.

Thankfully, any worthwhile fixes in CURRENT will usually be backported to the STABLE. For example:

From the article:
The problem of MySQL occasionally thinking that all databases had vanished resulted from FreeBSD's non-threadsafe implementation of realpath().

CVS log for src/lib/libc/stdlib/realpath.c
MFC: make realpath thread-safe.

So personally me thinks a make world would be an idea sometime soon.

Anticipatory scheduler

[placiBo]

I'd like to see similar comments running the anticipatory scheduler for Linux and a quad processor SMP box vs FreeBSD. Thats where the differences in SMP performance and the threading implementation will show.