toevallig geen loop in een script ?
Wij hebben dit ooit eens gehad.
result :)
Afdrukvoorbeeld
toevallig geen loop in een script ?
Wij hebben dit ooit eens gehad.
result :)
Het verschil is, dat jouw loop R processen oplevert en we hier te maken hebben met D processen. Veel processen in de run queue (R) is helemaal niet erg, zolang ze maar niet blocking zijn (D).
Dat is ook mijn gedachte... daarnaast staan er evenveel MySQL processen. Heb je mytop al geïnstalleerd en eens bekeken tijdens zo'n hoge server load?Citaat:
Oorspronkelijk geplaatst door parmaweb
Mogelijk dat je hierdoor gelijk ziet wie de user is die het probleem genereert.
en je swap partitie zit ook helemaal vol..
Een soort gelijke storing heb ik zelf gehad, bij mij was de oorzaak het script cj-overkill wat veel op adultsites wordt gebruikt...
na een herinstall waren de problemen weg
Zo'n script zou m.i. voor een constante hoge server load zorgen en geen piek.
Bij mij liep het juist in heel korte tijd ( binnen paar uur ) naar een load ver boven de 100 totdat de hele server vast liep, en had met top misschien wel 75x httpd aktief staan..
Je kan het ook vaak zien aan de i/o wait die erg oploopt. Maar inderdaad, asap schijfje vervangen en gaan met de spreekwoordelijke banaan (tijd voor een redundant setupje?)
Ik weet simpelweg niet welke scriptjes er allemaal op de sites van de klanten staan, dus even upgraden naar een laatste versie zit er niet in.
De hosters zeiden echter (zoals al door iemand was opgemerkt in deze thread) dat 'al' hun Seagate schijven (onder FedoraCore 5) dergelijke SMART waardes geven. In FC6 staan ze mooi op 0.
We hebben inmiddels alweer een uptime van 9 dagen (schokkend), dus ik heb nog geen crash meegemaakt die ik kan analyseren.
Het blijkt een script te zijn van een externe server die binnen enkele seconden 184 hits veroorzaakt op een site van een klant, waarvan de pagina's dmv behoorlijke queries opgebouwd worden (fulltext en regexp op tabellen met miljoenen rijen, en grote TEXT columns). Daarnaast maakt die site voor elke pageview een nieuwe DB connection. Elke MySQLd fork neemt 17MB in beslag, dus met 184x 17MB ( = 3GB) schiet de server compleet de swap in, en komt hij er ook niet meer uit (helaas).
Het verkeer komt allemaal vanaf dezelfde range X.Y.Z.{0-255}. Alle referers komen van search.live.com/ met allerlei aan die website gerelateerde keywords. Het is waarschijnlijk een tool die de ranking analyseert EN de contents van de resultaten binnen haalt. Ook een HTTP versie van 1.0 met als user agent MSIE 6.0 lijkt erop te duiden dat dit een bot/tool is.
Dus die IP range staat nu dus fijn in de firewall :ban:
De echte oplossing was geweest om die loodzware pagina's te optimaliseren. Gebruik maken van caching, betere SQL (wtf @ regex op miljoenen rijen?) of simpelweg het aantal gegevens meer beperken. Beste zou dus een combinatie van alles zijn.
Ik kan moeilijk in de scripts van een klant gaan knutselen... toch?
Ik kan hooguit de klant op de hoogte stellen van dit probleem en lief vragen om zijn script te optimaliseren. De klant heeft er waarschijnlijk de ballen verstand van (die gebruikt wordpress voor een webwinkel... pff), dus dat gaat niet opschieten.
Simpelste oplossing is IP range in de firewall, en als dat niet genoeg blijkt, de klant een waarschuwing geven.
Je zou het 'm kunnen aanbieden.. tenslotte zorgt zijn site er voor dat jouw server & services uit de lucht gaan en het kan leiden tot hardwareschade (en uiteraard reputatieschade).Citaat:
Oorspronkelijk geplaatst door Riven
Mijn oplossing zou zijn (en is in het verleden geweest): de klant max. 24 uur geven om het probleem op te lossen en anders een andere host te zoeken. Je gaat je spullen toch niet voor een paar euro hostingvergoeding naar de maan laten helpen door een klant die er 'de ballen verstand' van heeft?Citaat:
Oorspronkelijk geplaatst door Riven
Brengt me terug op het eerste; als jij je klant kan overtuigen dat zijn site niet goed in elkaar zit, dan help je 'm, tegen een passende vergoeding, dat op te lossen. En anders zoekt hij/zij z'n heil maar elders. Shared hosting is keuzes maken; laat je de klanten die wel goed doen/willen lijden onder het geprutst van die éne,..?
Verder denk ik dat eerder gegeven advies om de schijf te vervangen niet zo'n slecht idee is..
Ik heb het eigenlijk veel te druk met andere projecten, om in de scripts van iemand te gaan neuzen. Ik denk dat het het beste is als er inderdaad een deadline gesteld wordt.
Helaas ben ik zelf niet bevoegd om iemand van de server af te wippen...
-knip-