GOT database probs?

[Verwijderd]

Ik heb om de haverklap code #55- database problemen. Ligt dat nou aan mij of heeft iedereen dat?

[Verwijderd]

[topic=301346/1/100]

[Dommel]

[topic=301346/1/75]

Op donderdag 25 oktober 2001 12:43 schreef ACM het volgende:
Er zijn vrij lastige problemen met de mysqldeamons.

Waar dit aan ligt weet ik niet en ik heb me daar ook niet echt mee beziggehouden.

Het kan dus zomaar gebeuren dat het "weer gebeurd".


Daarnaast heeft artemis het de laatste tijd erg druk, met queries. Daardoor zal af en toe de frontpage niet al te lekker werken.

[Verwijderd]

Het is weer tijd voor een sticky one...

[Laurent]

Op donderdag 25 oktober 2001 12:57 schreef Courage het volgende:
Het is weer tijd voor een sticky one...

Een topic in het mededelingen forum lijkt me voldoende.

[wildhagen]

Op donderdag 25 oktober 2001 14:02 schreef Aikeleer het volgende:

[..]

Een topic in het mededelingen forum lijkt me voldoende.

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.

[Verwijderd]

Op donderdag 25 oktober 2001 14:02 schreef Aikeleer het volgende:

[..]

Een topic in het mededelingen forum lijkt me voldoende.

[topic=301433/1/50]

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.

Nou idd zeg

[Pc123]

Zowel GOT als tweakers.net doen het heel erg slecht, die mysql update is toch niet helemaal ok.

[Onno]

Op donderdag 25 oktober 2001 12:43 schreef ACM het volgende:
Er zijn vrij lastige problemen met de mysqldeamons.

Waar dit aan ligt weet ik niet en ik heb me daar ook niet echt mee beziggehouden.

Huh, hoe kun je nou weten dat de problemen vrij lastig zijn als je niet weet wat er aan de hand is?

_{En pssst: gebeurt is met een 't'.}

[Jaymz]

Op donderdag 25 oktober 2001 14:13 schreef Onno het volgende:

[..]

Huh, hoe kun je nou weten dat de problemen vrij lastig zijn als je niet weet wat er aan de hand is?

Als je niet weet wat er aan de hand is, is dat best lastig

[ACM]

Op donderdag 25 oktober 2001 14:13 schreef Onno het volgende:
Huh, hoe kun je nou weten dat de problemen vrij lastig zijn als je niet weet wat er aan de hand is?

Ik vind het lastig, mede omdat we niet weten wat er nou (precies?) aan de hand is...
En er is toch al vrij veel getest.

_{En pssst: gebeurt is met een 't'.}

Fixed.

[raptorix]

Gebruik de MySql Enterprise tools/analyzers

[Onno]

Terug in je hok!

[ACM]

Op donderdag 25 oktober 2001 14:41 schreef raptorix het volgende:
Gebruik de MySql Enterprise tools/analyzers

Das flauw

[Verwijderd]

Mwha mooie gelegenheid om got niet naar ms-sql server te migreren is toch? Dat geëtter met mysql duurt al veel te lang En dan heb je als bonus nog je enterprise tools ook

[Verwijderd]

Op donderdag 25 oktober 2001 12:43 schreef ACM het volgende:
Waar dit aan ligt weet ik niet en ik heb me daar ook niet echt mee beziggehouden.

Het kan dus zomaar gebeuren dat het "weer gebeurt".

sorry hoor, maar wat is dit voor loze mededeling

dat er iets mis is met GoT was ik ook al achter, dus dit alles heeft een toegevoegde waarde van 0,0

had bv. Kees misschien niet iets zinnigs neer kunnen zetten

[ACM]

Op donderdag 25 oktober 2001 15:06 schreef BBQ-Man het volgende:
sorry hoor, maar wat is dit voor loze mededeling

dat er iets mis is met GoT was ik ook al achter, dus dit alles heeft een toegevoegde waarde van 0,0

had bv. Kees misschien niet iets zinnigs neer kunnen zetten

Als ik niks had gezegd was er wel weer een stel threads in LA opgestart met de mededeling dat GoT-brak is...

Nu weet je dat we daar vanaf weten. En dat we proberen een oplossing te vinden.

[wildhagen]

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

[..]

Als ik niks had gezegd was er wel weer een stel threads in LA opgestart met de mededeling dat GoT-brak is...

Nu weet je dat we daar vanaf weten. En dat we proberen een oplossing te vinden.

En hebben jullie al enig idee in welk jaar jullie een oplossing denken te vinden? Dit word van kwaad tot erger, en je kan je zo toch nauwelijks meer een professionele site noemen (getuigt wel van lef overigens...).

[raptorix]

Op donderdag 25 oktober 2001 15:24 schreef wildhagen het volgende:

[..]

En hebben jullie al enig idee in welk jaar jullie een oplossing denken te vinden? Dit word van kwaad tot erger, en je kan je zo toch nauwelijks meer een professionele site noemen (getuigt wel van lef overigens...).

Ik vermoed hardware uitbreiding

[JvS]

Op donderdag 25 oktober 2001 15:24 schreef wildhagen het volgende:

[..]

En hebben jullie al enig idee in welk jaar jullie een oplossing denken te vinden? Dit word van kwaad tot erger, en je kan je zo toch nauwelijks meer een professionele site noemen (getuigt wel van lef overigens...).

Je weet (neem ik aan) dat we nog met een financieel probleem zitten, zodat we voor een aardig deel afhankelijk zijn van vrijwilligers? De site is dus wel professioneel bezig (er moet ooit idd geld mee verdiend worden), maar nu gaat het gewoon erg moeilijk.

En ja, daar kan ik ook weleens treurig/boos van worden .

Dat van die mededeling:

Het was gewoon een mededeling om te laten weten dat we het weten. Er staat nergens dat we een complete technische verantwoording moeten afleggen (ook al doen we dat wel! ). Nu wisten we het niet eens.

[wildhagen]

Op donderdag 25 oktober 2001 15:34 schreef JvS het volgende:

[..]

Je weet (neem ik aan) dat we nog met een financieel probleem zitten, zodat we voor een aardig deel afhankelijk zijn van vrijwilligers? De site is dus wel professioneel bezig (er moet ooit idd geld mee verdiend worden), maar nu gaat het gewoon erg moeilijk.

Ja, dat weet ik. Maar ga nou eens na, je hebt een ENORM serverpark, waar de Shell of Unilever nog jaloers op is (bij wijze van...), daar kan het gewoonweg niet aanliggen, die moeten het prima trekken.

En je jaagt je bezoekers op deze manier, met een downtime van 3-4 uur per dag wel massaal weg. Word het alleen maar nog moeilijker om er ooit geld mee te gaan verdienen.

En ja, daar kan ik ook weleens treurig/boos van worden .

Ik word er niet treurig van hoor, het IS gewoon treurig. Kijk nou eens naar Anandtech, een site die een veelvoud aan bezoekers krijgt van wat tw.net heeft, en die hebben slechts enkele servers meer... en daar draait het (na even een mindere periode) gewoon allemaal als een gigantisch mooi zonnetje.

[ACM]

Op donderdag 25 oktober 2001 15:24 schreef wildhagen het volgende:
En hebben jullie al enig idee in welk jaar jullie een oplossing denken te vinden? Dit word van kwaad tot erger, en je kan je zo toch nauwelijks meer een professionele site noemen (getuigt wel van lef overigens...).

Ik ontdekte net een klein foutje in de mysql config file...

Maar of dat het oplost weet ik niet, het was iig wel toevallig op de plek waar kees het laatst dacht wat gewijzigd te hebben sinds het wat slecht(er) werkt.

[ACM]

Op donderdag 25 oktober 2001 15:39 schreef wildhagen het volgende:
Maar ga nou eens na, je hebt een ENORM serverpark, waar de Shell

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

En je jaagt je bezoekers op deze manier, met een downtime van 3-4 uur per dag wel massaal weg. Word het alleen maar nog moeilijker om er ooit geld mee te gaan verdienen.

Weten we ook

Het ligt ook niet aan de hardware, dat is geloof ik ook nergens gezegd.

[JvS]

Op donderdag 25 oktober 2001 15:39 schreef wildhagen het volgende:


Ik word er niet treurig van hoor, het IS gewoon treurig. Kijk nou eens naar Anandtech, een site die een veelvoud aan bezoekers krijgt van wat tw.net heeft, en die hebben slechts enkele servers meer... en daar draait het (na even een mindere periode) gewoon allemaal als een gigantisch mooi zonnetje.

Nou ben ik technisch niet helemaal een kenner, maar ik ben net als jij wel kritiesch. Dat vergelijk heb ik ook weleens gemaakt. Ik kreeg toen te horen dat T.net veel dynamischer is en dat gebruikers van het forum van t.net gemiddeld een stuk actiever zijn...

Weet niet of dat nou bij een vergelijk met Anand was. Maar wij hebben op de frontpage wel ziek veel dynamische dingen staan. (ik hoorde ooit iets van 13query's per pageview). En de forumsoftware is inderdaad niet goed getuned. Dat is heel spijtig. Maar daar kan kees of ACM misschien wat beter op ingaan

[Verwijderd]

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.

Hoe doe je dat????
Gewoon zoiets:
[marquee bold, 72pt, blink]Tekst[/marquee]

[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