Hey Josh, I came in really late on this discussion. It's been my
experience that InnoDB is great until the size of the database/indexes
surpasses the amount of memory you can give to InnoDB for caching.
The performance drop off is pretty quick and dramatic. I've seen this
happen on live ta
On Fri, Sep 5, 2008 at 12:55 PM, Josh Miller <[EMAIL PROTECTED]> wrote:
> Aaron Blew wrote:
>>
>> Here are a couple ideas:
>> * Decrease innodb_autoextend_increment to 8 or even 4. You may see
>> additional IO wait because you're pre-allocating space in chunks
>> disproportinate to what you immedi
Aaron Blew wrote:
Here are a couple ideas:
* Decrease innodb_autoextend_increment to 8 or even 4. You may see
additional IO wait because you're pre-allocating space in chunks
disproportinate to what you immediately need, causing bursty performance.
* If your remaining MyISAM tables don't need it
Here are a couple ideas:
* Decrease innodb_autoextend_increment to 8 or even 4. You may see
additional IO wait because you're pre-allocating space in chunks
disproportinate to what you immediately need, causing bursty performance.
* If your remaining MyISAM tables don't need it, take 2GB of the ke
On Thu, Sep 4, 2008 at 6:43 PM, Josh Miller <[EMAIL PROTECTED]> wrote:
> We'd like to prove InnoDB and move onto that storage engine for the
> transaction support, MVCC, etc.. but we're finding that performance is poor.
Well, thousands of large InnoDB database users prove that the engine
itself ha
AM
To: Tom Horstmann
Cc: mysql@lists.mysql.com
Subject: Re: innodb/myisam performance issues
Tom Horstmann wrote:
> Addendum..
> Please also try increasing your innodb_log_file_size to a much higher
value
> if you
> have lots of writes/transactions. Maybe 250MB is a good first try.
>
Perrin Harkins wrote:
What you really need to do is look at which queries are slow and run
EXPLAIN plans for them. Most big performance problems like you're
describing are due to index issues, so that's where you should be
looking. Server tuning comes lat
We definitely need to work on re-des
Tom Horstmann wrote:
Addendum..
Please also try increasing your innodb_log_file_size to a much higher value
if you
have lots of writes/transactions. Maybe 250MB is a good first try.
You need to delete/move the InnoDB logs before restart.
Not sure about this, but please also set innodb_log_buff
On Thu, Sep 4, 2008 at 4:26 PM, Josh Miller <[EMAIL PROTECTED]> wrote:
> We're seeing a significantly higher percentage of IO wait on the system,
> averaging 20% now with the majority of that being user IO. The system is
> not swapping at all.
O_DIRECT may not be the best setting for your hardwa
between 16-32MB if you have many transactions.
TomH
-Original Message-
From: Tom Horstmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2008 11:15 PM
To: 'Josh Miller'
Cc: mysql@lists.mysql.com
Subject: RE: innodb/myisam performance issues
> The rows in this table
> The rows in this table are accessed concurrently as any activity on the
> site is recorded/added/updated to this table. We have several others
> which serve similar purposes, (sessions, totaltraffic, etc...).
Is the performance lag occurring with read-only queries and updates/inserts
to the I
Tom Horstmann wrote:
Hello Josh,
why you moved your table to InnoDB? Your description doesn't sound like the
tables rows
are accessed concurrently and need to be locked? Are you sure you need
InnoDB for this table?
If you need InnoDB you probably need to redesign your queries and table
structur
Hello Josh,
why you moved your table to InnoDB? Your description doesn't sound like the
tables rows
are accessed concurrently and need to be locked? Are you sure you need
InnoDB for this table?
If you need InnoDB you probably need to redesign your queries and table
structure to get them
more conv
13 matches
Mail list logo
