Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 63 reacties

Artemis zal vandaag na 16:00u kort down gaan in verband met de vervanging van een voeding. Vorige week kwam tijdens de terugplaatsing van Artemis op het laatste moment een probleem aan het licht dat had te maken met de herkenning van de twee PIII's en vier Cheetah X15's. Dit probleem wordt mogelijk veroorzaak door een te zwakke 300W voeding. OC-Shop.nl wist ons net op tijd een 550W Enermax te bezorgen (voor de prijs van een 430W, die niet uit voorraad geleverd kon worden ). Hopelijk lost dit de problemen op en kan de database server eindelijk zijn werk doen met de snelheid van twee 1GHz PIII's.

MySQL heeft de laatste dagen al behoorlijk stabiel gedraaid terwijl tijdens de drukke momenten meer dan 15 pageviews en 200 queries per seconde werden afgehandeld.

*Update* Artemis draait nu weer, de database is opgestart en de ircd draait weer als vanouds. Met dit verschil: het geheel heeft nu 1 processor meer tot zijn beschikking. Mocht je de komende paar minuten nog wat foutjes tegenkomen, schrik niet, maar ga even naar de zon buiten kijken, doe wat sociale contacten op, en als je terug bent zijn de tables vast al wel gefixed .

Door Femme Taken

- Architect

Femme is in 1998 als oprichter met Tweakers begonnen en werkt tegenwoordig als ontwerper in het productteam van Tweakers. In de vrije tijd knutselt Femme fanatiek aan zijn domoticasysteem.

Moderatie-faq Wijzig weergave

Reacties (63)

Uh is dit alleen bij het booten? Want dan kan je startdelay bij de hd's aanzetten dan is het meestal idx16 sec en dan pas spinup dan belast je de voeding minder.
Zo vaak boot Artemis niet dus dat lijkt me het probleem niet. Reken maar dat 2 PIII's en 4 Cheeta X15's flink wat stroom trekt. en niet alleen bij het opstarten.
:? heeft een gemiddelde pageview 13(!) queries nodig dan?
Vooral de reacties kosten veel queries ivm threads (nieuwe query voor elke subthread).
Femme, gelukkig dat de error pagina het dan doet :P

Da's best wel ranzig. Kun je niet met 1 query alle reacties eruit trekken, met een order by of group by oid, en dan alles in arrays douwen en daar mee verder gaan? Lijkt me een hoop schelen..
je kan je reaktie-ophaal/afbeeld routine ook herschrijven zodat hij recursief is. dan kan je unlimited reaktie op reaktie aan.
IK zou een ranzige constructie kunnen bouwen die alle reacties in de goede volgorde laat uitpoepen (moet je wel heel vaak door een array zoeken en onnodig veel reacties naar boven halen omdat het niet zeker is of een reactie op een bepaald niveau daadwerkelijk zichtbaar ivm threads).
Mischien nog een optie: een template achtig systeem met blocks. Alle reacties in een apart block, dingen als het icoontje voor de post die variable zijn (edit icoon, of niet) als $icon oid opnemen, en cachen die hap. Dan in nieuws.dsp het level checken waarop de gebruiker leest, en alleen die blocken + variable delen parsen met eval() oid.

Zoiets als Xtemplate, alleen is dat een beetje traag. Maar je zou er eens naar kunnen kijken (en dan als het wat is zelf zoiets efficienter proggen).

Dat lijkt me niet al te veel moeite voor zulke dikke servers :)
Unlimited kan nu ook wel maar hij doet max 4 ivm de layout.
Ok. mijn oplossing:

- stouw de hele zooi in een Jscript array.
- stuur die naar de client.
- stuur een .js template naar de client
- voer het gecursieve gerommel op de client uit dmv arrays. sorteren gebeurdt ook maar lekker daar. dan kun je de page ook nog refreshen zonder een nieuwe query uit te moeten voeren op de server. gewoon op de button rammen, en de JScript template draait een nieuwe HTML-stuk uit waarbij de volgorde van de array met comments gewoon omgedraaid is.
- klaar....

nadeel: Jscript-impaired browsers......
Dat levert meer traffic op en is dus trager omdat de client meer data binnen moet halen en omdat javascript de pagina moet renderen (en javascript is niet erg snel, zeker niet onder bepaalde browsers :)).
Ik dacht eerst ook dat JScript meer traffic oplevert. maar dat is niet zo hoor. want ga maar eens na, als jij alleen een JScript array met daarin de resultaten van de query terugzend, inclusief een .js template, dan heb je netto winst.

Want...de template is de normale HTML-code die vereist is voor 1 reactie, inclusief wat code om het in te vullen. Die .js hoeft maar 1 maal verzonden te worden en wordt daarna ook nog eens gecached door de browser.

en dat JScript sloom is....ja, daar kan ik weinig over zeggen. dat is zo. maar een beetje slim scriptje is best wel snel hoor. vooral als je niet honderd keer document.write doet, maar het gewoon in een buffer var stopt en die uitpoept met document.write.

Ik heb het gedoe met JScript in mijn eigen site zover doorgevoerd dat je feitelijk meer XML met javascript hebt. Nu heb ik een grote site op een enkele server met een DSL lijn, da's dus helemaal een ramp als het op dataverkeer aankomt. Deze oplossing heeft mij heel veel problemen helpen oplossen. het dataverkeer is flink gedaald en de server is veel meer ontlast. het renderen van de pages gebeurdt alleen maar op de client, en de server speelt datapomp. Maar ja, dat komt tegen de prijs dat browsers die niet overweg kunnen met javascript er niet op kunnen. maar het is ook 2001...en de meeste mensen hebben IE5.5.
Als je alles door javascript laat doen, dus ook het filteren van de niveau's, dan zal voor iemand die op niveau 3 kijkt veel onnodige tekst verzonden worden. En javascrippies worden hier al veel gebruikt om veel veelvuldig terugkomende stukken HTML te schrijven.
da's waar. maar dan moet je kijken hoeveel mensen het niveau veranderen (hier zal ik je gelijk moeten geven denk ik, want niet zo heel veel doen dat). Als mensen vaak de instellingen voor hoe zij de reacties willen zien wijzigen, dan is de server lekker bezig met het uitvoeren van queries. door alles (ik page wel een beetje hoor, anders wordt het te gek) op de client onder te brengen kun je dus refreshen zonder een request naar de server te sturen. da's ook makkelijk als je het offline opslaat. kun je toch lekker blijven filteren.

Daarnaast voer je steeds een zelfde soort query uit met weinig params -> da's makkelijk cachen voor MySQL :)

Is dit nou 'net niet' real-time chatten?
Hmm, maar je kunt toch in één keer de reacties uit de tabel halen van een post, de eerste zonder parentid renderen, recursief zoeken naar posts met die eerste reactie als parentid en dan weer aan het begin van de resultaten beginnen om de 2e posts zonder parentid te renderen, tot de ingestelde limiet wordt bereikt?

Dus in plaats van iedere keer een nieuwe query dezelfde resultaten een aantal keer doorlopen. Of kost dat te veel processortijd/geheugen van de webserver?
Ik denk niet dat er een nieuwe query gestard word voor elke subthread! Lijkt me nogal logisch dat de PHP servertjes het resultaat wel onder handen nemen.

En trouwens: query voor het bijwerken van het aantal keer dat ik een pagina bekijk voor m'n carma? Wat dacht je van de teller tabel?
Ik heb ff in de source van nieuws.dsp gekeken (die ik heb is vrij oud), en daarin staan 9 queries.
Beste Tom, Femme heeft per ongeluk gereageerd onder mijn naam, het lijkt mij dat hij wel weet waar hij over praat :) (Hij heeft het immers zelf geschreven en bedacht...)
9 queries....wow. dat kan dus wel beter. laat de PHP-code dat maar uitzoeken. zijn die queries ook recursief? (misscien kan MySQL dat niet aan overigens...ik weet niet, ken alleen MS SQL). Ik heb toevallig dit systeem redelijk nagebootst in een ASP-omgeving waarbij je maar 1 query nodig hebt. Het aantal joins komt niet boven de 3 uit en de db is volledig genormaliseerd.

[sorry]
zie net dat de discussie hieronder ineens verder is gegaan :).
[/sorry]
gegevens gebruiker ophalen
update tracker ophalen
bericht ophalen
reacties ophalen
etc etc etc

* 786562 D-RiSe
Daar heb je er 4... terwijl één daarvan (update tracker) een gecachte pagina is. Wordt GoT soms niet meegetelt in het aantal views? Of telt MySQL joins/subqueries ook apart? 13 lijkt me nog steeds errug veel.
Mij ook, daar kan dan misschien ook wel wat verbetering in komen, ietsje minder queries zou fijn zijn, mysql krijgt het minder druk, hopelijk wordt die dan stabiel en is iedereen blij :)
Mysql kan geeneens subqueries. Daar moet je PostgreSQL voor hebben
Let wel....subqueries zijn niet snel. je kunt beter 10 queries draaien dan 5 zware queries. Kleine queries zijn voorspelbaarder, en beter te cachen dan grote queries. Die zijn vaak afkomstig uit veel tabellen die vaak gewijzigd worden.

Ik weet niet hoeveel tabellen t.net heeft, maar het zijn er veel, en ze zijn vooral groot. Daarbij komt dat MySQL geen officieel RDBMS is en dus niet per definitie geschikt is voor dit soort load.

De site laad best snel hoor, gezien het aantal pageviews en het aantal queries per seconde.
Ik hoop dat we nog wat fotootjes van de recente upgrades krijgen. Ook ben ik wel benieuwd hoe het nu met de belasting van de servers is. Kunnen we met het huidige serverpark een flinke tijd uit de voeten, of zijn er binnen enkele maanden verdere upgrades noodzakelijk. Misschien leuk om hier een keer een column over te schrijven...
<TABLE border=0 cellpadding=0 cellspacing=0><TR><TD bgcolor='#9B9B9B'><TABLE border=0 cellpadding=3 cellspacing=1 width=450><tr bgcolor='#e4e4e4'><Td class=b6 width=110> </td><td class=b6 width=380>Huidige webserver uptime en load</td></tr><tr bgcolor=white><td class=b6 bgcolor='#f6f6f5' valign=top width=110>Aphrodite</td><td class=b6 bgcolor='white' width=380> 6 days, 3:13, 0 users, load average: 4.06, 5.12, 4.30</td></tr><tr bgcolor=white><td class=b6 bgcolor='#f6f6f5' valign=top width=110>Athena</td><td class=b6 bgcolor='white' width=380> 6 days, 23:42, 3 users, load average: 0.00, 0.02, 0.00</td></tr><tr bgcolor=white><td class=b6 bgcolor='#f6f6f5' valign=top width=110>Odin</td><td class=b6 bgcolor='#f6f6f5' width=380> 15 days, 5:33, 0 users, load averages: 0.26, 0.27, 0.25</td></tr><tr bgcolor=white><td class=b6 bgcolor='#f6f6f5' valign=top width=110>Arshia</td><td class=b6 bgcolor='white' width=380> 21 days, 21:07, 0 users, load averages: 1.79, 1.92, 2.02</td></tr></table></td></tr></table>
Hoe zit het met de automagische verdeling? Wat ik nu de hele tijd zie ziet er een beetje vaag uit... Aphrodite & Arshia hebben het druk, en Athena staat gewoon uit d'r neus te vreten?

Ik dacht dat het nieuws enzo ook verdeeld werd over www en www2... Zie ik niet meer de laatste dagen :?.
Aphrodite is de database-server (de andere zijn webservers). Daarom is appie ook het meest belast. Op Arshia draait GoT, vandaar dat zij ook veel moet verwerken. De andere twee servers dienen als webserver voor tweakers.net en hebben zoals je ziet niet zo veel te doen.
WRONG! :) Kijk es in de titel, artemis is de db server, appie is een web server, athena daarentegen is ff db server geweest, vraag ik me nog steeds af waarom appie zo'n hoge load heeft...
hmmzz |:(
Robin uptime: too long (go to sleep) :Z
Athena heeft vorige week voor database server gespeeld toen Artemis weg was en ze heeft even database replication gedaan om de load op Artemis te verzachten. Ze kan nu wel weer gaan webserven omdat Artemis nu twee werkende PIII's heeft.
Dat was ik al van .plan :). Wat er in de komende weken gaat gebeuren:

- SCSI kabel fixen voor Artemis
- Cisco Catalyst 2900 24-poorts switch, via 2Source4
- SQL Replication server (Dual PIII-1000, Asus CUV4X-DLS, 1GB PC133, Cheetah X15, 2U kastje), gesponsord door Hardware.nl

Plaatjes van deze upgraden heb ik bdw niet gemaakt. Voeding wisselen is ook niet echt spannend. Check deze .plan en deze .plan voor oudere foto's.
MySQL heeft de laatste dagen al behoorlijk stabiel gedraaid
Vergeleken met hiervoor wel ja, maar het woord stabiel durf ik nog lang niet in m'n mond te nemen, hij was toch weer enkele malen koffie aan het drinken en got wou nou ook niet echt fantastisch...
Ik denk dat koffie drinken het probleem niet echt is, zolang hij daarna maar gewoon doorwerkt :P.

Maar wat ik me nu afvraag, hoe kom je er nu echt achter of je voeding het niet trekt, je kunt natuurlijk meten hoeveel stroom hij trekt, maar dat zegt alleen iets over de belasting, nog steeds niet echt iets over de kwaliteit van de uitgangsstroom/spanning.

* 786562 TheGhostInc
We hebben heel eenvoudig uitgerekend hoeveel watt alle apparatuur trekt die in Artemis zit.
104 Geheugenchipjes (in totaal 1,5GB) van 0,9Watt/stuk in totaal 90Watt.
4x Cheetah X15 a 16Watt IDLE.
2x Intel P3 a 30Watt/stuk
5x 80mm Fan a 12Watt/stuk
2x Proc koeler a 8Watt
1x Raid Controller a xxWatt (onbekend jah)
2xNIC, videokaart, etc.

Reken maar raak, dat trekt een 300Watter niet echt... We wilden eigenlijk een 431Watt voeding, maar die was niet leverbaar, de heren van oc-shop.nl zijn zo vriendelijk geweest om ons te voorzien van een 550Watt model voor dezelfde prijs, dus zo duur was het nou ook weer niet hoor :)
Het is een fout die je maar één keer maakt :)
104 Geheugenchipjes (in totaal 1,5GB) van 0,9 Watt/stuk in totaal 90 Watt.
Kan aan mij liggen hoor, maar is 90Watt voor wat geheugen niet een beetje erg veel? En ik geloof er lekker ook niks van dat die fans zo veel stroom zuipen...
Uhh, maar waarom hebben jullie dat niet gedaan voordat Artemis gebouwd werd?? Een beetje tweaker zet toch al vraagtekens bij deze config op een 300W voedinkje.
Het was slechts een vermoeden dat de voeding het probleem was. Na het verwisselen van de processors deden de 2 CPU's het eindelijk, dus de voeding was waarschijnlijk net voldoende maar ook als die 550W niet nodig was is het beter met het ogen op de toekomst.
Uhh, maar waarom hebben jullie dat niet gedaan voordat Artemis gebouwd werd?? Een beetje tweaker zet toch al vraagtekens bij deze config op een 300W voedinkje.
Meten met een scoop erop. En dat doe je niet zomaar even, daar moet je dus wel koek van gegeten hebben. Misschien wel de koek voor bij de koffie van Artemis?
Mocht je de komende paar minuten nog wat foutjes tegenkomen, schrik niet, maar ga even naar de zon buiten kijken, doe wat sociale contacten op, en als je terug bent zijn de tables vast al wel gefixed
Zon :?, Buiten :? waar hebben jullie het over :?.
Nou hopen dat het MySQL databeest nu genoeg koffie heeft gedronken om weer een tijdje vooruit te kunnen ;). En ja die servers hebben het nogal druk. Als je weet watvoor computer je nodig hebt voor een simpele online chat die uit MySQL wordt gegenereerd, dan wordt je ook nie lekker.
ik kom al daaaagen niet meer op ftp://artemis.tweakers.net ... was daar mee mis dan? :?

Edit: misschien snapt de mod het niet, maar dis dus een vraag! De public FTP van Tweakers.Net ligt al dagen plat, en ik weet nog steeds niet waarom...
Als je onderaan van de pagina kijkt, zie je iets wat o p dit lijkt:
©1998-2001 Tweakers.net - Powered by Linux, FreeBSD, Apache, PHP & MySQL (Odin & Artemis)
Helemaal achteraan zie je de servers die gebruikt worden. En kijk eens aan: Artemis. Zegt wel genoeg toch?
Nee, dat zegt geen ruk, want ik kan nog steeds niet op de FTP komen... die dus op Artemis zou moeten draaien...
http://www.tweakers.net/plan/79?&niv=-1

edit:
Ah, kijk ... dat zegt wel wat. Tx Femme.
Artemis is vorige week helemaal opnieuw geïnstalleerd. Ik vermoed dat Rick nog niet is toegekomen aan het public FTP gebeuren.
Zat er eerst een no-name 300W voeding? Of ook een bekend merk!
voor de prijs van een 430W, die niet uit voorraad geleverd kon worden
Nu ook al gesponsord door OC-SHOP :P.
nou ik denk dat er in een kast van 2000 gulden geen noname voeding zit :P
Het was idd een kastje van circa 2000 piek :). Het merk voeding weet ik niet. De voeding hebben we aan Vuurwerk gegeven (omdat we in december een keer een voeding van hun hebben kunnen krijgen toen de voeding van Appie plotseling brak was).
Het werkt allemaal nog niet feilloos. heb alweer 5 #55's te pakken gehad :(
De tables waren nog niet gefixed, mysql ging zwaar over de zeik
Ik heb hier een bak met 300W voeding (Normale target voeding) met daarin:

- Asus cubx-e + celeron 533MHz 192MB ram
- 4 x 80 GB maxtor
- 4 x 60 GB maxtor
- 6 x 45 GB WD
- 1 x 3GB Quantum
- 3 x promise ata/100
- 2 x 3com 3c905b
- 1 x 512 KB vga (ISA style)
- 4 x fans

En draait als een tiet. Tijdens het opspinnen v/d schijven, (alle 15 tegelijker tijd) wat me toch het meeste stroom lijkt trekken, houdt ie het prima vol.

Dus ik snap nu niet wat jullie te zwammen hebben over een te zwakke 300W voeding.
Waarvoor gebruik jij je pc wel niet dan.
Oh ik snap het, je hebt een mysql gebaseerde DivX site :P

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True