php-server met 3 miljoen queries per dag...

[zipkid]

Wie o wie kan een advies geven voor een postgresql server (de hardware dus) die op een database met 3000 records 3 miljoen queries per dag aan kan?

[Verwijderd]

Ik weet niet wat PGSQL verbruikt aan resources e.d, maar veel memory lijkt me toch zeker niet verkeerd. Ik zou gaan voor 1Ghz en minstens 512 memory.

Dan zit je zeker goed, en uiteraard een snelle (SCSI) schijf.

Da's allemaal helemaal niet zo duur meer tegenwoordig, de prijzen zakken erg snel op het moment.

[zipkid]

heeft muliprocessor nog nut?
(als ik linux wil draaien met postgresql)

[sverzijl]

Op donderdag 28 juni 2001 20:52 schreef zipkid het volgende:
Wie o wie kan een advies geven voor een postgresql server (de hardware dus) die op een database met 3000 records 3 miljoen queries per dag aan kan?

3000 records? Ga je er een ERP/CRM database op draaien ofzo (SAP / PeopleSoft / Siebel) ?

[Verwijderd]

Daar weet ik niets over, maar hij kan dan wel de load over 2 processoren verdelen, waardoor ie 2x zoveel aan kan denk ik. Maar dan kun je beter 1 snelle proc kopen volgens mij, is vaak goedkoper dan 2.

[Ro_meo]

harddisks in raid opstelling..

performance :
-0- 'goede' queries en datamodel/ontwerp
-1- harddisk
-2- geheugen
-3- processor

[zipkid]

Het geheel moet ingaand en uitgaande hits bij gaan houden...

[Verwijderd]

Op donderdag 28 juni 2001 20:59 schreef zipkid het volgende:
Het geheel moet ingaand en uitgaande hits bij gaan houden...

Heh

[Femme]

Als 't maar 3000 records zijn dan lijkt me de hoeveelheid data beperkt. Dat kan gemakkelijk in RAM gecached worden en dan is de harddisk performance ook minder belangrijk.

Hier op Tweakers.net deden we 15 miljoen queries op een Dual PIII-1000 met 2GB en 2x10K RAID 1 SCSI, maar dan wel met databases van in totaal 3GB en 20 miljoen records.

Ik denk niet dat je voor die 3 miljoen queries hele zware hardware nodig hebt. Hangt er van af wat voor queries het zijn.

---
Ow, hij moet dus stats gaan loggen? Dat lijkt me niet al te zwaar. Je hebt dan waarschijnlijk wel vrij veel harddisk verkeer (veel inserts/updates?).

bdw: als je iets gaat loggen dan krijg je toch al snel veel meer dan 3000 records?

[Onno]

Op donderdag 28 juni 2001 21:00 schreef Femme het volgende:
Hangt er van af wat voor queries het zijn.

Op 3000 records kun je nauwelijks zware queries doen.

[sverzijl]

aaaargh@%$ Ik ga PeopleSoft een proces aandoen wegens opzettelijk misleidende en uiterst foutieve termen te gebruiken.

PeopleSoft (ERP pakket) noemt tabellen 'records' en heeft +/- 3000 'records' (tabellen dus) voor de HR module. Dus ik zie hier '3000 records' en denk meteen '3000 tabellen'.

Misschien heb ik last van beroepsdeformatie ? Kan ik ze daarvoor ook aanklagen ? (tis een US bedrijf)

[ACM]

Op donderdag 28 juni 2001 20:55 schreef zipkid het volgende:
heeft muliprocessor nog nut?
(als ik linux wil draaien met postgresql)

Ja heeft zeker nut, iig, postgresql is een multiprocessed dbms.
De threads zullen dus netjes verdeeld worden over je cpu's.

Veel ram geheugen is een pre (ram kost toch weinig nu, 1GB zou ik er minimaal insteken, vergeet namelijk niet dat elke open connectie ook ram kost)

Daarnaast dus snelle disks (mindere issue als de db niet al te groot is, snel schrijven is opzich nog steeds belangrijk hoor)

[ACM]

Op donderdag 28 juni 2001 21:02 schreef Onno het volgende:
Op 3000 records kun je nauwelijks zware queries doen.

Ach, ik wil er wel wat voor je bedenken hoor
Maar de standaard queries zullen niet al te zwaar zijn erop nee.

[Ro_meo]

select * from women where month(birthday) not in (select distinct month(partners.birthday) from partners where partners.partner_id = women.women_id) and....

zal ik door gaan ?

[Verwijderd]

3 miljoen? Lijkt me voor een gewone (single processor) P3 geen probleem. (Tenminste niet in mijn ervaring)

[Onno]

Op donderdag 28 juni 2001 21:24 schreef davar het volgende:
select * from women where month(birthday) not in (select distinct month(partners.birthday) from partners where partners.partner_id = women.women_id) and....

zal ik door gaan ?

Ach. In Nederland doen we niet aan polygamie. Dus kun je hier een gewoon jointje van maken en is 't ineens niet zo zwaar meer.

Maarre.. natuurlijk *kun* je wel zware dingen verzinnen (ga een tabel maar 20x met zichzelf joinen), maar dat is niet echt reeel meer.

[Ro_meo]

bovengenoemde query is ontworpen voor harems

Ik ben nu bezig met een SAP <-> SIEBEL koppeling implementatie.. hp/ux met 8 processoren, in een nacht moeten (= 6 uur maximaal) 20 jobs draaien...

waarvan bijv. eentje 1,5 miljoen records moet verwerken (pl/sql van 20 kantjes)

maar.. ik dank degenen die dit 'geintje' hebben verzonnen.. zo hebben wij ook nog eens een leuke baan..

[igmar]

De threads zullen dus netjes verdeeld worden over je cpu's.

Threads ? Processen bedoel je. Threads is wat anders.

Advies : Veel ram. En een 2.4 kernel

[ACM]

Op vrijdag 29 juni 2001 00:13 schreef igmar het volgende:
Threads ? Processen bedoel je. Threads is wat anders.

Advies : Veel ram. En een 2.4 kernel

2.4 kernel is niet een goed advies
Wacht daar maar een tijdje mee, zitten toch wat meer kleine rotbugs in, dan ze verwacht hadden blijkbaar...

Btw, threads en processes is eigenlijk 1 pot nat Maar hangt wel een beetje van het os af hoe het behandeld en gebruikt wordt.

[Mark]

Op vrijdag 29 juni 2001 00:17 schreef ACM het volgende:

[..]

2.4 kernel is niet een goed advies
Wacht daar maar een tijdje mee, zitten toch wat meer kleine rotbugs in, dan ze verwacht hadden blijkbaar...

Btw, threads en processes is eigenlijk 1 pot nat Maar hangt wel een beetje van het os af hoe het behandeld en gebruikt wordt.

2.4.x is sowieso ook meer een eindgebruikers kernel. Voor server toepassingen raden de meeste (als het niet allemaal is) distromakers nog 2.2.19 aan.

[zipkid]

En nu een leuke om over te vechten:
waar zoiets aan te schaffen????

Zipkid

[Verwijderd]

Op vrijdag 29 juni 2001 16:14 schreef zipkid het volgende:
En nu een leuke om over te vechten:
waar zoiets aan te schaffen????

Zipkid

Ik zat gister avond ff te kijken bij VALinux.com, mooi spul voor niet zo heel duur, veelal 1 en 2U kastjes

[McMiGHtY]

ja valinux zijn wel leuk ebakkies...worden momenteel redelijk vaak aangeboden op Ebay

[Coen Rosdorff]

Op vrijdag 29 juni 2001 17:06 schreef [nielsonline] het volgende:

Ik zat gister avond ff te kijken bij VALinux.com, mooi spul voor niet zo heel duur, veelal 1 en 2U kastjes

VA-linux is uit de hardware markt gestapt deze week

[Coen Rosdorff]

Op vrijdag 29 juni 2001 00:17 schreef ACM het volgende:

Btw, threads en processes is eigenlijk 1 pot nat Maar hangt wel een beetje van het os af hoe het behandeld en gebruikt wordt.

Ga je diep schamen. Een thread is heel iets anders dan een process. Processes vreten veel meer resources dan threads.

[FragDaddy]

waar zoiets aan te schaffen????

gewoon bij de leverancier waar je normaal je servers ook vandaan trekt..

[zipkid]

'normaal' ;?
Dat is nooit. Werden altijd gehuurd en nu hebben we opeens een grote nodig.

Waarom moeten er altijd van die 'slimme' antwoorden gegeven worden op toch best wel duidelijke vragen...

Sorrie voor de kleine irritatie...

[Onno]

Op zaterdag 30 juni 2001 03:38 schreef little_soundman het volgende:

[..]

Ga je diep schamen. Een thread is heel iets anders dan een process. Processes vreten veel meer resources dan threads.

Dat ligt helemaal aan de implementatie van threads/processes van je besturingssysteem. Het is niet zo dat processes per definitie meer resources vreten dan threads ofzo.

[uhh, ja, dat was een typo ACM :)]

[ACM]

Op zaterdag 30 juni 2001 12:01 schreef Onno het volgende:
Dat ligt helemaal aan de implementatie van threads/processes van je besturingssysteem. Het is niet zo dat threads per definitie meer resources vreten dan threads ofzo.

(processes meer dan threads)

En dat is dus exact wat ik bedoelde.
Meestal zal het idd zo zijn, maar het hangt helemaal van het achterliggende OS en de evt bijbehorende VM (als er zoals bij java meerdere zijn, dan alleen die van het OS) die het implementeert.

[raptorix]

Voor de meeste database servers geld dat je eigenlijk nooit genoeg geheugen kan hebben, zeker als het een database systeem is met een goed caching systeem scheelt dat een hoop.