| 1 |
>>>>> Any reason you're still using MyISAM tables? Innodb is almost as |
| 2 |
>>>>> fast |
| 3 |
>>>>> or much much faster than MyISAM in nearly every way these days. |
| 4 |
>>>> |
| 5 |
>>>> Can multiple processes be utilized for mysql like they are for |
| 6 |
>>>> apache2? Perhaps not since it's a database? |
| 7 |
>>> |
| 8 |
>>> Mysql is multithreaded and spawns a thread for each connection. |
| 9 |
>>> Try a |
| 10 |
>>> ps -efL and you should see a number of Mysql threads. However that is |
| 11 |
>>> part |
| 12 |
>>> of the problem with MyISAM. It throws a giant table lock blocking all |
| 13 |
>>> other |
| 14 |
>>> threads until the SQL statement is complete. Innodb uses row locks which |
| 15 |
>>> allows the other threads to use the table. |
| 16 |
>>> |
| 17 |
>>> As far as moving to Innodb tables it's actually easy, but with a |
| 18 |
>>> number of caveats. I'd lower your Apache max clients, tweak my.cnf, and |
| 19 |
>>> runs |
| 20 |
>>> some load tests before getting deep into Mysql. When you're ready I'd go |
| 21 |
>>> about this way. |
| 22 |
>> |
| 23 |
>> apache MaxClients has been lowered to 50 which is a shame because I |
| 24 |
>> have 30+ separate images on each of my pages and that number can not |
| 25 |
>> be reduced. This means I may not be able to serve more than 1 full |
| 26 |
>> page at a time. |
| 27 |
> |
| 28 |
> This is wrong. |
| 29 |
|
| 30 |
MaxClients is defined as "the limit on the number of simultaneous |
| 31 |
requests that will be served". If each of my pages requires 30 |
| 32 |
requests in order to be fully served, I don't think I'll be able to |
| 33 |
fully serve more than one page at a time. |
| 34 |
|
| 35 |
>>> 1. Make backups first. |
| 36 |
>>> 2. See if you have any full text fields. Tables with full text fields |
| 37 |
>>> will |
| 38 |
>>> have to remain MyISAM. |
| 39 |
>> |
| 40 |
>> Many of my tables have one or more fields defined as TEXT out of |
| 41 |
>> laziness. Should I instead come up with an appropriate char(N) |
| 42 |
>> declaration for each? Can N go as high as necessary? |
| 43 |
> |
| 44 |
> TEXT fields don't matter, FULL TEXT indexes do. Sorry my mistake. |
| 45 |
|
| 46 |
I don't have any FULL TEXT. Since TEXT is alright, I will be making |
| 47 |
the switch to InnoDB very soon. |
| 48 |
|
| 49 |
>> OK, just leave key_buffer at the default 16M? |
| 50 |
> |
| 51 |
> No. Make key_buffer 256M and then restart Mysql or update it from the |
| 52 |
> commandline. You're starving Mysql for resources. Fix this first. Then you |
| 53 |
> can mess around with tables and engines. |
| 54 |
|
| 55 |
Yep, I increased key_buffer when you told me to previously. |
| 56 |
|
| 57 |
- Grant |
Archives