Re: mysql memory optimization - AMD 64 - odd crashes
Our Opteron server should be arriving today, so I can't provide a whole lot of insight. 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]
Re: mysql memory optimization - AMD 64 - odd crashes
First, what version are you using? 4.0.20? 4.0.18 as provided by Suse with 9.1 Professional. 64 bit 4.0.20 64bit crashes 'out of the box' (segfault as I start it). I just filed a bug report for that 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 yes. I am refering to key_buffer_size. My tables are rather large. The data is log data (one table for each day) and the MYI files are of the order of 2-4 GByte for each day. The intend of setting key_buffer_size to 8 GByte was to keep 2-3 days worth of indexes buffered (the last 2-3 days, which are the most 'popular' for queries). 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? currently trying that out. Its a bit hard to nail this down, as I am still setting things up and the load is low (compared to the production copy). Takes about 5 hrs or so right now for the DB to crash. I did see a bug report related to 'load table from master' with may apply, as I am using this command to populate the database while testing. 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). No core file so far. But i managed to get a (very brief) erorr message. All it tells me is that is caught a 'signal 11'. No backtrace :-( I know I haven't really answered your question; just listed what I would look at. Thanks for trying ;-) -- Johannes Ullrich [EMAIL PROTECTED] pgp key: http://johannes.homepc.org/PGPKEYS contact: http://johannes.homepc.org/contact.htm There are two kinds of system administrators: The first kind solves problems with little shell scripts. The second kind are the problem. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
mysql memory optimization - AMD 64 - odd crashes
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? -- Johannes Ullrich [EMAIL PROTECTED] pgp key: http://johannes.homepc.org/PGPKEYS contact: http://johannes.homepc.org/contact.htm There are two kinds of system administrators: The first kind solves problems with little shell scripts. The second kind are the problem. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
