Hi Dan, You never really say what your memory problems are. Is MySQL crashing because you're trying to use too much memory?
more comments inline.... On 5/11/06, Dan Trainor <[EMAIL PROTECTED]> wrote:
What I'm dealing with here is memory problems using MySQL 5.0.19 under FreeBSD. Although I've enabled allocation of more memory per-process, as described by the FreeBSD notes for 5.0.x, I'm still seeing problems.
[snip]
We're trying to make our database 'hot', and stick as much of it as we can, into memory. I see a few problems with the current configuration (hopefully others can see more problems than I do): I don't have a innodb_log_file_size in there. I think that I would benefit from using this one, because the default is 5M. I believe that our bottleneck has a lot to do with disk I/O as well, so I think bringing this up substantially would help.
Are your logs and data on a different partition? If not, put them on different partitions, preferably different disks.
If we have four ibdataN files of 500M each, there's no way that we can make this database 'hot', especially when taking into consideration that this is a 32bit platform. On top of that, our innodb_buffer_pool_size is set to 1600M.
ibdata files set up a tablespace allocation for innodb tables. This is the max they can get to, and MySQL reserves the disk space so nobody else can touch it. But what goes into memory is actual data and indexes. So memory isn't going to take 2,000M -- unless your tablespace is totally full. At least that's my understanding of it. Seems a waste to allocate memory for data that don't exist!
Another idea would involve dumping a 32bit platform in favor of a 64bit platform, and just throw more memory at it. But who's employer would be fond of that? ;)
Mine for one! You want your database hot, and in memory, ...but why? For performance? Performance for your paying customers? Who are currently complaining? Then buying hardware that can have more memory is a good investment. Basically, the question is, "do you really need your database in memory or not?" If so, your employer should be willing to spend the money. If not, your employer should be willing to deal with the fact that the db is not in memory, and any resultant slow performance. A rhetorical question to think about: How do you know your entire database isn't in memory? -Sheeri -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
