Bekijk Volledige Versie : POP3 knalt er dagelijks meerdere keren uit
Vinden jullie het normaal dat bij een hosting account het POP3 deel er elke dag minstens 1x (meestal 2 to 3x) mee stopt? (stopt = connectie op poort 110 wordt aangenomen maar er komt geen vervolg op)
Dat je dit elke dag meld aan de hoster en dat je als enige resultaat ziet dat als je het meldt op het moment dat het zich voor doet dat of de POP3 ge-restart wordt of dat de server gereboot wordt? Maar het probleem zelf blijft dag na dag weer terug komen.
Wat zouden jullie hiermee doen??
GlobalServe
23/05/08, 20:14
In gebreke stellen per aangetekende brief.
Ze moeten een oplossing vinden voor dat probleem, anders kan je het hostingcontract gewoon opzeggen. Als zij hun voorwaarden niet nakomen kwa uptime en dergelijke.
Triloxigen
23/05/08, 20:24
Maak je niet zoveel connecties dat hij het blokkeert omdat het een aanval lijkt?
Na zoiets moet je denk ik altijd op kunnen zeggen, ongeacht je contract. Als je daar, als hosting provider, nee tegen zegt dan ben je stom bezig.
Verder klinkt het alsof het geen partij is met veel verstand van zaken, anders was zoiets al lang opgelost.
Maak je niet zoveel connecties dat hij het blokkeert omdat het een aanval lijkt?
Er worden heel de tijd door hetzelfde aantal connecties gemaakt. We hebben een lokale server die een aantal POP3 mailboxen poll op de hosting server. En onze server doet dat zowel overdag als 's nachts op dezelfde manier. Dus het aantal connecties dat we (letterlijk) nu maken is hetzelfde als het aantal dat we binnen een paar uur maken en dat we morgen maken. Toch knalt ie er zowiezo uit ergens tussen 2h en 4h 's nachts en meestal ook nog 1 à 2x overdag ook.
Onze server pollt ook andere POP3 mailboxen (op andere hosting servers) waar er veel meer mailboxen gepollt worden en dit zonder enig probleem.
Dirk, ik vindt het een beetje jammer dat je na 1 sms-je met daarin het bericht dat je er echt boos over bent, meteen er hier al om te gaan vragen. Maar ik begrijp je uiteraard goed....:
Tuurlijk, dit moet verholpen worden en hoort absoluut niet.
Echter zijn we ook al lang bezig, hebben we bij medehosters geïnformeerd, en zijn we zelf flink op zoek gegaan. We hebben ook gewoon actie ondernomen (een klant kan dat bevestigen, zie de laatste ervaring op www.ispgids.com/isp/telahosting), alleen bleek die klant toch niet het probleem op te leveren. Inmiddels heb ik al een idee en naar die betreffende klant is er ook een mail uit gegaan. Grote kans dat hij ook dat probleem verzorgt van die ~15 min tussen 2 en 4 uur gezien zijn cronjobs.
Dat je dit elke dag meld aan de hoster en dat je als enige resultaat ziet dat als je het meldt op het moment dat het zich voor doet dat of de POP3 ge-restart wordt of dat de server gereboot wordt?
Zoals in de SMS ook vermeld, is het 9 van de 10 keer het geval dat we er op dat moment mee bezig zijn, wanneer je ons SMS't. Echter is het niet alleen de POP server die problemen oplevert, maar heeft de hele server last van een hoge load (30, soms zelfs 50+), waardoor we zelf amper de server in kunnen komen en dus kunnen bekijken wat het is. Zelfs via DirectAdmin lukt het niet om simpelweg de reboot-knop in te drukken, want dan doet 'ie nog niks totdat de load terug gezakt is of httpd wordt stopgezet (wat ook al niet vanuit SSH lukt, omdat je daar dus niet in komt).
@GlobalServe
In principe geven we geen uptimegaranties af, waardoor men ons dáárop überhaupt niet vast zou kunnen pinnen. Ingebrekestelling is echter wel een mogelijkheid uiteraard, omdat er niet de diensten worden geleverd op de manier zoals ze geleverd zouden moeten worden.
Maar verder is het ook erg lastig om het probleem waar te nemen, schiet die load namelijk omhoog, dan kun je misschien maar enkel de eerste 2 à 3 minuten überhaupt verbinding maken met de server. Een onderzoek, wat alleen eigenlijk op zo'n 'hoge-load' moment kan, is dus erg moeilijk. Het omvat namelijk de hele server, zoals gezegd, en niet alleen POP3.
Wellicht kun en wil je vannacht doorgeven wat jouw systeem geconstateerd heeft. Als het goed is hebben we nu de betreffende klant te pakken namelijk en moet het probleem niet meer optreden.
Overigens kreeg ik zelf niet de indruk dat je die problemen tussen 2 en 4h nou zó'n ramp vondt, aan je mails te zijn. Natuurlijk het is niet goed, dat ben ik met je eens...
Overdag is het natuurlijk wel écht not-done en mag het gewoon niet voorkomen.
Laten we hopen dat we vannacht niks van downtime merken, en daarna ook overdag niet meer!
Wanneer je overigens het contract op wil zeggen ga ik daar verder ook niet moeilijk over doen en daar heb je het recht ook toe. Je hebt tenslotte helemaal gelijk, en wij zitten fout, zo simpel is dat.
Toch kunnen we het nog een paar dagen aankijken in mijn ogen, of het met deze gebruiker wél veranderd.
Ik hoor het graag, en dan voor uiteraard liever via e-mail zoals je hopelijk begrijpt.
Slechts 1 server en dat is ook nog eens een desktopmoederbord in een 1U kast, zo zie ik op je site... Daar word ik niet vrolijk van. Maar ben de slechtste niet, evenzo geldt voor Luuk. Mocht je hulp nodig hebben, wil ik best even meekijken bij je. Heb je SNMP stats van je serverload (cacti/nagios) om de tijdstippen te vergelijken. Daarna is het logfiles doorspitten om te kijken hoe het gebeurd. Want die AMD desktopCPU zou neit met een load van 2 of hoger moeten werken, uitgaande vdat die dualcore is.
Randy, zo zijn de meeste begonnen waarschijnlijk. Of dat ook wel of niet het geval is, dat maakt niet uit uiteraard, het probleem moet gewoon opgelost worden ;)
Zoals gezegd denk ik nu het probleem verholpen te hebben. De hoge load komt niet overeen met een van mijn eigen cronjobs, maar wel redelijk met een van mijn klanten. Daarmee zou het dus zeer zeker te maken kunnen hebben. Hij is programmeur, en daar gebeurt flink wat in dat script.
Uiteraard hoort een CPU niet zo hoog te gaan, dat snap ik zelf ook wel, het is alleen zo dat het tijd heeft gekost om het goed uit te zoeken en daar is dirk, denk ik en volkomen terecht ook overigens, boos over.
(Overigens zijn er nog steeds vele hosters met 20 server die op desktopboards draaien en Athlon's) Ook een Opteron zou opgevreten worden door dat script, dat kan ik je garanderen, al zal het dan uiteraard langer duren voordat dat gebeurt en het misschien ietwat minder te merken zijn... Het is gewoon een brak script. Iets dat soms meer als 30 minuten de serverload kan laten stijgen is gewoon slecht geprogrammeerd m.i.
Het enige wat ik wel merk is dat er nog steeds heel vaak (meer als één keer per seconde in ieder geval) verbinding wordt geprobeerd te maken met dat bestand. Gelukkig komt het nu uit bij een 404 not found, waardoor PHP en MySQL niet meer wordt belast...
Randy, zo zijn de meeste begonnen waarschijnlijk. Of dat ook wel of niet het geval is, dat maakt niet uit uiteraard, het probleem moet gewoon opgelost worden ;)
Natuurlijk zijn de meeste hostingbedrijven zo begonnen, maar jezelf profileren als 'Quality hosting' is dan denk ik nog wat te hoog gegrepen. Bij kwaliteit hoor toch een bepaalde uptime.
Het enige wat ik wel merk is dat er nog steeds heel vaak (meer als één keer per seconde in ieder geval) verbinding wordt geprobeerd te maken met dat bestand. Gelukkig komt het nu uit bij een 404 not found, waardoor PHP en MySQL niet meer wordt belast...
Zulke duidelijke problemen zou je toch heel snel moeten kunnen vinden. Als ik jou was zou ik iemand als Randy voor een paar uur inhuren, bespaard je ook voor in de toekomst een hoop werk waarschijnlijk...
Dirk, ik vindt het een beetje jammer dat je na 1 sms-je met daarin het bericht dat je er echt boos over bent, meteen er hier al om te gaan vragen. Maar ik begrijp je uiteraard goed....:
Tuurlijk, dit moet verholpen worden en hoort absoluut niet.
Echter zijn we ook al lang bezig, hebben we bij medehosters geïnformeerd, en zijn we zelf flink op zoek gegaan. We hebben ook gewoon actie ondernomen (een klant kan dat bevestigen, zie de laatste ervaring op www.ispgids.com/isp/telahosting), alleen bleek die klant toch niet het probleem op te leveren. Inmiddels heb ik al een idee en naar die betreffende klant is er ook een mail uit gegaan. Grote kans dat hij ook dat probleem verzorgt van die ~15 min tussen 2 en 4 uur gezien zijn cronjobs.
Zoals in de SMS ook vermeld, is het 9 van de 10 keer het geval dat we er op dat moment mee bezig zijn, wanneer je ons SMS't. Echter is het niet alleen de POP server die problemen oplevert, maar heeft de hele server last van een hoge load (30, soms zelfs 50+), waardoor we zelf amper de server in kunnen komen en dus kunnen bekijken wat het is. Zelfs via DirectAdmin lukt het niet om simpelweg de reboot-knop in te drukken, want dan doet 'ie nog niks totdat de load terug gezakt is of httpd wordt stopgezet (wat ook al niet vanuit SSH lukt, omdat je daar dus niet in komt).
@GlobalServe
In principe geven we geen uptimegaranties af, waardoor men ons dáárop überhaupt niet vast zou kunnen pinnen. Ingebrekestelling is echter wel een mogelijkheid uiteraard, omdat er niet de diensten worden geleverd op de manier zoals ze geleverd zouden moeten worden.
Maar verder is het ook erg lastig om het probleem waar te nemen, schiet die load namelijk omhoog, dan kun je misschien maar enkel de eerste 2 à 3 minuten überhaupt verbinding maken met de server. Een onderzoek, wat alleen eigenlijk op zo'n 'hoge-load' moment kan, is dus erg moeilijk. Het omvat namelijk de hele server, zoals gezegd, en niet alleen POP3.
Wellicht kun en wil je vannacht doorgeven wat jouw systeem geconstateerd heeft. Als het goed is hebben we nu de betreffende klant te pakken namelijk en moet het probleem niet meer optreden.
Overigens kreeg ik zelf niet de indruk dat je die problemen tussen 2 en 4h nou zó'n ramp vondt, aan je mails te zijn. Natuurlijk het is niet goed, dat ben ik met je eens...
Overdag is het natuurlijk wel écht not-done en mag het gewoon niet voorkomen.
Laten we hopen dat we vannacht niks van downtime merken, en daarna ook overdag niet meer!
Wanneer je overigens het contract op wil zeggen ga ik daar verder ook niet moeilijk over doen en daar heb je het recht ook toe. Je hebt tenslotte helemaal gelijk, en wij zitten fout, zo simpel is dat.
Toch kunnen we het nog een paar dagen aankijken in mijn ogen, of het met deze gebruiker wél veranderd.
Ik hoor het graag, en dan voor uiteraard liever via e-mail zoals je hopelijk begrijpt.
Ik zou je er dan ook even op willen wijzen dat ik in mijn vraag op WHT nergens je naam vermeld heb, nergens een verwijzing doe naar je bedrijf en dat aan de hand van mijn usergegevens het niet evident zou geweest zijn de link naar jou te leggen. Mijn vraag op WHT was duidelijk een vraag naar advies. Wat ik zal doen, staat voor mij nog steeds niet vast. Als alles inderdaad zoals je zegt goed zal lopen vanaf nu dan kan ik met deze account verder anders niet. (je hebt nl nog al eens gezegd dat je het gevonden had en toen bleek dan ook niet het geval). Dit probleem is er al ongeveer een maand, dus misschien wel normaal dat ik mijn licht ga opsteken. (en dit ZONDER jou op enige manier dan ook te vernoemen).
Is toch een eenvoudige oplossing voor: zet beide gebruikers over naar een verschillende andere server en je weet in no-time waar het probleem zat EN er is meteen een oplossing. Of denk ik te simpel.
Is toch een eenvoudige oplossing voor: zet beide gebruikers over naar een verschillende andere server en je weet in no-time waar het probleem zat EN er is meteen een oplossing. Of denk ik te simpel.
Hij heeft maar 1 server :)
Overigens is dit het probleem verplaatsen, niet oplossen lijkt me.
Ik zou je er dan ook even op willen wijzen dat ik in mijn vraag op WHT nergens je naam vermeld heb, nergens een verwijzing doe naar je bedrijf en dat aan de hand van mijn usergegevens het niet evident zou geweest zijn de link naar jou te leggen. Mijn vraag op WHT was duidelijk een vraag naar advies. Wat ik zal doen, staat voor mij nog steeds niet vast. Als alles inderdaad zoals je zegt goed zal lopen vanaf nu dan kan ik met deze account verder anders niet. (je hebt nl nog al eens gezegd dat je het gevonden had en toen bleek dan ook niet het geval). Dit probleem is er al ongeveer een maand, dus misschien wel normaal dat ik mijn licht ga opsteken. (en dit ZONDER jou op enige manier dan ook te vernoemen).
Dat klopt, maar ik ben toch ook niet boos op je? En zoals ik al zei heb je helemaal gelijk. Ik ga me gewoon niet 'verschuilen' door wel het topic te lezen, en dan maar niet te reageren, dat vindt ik laf.
Maargoed, daarover gaan discussiëren is volgens mij ook nutteloos.
Ik heb verder geen hoge load meer gemeten, dus het lijkt nu in ieder geval te werken.
Ik vindt het uiteraard ook jammer dat het probleem toen niet verholpen bleek te zijn. Ik wordt er ook niet vrolijk van om soms 3 keer per dag onderbroken te worden met waar ik op dat moment mee bezig ben, omdat die server eruit ligt. Was het maar zo makkelijk van een user over verplaatsen, maar wat Randy al zegt heb ik inderdaad maar één server en dus niet de mogelijkheden daartoe. Overigens is dat inderdaad dan zo dat het probleem zich dan voor zou doen op die andere server. Het heeft nl. niet echt iets met servercapaciteit te maken maar gewoon met een brak script van een klant.
We wachten in ieder geval af hoe het nu verder loopt.
Wellicht kun en wil je vannacht doorgeven wat jouw systeem geconstateerd heeft. Als het goed is hebben we nu de betreffende klant te pakken namelijk en moet het probleem niet meer optreden.
Laten we hopen dat we vannacht niks van downtime merken, en daarna ook overdag niet meer!
Deze nacht tussen 2:22 en 2:39 lag de POP3 er opnieuw uit...dus niet opgelost.....
Overigens is dit het probleem verplaatsen, niet oplossen lijkt me.
voor de TS zou het wel meteen de oplossing zijn, geen uitvallende POP meer.
voor die brakke coder zou het inzicht zijn waarmee hij het kan oplossen. devven doe je maar op je eigen machine, niet op een shared hosting bak.
Laten we hopen dat we vannacht niks van downtime merken, en daarna ook overdag niet meer!
Hoop doet leven.....
Zowel deze nacht als vandaag was er downtime dus ....???
Deze nacht tussen 2:22 en 2:39 lag de POP3 er opnieuw uit...dus niet opgelost.....
dat is 15 min in een tijdsframe waarbij het gemiddelde op een oor ligt. Ga je nu elke hik hier vermelden ?
wellicht was het een netwerkprobleem aan jouw kant? of was de server druk met een backup en jouw script wat snel met een time out? (zomaar wat ideeën die ook zouden kunnen natuurlijk)
crazycoder
24/05/08, 15:21
Deze nacht tussen 2:22 en 2:39 lag de POP3 er opnieuw uit...dus niet opgelost.....
Hoeveel connectiepogingen? Als het een sbs server is met standaard pop3 connector is dat 1 keer.
Als het je echt zo irriteert vraag ik mezelf af waarom je de e-mail niet gewoon op je eigen server af laat leveren. Dan hoef je zelfs niet te wachten totdat het op wordt gehaald.
Persoonlijk vind ik dit soort problemen als ze gedurende de nacht en zeer beperkt plaatsvinden een non-issue. O ja, je zit toevallig niet op een adsl lijntje waar 's nachts via DHCP het ip adres wordt vernieuwd/aangepast he.. want dan kan je ook dit soort problemen krijgen.
dat is 15 min in een tijdsframe waarbij het gemiddelde op een oor ligt. Ga je nu elke hik hier vermelden ?
De POP3 server doet dit elke nacht en soms 15 minuten soms 30 of meer.
Tijdens de dag exact hetzelfde.
Vandaag al 2x een downtijd gehad, één keer "maar" 15 minuten en nu net ongeveer 45 minuten.
Ik ga ze niet allemaal vermelden. Luke zei dat hij dacht de opgelost was en dat ik het wel zou zien, wel hij (en jullie dus ook) kunnen zien dat het niet opgelost is.
Als het een pb langs mijn kant zou zijn (netwerk connectie) dan zouden andere servers die ik aanspreek dit zelfde "probleem" vertonen en dat is NIET het geval. Tevens als ik "wakker" ben, dan check ik steeds via 2 totaal verschillende netwerk verbindingen. Ik weet hoe ik moet monitoren....
Dirk heeft gewoon gelijk, al vindt ik dat kwartiertje iedere nacht ook wat overdreven om er zorgen over te maken. Overdag is het echter een ander verhaal, en dat is nu dus ook nog steeds het geval...
Waarom? Dat is me nu dus weer een raadsel.
Randy hoe kan ik je contacten? :)
Tja lijkt mij een kwestie van de logs goed doorkijken. Eventueel extra debug informatie instellen en je komt al een heel eind.
dreamhost_nl
24/05/08, 22:14
Is het geen combinatie van een hoge server load met de POP3/IMAP service die er als eerste uitklapt of echt alleen de POP3/IMAP service die eruit klapt? Of is dat nog niet bekend?
systemdeveloper
25/05/08, 00:15
2 kannen koffie, een hand vol ssh windowtjes met top, tail, mytop en iftop en tegen 3 uur vannacht zal het vast allemaal duidelijk zijn ;)
crazycoder
25/05/08, 08:15
Is het geen combinatie van een hoge server load met de POP3/IMAP service die er als eerste uitklapt of echt alleen de POP3/IMAP service die eruit klapt? Of is dat nog niet bekend?
Hoezo zou het een kwestie zijn van "eruit klappen"? Als het inderdaad iets met de load te maken heeft dan is het eerder een timeout die optreed dan "eruit klappen".
Voor de eindgebruiker maakt het geen verschil, voor de beheerder wel.
Verstandig limiteren van resources kan beslist helpen om dit soort problemen te voorkomen. Net zoals het om zeep helpen van vage scripts van gebruikers die problemen opleveren.
Hoezo zou het een kwestie zijn van "eruit klappen"? Als het inderdaad iets met de load te maken heeft dan is het eerder een timeout die optreed dan "eruit klappen".
Voor de eindgebruiker maakt het geen verschil, voor de beheerder wel.
Verstandig limiteren van resources kan beslist helpen om dit soort problemen te voorkomen. Net zoals het om zeep helpen van vage scripts van gebruikers die problemen opleveren.
Het is inderdaad eerder een kwestie van timeout, zoals ik in de eerste post gezet had:
"(stopt = connectie op poort 110 wordt aangenomen maar er komt geen vervolg op)"
dreamhost_nl
25/05/08, 17:22
Zoals crazycoder al aangaf kun je dat als eindgebruiker niet weten. Een service die geen tegenreactie geeft, kan er uitliggen of teveel tegelijkertijd te doen hebben op dat moment.
Zoals crazycoder al aangaf kun je dat als eindgebruiker niet weten. Een service die geen tegenreactie geeft, kan er uitliggen of teveel tegelijkertijd te doen hebben op dat moment.
Als je een connectie naar de poort kan maken, maar geen reactie (+OK) krijgt van de POP3 server, dan mag je ervan uitgaan dat de service/daemon opzich nog wel draait.
Gezien mijn monitoring background (zie sig) ben ik geen gewone eindgebruiker....