GOT database probs?

[JvS]

*kuch*

http://forums.anandtech.com/messageview.cfm?catid=42&threadid=607201

*kuch*

[wildhagen]

Op donderdag 25 oktober 2001 15:44 schreef ACM het volgende:

[..]

Grapjas
Check oa: http://www.tweakers.net/reviews/238 voor je zulke uitspraken weer doet

Ik zat daar bijna bovenop (2 meter vandaan) een server die al meer waard was dan het hele t.net serverparkje van T.net...

Weet ik, stond ook "bij wijze van" achter

Maar het lijkt me toch sterk dat het huidige park dit bezoekersaantal niet aankan... ik heb wel eens simpele P2's en langzame P3's gezien die ook vele duizenden bezoekers kon serven. Weliswaar een stuk minder dynamisch dan tw.net, maar toch...

Als je nou eerst de software van tw.net (over GoT/Topix wil ik het niet eens hebben, dat is inmiddels hopeloos) zou optimizen, dat-ie minder queries per pageview moet doen, scheelt dat meteen een hoop in de load.

En nou eens keer ECHTE loadbalancing doen. Ik bedoel, het KAN niet zo zijn dat de ene server een load van 100-150 heeft (Arshia) terwijl een tweede server (Odin) nog niet 0.1 aan load heeft... en Appie en Aphrodite ook slechts rond de 1-2 aan load. Dan gaat er iets helemaal fout.

[wildhagen]

Op donderdag 25 oktober 2001 15:50 schreef JvS het volgende:
*kuch*

http://forums.anandtech.com/messageview.cfm?catid=42&threadid=607201

*kuch*

Bij HEM ja... bij iedereen anders (including me) is het gewoon lekker rap hoor...

[ACM]

Op donderdag 25 oktober 2001 15:50 schreef wildhagen het volgende:
Maar het lijkt me toch sterk dat het huidige park dit bezoekersaantal niet aankan... ik heb wel eens simpele P2's en langzame P3's gezien die ook vele duizenden bezoekers kon serven. Weliswaar een stuk minder dynamisch dan tw.net, maar toch...

De hardware kan het ook nog wel behoorlijk goed aan.
Overigens is het ook al aangegeven, maar binnenkort (nog dit jaar heb ik gehoord ) komen daar nog wat veranderingen in.

Als je nou eerst de software van tw.net (over GoT/Topix wil ik het niet eens hebben, dat is inmiddels hopeloos) zou optimizen, dat-ie minder queries per pageview moet doen, scheelt dat meteen een hoop in de load.

Topix is nog niet eens zo heel slecht, als je bedenkt dat onder normale omstandigheden arshia het redelijk goed af kan. Ondanks de 500K pageviews die topix dagelijks trekt.

De tw.net FP zelf wordt geloof ik al behoorlijk gecached.

En nou eens keer ECHTE loadbalancing doen. Ik bedoel, het KAN niet zo zijn dat de ene server een load van 100-150 heeft (Arshia) terwijl een tweede server (Odin) nog niet 0.1 aan load heeft... en Appie en Aphrodite ook slechts rond de 1-2 aan load. Dan gaat er iets helemaal fout.

De topix software laat loadbalancing niet echt goed toe geloof ik (klinkt vreemd en nee, ik weet de details ook niet)

De loads van 100-150 heb ik ondertussen eigenlijk niet meer gezien, sinds kees de eerder genoemde veranderingen uitvoerde.

Odin schijnt hardware/software technisch niet helemaal lekker in elkaar te zitten, daar wordt bij de eerder genoemde server uitbreiding ook naar gekeken, maar dat is in principe de reden dat kees hem ontlast.

Aphrodite doet nog vrij veel taken ernaast hoor, die niet perse zwaar zijn.

[RvdH]

Op donderdag 25 oktober 2001 16:00 schreef ACM het volgende:

[..]

De hardware kan het ook nog wel behoorlijk goed aan.
Overigens is het ook al aangegeven, maar binnenkort (nog dit jaar heb ik gehoord ) komen daar nog wat veranderingen in.
[..]

Die hebben we eerder gehoord ja..

Topix is nog niet eens zo heel slecht, als je bedenkt dat onder normale omstandigheden arshia het redelijk goed af kan. Ondanks de 500K pageviews die topix dagelijks trekt.

Dus elke keer als GoT niet werkt, zijn er niet normale omstandigheden? Zoals wat dan?

De topix software laat loadbalancing niet echt goed toe geloof ik (klinkt vreemd en nee, ik weet de details ook niet)

En dat was begin dit jaar ook al bekend, maar ondertussen is er nog niks aan gedaan.. wieso?

Aphrodite doet nog vrij veel taken ernaast hoor, die niet perse zwaar zijn.

Dus kan je die erg makkelijk inzetten om nog meer taken te verdelen. Waarom gebeurt dat niet?

[Pc123]

Aphrodite 5 days, 16:24, 1 user, load average: 9.70, 8.31, 6.49
Athena 126 days, 1:48, 2 users, load average: 0.98, 1.73, 1.74
Odin 17 days, 21 mins, 1 user, load averages: 0.56, 0.75, 0.77
Arshia 16 days, 17:06, 0 users, load averages: 0.93, 0.85, 1.05

Odin heeft het inderdaad niet druk maar dat komt dus omdat die niet helemaal stabiel en ie daarom niet zo heel veel gebruikt wordt. Wat vooral opvalt is dat aphrodite het veel te druk heeft. Daar moet wat aan gebeuren.

Artemis MySQL status
Load 415 queries per seconde gemiddeld, 2.564.315 totaal

Apollo MySQL status
Load 87 queries per seconde gemiddeld, 312.305 totaal

Ook dit verschil is veel te groot, Artemis is geloof ik wel sneller maar apollo zou zeker meer moeten doen. Waarschijnlijk komt dit doordat de replication niet werkt. Dat is dus ook een probleem dat opgelost moet worden.

[Laurent]

Op donderdag 25 oktober 2001 16:19 schreef Pc123 het volgende:
Aphrodite 5 days, 16:24, 1 user, load average: 9.70, 8.31, 6.49
Athena 126 days, 1:48, 2 users, load average: 0.98, 1.73, 1.74

Dit verschil is ook niet klein zeg.

[justmental]

Op donderdag 25 oktober 2001 16:16 schreef RickJansen het volgende:

En dat was begin dit jaar ook al bekend, maar ondertussen is er nog niks aan gedaan.. wieso?

Bied je jezelf hiermee aan om dit gratis en voor niets te onderzoeken, analyseren, verbeteren en implementeren?

[ACM]

Op donderdag 25 oktober 2001 16:16 schreef RickJansen het volgende:
Die hebben we eerder gehoord ja..

Klopt, het is alleen niet aan mij om te zeggen voor wanneer het gepland is. Maar er is in principe een datum bekend...

Dus elke keer als GoT niet werkt, zijn er niet normale omstandigheden? Zoals wat dan?

Nee, je draait het om. Ik doel er op dat onder normale omstandigheden (dus als er niet extra veel views zijn, een harddisk kapot of wat voor gekke omstandigheden dan ook) het makkelijk 500K pageviews dagelijks trekt.

En dat was begin dit jaar ook al bekend, maar ondertussen is er nog niks aan gedaan.. wieso?

Weet ik niet.

Dus kan je die erg makkelijk inzetten om nog meer taken te verdelen. Waarom gebeurt dat niet?

Zoals je in je de reply onder de jouwe ziet, is aphrodite niet altijd zonder werk...

Op donderdag 25 oktober 2001 16:19 schreef Pc123 het volgende:
Artemis MySQL status
Load 415 queries per seconde gemiddeld, 2.564.315 totaal

Apollo MySQL status
Load 87 queries per seconde gemiddeld, 312.305 totaal

Ook dit verschil is veel te groot, Artemis is geloof ik wel sneller maar apollo zou zeker meer moeten doen.

Dit verschil is me ook niet helemaal duidelijk, althans. Apollo draait met een normale belasting (ietsje lager geloof ik zelfs).

Sinds een tijdje (ik weet niet sinds wanneer, maar ben er achteraan aan het gaan) wordt artemis veel zwaarder belast.

Waarschijnlijk komt dit doordat de replication niet werkt. Dat is dus ook een probleem dat opgelost moet worden.

Neuh, dat staat daar verder los van.

Er was een redelijk gelijke belasting voor apollo en artemis, maar (zie paar regels omhoog) sinds kort niet meer.

[RvdH]

Op donderdag 25 oktober 2001 17:05 schreef justmental het volgende:

[..]

Bied je jezelf hiermee aan om dit gratis en voor niets te onderzoeken, analyseren, verbeteren en implementeren?

Oh nee, absoluut niet. Dat kan Kees of die andere serverbeheerder waar we niks van zien vast wel af.

Op donderdag 25 oktober 2001 17:11 schreef ACM het volgende:

Nee, je draait het om. Ik doel er op dat onder normale omstandigheden (dus als er niet extra veel views zijn, een harddisk kapot of wat voor gekke omstandigheden dan ook) het makkelijk 500K pageviews dagelijks trekt.
[..]

Kapotte harddisk zou ik idd geen normale omstandigheid noemen, maar extra views? Extra views horen juist onder normale omstandigheden, want dat komt altijd weer voor.

Zoals je in je de reply onder de jouwe ziet, is aphrodite niet altijd zonder werk...

Inderdaad... dan zal ik dat "vrij veel taken ernaast hoor, die niet perse zwaar zijn." wel verkeerd begrepen hebben.

Dit verschil is me ook niet helemaal duidelijk, althans. Apollo draait met een normale belasting (ietsje lager geloof ik zelfs).

Sinds een tijdje (ik weet niet sinds wanneer, maar ben er achteraan aan het gaan) wordt artemis veel zwaarder belast.
[..]

Neuh, dat staat daar verder los van.

Er was een redelijk gelijke belasting voor apollo en artemis, maar (zie paar regels omhoog) sinds kort niet meer.

Oke, dus even opsommen:
1 webserver (odin) die niet ingezet wordt wegens instabiliteit;
1 database server (Apollo) die niet goed ingezet wordt wegens ???;
1 database server (Artemis) die overbelast is door het verkeerd inzetten van Apollo, zie hierboven;
1 webserver (arshia) die vaak overbelast wordt door verkeerd geschreven software dat zich ook nog eens niet laat loadbalancen;
1 webserver (aphrodite) die overbelast is omdat er taken op draaien die makkelijk ergens anders zouden kunnen draaien

En dat wilt men oplossen door nog meer servers in te zetten. Ligt het dan aan mij of wordt het gewoon verkeerd aangepakt?

[Pc123]

Op donderdag 25 oktober 2001 18:06 schreef RickJansen het volgende:

En dat wilt men oplossen door nog meer servers in te zetten. Ligt het dan aan mij of wordt het gewoon verkeerd aangepakt?

Een load balancer lijkt me wel een goed idee maar met de servers die er nu zijn moet t allemaal best kunnen met de goeie software.

[wildhagen]

Op donderdag 25 oktober 2001 18:08 schreef Pc123 het volgende:

[..]

Een load balancer lijkt me wel een goed idee maar met de servers die er nu zijn moet t allemaal best kunnen met de goeie software.

Dat klopt ja... maar dan moet er ook voor worden gezorgd dat Apollo en Odin goed gaan functioneren. En wel zo spoedig mogelijk, gezien de uren downtime die we tegenwoordig dagelijks hebben.

[ACM]

Op donderdag 25 oktober 2001 18:06 schreef RickJansen het volgende:
Kapotte harddisk zou ik idd geen normale omstandigheid noemen, maar extra views? Extra views horen juist onder normale omstandigheden, want dat komt altijd weer voor.

Nee, dat is niet waar... Goed voorbeeld was het slashdot effect bij die itanium review. Dat zal uiteraard op got wat minder snel gebeuren, maar het is mogelijk.

Een lapje

Je kan natuurlijk ook al mijn woorden verdraaien.

Inderdaad... dan zal ik dat "vrij veel taken ernaast hoor, die niet perse zwaar zijn." wel verkeerd begrepen hebben.

Ik had het niet over "niet zware taken" maar over taken die niet perse zwaar zijn.
En in dit geval oa niet continue zwaar zijn.

1 database server (Apollo) die niet goed ingezet wordt wegens ???;

Knap dat je die conclusie trekt... Dat is namelijk niet het geval.

De load van mysql op artemis is af en toe buitensporig hoog, maar het is alweer flink aan het dalen sinds die piek van vanmiddag.

1 webserver (arshia) die vaak overbelast wordt door verkeerd geschreven software dat zich ook nog eens niet laat loadbalancen;

Sinds een tijdje (en laat de wijzigingen in de software van apollo nou net daarvoor bedoelt zijn) valt dat reuze mee.

1 webserver (aphrodite) die overbelast is omdat er taken op draaien die makkelijk ergens anders zouden kunnen draaien

Zie stuk omhoog.

En dat wilt men oplossen door nog meer servers in te zetten. Ligt het dan aan mij of wordt het gewoon verkeerd aangepakt?

Belachelijk niet? Magoed, ik ga geen details geven van dingen waar ik niet weet of dat de bedoeling is. Dus kan ik hier verder niet al te goed op ingaan.

[RvdH]

Op donderdag 25 oktober 2001 18:17 schreef ACM het volgende:

[..]

Nee, dat is niet waar... Goed voorbeeld was het slashdot effect bij die itanium review. Dat zal uiteraard op got wat minder snel gebeuren, maar het is mogelijk.
[..]

Uhuh, dat soort views zijn eenmalig. Maar op GoT zien we regelmatig een #55 of timeout. Jouw theorie volgende dat 500K views makkelijk kan, zal GoT dus tijdens die #55 of timeout meer bezoekers, meer pageviews/sec moeten verwerken, en dat zijn extra views. Extra views die naarmate t.net/GoT populairder worden alleen maar groeien. De bezoekers zouden daar niets van moeten merken, maar krijgen toch weer een #55 of timeout voor hun neus, een teken dat of Topix of Arshia niet goed geconfigged is.

Je kan natuurlijk ook al mijn woorden verdraaien.

Sorry, waar slaat dit stukje op? Ik kan dat "lapje" nergens in mijn reactie terugvinden.

Ik had het niet over "niet zware taken" maar over taken die niet perse zwaar zijn.
En in dit geval oa niet continue zwaar zijn.
[..]

Maar toch zorgt het ervoor dat Aphrodite continue een hogere load heeft dan de andere servers.

Knap dat je die conclusie trekt... Dat is namelijk niet het geval.

Als ik zie dat het aantal queries op Apollo maar een klein percentage is van de queries op Artemis, terwijl Apollo als primaire taak een database draaien heeft, kan ik alleen maar concluderen dat er van Apollo's capaciteiten niet voldoende gebruik wordt gemaakt -> en dus verkeerd wordt ingezet.

De load van mysql op artemis is af en toe buitensporig hoog, maar het is alweer flink aan het dalen sinds die piek van vanmiddag.
[..]

Die pieken zullen toch ergens vandaan moeten komen, wellicht is het de moeite waard dat te onderzoeken.

Sinds een tijdje (en laat de wijzigingen in de software van apollo nou net daarvoor bedoelt zijn) valt dat reuze mee.
[..]

Wat heeft de (MySQL, neem ik aan) software op Apollo te maken met de Topix die vanaf Arshia naar Artemis connect (toch?) ? GoT had toch niks met Apollo te maken, dat was immers een replication slave voor Artemis

Belachelijk niet? Magoed, ik ga geen details geven van dingen waar ik niet weet of dat de bedoeling is. Dus kan ik hier verder niet al te goed op ingaan.

In het verleden is al gebleken dat het inzetten van extra servers geen goede oplossing is, zolang ze niet goed worden ingezet. Zolang er doorgegaan wordt met symptoombestrijding ipv dat de problemen bij de fundering worden aangepakt, zul je keer op keer tegen deze zelfde problemen aanlopen. Immers, het bezoekersaantal blijft groeien. Een (paar) nieuwe server(s) erbij plaatsen werkt misschien tijdelijk, maar het aantal bezoekers haalt dat snel weer in. Dat was zo met de switch van Athena -> Artemis, en met de plaatsing van de nieuwe webservers.

[ACM]

Op donderdag 25 oktober 2001 18:41 schreef RickJansen het volgende:
Uhuh, dat soort views zijn eenmalig. Maar op GoT zien we regelmatig een #55 of timeout. Jouw theorie volgende dat 500K views makkelijk kan, zal GoT dus tijdens die #55 of timeout meer bezoekers, meer pageviews/sec moeten verwerken, en dat zijn extra views. Extra views die naarmate t.net/GoT populairder worden alleen maar groeien. De bezoekers zouden daar niets van moeten merken, maar krijgen toch weer een #55 of timeout voor hun neus, een teken dat of Topix of Arshia niet goed geconfigged is.

Klopt, ik had het ook niet over de 500k views per dag, maar over de extremen.

Sorry, waar slaat dit stukje op? Ik kan dat "lapje" nergens in mijn reactie terugvinden.

't Sloeg eigenlijk op je hele post.

Maar toch zorgt het ervoor dat Aphrodite continue een hogere load heeft dan de andere servers.

Een hogere load is niet perse slecht.
Natuurlijk, het kan beter. Maar ik ga niet zomaar rommelen in configuraties die ik niet ingesteld heb en ik laat het serverbeheer ook aan de persoon die daarvoor aangenomen is over.

Als ik zie dat het aantal queries op Apollo maar een klein percentage is van de queries op Artemis, terwijl Apollo als primaire taak een database draaien heeft, kan ik alleen maar concluderen dat er van Apollo's capaciteiten niet voldoende gebruik wordt gemaakt -> en dus verkeerd wordt ingezet.

Wat is artemis' primaire taak dan? irc.tweakers.net ?
Dat is ook een database draaiend houden.

Die pieken zullen toch ergens vandaan moeten komen, wellicht is het de moeite waard dat te onderzoeken.

Dat ben ik ook aan het doen.
Een deel daarvan had juist te maken met replication (voor zover ik begreep/kon overzien).

Wat heeft de (MySQL, neem ik aan) software op Apollo te maken met de Topix die vanaf Arshia naar Artemis connect (toch?) ? GoT had toch niks met Apollo te maken, dat was immers een replication slave voor Artemis

Replication staat al tijden uit (ga daar niet op doorvragen, daar weet ik nauwelijks een antwoord op en geef ik dus ook niet)
En daardoor draait apollo _juist_ de GoT database.

Bovendien, zou als apollo puur replication slave zou zijn, arshia ook met apollo moeten (kunnen) connecten.

In het verleden is al gebleken dat het inzetten van extra servers geen goede oplossing is, zolang ze niet goed worden ingezet. Zolang er doorgegaan wordt met symptoombestrijding ipv dat de problemen bij de fundering worden aangepakt, zul je keer op keer tegen deze zelfde problemen aanlopen. Immers, het bezoekersaantal blijft groeien. Een (paar) nieuwe server(s) erbij plaatsen werkt misschien tijdelijk, maar het aantal bezoekers haalt dat snel weer in. Dat was zo met de switch van Athena -> Artemis, en met de plaatsing van de nieuwe webservers.

Er wordt dan ook niet alleen maar een webserver bijgeplaatst, maar ademruimte voor de andere servers gecreeerd en daarnaast meer capaciteit gegenereerd.

Magoed, zoals ik al eerder zei. Ik weet niet wat ik wel en niet mag zeggen daarover, dus zeg ik er niks over.

[Femme]

De extra Dual Athlon webserver komt erbij omdat we sinds maar dit jaar geen uitbreiding van de webservers meer hebben gedaan terwijl het aantal pageviews is gestegen van 550K naar 850K-950K per dag. Athena moet meegenomen worden om opnieuw geconfigged te worden. Dit zou veel problematischer worden als we op 3 webservers moeten draaien. Vier kan in principe wel als de load goed gebalanced is, maar het is geen prettige situatie met het oog op de toekomst.

Die nieuwe server kan in principe erg snel geplaatst worden, maar dat ligt aan de vorderingen die Kees heeft gemaakt met het configgen van dat ding.

De LVS'en gaan pas werken als Athena opnieuw is geconfigged als fileserver. Eventueel kunnen de LVS'en ook gebruikt worden voor het serveren van images. Er kan dus meer capaciteit komen en een veel betere load balancing.

Aphrodite is de enige webserver die op dit moment een goede configuratie heeft. De load is hoger dan van de andere servers, maar ze heeft er niet echt veel problemen mee.

Athena moet sowieso opnieuw geconfigged worden. Hier draait Fok! in zijn geheel op en dat is ook niet bepaald handig ivm load balancing.

Odin en Arshia draaien op FreeBSD wat allerlei problemen geeft. Beide servers worden overgezet naar Linux als de dual Athlon webserver wordt geplaatst. Dit probleem is dus ook binnenkort opgelost.

Waar die enorme hoeveelheid queries op Artemis plotseling vandaan komt is mij niet geheel duidelijk (Fok! misschien). Het zegt niet zoveel over de load, aangezien je zware en lichte queries hebt. De load op Artemis is normaal gesproken niet dramatisch veel hoger dan op Apollo. Er waren wat problemen met de load op Artemis maar die zijn nu opgelost.

Wat heeft de (MySQL, neem ik aan) software op Apollo te maken met de Topix die vanaf Arshia naar Artemis connect (toch?) ? GoT had toch niks met Apollo te maken, dat was immers een replication slave voor Artemis

Apollo doet (bijna) niets anders dan GoT.

In het verleden is al gebleken dat het inzetten van extra servers geen goede oplossing is, zolang ze niet goed worden ingezet. Zolang er doorgegaan wordt met symptoombestrijding ipv dat de problemen bij de fundering worden aangepakt, zul je keer op keer tegen deze zelfde problemen aanlopen. Immers, het bezoekersaantal blijft groeien.

In het verleden is gebleken dat het plaatsen van extra webservers erg goed helpt om de load problemen op te lossen. Echter, om de extra webservers optimaal in te zetten moet er gezocht worden naar een betere opstelling. Dit is zo ongeveer het eerste wat Kees heeft gedaan toen hij sysadmin werd. Dit zien we terug in het plan met de twee load balancers en de centrale fileserver. Verder draait er nu (of gaat er draaien) up-to-date software op de webservers en database servers zodat we optimaal gebruik kunnen maken van de Linux 2.4 kernel, MySQL/InnoDB en snellere webservers zoals Boa voor statische files.

Een (paar) nieuwe server(s) erbij plaatsen werkt misschien tijdelijk, maar het aantal bezoekers haalt dat snel weer in.

Dat is nogal logisch. Als de belasting toeneemt heb je meer capaciteit nodig. Ik ken niemand met een toverstok die heel t.net op een 386 kan laten draaien.

[ACM]

Ik vraag me trouwens af...

Heeft iemand nog last van een #55 oid gehad de afgelopen 3 uur en 40 mins (uptime van apollo's mysql) ??

[Buzzman]

Op donderdag 25 oktober 2001 19:00 schreef ACM het volgende:
Ik vraag me trouwens af...

Heeft iemand nog last van een #55 oid gehad de afgelopen 3 uur en 40 mins (uptime van apollo's mysql) ??

hier draait ie per-fect

[RvdH]

Op donderdag 25 oktober 2001 18:54 schreef ACM het volgende:

[..]

Klopt, ik had het ook niet over de 500k views per dag, maar over de extremen.
[..]

Eh, jaja. Naja nu snap ik er helemaal niks meer van.

't Sloeg eigenlijk op je hele post.
[..]

Met.. welke bedoeling?

Een hogere load is niet perse slecht.
Natuurlijk, het kan beter. Maar ik ga niet zomaar rommelen in configuraties die ik niet ingesteld heb en ik laat het serverbeheer ook aan de persoon die daarvoor aangenomen is over.
[..]

Fully agreed..

Wat is artemis' primaire taak dan? irc.tweakers.net ?
Dat is ook een database draaiend houden.
[..]

En dat heeft.. wat precies met mijn stukje over Apollo te maken
Artemis heeft netzoveel PK's onder de kap als Apollo (ik dacht nog wat minder geheugen), terwijl Artemis 4,5 keer zoveel queries verwerkt. Dat is dus of een ontzettende verspilling van capaciteit, of Apollo kan niks meer (getuigende de #55's), wat weer wijst op een verkeerde configuratie.

Er wordt dan ook niet alleen maar een webserver bijgeplaatst, maar ademruimte voor de andere servers gecreeerd en daarnaast meer capaciteit gegenereerd.

Met welk doel? Er is al een capaciteitsoverschot (er wordt alleen geen gebruik van gemaakt), en "ademruimte" (wat dat ook moge wezen) lijkt me gelijk staan aan capaciteit.

Op donderdag 25 oktober 2001 18:59 schreef Femme het volgende:

Athena moet sowieso opnieuw geconfigged worden. Hier draait Fok! in zijn geheel op en dat is ook niet bepaald handig ivm load balancing.

Wat is er mis mee dan? Zo te zien is het de enige server die al 125+ dagen lekker draait. Maargoed, dat is ook maar van de buitenkant gezien..

Dat is nogal logisch. Als de belasting toeneemt heb je meer capaciteit nodig.

Tenzij je de huidige capaciteit goed verdeelt en inzet.

[RvdH]

Op donderdag 25 oktober 2001 19:00 schreef ACM het volgende:
Ik vraag me trouwens af...

Heeft iemand nog last van een #55 oid gehad de afgelopen 3 uur en 40 mins (uptime van apollo's mysql) ??

Laatste keer was 11:45am

[ACM]

Op donderdag 25 oktober 2001 19:18 schreef RickJansen het volgende:
Laatste keer was 11:45am

Mooi, de laatste mysql reset was nl om wat settings te wijzigen en die lijken veel problemen opgelost te hebben.

Daarvoor was het alleen maar omdat het 'niet werkte'.

Het aantal queries dat artemis te verwerken heeft is ook stukken gedaald sinds Femme's wijzigingen aan de configuratie daarvan geloof ik.

[MoBi]

enkele punten met rick ben ik wel eens. Er word een vergelijking ergens door iemand in deze thread gegeven met anandtech.com. Anand heeft lichtere database server dan tweakers staan. En deze draaien op windows. Probleem waar je volgens mij nu mee zit is dat
1)
De replication gewoon niet werkt van mysql. Dit heeft er toe geleid dat got een aparte db server heeft, leuk. Maar, als got te groot is voor een db server is er dus geen goede mogelijkheid tot het load balancen van de db server. Dat is nu ook een probleem aan het worden met tweakers.net. Ja in nieuwere versies, bla bla bla. De nieuwe versie van mysql is er nog lang niet, je zit nu met dit probleem. Misschien moet er eens naar een echt betaalde dmbs worden gekeken al dan niet gesponserd. In oudere threads over dit onderwerp. Is een compleet pakket aangeboden door iemand. Windows 2000 server en Mssql versie zoveel. Is niks mee gedaan omdat de kennis voor het onderhouden ontbrak. Aan het verhaaltje van Femme te horen zitten we nog wel een tijdje met error 55's brakke frontpage enz.
2) Php. Php? Ja, php heeft geen goede cache mogelijkheden. De pollvraag kun je gewoon cachen op de frontpage (antwoord niet, natuurlijk). En zo zijn er nog wel meer dingen die je kunt cachen. Andere ontwikkelingstaal die die punten wel heeft misschien al dan niet betaald.
3) Toekomst tweakers.net / got. Dit probleem is niet tijdelijk, dit is een terug kerend probleem. Deze discussie is al eerder geweest. Rick heeft gelijk, het bij plaatsen van servers is geen goede oplossing als de pagina's of serversoftware op de server gewoon brak zijn. Daar denk je het mee op te lossen. Andere software kan al zo veel helpen.

[Steven]

Op donderdag 25 oktober 2001 14:05 schreef wildhagen het volgende:

[..]

Kijkt daar wel eens iemand dan?

Een bericht in Marquee, Bold, Lettergroote 72 punt, over het hele scherm. Dat lijkt me de beste manier. Owja, doe ook nog maar Blink.

Vergeet <blink> niet voor de Netschaap users

[Femme]

Tenzij je de huidige capaciteit goed verdeelt en inzet.

Dat is uiteraard wel zo, maar het is een vasstaand feit dat er een directe relatie bestaat tussen belasting en capaciteit. Ook als de scripts en databases optimaal getuned zijn, zal een bepaalde hardware configuratie op een gegeven niet meer snel genoeg zijn om de load te verwerken.

Anand heeft lichtere database server dan tweakers staan. En deze draaien op windows.

AnandTech doet heel veel aan caching van SQL queries in ColdFusion. AnandTech is dus onvergelijkbaar met Tweakers.net.

De replication gewoon niet werkt van mysql. Dit heeft er toe geleid dat got een aparte db server heeft, leuk. Maar, als got te groot is voor een db server is er dus geen goede mogelijkheid tot het load balancen van de db server.

Replication werkt in feite prima, alleen gaat-ie steeds stuk op een bepaalde query in Topix. Waarschijnlijk is het niet zo moeilijk om daar een oplossing of workaround voor te vinden, maar ik kan de code van Topix niet aanpassen. Toen die query nog niet in Topix zat heeft replication wekenlang probleemloos gedraaid.

Ook al zou replication goed werken, dan nog is het niet slim om alle databases op één master server te draaien en daar een paar slaves aan te hangen. Dit zorgt alleen maar voor onnodige overhead in het bijhouden van de replication logs en het updaten van de slaves.

Op dit moment hebben beide database servers het redelijk druk. Het heeft weinig zin om replication op te zetten tussen twee redelijk belaste servers als daarmee je doel is om de load te verlagen. Je krijgt dan alleen maar meer overhead.

Misschien moet er eens naar een echt betaalde dmbs worden gekeken al dan niet gesponserd. In oudere threads over dit onderwerp. Is een compleet pakket aangeboden door iemand. Windows 2000 server en Mssql versie zoveel.

Ik hoor alleen maar geluiden dat Oracle en MSSQL veel trager zijn dan MySQL. Waarom upgraden naar een tragere database server die ook nog eens onbetaalbaar is...

Is niks mee gedaan omdat de kennis voor het onderhouden ontbrak. Aan het verhaaltje van Femme te horen zitten we nog wel een tijdje met error 55's brakke frontpage enz.

Voor de MySQL upgrade heeft de MySQL op Artemis 26 dagen onafgebroken gewerkt en in die tijd 400 miljoen queries verwerkt. Het is nu gewoon even een kwestie van MySQL opnieuw tunen.

Php. Php? Ja, php heeft geen goede cache mogelijkheden. De pollvraag kun je gewoon cachen op de frontpage (antwoord niet, natuurlijk). En zo zijn er nog wel meer dingen die je kunt cachen. Andere ontwikkelingstaal die die punten wel heeft misschien al dan niet betaald.

De frontpage en de update tracker worden al gecached.

3) Toekomst tweakers.net / got. Dit probleem is niet tijdelijk, dit is een terug kerend probleem. Deze discussie is al eerder geweest. Rick heeft gelijk, het bij plaatsen van servers is geen goede oplossing als de pagina's of serversoftware op de server gewoon brak zijn. Daar denk je het mee op te lossen. Andere software kan al zo veel helpen.

En daar wordt dus ook aan gewerkt.

[MoBi]

Op donderdag 25 oktober 2001 20:21 schreef Femme het volgende:


AnandTech doet heel veel aan caching van SQL queries in ColdFusion. AnandTech is dus onvergelijkbaar met Tweakers.net.
[..]

De mogelijkheid zit in coldfusion waarom zou je die dan niet gebruiken? Anands frontpage is niet minder dynamisch dan die van tweakers.

Ik hoor alleen maar geluiden dat Oracle en MSSQL veel trager zijn dan MySQL. Waarom upgraden naar een tragere database server die ook nog eens onbetaalbaar is...
[..]

Trager wil niet zeggen slechter. Dat je frontpage er 10 ms langer over doet, maakt niks uit, dingen als stored procedures, sub query's enz zorgen weer voor snelheids winst.

Voor de MySQL upgrade heeft de MySQL op Artemis 26 dagen onafgebroken gewerkt en in die tijd 400 miljoen queries verwerkt. Het is nu gewoon even een kwestie van MySQL opnieuw tunen.
[..]

Waarom upgraden als het werkt? Is een hoger versie nummer altijd beter? Support voor innodb kun je ook in oudere versie's bouwen.

[Femme]

Op donderdag 25 oktober 2001 21:50 schreef MoBi het volgende:

[..]

De mogelijkheid zit in coldfusion waarom zou je die dan niet gebruiken? Anands frontpage is niet minder dynamisch dan die van tweakers.

Er is een universum van verschil tussen de dynamiek van AnandTech en Tweakers.net. De t.net database is continu onderhevig aan veranderingen (reacties, pricewatch, moderaties enz.). AnandTech heeft dat niet, daar worden regelmatig wat nieuwe artikelen en nieuwspostings gepost en verder gebeurd er weinig.

Trager wil niet zeggen slechter. Dat je frontpage er 10 ms langer over doet, maakt niks uit, dingen als stored procedures, sub query's enz zorgen weer voor snelheids winst.

Maar er is geen snelheidswinst is wat ik hoor en lees van de mensen die ervaring hebben met Oracle-achtige DBMS'en en MySQL. De dure commerciële DBMS'en zijn zware overkill voor wat wij willen doen (een website draaien).

Waarom upgraden als het werkt? Is een hoger versie nummer altijd beter? Support voor innodb kun je ook in oudere versie's bouwen.

Bugfixes (o.a. mbt replication), nieuwe features enz. De MySQL 3.43 op Artemis draaide al 2 dagen stabiel totdat ik met binlogs ging klooien waardoor de load skyhigh ging. Inmiddels draait het weer normaal en ik verwacht verder geen grote problemen meer. Wat er op Apollo aan de hand is weet ik niet aangezien ik me daar niet mee heb bezig gehouden.

[MoBi]

Op donderdag 25 oktober 2001 22:23 schreef Femme het volgende:

Bugfixes (o.a. mbt replication), nieuwe features enz. De MySQL 3.43 op Artemis draaide al 2 dagen stabiel totdat ik met binlogs ging klooien waardoor de load skyhigh ging. Inmiddels draait het weer normaal en ik verwacht verder geen grote problemen meer. Wat er op Apollo aan de hand is weet ik niet aangezien ik me daar niet mee heb bezig gehouden.

Klooien doe je op een test server thuis (of op je eigen pc die als test server fungeert) klooien doe je nooit op een productie server, want ieder uur niet bereikbaar is ieder uur geen banners is ieder uur geen geld voor tweakers.net

[ACM]

Op donderdag 25 oktober 2001 22:31 schreef MoBi het volgende:
Klooien doe je op een test server thuis (of op je eigen pc die als test server fungeert) klooien doe je nooit op een productie server, want ieder uur niet bereikbaar is ieder uur geen banners is ieder uur geen geld voor tweakers.net

In principe heb je daar gelijk in.

Nadeel is, dat we thuis niet echt systemen hebben die we kunnen onderwerpen aan de belasting die t.net eraan stelt.

Tuurlijk, kleine tests kan wel... php-development zie ik ook nooit een parse-error voorbij komen, maar je kan natuurlijk niet thuis erachter komen dat je dual-p3-1Ghz database niet soepel loopt met 400 connected clients etc etc.

[Femme]

Op donderdag 25 oktober 2001 22:31 schreef MoBi het volgende:

[..]

Klooien doe je op een test server thuis (of op je eigen pc die als test server fungeert) klooien doe je nooit op een productie server,

Ik kan maar beter niet het woord 'klooien' gebruiken want dan krijg je weer dit soort opmerkingen. Replication heeft nooit een grote invloed gehad op de load dus er was geen reden om te vermoeden dat het nu 's middags wel een probleem zou geven.

En probeer maar eens een testomgeving met dezelfde hardware en load van t.net te simuleren.

[/quote]want ieder uur niet bereikbaar is ieder uur geen banners is ieder uur geen geld voor tweakers.net[/quote]

Die vlieger gaat niet op aangezien het totaal aantal beschikbare bannerviews de verkochte banner ruimte ruimschoots overschrijdt.

[Onno]

Op donderdag 25 oktober 2001 22:23 schreef Femme het volgende:
De dure commerciële DBMS'en zijn zware overkill voor wat wij willen doen (een website draaien).

Je vergeet daarbij wel iets: die dure commerciele RDBMS'en bieden niet alleen een overvloed aan nuttige features, ze hebben nog iets wat ze onderscheidt van MySQL: stabiliteit en schaalbaarheid. En dat zijn twee dingen die je ook voor je website wilt hebben.

De MySQL 3.43 op Artemis draaide al 2 dagen stabiel

Moet dit ook maar enig gevoel van ontzag voor MySQL opwekken ofzo?

Die vlieger gaat niet op aangezien het totaal aantal beschikbare bannerviews de verkochte banner ruimte ruimschoots overschrijdt.

Ow, dus eigenlijk hebben jullie helemaal geen last van een paar bannerblockers, er zijn toch niet genoeg betalende banners.

[Femme]

Op vrijdag 26 oktober 2001 00:14 schreef Onno het volgende:

Moet dit ook maar enig gevoel van ontzag voor MySQL opwekken ofzo?

Die nieuwe MySQL draaide net 2 dagen. Daarvoor zat MySQL 3.23.38 op een uptime van 26 dagen.

[Pc123]

Volgens mij is Artemis down, het nieuws is 6 dagen oud.

[Femme]

Ik moest even een dump maken.

[Bart Coppens]

Lag GoT zonet wéér down of lag het aan mijn brakke ADSL-verbinding?

[Slasher]

het lag niet aan jouw

[Tomsworld]

Op vrijdag 26 oktober 2001 13:56 schreef Bart Coppens het volgende:
Lag GoT zonet wéér down of lag het aan mijn brakke ADSL-verbinding?

Ja GoT lag er blijkbaar uit van rond 12u.

[Garfield|IA]

Ja, maar ook T-net als ik mij niet vergis.

[Koffie]

Zou hetniet eens een keer verstandg zijn om iets op de T.Net frontpage te plaatsen als GoT weer 'ns plat ligt ?

[Onno]

Daar wordt de frontpage wel erg vol van.

[Crazy D]

Op vrijdag 26 oktober 2001 13:59 schreef Devil_2000 het volgende:
Ja, maar ook T-net als ik mij niet vergis.

t.net deed het hier gewoon hoor...

[Verwijderd]

Onno: Daar wordt de frontpage wel erg vol van.

Lang plat is maar 1 melding.

[justmental]

Op donderdag 25 oktober 2001 22:23 schreef Femme het volgende:

Maar er is geen snelheidswinst is wat ik hoor en lees van de mensen die ervaring hebben met Oracle-achtige DBMS'en en MySQL. De dure commerciële DBMS'en zijn zware overkill voor wat wij willen doen (een website draaien).
[..]

Daar heb ik andere ervaringen mee.
Professionele commerciële DBMS'en zijn stabieler en schaalbaarder en zeker geen overkill voor een website als deze (welke je uiteindelijk ook beter kunt karakteriseren als een applicatie).
Maar ik ben het met je eens dat dat veel geld kost, en als dat er niet is vervalt de optie dus tot een manier gevonden wordt om meer inkomsten te genereren.

[Crazy D]

Op vrijdag 26 oktober 2001 14:10 schreef justmental het volgende:
Maar ik ben het met je eens dat dat veel geld kost, en als dat er niet is vervalt de optie dus tot een manier gevonden wordt om meer inkomsten te genereren.

Er is al eens een w2k licentie + MSSQL licentie aangeboden. Alleen zet je een site als deze niet zomaar ff over naar iets wat op windows/MSSQL goed draait om ff te testen... zeker niet als je ook de load zoals we die hier kennen wil nabootsen op een realistische manier.

[Verwijderd]

CrazyD_at_work: Je zet een site als deze niet zomaar ff over naar iets wat op windows/MSSQL goed draait om ff te testen... zeker niet als je ook de load zoals we die hier kennen wil nabootsen op een realistische manier.

En waarom zou het draaien van GoT/t.net op Windows/MSSQL ineens alle problemen oplossen? Of ligt het allemaal aan Linux/FreeBSD en MySQL?

/me thinks not...

[Crazy D]

Op vrijdag 26 oktober 2001 14:22 schreef Arien het volgende:
En waarom zou het draaien van GoT/t.net op Windows/MSSQL ineens alle problemen oplossen? Of ligt het allemaal aan Linux/FreeBSD en MySQL?

/me thinks not...

Dat zeg ik ook niet. Maar geef toe, veel brakker dan de laatste dagen kan haast niet
En 't was een reactie op justmental.

[raptorix]

Misschien lost het niet alle problemen op maar via sqlserver tools kan je tenminste op een degelijke manier je database testen, daarnaast is replicatie dan wel clustering stukken makkelijker op te zetten.

[Verwijderd]

raptorix: Misschien lost het niet alle problemen op maar via sqlserver tools kan je tenminste op een degelijke manier je database testen, daarnaast is replicatie dan wel clustering stukken makkelijker op te zetten.

En configuratie van SQL Server voor het onderste uit de kan mbt performance en resources gaat vanzelf, etc.

[justmental]

Op vrijdag 26 oktober 2001 14:28 schreef CrazyD_at_work het volgende:

Dat zeg ik ook niet. Maar geef toe, veel brakker dan de laatste dagen kan haast niet
En 't was een reactie op justmental.

Of het de oplossing voor de performance problematiek is is IMHO niet zo relevant.
Migratie/ombouw zou veel meer kosten dan zo'n licentie.

In mijn optiek zit t.net/got op een kruispunt waar men (MT) moet gaan beslissen om op deze manier verder te gaan of een meer commercieel pad in te slaan.

[raptorix]

Op vrijdag 26 oktober 2001 14:34 schreef Arien het volgende:

[..]

En configuratie van SQL Server voor het onderste uit de kan mbt performance en resources gaat vanzelf, etc.

Zoveel resources neemt Sql Server nou ook weer niet, in ieder geval zou het goed moeten draaien op wat er nu tot beschikking staat. Daarnaast zijn er idd zeer veel manieren om sqlserver te optimaliseren, echter imo zou je met een slim caching systeem een veel beter resultaat kunnen bereiken.

[Onno]

Op vrijdag 26 oktober 2001 15:00 schreef raptorix het volgende:
echter imo zou je met een slim caching systeem een veel beter resultaat kunnen bereiken.

En dat is dus het hele punt: al kan je software nog zo veel, zolang je 't niet optimaal gebruikt heb je er niets aan. En voor dat optimaal kunnen gebruiken is weer (ontbrekende) kennis nodig.

[Verwijderd]

raptorix: Er zijn idd zeer veel manieren om sqlserver te optimaliseren, ...

En aangezien dat niet automagisch allemaal gebeurt moet je wel weten hoe het optimaal geconfigureerd kan worden.

... echter imo zou je met een slim caching systeem een veel beter resultaat kunnen bereiken.

Eens, vandaar mij opmerking.

Er zijn veel meer factoren dan je database en je specifieke OS: Hoe zijn de servers geconfigureerd? Hoe is de database geconfigureerd? Hoe efficient is de scripting van het forum? Wordt caching gebruikt? Op welke manier? Waar zit de bottleneck eigenlijk (gemeten, niet verondersteld)? Etc.

[Verwijderd]

Onno: Voor [het] optimaal kunnen gebruiken [van je software] is weer (ontbrekende) kennis nodig.

Bijvoorbeeld de werking van het forum...

[Kees]

Hmmjah, de allerbelangrijkste limiterende factor van het moment zijn de (lange) tablelocks. we gaan testen met innodb, dat zou de boel een beetje moeten ontlasten omdat het met rowlevellocking werkt ipv tablelocks.

Ook zijn we aan het kijken naar meer permanente oplossingen, maar dit duurt zeker enige maanden.

[Femme]

En het goede nieuws is dat de dual Athlon webserver morgen in z'n rackje gaat .

[Verwijderd]

Op vrijdag 26 oktober 2001 16:37 schreef Femme het volgende:
En het goede nieuws is dat de dual Athlon webserver morgen in z'n rackje gaat .

Woohoo!

Maarre .. die doet T.Net, en niet GoT toch ?

[Femme]

Het lijkt me het slimst dat-ie Arshia gaat vervangen totdat de load balancers er zijn.

[Verwijderd]

Dat klinkt niet verkeerd

[Verwijderd]

Op vrijdag 26 oktober 2001 16:39 schreef Femme het volgende:
Het lijkt me het slimst dat-ie Arshia gaat vervangen totdat de load balancers er zijn.

Femme, wanneer komt de serverpark update. Er hebben namelijk veel wijzigingen plaats gevonden en ik snap er geen bal meer van.

[wildhagen]

Op vrijdag 26 oktober 2001 16:44 schreef Generaal_Putlucht het volgende:

[..]

Femme, wanneer komt de serverpark update. Er hebben namelijk veel wijzigingen plaats gevonden en ik snap er geen bal meer van.

Is toch niet zo moeilijk?

Athena : Fok+Fokzine + webserver
Apollo : DB-server voor GoT
Artemis: DB-server tw.net (en ook Fok?)
Odin : webserver
Arshia : GoT-webserver
Aphrodite : weet ik niet... webserver?

Hoe gaat die nieuwe heten?

[Kees]

Op vrijdag 26 oktober 2001 16:46 schreef wildhagen het volgende:

[..]

Is toch niet zo moeilijk?

Athena : Fok+Fokzine + webserver
Apollo : DB-server voor GoT
Artemis: DB-server tw.net (en ook Fok?)
Odin : webserver
Arshia : GoT-webserver
Aphrodite : weet ik niet... webserver?

Hoe gaat die nieuwe heten?

Athena: fok frontpage, tw.net
Apollo: GoT dbaseserver
Artemis: DBserver tw.net & fok
Odin: tw.net
arshia: GoT
Aphrodite: fokforum & klein beetje tw.net

dual morgen gaat arhsia vervangen, die neemt athena over en athena gaat mee naar huis voor een restyle

[Verwijderd]

Op vrijdag 26 oktober 2001 16:50 schreef Kees het volgende:

[..]

Athena: fok frontpage, tw.net
Apollo: GoT dbaseserver
Artemis: DBserver tw.net & fok
Odin: tw.net
arshia: GoT
Aphrodite: fokforum & klein beetje tw.net

dual morgen gaat arhsia vervangen, die neemt athena over en athena gaat mee naar huis voor een restyle

Mjah. System specs + foto's doen het ook altijd wel goed

[Femme]

Kees weet de exacte specs, maar het lijkt op:

Dual Athlon MP 1,2GHz
Tyan Tiger MP
1GB PC2100 DDR
20GB Seagate Barracuda ATA IV
2x Intel EtherExpress Pro 10/100 NIC
Diamond Stealth S220 3D accelerator (Rendition Vérité 2100)
ProCase C2S 2U rackmount

En we hebben ook nog een Tyan Thunder K7 liggen waar we iets leuks mee gaan doen .

[Tomsworld]

Op vrijdag 26 oktober 2001 16:57 schreef Femme het volgende:
Kees weet de exacte specs, maar het lijkt op:

Dual Athlon MP 1,2GHz
Tyan Tiger MP
1GB PC2100 DDR
20GB Seagate Barracuda ATA IV
2x Intel EtherExpress Pro 10/100 NIC
Diamond Stealth S220 3D accelerator (Rendition Vérité 2100)
ProCase C2S 2U rackmount

En we hebben ook nog een Tyan Thunder K7 liggen waar we iets leuks mee gaan doen .

Femme of Kees.

Komt er dan nog een kleine .plan op de frontpage vandaag waarin staat hoelang de downtime gaat zijn. En waarin je de leuke serveerspecs nog es meldt. Dat iedereen weet dat de downtime vooruitgang betekent. (Hopen we )

[RvdH]

Okee, dus er wordt weer een andere webserver ingezet. Leuk en alles, maar wat lost dat aan database (#55) problemen op?

[Femme]

Niets. Die webserver wordt niet ingezet omdat de load op de databases hoog is maar omdat de webservers het zwaar hebben...

Vannacht gaan we kijken of het forum deels overgezet kan worden naar InnoDB. Table-locking is op dit moment een zwaar probleem aan het worden, zowel op GoT als Fok!

[Coen Rosdorff]

Op vrijdag 26 oktober 2001 18:29 schreef Femme het volgende:
Vannacht gaan we kijken of het forum deels overgezet kan worden naar InnoDB. Table-locking is op dit moment een zwaar probleem aan het worden, zowel op GoT als Fok!

Dat klinkt nu eens als een stap in de goede richting.

Maak van de queries die een nieuw topic maken gelijk even een transactie. Dan zijn we van de brakke topics af.

Keep up doing the good work.

[RvdH]

Ah oke, dan weet ik dat ik geen verbeteringen hoef te verwachten

[Wouter Tinus]

Op vrijdag 26 oktober 2001 19:44 schreef little_soundman het volgende:
Maak van de queries die een nieuw topic maken gelijk even een transactie. Dan zijn we van de brakke topics af.

Dat moeten de ontwikkelaars van Topix doen.. 'nuff said

[Verwijderd]

maar is het aangezien de groei van GoT geen goed idee (het is maar een idee, waarschijnlijk kan het niet) om GoT op 2 db servers te draaien (van wat ik nu had begrepen draait ie op 1 db server). dat bv dmv een simpel php scriptje alle even topicnummers naar de ene worden gestuurd en alle oneven naar een andere? IMO zou dat het lichter maken voor de db server en het is IMO ook niet moeilijk te realiseren.

[Steven]

Op vrijdag 26 oktober 2001 21:29 schreef spock13 het volgende:
maar is het aangezien de groei van GoT geen goed idee (het is maar een idee, waarschijnlijk kan het niet) om GoT op 2 db servers te draaien (van wat ik nu had begrepen draait ie op 1 db server). dat bv dmv een simpel php scriptje alle even topicnummers naar de ene worden gestuurd en alle oneven naar een andere? IMO zou dat het lichter maken voor de db server en het is IMO ook niet moeilijk te realiseren.

Dat kunnen dus alleen de makers van Topix...

[Coen Rosdorff]

Op vrijdag 26 oktober 2001 20:21 schreef WouterTinus het volgende:

Dat moeten de ontwikkelaars van Topix doen.. 'nuff said

Jaja, dat verhaal over dat wurg-contract van "android" kennen we nu wel.

Gewoon lekker zelf een patch schrijven voor die paar queries, en de patch beschikbaar stellen aan android. De relatie moet wel erg slecht willen ze daar bezwaar tegen maken.

Het gaat hier niet om schoonheids foutjes, maar om dingen in het belang van de goede werking.

[Femme]

Op vrijdag 26 oktober 2001 21:29 schreef spock13 het volgende:
maar is het aangezien de groei van GoT geen goed idee (het is maar een idee, waarschijnlijk kan het niet) om GoT op 2 db servers te draaien (van wat ik nu had begrepen draait ie op 1 db server). dat bv dmv een simpel php scriptje alle even topicnummers naar de ene worden gestuurd en alle oneven naar een andere? IMO zou dat het lichter maken voor de db server en het is IMO ook niet moeilijk te realiseren.

Dat kan ook met replication. Voor de toekomst zou het een idee kunnen zijn om licht geconfigureerde replication servers in te zetten met snelle processors, veel geheugen en een snelle SCSI schijf (maar verder geen RAID e.d.).

Voorlopig kan Apollo het nog wel hebben, alleen is er dus een probleem met table-locking waardoor er soms gigantische opstoppingen ontstaan. Hopelijk kan dit verholpen worden met row-level locking in InnoDB.

Op vrijdag 26 oktober 2001 19:55 schreef RickJansen het volgende:
Ah oke, dan weet ik dat ik geen verbeteringen hoef te verwachten

Tja, als ik had gezegd dat er meer hardware was gekomen (wat ook nog wel gaat gebeuren aan de db-kant) had je gezegd dat dit niet zou helpen aangezien jij kennelijk in de veronderstelling verkeert dat meer hardware niet helpt om load problemen op te lossen, wat natuurlijk onzin heeft. Toen de tweede database server erbij kwam waren alle load problemen ook verdwenen. De bezoekersaantallen nemen toe en de databases worden groter. Het is logisch dat er dan op een gegeven moment weer het plafond wordt bereikt.

Daarbuiten is table-locking een steeds groter probleem geworden, veel meer dan voorheen. Toen was de load continu hoog en nu hebben we alleen soms load pieken die alleen wel erg heftig zijn.

Op vrijdag 26 oktober 2001 19:44 schreef little_soundman het volgende:

[..]

Dat klinkt nu eens als een stap in de goede richting.

Maak van de queries die een nieuw topic maken gelijk even een transactie. Dan zijn we van de brakke topics af.

Keep up doing the good work.

Alles in InnoDB gebeurt binnen transacties, ook als je queries niet expliciteit in je code als transactie behandeld. In InnoDB zullen inserts daarom niet mysterieus verdwijnen zoals dat bij MyISAM soms wel het geval is. Bij een MySQL crash kunnen de laatste updates uit de log buffer gerecovered worden.

[Wouter Tinus]

Op vrijdag 26 oktober 2001 21:57 schreef little_soundman het volgende:
Gewoon lekker zelf een patch schrijven voor die paar queries, en de patch beschikbaar stellen aan android. De relatie moet wel erg slecht willen ze daar bezwaar tegen maken.

Dat zou een optie zijn, maar we hebben geen source-code van Topix (alleen Zend encoded files). Ik begrijp ook uit het verhaal van Femme hierboven dat het helemaal niet nodig is

[Coen Rosdorff]

Op vrijdag 26 oktober 2001 22:28 schreef WouterTinus het volgende:

Dat zou een optie zijn, maar we hebben geen source-code van Topix (alleen Zend encoded files). Ik begrijp ook uit het verhaal van Femme hierboven dat het helemaal niet nodig is

Is dit nu weer de laatste smoes ?
Android heeft geen xxx duizend piek betaald voor de zend-encoder. Eerdere kleine aanpassingen door de crew ondersteunen dit gegeven.

Als reactie op Femme:
Of je laat innodb in auto-commit mode draaien : Elke insert wordt dan gelijk uitgevoerd.
Of je laat innodb niet in auto-commit mode draaien : In dat geval zul je na een insert een commit moeten geven. Dat is vooral handig als je transactie meerdere inserts over meerdere table's omvat. (Zoals bij het aanmaken van een nieuw toppic) Als mysql of apache dan midden in de transactie dood gaat, ontstaan er geen brakke topics of andere enge dingen.

[WoutF]

Op vrijdag 26 oktober 2001 22:36 schreef little_soundman het volgende:

[..]

Is dit nu weer de laatste smoes ?
Android heeft geen xxx duizend piek betaald voor de zend-encoder. Eerdere kleine aanpassingen door de crew ondersteunen dit gegeven.

In een ander topic liet ACM een stukje topix code zien, en reken maar van yes dat dat ge-encode was, ze kunnen er niks mee. Zelfs template dingen moeten door Android gedaan worden

[ACM]

Op vrijdag 26 oktober 2001 22:36 schreef little_soundman het volgende:
Is dit nu weer de laatste smoes ?
Android heeft geen xxx duizend piek betaald voor de zend-encoder. Eerdere kleine aanpassingen door de crew ondersteunen dit gegeven.

Nope, we hebben geen source van topix.
Of zij die encoder gekocht hebben, of wat dan ook. Weet ik niet, maar vrijwel alle aanpassingen (voor zover niet db-related) zijn door Arjen uitgevoerd.

[xoror]

Alles in InnoDB gebeurt binnen transacties, ook als je queries niet expliciteit in je code als transactie behandeld. In InnoDB zullen inserts daarom niet mysterieus verdwijnen zoals dat bij MyISAM soms wel het geval is.

Dat is autocommit. het klopt tot op zekere hoogte wat je zegt. Maar de inserts zullen nog steeds mysterieus verdwijnen als je de zooi niet (zelf) binnen transacties zet. Voor een forum bijv. moeten alle insert queries (dus 1e voor topic gegevens, en daarna body) goed gegaan zijn (voor het plaatsen van een topic). anders moet je een rollback doen. Als je dus alleen inndoDB installed met autocommit, helpt dat in dit geval nog niets.
de insert worden een voor een gecommit wat op het zelfde effect neer komt als met de oude situatie. De autocommit kan je in dit voorbeeld nog als extra overhead zien. De brakke topics gaan (in dit voorbeeld) pas weg als je zelf de SQL aanpast in topix. zoals aangegeven is het lekker gezend encoded.

[xoror]

Op vrijdag 26 oktober 2001 22:43 schreef woutf het volgende:

[..]

In een ander topic liet ACM een stukje topix code zien, en reken maar van yes dat dat ge-encode was, ze kunnen er niks mee. Zelfs template dingen moeten door Android gedaan worden

dit is natuurlijk niet waar. de templates kunnen niet ge-zend encoded zijn. immers ze worden in je code geparsed. dus jij leest die files zelf in om te parsen. je kan prima de templates dus zelf aanpassen. (ik reageer zo omdat jij met je zinnen suggereert dat zelfs de templates ge-encode zijn)

Overigens waarom denkt iedereen dat zend encoder duur is. Je HOEFT niet gelijk de unlimited te kopen. je kan ook huren voor paar honderd dollar per jaar.

[Femme]

Op vrijdag 26 oktober 2001 23:00 schreef xoror het volgende:

Als je dus alleen inndoDB installed met autocommit, helpt dat in dit geval nog niets.

In InnoDB is de kans dat één insert/update mislukt veel kleiner. Het is dus ook veel minder waarschijnlijk dat één van de queries in een 'transactie' (het toevoegen van een nieuw topic of nieuwe posting) mislukt.

[Wouter Tinus]

Op vrijdag 26 oktober 2001 23:08 schreef xoror het volgende:
dit is natuurlijk niet waar. de templates kunnen niet ge-zend encoded zijn. immers ze worden in je code geparsed.

ze worden geloof ik gechecked op het aantal bytes dat ze groot zijn

[xoror]

Op vrijdag 26 oktober 2001 23:13 schreef Femme het volgende:

[..]

In InnoDB is de kans dat één insert/update mislukt veel kleiner. Het is dus ook veel minder waarschijnlijk dat één van de queries in een 'transactie' (het toevoegen van een nieuw topic of nieuwe posting) mislukt.

ik hoop het, ben erg benieuwd. De oorzaak van brakke topics is toch ook nooit gevonden ? (en nee dan bedoel ik niet dat een insert failed het gaat erom waarom ie failed).

[xoror]

Op vrijdag 26 oktober 2001 23:15 schreef WouterTinus het volgende:

[..]

ze worden geloof ik gechecked op het aantal bytes dat ze groot zijn

das flauw, je maakt die zooi met templates omdat je niet om de paar kleine updates alles zelf moet doen. Je geeft daarmee je klanten geen kans kleine veranderingen zelf te doen.

Waarom nemen jullie geen oude versie van topix toen er nog source bij zat en ga je die niet modificeren ? of is het in het contract expliciet opgenomen dat het niet toegestaan is ?

[Coen Rosdorff]

Op vrijdag 26 oktober 2001 23:17 schreef xoror het volgende:

het gaat erom waarom ie failed

Te lange wachttijd (timeout). Door de table-locks kan het nogal lang duren als er veel inserts zijn. (Is "delayed-insert" in dit opzicht eigenlijk wel eens geprobeert ?)

Of mysql die op zijn gat gaat. Of apache die uit elkaar spat omdat hij memory lekt.

Kan vanalles zijn. Niet echt haalbaar om al die kwalen op te lossen. Er kan altijd iets mis gaan. Door van de belangrijkste dingen transacties te maken kan je dat prima opvangen.

Leuk nieuws van vandaag trouwens : Benchmark: Oracle on SuSE is Faster Than NT2000

[McMiGHtY]

Geen enkele technische reden meer om niet over te stappen op Oracle dus

[Femme]

InnoDB doet wat we nodig hebben (row-level locking), draait onder MySQL (waar we ervaring mee hebben) en kost niks.

[Verwijderd]

helemaal mee eens femme. het doet wat het doen moet.
ach der blijft altijd wel wat te zeuren cq wensen over

alleen jammer dat jullie van FreeBsd afgaan

[ACM]

Op maandag 29 oktober 2001 00:22 schreef McMiGHtY het volgende:
Geen enkele technische reden meer om niet over te stappen op Oracle dus

Geen technische (behalve dat we geen Oracle DBA in huis hebben en dat zeker de eerste periode best wel een belangrijke job kan zijn).

De financiele zijn wat belangrijker. Oracle vraagt vrij veel voor 4Cpu's, met dus een setje named users (moeten 500 connecties per server kunnen komen, maar dat zijn natuurlijk grotendeels hetzelfde clubje users)

[Verwijderd]

of ze moeten gaan sponsoren. maar dat zie ik ze nog niet zo snel doen.

[McMiGHtY]

er is al vaak genoeg hulp en hw aangeboden. Misschien moeten ze dat is aannemen?

[Daniel]

Op dinsdag 30 oktober 2001 16:57 schreef McMiGHtY het volgende:
er is al vaak genoeg hulp en hw aangeboden. Misschien moeten ze dat is aannemen?

Een aanbod wordt aangenomen als we er iets aan hebben. Als ik in een Ford rij en iemand biedt mij gratis en voor niks het motorblok van een Volkswagen aan is dat leuk, maar daar heb ik dus niets aan

[Verwijderd]

Ondanks de laatste reactie van 30 Oktober vond ik het toch zinvol om er nog een reactie van mijn kant bij te plaatsen aangezien ik dus dag in dag uit met ColdFusion werk en er ook werkelijk alle ins-en-outs vanaf weet.

Dat de tweakers server niet helemaal lekker lopen kan zo zijn, maar ik zou het eventjes afwachten totdat je de loadbalancer ernaast hebt staan. Het kan zijn dat door de de LVS er de nodige problemen opgelost gaan worden.

Wat betreft de mogelijkheid van Anandtech om een hogere load aan te kunnen op mindere servers heeft alles te maken met het gebruik van ColdFusion in tegenstelling tot PHP.

ColdFusion biedt standaard de optie om queries te cachen en de mogelijkheid om andere queries uit te voeren op de reeds gecachede query. Uit ervaring kan ik mededelen dat dit enorm scheelt in de load. De database wordt als het ware uit het geheugen gehaald ipv harde schijf. Tevens doet ColdFusion dit met pagina's.

De hoeveelheid hardware die jullie nu nodig hebben is denk ik een combinatie van database+scripting language die niet op de huidige hoeveelheid data is berekend.

[Verwijderd]

Op maandag 29 oktober 2001 00:27 schreef Femme het volgende:
InnoDB doet wat we nodig hebben (row-level locking), draait onder MySQL (waar we ervaring mee hebben) en kost niks.

Maar je zou ook is Microsoft kunnen opbellen om te vragen of ze jullie graag zouden willen sponsoren met een versie van MSSQL. Ik als marketing manager van Microsoft zou daar geen moment over aarzelen en mijn software grabbelton erbij pakken om vervolgens je een doosje MSSQL software te overhandigen.

Nee heb je en ja kun je krijgen. Probleem is alleen hoe ga je MSSQL op een Linux machine draaien.. niet dus. Is er dan de optie om van Linux naar Win2K over te stappen

Dus volg dan je hart op zakelijk gebied ipv het tweakers gebied. Wat is het beste?

[Verwijderd]

Gordijnstok: Je wil dus zeggen dat GoT te traag is door verkeerde software die niet berekend is op zo'n hoge load en dat ColdFusion Rulez

Ik snap het.

[Verwijderd]

Op maandag 19 november 2001 14:59 schreef mgfun het volgende:
Gordijnstok: Je wil dus zeggen dat GoT te traag is door verkeerde software die niet berekend is op zo'n hoge load en dat ColdFusion Rulez

Ik snap het.

Nee en ja. Ik vind ( en dat geef ik eerlijk toe ) ColdFusion ( en Jrun) gewoon een beter pakket. Daarnaast zie ik de immer rijzende problemen die al tijden en tijden aan de gang zijn.

Dan weeg ik de hoeveelheid hardware en hits van T.net relatief af tegen die van Anandtech, en dan zie ik toch een flink verschil waarbij T.net het "niet al te goed doet".

Daarbij komt nog dat mysql table locking gebruikt ipv row locking en bij iedere db request dus de gehele tabel vastzet totdat deze is afgerond.

Dan bekijk ik de mogelijkheden van caching door php en die zijn praktisch nihil. Dan bekijk ik die van CF en die zijn erg uitgebreid. Nog steeds is RAM geheugen sneller als een harde schijf.

Nu zeg ik niet dat T.net meteen moet overstappen op ColdFusion, er zijn evt. ook andere talen beschikbaar die wel over caching beschikken, maar wel om is verder te kijken naar professionele pakketten, die evt. worden gesponsord, want het ontbreekt ze aan financiele kracht om bijv. een websphere in te zetten.

[MoBi]

Op maandag 19 november 2001 15:05 schreef Gordijnstok het volgende:

Daarbij komt nog dat mysql table locking gebruikt ipv row locking en bij iedere db request dus de gehele tabel vastzet totdat deze is afgerond.

Dat hebben ze nu opgelost via innodb.

Als je software dat niet ondersteund terwijl je dat wel gebruik van wil maken om dat sommige dingen niet iedere keer hoeven worden opgehaald, dan zou ik ook serieus kijken naar andere pakketten die dat inderdaad wel hebben ja.

Voorbeeld zijn de reviews, waarbij alleen de laastste pagina (die met reacties) dynamisch hoeft te zijn. Als een review geplaatst is veranderd er aan de rest van voorgaande pagina's niks. Maar ze moeten wel iedere keer uit de db gehaald worden. Vooral als er weer een review is waarmee je het slashdot effect over je krijgt dan is dat super makkelijk (cachen dus). Probleem met het forum is dat het (volgens mij nog steeds) niet mogelijk is te load balancen omdat er gebruik word gemaakt van sessie's. Deze kunnen niet naar een andere server worden meegenomen met php.

[Verwijderd]

Of waarom juist die pagina's dynamisch gaan serveren ipv statisch genereren

Oftewel je drukt in je CMS op publish, een html pagina wordt aangemaakt, en alleen de reactie hoeven dynamisch te zijn

[ACM]

Op maandag 19 november 2001 15:59 schreef Gordijnstok het volgende:
Of waarom juist die pagina's dynamisch gaan serveren ipv statisch genereren

Enneuhm, waar zit dan precies het verschil met hoe het nu werkt?

Imho zijn alle problemen die we nu met de load (die we niet eens zo heel erg veel hebben momenteel) op te lossen met zaken die niet een ander software pakket vereisen.

Het grootste nadeel zit hem in het niet kunnen wijzigen van de topix-source en de tijd die het neemt daar een oplossing voor te vinden.

Daarnaast worden vrijwel alle load problemen die er nu nog zijn door de search engine veroorzaakt.
Deze is gewoon niet efficient genoeg met ruim 3Miljoen posts. (en dan wordt er niet eens een LIKE search gedaan )

[Verwijderd]

Op maandag 19 november 2001 16:13 schreef ACM het volgende:

[..]

Enneuhm, waar zit dan precies het verschil met hoe het nu werkt?

Imho zijn alle problemen die we nu met de load (die we niet eens zo heel erg veel hebben momenteel) op te lossen met zaken die niet een ander software pakket vereisen.

Het grootste nadeel zit hem in het niet kunnen wijzigen van de topix-source en de tijd die het neemt daar een oplossing voor te vinden.

Daarnaast worden vrijwel alle load problemen die er nu nog zijn door de search engine veroorzaakt.
Deze is gewoon niet efficient genoeg met ruim 3Miljoen posts. (en dan wordt er niet eens een LIKE search gedaan )

Dan moet je dus meer gaan cachen

Het verschil in die statische pagina's zit hem er juist in dat er totaal geen DB access meer is voor articles. Bijvoorbeeld Vignette V5 (voorheen StoryServer)is hiermee bekend geworden. Dit systeem levert puur alleen statische pagina's die alleen bij het publishen worden aangemaakt.

Alles kun je dan vanaf een webserver ipv applicatieserver serveren, en zo kun je dus je load gigantisch verlagen. Het geld wat je normaal gebruikt had voor nieuwe hardware kun je nu in je zak steken om evt. te investeren in verdiende (evt. langverwachte) loonsverhoging van de redactie, marketingactiviteiten, enterprise software, etc.

Let wel de winst wordt meestal niet hoger, winst is nl. een boekhoudkundige fout.

[ACM]

Op maandag 19 november 2001 16:18 schreef Gordijnstok het volgende:
Het verschil in die statische pagina's zit hem er juist in dat er totaal geen DB access meer is voor articles. Bijvoorbeeld Vignette V5 (voorheen StoryServer)is hiermee bekend geworden. Dit systeem levert puur alleen statische pagina's die alleen bij het publishen worden aangemaakt.

En hoe toepasbaar is dat, denk je, hier ter vervanging van GoT ??

De frontpage kan vast nog wel wat meer gecached van worden, maar topix? Niet zo veel dat je er helemaal statische request van kan maken (ok, vroegere ubb-principe...)

[Verwijderd]

Op maandag 19 november 2001 16:32 schreef ACM het volgende:

[..]

En hoe toepasbaar is dat, denk je, hier ter vervanging van GoT ??

De frontpage kan vast nog wel wat meer gecached van worden, maar topix? Niet zo veel dat je er helemaal statische request van kan maken (ok, vroegere ubb-principe...)

Statisch gezien is Topix 0,0. Topix heeft gewoon een betere code nodig. Zij het niet een ander forum. Qua statisch ging het voornamelijk om de pagina's van T.net.

Qua caching voor een forum zoals topix zijn de mogelijkheden en te behalen winsten behoorlijk hoor. Wat ColdFusion doet is heel snel de ge-cachede versie in de RAM controleren met een nieuwe insert/update statement, en de RAM versie bijwerken.

Omdat Anandtech voor hun forum gebruik maken van fusetalk maken ze automatisch gebruik van deze opties. En toch scheelt dat erg veel.