Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[IIS] Server 2012 Webserver timeouts extern

Pagina: 1
Acties:

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Wij hebben sinds een aantal weken een nieuwe VDS server. Alles draait vlekkeloos, alleen hebben we regelmatig last van timeouts op websites.

Er draait Windows Server 2012 op met IIS. Het probleem doet zich enkel voor met websites die via het internet lopen. Daarmee bedoel ik dat de sites vanaf kantoor (en andere locaties) ineens niet meer beschikbaar zijn. Vraag ik dezelfde site lokaal op op de server zelf, dan draaien ze nog wel en zonder problemen.

Er valt dus blijkbaar niet echt iets uit qua IIS!

In de logboeken staan totaal geen foutmeldingen die iets aanduidelijk over timeouts of fouten. Het gaat mis met zowel PHP als ASPX websites. Alle andere services (zoals mail en/of FTP) blijven gewoon functioneren.

We maken gebruik van de standaard Windows Firewall in Server 2012 en het vreemde is, zodra ik deze uitzet, werkt alles prima en zonder problemen!

Ik heb al gezocht naar iets van 'flood protection' of timeouts of andere beveiliging in de Windows Firewall, maar kan hier totaal niets over vinden.

De webhoster die ons de VDS heeft geleverd heeft ook al gezocht en een netwerk driver op de HYPERV host aangepast, maar dit was ook geen oplossing.

Ik heb werkelijk geen idee meer waar het nog in kan zitten en ik hoop dat 1 van jullie hier een goed idee heeft.

Het zou wellicht een instelling in de Windows Firewall kunnen zijn, maar ook een module van IIS of iets dergelijks kan misschien problemen veroorzaken.

Ben er zelf al een tijdje mee bezig zoals jullie zien en als ik er echt niet meer uitkom, vraag ik Tweakers altijd om hulp!

Alvast bedankt! Ik zal het topic in de gaten houden en z.s.m. antwoorden!

  • KoeKk
  • Registratie: September 2000
  • Laatst online: 24-11 19:11
Gezien je probleem omschrijving denk ik als eerste aan een issue in een website/DCOM component die gevolgen heeft voor heel IIS. De Windows/IIS codebase is wel zo ver ontwikkeld dat zeer onwaarschijnlijk is dat je daar tegen bugs gaat aanlopen.

Wat zie je in de task manager qua CPU / geheugen / schijf gebruik als dit probleem optreed?

Zie je in je W3 logs wel de requests van de bezoekers binnekomen? Wat voor statuscodes zie je terugkomen als het probleem optreed?

Als je een statuscode hebt: schakel failed request tracing in (http://www.iis.net/config...acing/tracefailedrequests), Daarmee kan je zien welk onderdeel (IIS/ASp.NET/Componenten) plat gaat.

Als je een platte HTML website er neer zet, blijft deze dan wel werken?

Sucses :)

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Bedankt voor je reactie, KoeKk. Goede tips, ik ga het oppakken en naar kijken! Bedankt!

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Ben er nog even wat verder ingedoken:

- Op het moment dat het misgaat, worden er GEEN logentries aangemaakt
- Caching heb ik volledig uitgezeg op IIS, omdat het wellicht daaraan kon liggen. Hielp ook niet.


Probleem blijft bestaan.

Iemand anders nog tips?

  • Zoetjuh
  • Registratie: Oktober 2001
  • Laatst online: 10-01-2024
Hmm, probeer anders eens die standaard dingetjes als alle TCP/IPSec Offloading zaken uitschakelen. Powersave op de LAN adapter uitschakalen. Is het een "webserver only", zou je IP Helper uit kunnen zetten. Via netsh chimney etc etc. uitschakelen. Lost vaak een hoop ellende op (helaas).

Overigens, wat voor onderliggende hardware gebruik je? Merk/model?

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Zoetjuh, het gaat om een HyperV server, virtueel dus. Ik weet dus niet wat voor hardware er exact draait.

Wel weet ik dat het een AMD Phenom 9500 Quad is met 2 threats/cores enabled en 2 GB intern geheugen.

Maar of je daar wat aan hebt....

De rest van je tips zitten op de netwerkkaart? Vind het 'eng' om daar wat op aan te passen, vooral dingen die ik niet ken. Bang dat ik mijn verbinding kwijt ben op afstand... Zeker op een zondagavond waar de helpdesk niet beschikbaar is, hehe.

  • Zoetjuh
  • Registratie: Oktober 2001
  • Laatst online: 10-01-2024
Begrijpelijk. Het uitzetten van IPSec/TCP Offloading zal zeker je verbinding even verbreken, maar die zou enkele seconden daarna weer terug moeten komen. Hoe dan ook lijkt het me verstandig dat inderdaad te doen wanneer je terug kan vallen op een helpdesk inderdaad.

Voor wat betreft de onderliggende hardware, Ik begreep dat het virtueel is inderdaad. Maar heb wel eens issues gezien op sommige Broadcom en specifieke Intel adapters; afhankelijk van de hardware had daar misschie iets zinnigs over zeggen. Maar dat is altijd op Intel based platformen geweest :)

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Okay, thanks voor je response zover!

Maar die tips, zitten die op je netwerkkaart? En welke zaken zal ik daar uitzetten precies? Zijn er nogal wat...

  • Zoetjuh
  • Registratie: Oktober 2001
  • Laatst online: 10-01-2024
Ik zet vaak alle IPSec en TCP/UDP Offloads uit

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Ik begrijp dat je de Windows firewall nodig hebt dus? Geen optie om een echte firewall ervoor te plakken? Of wellicht een VLB als je geen hardware mag plaatsen.

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Prijstechnisch gezien moet de Windows Firewall gebruikt blijven worden. Een hardware firewall is te duur (per maand) en software nog geen goede kunnen vinden...

  • wagenveld
  • Registratie: Februari 2002
  • Niet online
Geen echte firewall natuurlijk maar je zou alleen HTTP/HTTPS open hebben staan:
http://kemptechnologies.c...irtual-loadmaster-vlm-200

Veel slimmer dan gewoon poorten dichthouden is de Windows firewall ook niet dus wat dat betreft zou het niks moeten uitmaken. Komt bij dat je ook wat aan load balancing kunt doen. Wellicht interessant?

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Ook voor een VLB moet betaald worden :)

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Ik heb zojuist toch besloten alle IPSEC en TCP/UDP offloads uit te zetten. Maar het hielp niets... Voor mijn gevoel werd het zelf beetje erger... :S

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Even terugkomend op mijn eerdere bericht over de specificaties: ik heb per abuis op de verkeerde server gekeken. Dit zijn de juiste specificaties:

Intel Xeon CPU E5-2407 @ 2.2 GHz
2 logical processors
4GB Intern geheugen

Zoetjuh had nog wat ideeën, maar die waren gebaseerd op Intel. Het blijkt dus wel degelijk Intel te zijn. Wellicht kan Zoetjes alsnog reageren?

Thanks!

  • Zoetjuh
  • Registratie: Oktober 2001
  • Laatst online: 10-01-2024
Ik weet niet hoeveel VM's de hoster op deze Hyper-V server heeft en wat ze gebruiken om Hyper-V op te draaien; is dat 2008R2, 2012, 2012R2? Maar wij hebben ook wel eens iets dergelijks gehad en toen moest ik op Hyper-V niveau ook de Offloads uitzetten wilde het probleem verdwijnen.

  • Massiefje
  • Registratie: Mei 2002
  • Laatst online: 12-11 09:57
Okay, ik geef het aan ze door! Bedankt voor je reactie, Zoetjuh! Wordt erg gewaardeerd!

Heb overigens ook de offload checksums uitgezet op de netwerkkaart op de JUISTE server ditmaal...

Lijkt wel iets beter te gaan, maar probleem is er nog steeds :(

[ Voor 49% gewijzigd door Massiefje op 17-02-2014 15:49 ]


  • KoeKk
  • Registratie: September 2000
  • Laatst online: 24-11 19:11
Nu ik het allemaal nog eens teruglees: wat bedoel je precies met dat de sites niet meer beschikbaar zijn? Krijg je een blanco pagina of toch nog iets van een foutmelding? Wat doet je browser op dit moment, blijft deze laden?

Ik denk dat het tijd wordt om Wireshark maar eens te gaan installeren en te kijken wat er met de netwerk pakketjes gebeurd. Installeer het zowel op je server als op je client. Als je voldoende schijfruimte hebt zou ik hem op je server alles laten loggen naar een bestand. Als het probleem dan optreed kan je vanaf je client ook gaan loggen en via IE testen.

Vervolgens kan je de logfile gaan doorspitten. Controleer of het verkeer vanaf je client ook aankomt op je server e.d. Mischien is er wel een apparaat wat upstream (Gezien vanaf je server) zaken blokkeerd.
Pagina: 1