Error 500 bij 1,5 GB textfile
Hetzelfde probleem doet zich voor als ik mysql_query() in een loop zet en er 7,5 miljoen query's zijn uitgevoerd.
Bij onderstaand script dus error 500 na 1,5 gigabyte (+/- 30 minuten). Iemand enig idee wat het probleem is?
Het gaat overigens om een P4, 2.8ghz, 512MB, FSB800, Windows XP Home computer met PHP 4.3.4 en Apache 2 (nieuwste).
Code (php)
en laat je dan stoppen
dus ga allebeide tijden opnemen als ze gelijk zijn licht het daaraan
Dan zegt apache ook, jah mijn hoela, je bent al zo lang bezig nu heb ik geen zin meer ;)
En even tussendoor: waarom een text-betand van 1.5GB?!?! Is dat om je pc uit te testen of staan daar ook daadwerkelijk gegevens in?
Het heeft te maken met het testen van de snelheid van een database. En het gaat sneller om eerst alles naar een TXT-file te schrijven en vervolgens met 1 query de database in te dumpen, dan 100 miljoen query's te gebruiken. Uiteindelijk zal de database gevuld worden met ongeveer 500 miljoen records, maar dan niet vanuit 1 bestand, maar vanuit 500 miljoen bezoekers. (hiervoor zijn dan ook heel veel server gekocht)
Wat voor site is dat, google????
Overigens zal er wat tijd overheen moeten gaan voordat 500 miljoen wordt bereikt, maar dit is een realistische inschatting voor over 1 a 2 jaar.
Is het een zoekmachine?
Overigens houd ik er zelf niet van mijn tabellen groter te maken dan (pak 'm beet) 1GB. Heeft niet zozeer met query-performance te maken, maar met de handelbaarheid van de tabellen. Tot 1GB kun je nog goed een extra index aanbrengen of je database eens optimaliseren, daarboven lopen de wachttijden vaak teveel op en heb je teveel diskruimte nodig voor de tijdelijke bestanden.
Om de data toch gemakkelijk te kunnen benaderen maak ik vervolgens een of meerdere views aan die de losse tabellen combineren tot 1 grote virtuele tabel. Zeker met 500 miljoen records is dat geen overbodige luxe. Ik beheer op mijn werk een database met meer dan 400 miljoen records. Toen die nog in 1 tabel zaten was de database onwerkbaar traag. Een delete van 1 record kostte ongeveer 38 minuten. Nu 15 seconden.
Gewijzigd op 24/01/2006 23:53:00 door Willem vp
Dat is inderdaad een handige methode die hier ook toegepast zal worden, maar er worden naar verwachting zo'n 100 miljoen tot 10 miljard records (kan ikzelf nog niet goed inschatten) per dag toegevoegd aan die tabel.
De INSERT-query's via PHP laten lopen had ook als reden de hele MyISAM engine en InnoDB engine te testen.
SELECT...WHERE query uit 50 miljoen gaat nu in 0,0004 seconde op een PC, meer dan acceptabel.
Hoe zijn jouw ervaringen daarmee?
PHPerik:
@Willem
Dat is inderdaad een handige methode die hier ook toegepast zal worden, maar er worden naar verwachting zo'n 100 miljoen tot 10 miljard records (kan ikzelf nog niet goed inschatten) per dag toegevoegd aan die tabel.
De INSERT-query's via PHP laten lopen had ook als reden de hele MyISAM engine en InnoDB engine te testen.
SELECT...WHERE query uit 50 miljoen gaat nu in 0,0004 seconde op een PC, meer dan acceptabel.
Dat is inderdaad een handige methode die hier ook toegepast zal worden, maar er worden naar verwachting zo'n 100 miljoen tot 10 miljard records (kan ikzelf nog niet goed inschatten) per dag toegevoegd aan die tabel.
De INSERT-query's via PHP laten lopen had ook als reden de hele MyISAM engine en InnoDB engine te testen.
SELECT...WHERE query uit 50 miljoen gaat nu in 0,0004 seconde op een PC, meer dan acceptabel.
damn, 1157 tot 115740 inserts per seconde? kan zo'n db dat aan? slaat hij dan niet eens wat over vanwege de grote hoeveelheid?
PHPerik:
Dual Xeon 3.0 GHz, 2GB RAM, Linux (FC4). Helaas wel met SATA disks, omdat de baas SCSI te duur vond...Overigens, als het 15 seconden duurt om een record te deleten, dan moet je nog flink aan je datamodel werken, tenzij je werkt op een Pentium 1 PC.
Het datamodel is inderdaad niet optimaal. De software die de database vult is nogal buggy, zodat het op dit moment nog niet mogelijk is een primary key op de tabellen aan te maken. Ik ben die software nu aan het herschrijven, zodat we voor de toekomstige data het model wel kunnen optimaliseren.
Overigens moet ik zeggen dat ondanks dat we zonder PK werken het queryen op de database wel snel gaat. Ik vermoed dat die 15 seconden voor een delete-actie ook voornamelijk toe te schrijven zijn aan phpMyAdmin. Die heb ik er wel vaker van verdacht slecht te performen bij grote databases (12 minuten voor een select * from tabel limit 400000000,30; via de mysql-prompt gaat dat sneller)
SELECT * FROM tabel WHERE id = iets
---> 0,0004 sec (id = INT(10), primary key)
SELECT * FROM tabel WHERE ietsanders = iets
---> 37 seconden (ietsanders = INT(10), niet primary key)
En nee, hij slaat niks over, dat is het voordeel van een INDEX op je velden. Zo kun je ook considereren INDEXen te zetten op bijvoorbeeld [achternaam,voornaam], etc (niet gelimiteerd aan 1 veld per INDEX).
Er komt waarschijnlijk dagelijks een nieuwe tabel en/of database. Deze tabel is namelijk puur bedoeld om in te zoeken door één van de "admins" (directeuren) als dit nodig is.
Kijken of ik morgen een test kan draaien met 100 miljard records. (Even nagevraagd, het gaat om +/- 6 miljard records per maand).
Hoe krijg ik in godsnaam binnen 10 uur 100 miljard records in een database?
unieke_id bigint | niet-unieke bigint | timestamp | niet-unieke tinyint(1)
Gewijzigd op 25/01/2006 01:27:00 door PHP erik
Zou je trouwens de testresultaten openbaar willen/kunnen maken? Ik denk dat er wel mensen geïnteresseerd in zijn.
(de site klikt trouwens als of een geweldige nieuwe formule of een opdrachtgever met grootsheidwaanzin.)
PostgreSQL lijkt mij te traag, maar ik kan het natuurlijk proberen.
Het gaat inderdaad om een geweldig nieuwe formule. Ikzelf ben nauw betrokken bij het project, neem van mij aan dat het geen grootheidswaanzin is :)
Zodra het online komt, laat je het wel weten hier hè? Want ik, en ik geloof met mij nog veel meer mensen hier, zijn reuze benieuwd wat dat concept is :)
Kan je geen hintje geven? Klein hintje, zo van: het heeft te maken met... ;)
En je avatar, moet ik daar iets in zien trouwens (anders dan zo'n konijntje?) Want het lijkt net zo'n psychologisch plaatje waar je 2 dingen in kan zien, je kent ze wel.