Hi,
> Strange. My understanding was that RAID 5 was good for read bandwidth
> but that keeping the parity disk uptodate slowed it down for write
> bandwidth.
Well, what you say is almost true to a certain extent. Firstly, with RAID 5
parity is striped across the disks too, so there is no bottleneck with the
parity writing, just a slight overhead. So, RAID 5 isn't the fastest RAID
schema (that's RAID 0) but it's still faster than RAID 1, as the data still
only has to be written once overall (as opposed to one copy on each disk).
I've just thought of something else that might also warrant looking into. A
few of the guys at MySQL advocate using RAID 0+1 for the greatest speed. As
far as I remember, RAID 0+1 is where you have the data striped across two
disks, and those disks are mirrored on another pair.
> > Your Opened_tables figure is quite large, which means you are incurring
> > extra I/O penalties as tables have to be constantly opened and
> closed. You
> > should try increasing your table_cache size.
>
> Its already 2024 (I've upped it from 128). What is the maximum
> reasonable value on RedHat Linux 6.2 and a 2.2.X kernel. Would upgrading
> to RedHat 7.1 and 2.4.x help?
Hmm. I'm not sure exactly, but with RH 6.2 I don't think you'll be able to
increase this much more as I seem to remember the file descriptor limit is
2000-something. I may be wrong though... (It may be only 6.0 that has that
limit.)
> > Slow_launch_threads should never be more than zero. And, seeing as your
> > configured slow launch yardstick time is 2 seconds, this
> indicates you may
> > be starting to have a bottleneck here. You should trying setting a
> > thread_cache_size of something like 32 - maybe higher.
>
> Ok. Although 1 out of 346,157 doesn't seem to be significant. After the
> server has been up a week or two I can tell if this is significant. What
> is the downside of a thread_cache? Why isn't it on by default?
Having a thread cache is useful for environments with high frequencies of
MySQL connections. When a client connects, a new thread is created (you may
notice from the status variables that your Connections and Threads_created
are the same figures). To quote from the manual:
"When a client disconnects, the client's threads are put in the cache if
there aren't more than thread_cache_size threads from before. All new
threads are first taken from the cache, and only when the cache is empty is
a new thread created."
So, having a thread cache reduces latency on new connections to MySQL from
client apps - which can only be a good thing, yes? Granted, 1 out of 346,157
isn't significant in itself, but it's a good idea to pre-empt a potential
load problem. As far as I know, there is no downside of having a thread
cache (aside from the inevitable memory usage, etc.). As for why it isn't
turned on by default, I have no idea.
> We are running everything through a 100 Mbps switch.
> I can certainly take 3 or 4 very query instensive clients and set them
> up to use read only clients. Does it make sense to do it that way? Also,
> all the queries go through a perl module of mine, so I could distribute
> everything, but does it make sense to distribute updates?
It really depends on what replication topology you employ. If you go for a
'1-way' or 'one master, many slaves' topology then having your read-only
clients use the slave servers would make sense. All your read/write clients
could also read in a distributed fashion but would write only to the master.
If, however, you employed a '2-way' or 'many-masters' topology then the
issue of distributing updates occurs. However, '2-way' replication has whole
load of issues that you need to tip-toe around carefully (such as
auto-increment fields clashing values). Unless your environment has a high
update load too, then you probably don't need to worry about distributing
updates.
Regards,
Basil Hussain
---------------------------------------
Internet Developer, Kodak Weddings
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
