First, what version are you using? 4.0.20? The 64-bit or 32-bit version? Knowing the version might help. If this is not a production machine, you might want to try using the version from the MySQL website
Also, I noticed a bug that might be applicable the other day when reviewing what was coming up in 4.0.21 (the URL is http://bugs.mysql.com/bug.php?id=3754). It had to do with values > 4 billion being used in the client for things like myisam_max_sort_file_size (the values work fine in the my.cnf). It's a longshot, but just in case.... Check the bugs fixed between the version you are running and the latest - might find some insight there.
By key-cache, are you referring to the variable "key_buffer_size"? If so, keep in mind that the key-buffer is for MyISAM, and only caches the indexes. From, http://dev.mysql.com/doc/mysql/en/MyISAM_key_cache.html
* For index blocks, a special structure called the key cache (key
buffer) is maintained. The structure contains a number of block
buffers where the most-used index blocks are placed.
* For data blocks, MySQL uses no special cache. Instead it relies on
the native operating system filesystem cache.Your database would have to be huge to have 4 gig worth of indexes. What if you try to scale it back to 2 gig (or less) and let it run for a few days?
Does it generate a core file? There is a setting to specify the size of a core file; not sure if it turns the generation of a core file on or off (http://dev.mysql.com/doc/mysql/en/mysqld_safe.html and search for "|--core-file-size=size"). Once you had the core file, you might want to talk to the people on the development list, and see if one of them is willing to take a look at it (assuming they can - might need a 64-bit system to do so).
I know I haven't really answered your question; just listed what I would look at.
David |
Johannes B. Ullrich wrote:
I just started setting up a dual opteron system with Suse 9.1 (x86_64). At this point, I am sticking with the Suse provided rpms.
I am having some odd mysql restarts (crashed with immediate restart by safe_mysqld). Odd part about it: not a single line in the error log. The connections just drop and come back as the client tries to reconnect.
One possible issue I figures is the way I try to use memory.
Does MySQL allow to allocate more then 4 GByte of RAM? Right
now, I am using 4 GByte for key-cache alone. So it doesn't complain, and appears to use about 5 GByte at the time
it crashes (the machine has 16 GByte RAM). But does it cause
instability to use that much key-cache?
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
