AMD64 and thread stack size
It looks like the default thread stack is not large enough for MySQL 4.1 on Linux running on AMD64. With NPTL, the database quickly crashed after a few hours of heavy load (segv). Without NTPL, I believed it wasn't the case. But after one week mysqld process were stuck in a strange state. They weren't doing anything, just as if they were waiting for a dead lock. It didn't happen with MySQL 4.0 on the same hardware. Bumping up the thread stack to 256 K seems to fix the issue, both with and without NPTL. Best regards, -Frank. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
2 gigs limits on MyISAM indexes?
Is there a limit on the size of .MYI files? I have a database that worked flawlessly until today. I can't restart it, it immediately freezes. I noticed that the .MYI file of a table has reached exactly 2 gigs. May it be related? Is there anything to do in order to recover the data and to keep the server working? Best regards, -Frank. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: 2 gigs limits on MyISAM indexes?
On Fri, Jan 28, 2005 at 04:00:24PM +, Mat wrote: What Operating System are you running this on? Linux 2.6, 64 bits. MySQL 4.1.9. Also, is there anything in the errorlog? Nothing, but as soon as I restart the server, it enters a strange state where all slots are full with unauthenticated connections that never die. No real query seems to be running any more. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Rows_sent vs Rows_examined
Just wondering... I have this simple join: SELECT b.id_commentaire AS id_commentaire, id_skynaute, id_article, created_on, read, expediteur, email, text FROM comment_base AS b LEFT JOIN comment_content AS c USING (id_commentaire) WHERE id_skynaute = 4671022 AND id_article = 58366086; id_commentaire is the primary key of comment_base and comment_content tables. id_skynaute and id_articles are non-unique keys of comment_base. The slow query log shows: # Query_time: 9 Lock_time: 0 Rows_sent: 1601 Rows_examined: 3187 EXPLAIN shows that only indexes are used: id_article from comment_base and id_commentaire (primary key) from comment_content. My obvious question is: why 3187 rows were examined since everything is indexed and there's only one matching entry of the comment_content table for every comment_base entry? Best regards, -- Frank - my stupid blog: http://00f.net -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
InnoDB status: why do I see MyISAM requests?
Just curious... While running SHOW INNODB STATUS, the list of transactions for each sessions part shows queries that are only related to MyISAM tables. Is it the expected behavior? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: problems with php 4.3.9 / mysql 4.1.7
On Wed, Dec 08, 2004 at 11:25:55AM +0100, Bogdan TARU wrote: Everything went ok, up until the point when I tried linking PHP-4.3.9 against MySQL-4.1.7. After starting the new Apache/PHP (ldd httpd shows '/usr/local/mysql-4.1.7/lib/mysql/libmysqlclient.so.14'), I get a whole lot of Segmentation Faults in the Apache error log. Also, I have noticed in the PHP error log that a lot of MySQL queries aren't succesfully made (usually the error message is 'unable to save result set'). I noticed other MySQL 4.1 + PHP oddness, but with PHP 5 and Linux: http://00f.net/blogs/index.php/2004/11/28/bug_or_vulnerability_in_php_5_with_mysql_1 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
