3.23.41 and .42 threads problems
I have posted before regarding a problem with mysql 3.23.41 hitting some sort of threshold limit and spawing threads like crazy. I have seen others post here with the exact symptoms, from what I understand these are all linux boxen. I have personally tested it with the 2.4 series of kernels, and others have reported the same behaviour in the 2.2 series. From what I'm reading, we all experience: 1) Number of concurrent queries and, subsequently, threads increasing rapidly 2) CPU utilization reaching 100% in seconds 3) load levels reaching 100+ in minutes 4) RAM behaving as normally as possible under the circumstances So far, the only fix I have found, despite a ton of suggestions from this list and a linux sys admin list I queried, has been to downgrade to 3.23.32. Which obviously is not optimal, because of all the cool new stuff in the later releases. I don't feel like I can post this to the bugs list because of the strict rules regarding the bug script there. It is obviously a problem tho, since more and more people are reporting identical behaviour. So. Are there patches not mentioned in INSTALL that we should be applying? Is there someone who can help get this to the developers' attention? Can anyone provide any information on this? Thanks jenn - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL is hogging my box
(to answer a couple of posts at once): Our machine was seeing less than 20 connects / sec. The problems continued after we broke largeish (although only about 350,000 records, indexed) tables into smaller ones and verified/optimized all code that makes mysql queries. We have a good mix of selects, inserts, updates but as I said, not more than 20/sec and often quite a bit less. On a dual PIII 1Ghz with 1Gb of RAM... We use ISAM and MyISAM tables exclusively. The largest table has less than 400,000 rows, the hardest hit (lots of tiny select statements, 3 or 4 per sec) has maybe 1000 rows. The queried tables make use of indices. The exact same configuration with the exact same number of requests, etc, ran perfectly on a RH6.2 box, 800Mhz (single processor), 256 Mb RAM, using MySQL 3.23.32. We only very recently upgraded and haven't changed code that calls the database or number of requests, or any other external factor except hardware and upgraded to mysql 3.23.41 about a month later. Thanks for all the dialogue on this. jenn Rodney Broom wrote: From: Stefan Pinkert [EMAIL PROTECTED] There are some others with a similar problem(including me). Hi guys. I'd be really interested in knowing things like how many requests, and of what type, are being made of your database(s). If you're making a couple of dozen SELECTs per day, then I'd say that you have a problem, but if you're doing 500,000,000 INSERTs and 1 Bil. SELECTs, then I could see some call for your systems to slow down. --- Rodney Broom Programmer: Desert.Net - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
linux load level possibly solved
Today our servers got the highest consistant level of activity I've ever seen, almost all of it because our users were reloading a mysql-database driven message board like crazy. Fortunately, I was awakened at 7.30am by my mysql 3.23.41 machine dying again, and in utter frustration I backed off all the way to 3.23.32, which I was running successfully on this same hardware previously. My load level has gone up to around 10 today because of all the connections and some poor coding, but it *has recovered*. Yesterday, running on .41, this would have been the kiss of death. So I don't pretend to know what's going on with .41, but I've backed off to a release that I know works and am quite happy. I can say with certainty that it is not the 2.4 linux kernel causing problems in my case (YMMV as always). I'm sure the mysql development team will work it out soon, and I'll upgrade. Till then...sticking to what I know. Thanks for all the help and advice. jenn - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL and Perl
PHP's mysql_fetch_array() fetches an associative as well as indexed array...or you can specify which. (I'm a huge fan of perl, btw, and have used it to talk to mysql when PHP was just a baby language so no flames...just setting the record straight...) Cheers jenn Rich Duzenbury wrote: PHP has built in functions that will dump an entire row into an array (this works with CSV and SQL databases).well there is my 2 cents worth on PHP+MySQL Um, not to start a language war, perl also can dump a row into an array, as well as into a hash so that one can refer to fields by name, not just ordinal number. Regards, Rich - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
load level on linux mysql server out of control
I'm running mysql 3.23.41 on a PIII 800 Mhz machine with 512MB RAM, linux kernel 2.4.7, dedicated machine (ie, not running anything other than MySQL). I've been running mysql in a production environment for nearly 2 years, moderately hit (500,000 - 800,000 database connects per day) with no problems until very recently, and I'm trying to figure out what's going on. I just installed the 3.23.41 from source about 2 weeks ago, and fairly shortly thereafter I started seeing my load levels increase dramatically. This was on a faster machine with 1GB RAM...last week the hard drive developed bad sectors on a part of the disk where one of my larger and more frequently written tables lived, and that machine died a horrible death. So I chalked the load level increase up to bad hard drive, put the above-described machine in its place, and the load levels went thru the roof again. Ran isamchk and myisamchk -r on all problem tables. Verified the disk integrity...but yesterday the *new* disk failed at a block containing another big and heavily hit table started with the bad blocks...caught this one in time and moved the table someplace else. Two disks in one week makes me think of power fluctuations, and I'm wondering if this could be causing me to think the problem is MySQL and really it's a power spike during a table write?? And I wouldn't be seeing the same thing on the web server because it's not written to very often, unlike the mysql server... I'm having a lot of trouble tracing the origin of the problem -- sometimes it seems that accessing a particular large table is causing it, sometimes it seems that a combination of factors is causing it. Regardless, what I observe is that within 1 minute my load level climbs from between 2 and 4 to over 100, which I have never seen on any *nix system before. The RAM utilization is high, but not over 85%, and the CPU utilization fluctuates of course but stays below 40% user until whatever is causing my problems happens, and then it jumps to 100% and doesn't come down until I kill mysqld and let everything close. The database is being accessed almost entirely by PHP calls from php4.0.6 running with apache 1.3.20, using PHP's built in mysql functions. The web server lives on a different machine.Does anyone know of any problems with PHP and the newer versions of MySQL? What about large table handling on linux? I realise that if the tables aren't constructed properly they could cause problems, but these tables aren't *that* big...the data files are no more than 200Mb. And they seem to be using indexes correctly, and they've been running fine for nearly 2 years. These are mostly ISAM tables, if that makes a difference. This has been going on for the better part of a week now and I'm about out of guesses. We have combed our code for places where database connections aren't closed properly, we've split large tables off and checked indexing, we've even moved a high-volume read-only database onto the webserver itself to help lessen the load, and I don't know what else to do. If anyone can help, it will be greatly appreciated. TIA jenn - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
