phphulp db fout ?
Bij de eerste Query (het rijtje links boven de 10 laatste berichten) verscheen ook een fout melding.
Wat was er aan de hand ?
Kunnen we hier nog wat van leren, voor onze eigen website (hosting) ?
Moderators ? Bas ? Kunnen jullie iets melden ?
Wat was er te zien ? :
- een eigen globale opmerking: fout in query..... (zonder specifikaties)
- maar de (waarschijnlijk) echte fout melding: Error writing file '/tmp/MYMvVOfS' (Errcode: 28)
- en er was een complete query te zien, waar zo op het oog geen fout in zat.
(Wat me wel opviel waren wel de quotes !! stukje sql : " FROM `php_forum_msgs` " )
Wat me interesseert...
Hoe kun je zomaar een fout krijgen van het schrijven naar tmp ?
(pad veranderd ?)
- Roland - op 21/04/2013 23:44:45:
Hoe kun je zomaar een fout krijgen van het schrijven naar tmp ?
(pad veranderd ?)
(pad veranderd ?)
Meest waarschijnlijke oorzaak: disk vol. Errcode 28 is de standaard foutcode om dit aan te geven.
Dat het pad veranderd is, lijkt me niet waarschijnlijk. Als je op een Unix-systeem /tmp hernoemt, dondert zo ongeveer de hele machine in elkaar. Zal het binnenkort voor de gein eens uitproberen. ;-)
Gewijzigd op 21/04/2013 23:56:23 door Willem vp
is het niet raar, disk ruimte vol bij een hoster !! (en dat uren lang)
En als je dan bij hoster kijkt staat op de site dat er geen problemen zijn !
Nb. hosters met 99.99% up time eigenlijk geloof ik het totaal niet ! Als het niet openbaar is en ze het gewoon niet vertellen, weet ja haast niemand het !!
[en misschien bedoelen ze zolang de meeste mensen het niet hebben gemerkt tellen we het niet mee.... ]
Omdat /tmp in principe data bevat die niet lang bewaard hoeft te worden, is een dergelijk volume vaak ook niet heel erg groot (enkele honderden MB tot een paar GB) en kan het dus voorkomen dat daar een keer de rand van de disk bereikt is. Zelfs bij grote hosters. Voor software die geen (of weinig) gebruik maakt van /tmp is het ook geen probleem als dat volume vol zit, dus die blijft dan wel doorhobbelen.
Op onze servers wordt de ruimte in /tmp overigens ook niet gemonitord. Ik heb eigenlijk geen idee of dat bewust is, of dat het er tussendoor is geglipt.
Toevoeging op 22/04/2013 00:52:33:
Ozzie PHP op 22/04/2013 00:42:23:
Je eigen schijfruimte kan toch ook vol zijn? Heeft toch niks met de hoster te maken? Je sluit een abonnement af voor een x aantal GB. En dan kan het zo zijn dat die ruimte een keer vol is.
Gezien de foutmelding was het hier /tmp, en die valt niet bij alle hosters onder het quota-regime, omdat niemand die bij zijn volle verstand is daar gegevens neerzet die langer dan een paar minuten bewaard moeten worden.
Overigens is de foutcode als je je quota bereikt hebt ook anders: 122 (Disk quota exceeded)
Gewijzigd op 22/04/2013 00:56:07 door Willem vp
Er zat een fout in je SQL query!
Error writing file '/tmp/MYRD9hNW' (Errcode: 28)
Query:
SELECT id,cid,title,DATE_FORMAT(postdate, '%Y-%m-%d %H:%i:%s') as last_post,DATE_FORMAT(replydate, '%Y-%m-%d %H:%i:%s') as last_reply FROM `php_forum_msgs` WHERE closed IS NULL AND cid != 5 AND cid != 24 AND cid != 7 ORDER BY `replydate` DESC,`postdate` DESC LIMIT 0,10
kun je dat uitleggen ?
Is er een (rechtstreeks) verband met je query en het wel of niet gebruik van tmp bestanden ?
Gewijzigd op 22/04/2013 11:12:15 door - Roland -
Er waren wat webhosting problemen, hierdoor was de MySQL tmp dir even in de war.
Wanneer MySQL niet voldoende geheugen heeft (dit kun je instellen in my.cnf in /etc/mysql/ meestal) dan zal het je /tmp file storage gebruiken om dit te doen. Je kunt dit voorkomen door meer geheugen toe te kennen of nog beter je query te optimaliseren. Als je "EXPLAIN SELECT ..." uitvoert dan kun je zien of hij tmp tables gebruikt.
Kees Schepers op 23/04/2013 14:10:29:
@Roland, MySQL gaat tmp tables maken als je uit memory loopt.
Daarnaast kun je ook zelf temporary tables aanmaken. Je zou met select-queries data uit verschillende tabellen kunnen trekken en opslaan in een tmp-tabel. Daarna kun je weer queries loslaten op je tmp-tabel met (voorbewerkte) data. Vooral bij grote databases kan dit een aanzienlijke winst geven in performance, query-complexiteit en geheugengebruik.