I had already updated the online manual at http://www.innodb.com. It warns
now about the 2 GB limit on memory usage in Linux x86.
InnoDB does not use the record_buffer of MySQL at all. But sort_buffer is
I think the danger lies in server overload: many ORDER BY queries may get
stuck in the 'sorting data' phase which will raise memory usage to 2 GB.
InnoDB - transactions, row level locking, and foreign key support for MySQL
See http://www.innodb.com, download MySQL-Max from http://www.mysql.com
John Kemp wrote in message ...
>Heikki & Jeremy,
>Thanks again for your help. I'll try it out and see how things go. I
>will just note that in most of the MySQL documentation talks about how
>one can set key_buffer or innodb_buffer_pool up to 75% of your maximum
>memory, which in the case of our db machines is 4GB. I have been
>monitoring our memory usage under load, and even with the numbers I
>listed below, I have not yet seen a server crash from 200 simultaneous
>connections, which has been our peak so far. We did see this a while
>back on an earlier version (we're now running 3.23.45-max) but our
>server has been running like this for 45 days and counting.
>So I guess this is more of a case (as Jeremy seemed to be suggesting)
>that this *might* happen if we have a lot of simultaneous, tricky
>queries (when we'd see lots of sort_buffer and record_buffer get
>allocated for each connection/thread)
>This also implies that if you're mostly using Innodb tables for querying
>that you probably wouldn't see this happening, because:
>1) Innodb doesn't lock the whole table - so simultaneous queries on the
>same table will get done faster, and thus memory will be freed up quicker.
>2) Does querying or updating the Innodb tablespace effect record_buffer
>and sort_buffer anyway?
>The more I think about it, the more I realize that since we started
>doing work with Innodb tables, our database memory problems have
>basically gone away.
>Any thoughts on that?
>Director, Software Development