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
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
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 immediately need,
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
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
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
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 are accessed
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 hardware.
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
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
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.
You need to delete/move
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 has
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
13 matches
Mail list logo
