On Thu, Nov 5, 2009 at 11:47 PM, Alan Hodgson ahodgson@simkin.ca wrote:
On Thursday 05 November 2009, Rudi Ahlers Rudi@softdux.com wrote:
According to google search, errorcode 28 means the HDD is full. But it isn't:
root@vps:[~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 84G 18G 62G 23% / none 640M 0 640M 0% /dev/shm /usr/tmpDSK 485M 11M 449M 3% /tmp
What else could cause this kind of problem?
You only have 449MB free on /tmp. It could easily fill that up during the query, and then delete the file before you run df again. Run it while the query is executing, I bet you see /tmp filling up.
-- "No animals were harmed in the recording of this episode. We tried but that damn monkey was just too fast." _______________________________________________
Thanx, that seems to have solved the problem. I didn't think of checking to see if the tmp folder got full during the SQL statement execution. So, by increasing it to 1GB, the problem is solved
Rudi Ahlers wrote:
On Thu, Nov 5, 2009 at 11:47 PM, Alan Hodgson ahodgson@simkin.ca wrote:
On Thursday 05 November 2009, Rudi Ahlers Rudi@softdux.com wrote:
According to google search, errorcode 28 means the HDD is full. But it isn't:
root@vps:[~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 84G 18G 62G 23% / none 640M 0 640M 0% /dev/shm /usr/tmpDSK 485M 11M 449M 3% /tmp
What else could cause this kind of problem?
You only have 449MB free on /tmp. It could easily fill that up during the query, and then delete the file before you run df again. Run it while the query is executing, I bet you see /tmp filling up.
Thanx, that seems to have solved the problem. I didn't think of checking to see if the tmp folder got full during the SQL statement execution. So, by increasing it to 1GB, the problem is solved
I've seen mysql do dumb stuff like building a huge temp table in a 3-way join before evaluating any of the WHEN clause that would eliminate most of it, but does it really have to make a copy of a single table to pick a random chunk?
On Fri, Nov 6, 2009 at 12:44 AM, Les Mikesell lesmikesell@gmail.com wrote:
Rudi Ahlers wrote:
On Thu, Nov 5, 2009 at 11:47 PM, Alan Hodgson ahodgson@simkin.ca wrote:
On Thursday 05 November 2009, Rudi Ahlers Rudi@softdux.com wrote:
According to google search, errorcode 28 means the HDD is full. But it isn't:
root@vps:[~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 84G 18G 62G 23% / none 640M 0 640M 0% /dev/shm /usr/tmpDSK 485M 11M 449M 3% /tmp
What else could cause this kind of problem?
You only have 449MB free on /tmp. It could easily fill that up during the query, and then delete the file before you run df again. Run it while the query is executing, I bet you see /tmp filling up.
Thanx, that seems to have solved the problem. I didn't think of checking to see if the tmp folder got full during the SQL statement execution. So, by increasing it to 1GB, the problem is solved
I've seen mysql do dumb stuff like building a huge temp table in a 3-way join before evaluating any of the WHEN clause that would eliminate most of it, but does it really have to make a copy of a single table to pick a random chunk?
-- Les Mikesell lesmikesell@gmail.com
This could very well be the case. The website in question is written in PERL (yea, I know.....) and the client doesn't really pay much for us to look into the code to see if it can be optimized either. So I just have to make sure the VPS copes with it. But for now it's working fine :)
Rudi Ahlers wrote:
What else could cause this kind of problem?
You only have 449MB free on /tmp. It could easily fill that up during the query, and then delete the file before you run df again. Run it while the query is executing, I bet you see /tmp filling up.
Thanx, that seems to have solved the problem. I didn't think of checking to see if the tmp folder got full during the SQL statement execution. So, by increasing it to 1GB, the problem is solved
I've seen mysql do dumb stuff like building a huge temp table in a 3-way join before evaluating any of the WHEN clause that would eliminate most of it, but does it really have to make a copy of a single table to pick a random chunk?
This could very well be the case. The website in question is written in PERL (yea, I know.....) and the client doesn't really pay much for us to look into the code to see if it can be optimized either. So I just have to make sure the VPS copes with it. But for now it's working fine :)
There's nothing inherently wrong with perl for web programming and it doesn't have anything at all to do with the query passed to mysql. There are some quirks with apache/mod_perl that might matter for efficiency, though.
On Fri, Nov 6, 2009 at 1:02 AM, Les Mikesell lesmikesell@gmail.com wrote:
Rudi Ahlers wrote:
What else could cause this kind of problem?
You only have 449MB free on /tmp. It could easily fill that up during the query, and then delete the file before you run df again. Run it while the query is executing, I bet you see /tmp filling up.
Thanx, that seems to have solved the problem. I didn't think of checking to see if the tmp folder got full during the SQL statement execution. So, by increasing it to 1GB, the problem is solved
I've seen mysql do dumb stuff like building a huge temp table in a 3-way join before evaluating any of the WHEN clause that would eliminate most of it, but does it really have to make a copy of a single table to pick a random chunk?
This could very well be the case. The website in question is written in PERL (yea, I know.....) and the client doesn't really pay much for us to look into the code to see if it can be optimized either. So I just have to make sure the VPS copes with it. But for now it's working fine :)
There's nothing inherently wrong with perl for web programming and it doesn't have anything at all to do with the query passed to mysql. There are some quirks with apache/mod_perl that might matter for efficiency, though.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________
well, let me put it this way ( I should have said it in the previous email), the code was written about 6 years ago, and the developer has since "dissapeared", so it's old & outdated. PERL is good, I agree, but PERL programmers are few and far apart where we are, so it's a bit of a pain to keep up.
-
Les Mikesell -
Rudi Ahlers