Error 500 bij 1,5 GB textfile

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

PHP erik

PHP erik

24/01/2006 18:34:00
Quote Anchor link
Ben bezig wat testjes uit te voeren m.b.t. snelheid. Nu vul ik een textfile tot +/- 5 gigabyte, maar krijg ik na 1,5 gigabyte een Internal Server Error (500).

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)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php

$file
= "test.txt";
if ( file_exists($file) ) unlink($file);

$fp = fopen($file, "a");

for ( $i = 1111111111; $i <= 1211111111; $i++ ) // 100,000,000 keer
{
    fputs($fp, $i. ',' .rand(100000000000, 256000000000). ',' .time(). ',' .rand(0,9). '
'
);
}


fclose($fp);

?>
 
PHP hulp

PHP hulp

16/05/2021 11:37:17
 
Han eev

Han eev

24/01/2006 18:36:00
Quote Anchor link
Mieschien vind de server dat je te lang bezig bent...
en laat je dan stoppen
dus ga allebeide tijden opnemen als ze gelijk zijn licht het daaraan
 
PHP erik

PHP erik

24/01/2006 18:43:00
Quote Anchor link
Enig idee hoe ik dat in de server verander? Want alle apache instellingen en php.ini instellingen zijn correct.
 
Han eev

Han eev

24/01/2006 18:49:00
Quote Anchor link
Nee, Maar ik denk niet dat apache het leuk vind dat jij een half uur over doet om 1 script te benaderen ^^
Dan zegt apache ook, jah mijn hoela, je bent al zo lang bezig nu heb ik geen zin meer ;)
 
Winston Smith

Winston Smith

24/01/2006 19:26:00
Quote Anchor link
maximale uitvoertijd al opgehoogd (zowel in php.ini als in httpd.conf)?
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?
 
PHP erik

PHP erik

24/01/2006 19:32:00
Quote Anchor link
Uiteraard zijn die tijden verhoogd (of eigenlijk uitgezet).

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)
 

24/01/2006 20:37:00
Quote Anchor link
Een half miljard bezoekers?? Dat is dus 1/12 van de wereldbevolking die op die site komt?
Wat voor site is dat, google????
 
PHP erik

PHP erik

24/01/2006 21:00:00
Quote Anchor link
Dat mag ik niet bekendmaken, maar je kunt wel denken aan een site zo groot als hotmail ja. Google is een rang apart...

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.
 
PurpleMadness -

PurpleMadness -

24/01/2006 21:10:00
Quote Anchor link
Ben benieuwd..
Is het een zoekmachine?
 
Willem vp

Willem vp

24/01/2006 23:49:00
Quote Anchor link
Waarom zou je die database in 1x willen vullen? Waarom niet "slechts" 5 miljoen queries per keer en dan je script 20x uitvoeren? Je zou natuurlijk ook PHP vanaf de commando-prompt kunnen starten; dan zet je die 20 script-aanroepen in een shell script en hoef je er verder niet meer naar om te kijken.

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
 
PHP erik

PHP erik

24/01/2006 23:53:00
Quote Anchor link
@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.
 
PHP erik

PHP erik

24/01/2006 23:55:00
Quote Anchor link
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.
 
Willem vp

Willem vp

24/01/2006 23:55:00
Quote Anchor link
Mijn ervaring met InnoDB is dat 'ie ongeveer 3,5x zo traag is als MyISAM, in ieder geval in de omstandigheden waaronder ik hem heb getest.

Hoe zijn jouw ervaringen daarmee?
 
PHP erik

PHP erik

24/01/2006 23:56:00
Quote Anchor link
Uit mijn tests blijkt InnoDB in het algemeen ongeveer 200 keer zo traag te zijn als MyISAM. Maar hierbij heb ik geen rekening gehouden met mogelijke meerdere connecties. Wellicht werkt InnoDB wel beter als er 10000 mensen tegelijk bezig zijn.
 
Willem vp

Willem vp

25/01/2006 00:04:00
Quote Anchor link
Dan kom je inderdaad op het fenomeen "record locking", wat niet ondersteund wordt door MyISAM. Was in mijn geval geen issue, omdat de updates door 1 vast proces worden gedaan. De transactie-overhead van InnoDB heeft dan juist een negatieve invloed.
 
Stefan van Iwaarden

Stefan van Iwaarden

25/01/2006 00:05:00
Quote Anchor link
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.


damn, 1157 tot 115740 inserts per seconde? kan zo'n db dat aan? slaat hij dan niet eens wat over vanwege de grote hoeveelheid?
 
Willem vp

Willem vp

25/01/2006 00:22:00
Quote Anchor link
PHPerik:
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.
Dual Xeon 3.0 GHz, 2GB RAM, Linux (FC4). Helaas wel met SATA disks, omdat de baas SCSI te duur vond...

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)
 
PHP erik

PHP erik

25/01/2006 01:18:00
Quote Anchor link
In een tabel met 50,000,000 records van elk ongeveer 50 bytes:


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
 
Jelmer -

Jelmer -

25/01/2006 08:22:00
Quote Anchor link
Misschien is het ook een idee om postgresql in je test op te nemen, al is het maar ter vergelijking. MySQL kan wel wat hebben (google heeft vroeger gewerkt op MySQL. Of het dat nu nog steeds doet is niet bekend) maar je tovert wel hele grote getallen uit de mauw.

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.)
 
PHP erik

PHP erik

25/01/2006 15:08:00
Quote Anchor link
Testresults zal ik publiceren. Wellicht zelfs een tutorialtje erbij zodat mensen zelf het e.e.a. kunnen testen.

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 :)
 
Winston Smith

Winston Smith

25/01/2006 15:18:00
Quote Anchor link
offtopic:
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.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.