Een tijd lang ging het draaien van een bepaalde online game erg lekker op een dedicated server bij een hosting company.
Toen wilden we nog een server huren. Bij die hosting company wass het echter geen mogelijkheid om de 2e server in hetzelfde rack te plaatsen met een interne connectie tussen de twee servers.
We zijn toen geswitched van hosting company en hebben wel de config gekregen die we wilden, echter bleek de hardware daar aan het rommelen te zijn, kapotte memory chips enzo. Toen weer van hosting company geswitched en nu draaien we net een maandje bij een hosting company waar het ook niet mogelijk is om een interne connectie tussen de servers te krijgen, enfin dat leek ons niet zo'n heel erg groot probleem uiteindelijk.
We hebben een AMD MP 2600, 1GB ram server met Redhat die als webserver fungeert, en een Dual AMD MP 2600, 2GB ram server met Debian die de MySQL database runt. De connectie tussen deze twee is dus extern. Maar dat mag het probleem niet zijn.
Nu is het zo dat we om de haverklap een MySQLd (3.2.23) crash hebben. We gebruiken MyISAM tabellen, die qua design opzich geen schoonheidsprijs krijgen, en ook overhead produceren, maar volgens mij is dat het probleem niet.
In PHP gebruiken we om dit moment een mysql_connect naar de DB server, de timeout van deze connects is 5 seconden wat een default instelling is. We hebben ook een tijdje met mysql_pconnect gedraaid maar het verschilde niet in crashes.
Ik heb even gadegeslagen wat er ongeveer gebeurt:
Eerst krijg je om de zoveel pagina's een bericht dat er geen connectie gevonden kon worden met de DB server, na een paar minuten gaat mysqld <defunct> draaien, en dan sluiten worden alle child-processen afgesloten, en blijft alleen de parent nog draaien. In zoverre je het draaien kan noemen tenminste. '/etc/init.d/mysql restart' zorgt er niet voor dat de mysql server restart. De enige mogelijkheid is 'killall -9 mysqld' en dan opnieuw '/etc/init.d/mysql start' om de mysql weer aan de praat te krijgen.
Soms is er zelfs een (door de hosting company aangeleverde optie) 'rapidreboot' nodig omdat de server na zo'n crash niet meer te pingen/ssh'en valt.
Is het de hardware, de software, onze instellingen, de overhead (database design) of een ander probleem. Ik weet het niet meer. Misschien een van jullie?
Toen wilden we nog een server huren. Bij die hosting company wass het echter geen mogelijkheid om de 2e server in hetzelfde rack te plaatsen met een interne connectie tussen de twee servers.
We zijn toen geswitched van hosting company en hebben wel de config gekregen die we wilden, echter bleek de hardware daar aan het rommelen te zijn, kapotte memory chips enzo. Toen weer van hosting company geswitched en nu draaien we net een maandje bij een hosting company waar het ook niet mogelijk is om een interne connectie tussen de servers te krijgen, enfin dat leek ons niet zo'n heel erg groot probleem uiteindelijk.
We hebben een AMD MP 2600, 1GB ram server met Redhat die als webserver fungeert, en een Dual AMD MP 2600, 2GB ram server met Debian die de MySQL database runt. De connectie tussen deze twee is dus extern. Maar dat mag het probleem niet zijn.
Nu is het zo dat we om de haverklap een MySQLd (3.2.23) crash hebben. We gebruiken MyISAM tabellen, die qua design opzich geen schoonheidsprijs krijgen, en ook overhead produceren, maar volgens mij is dat het probleem niet.
In PHP gebruiken we om dit moment een mysql_connect naar de DB server, de timeout van deze connects is 5 seconden wat een default instelling is. We hebben ook een tijdje met mysql_pconnect gedraaid maar het verschilde niet in crashes.
Ik heb even gadegeslagen wat er ongeveer gebeurt:
Eerst krijg je om de zoveel pagina's een bericht dat er geen connectie gevonden kon worden met de DB server, na een paar minuten gaat mysqld <defunct> draaien, en dan sluiten worden alle child-processen afgesloten, en blijft alleen de parent nog draaien. In zoverre je het draaien kan noemen tenminste. '/etc/init.d/mysql restart' zorgt er niet voor dat de mysql server restart. De enige mogelijkheid is 'killall -9 mysqld' en dan opnieuw '/etc/init.d/mysql start' om de mysql weer aan de praat te krijgen.
Soms is er zelfs een (door de hosting company aangeleverde optie) 'rapidreboot' nodig omdat de server na zo'n crash niet meer te pingen/ssh'en valt.
Is het de hardware, de software, onze instellingen, de overhead (database design) of een ander probleem. Ik weet het niet meer. Misschien een van jullie?
[ Voor 3% gewijzigd door Verwijderd op 10-08-2004 15:36 . Reden: xeon 2.4 ghz moest zijn AMD MP 2600 ]