Verbroken verbindingen en keepalive-packets onder windows

[doskabouter]

Ik heb een probleem met tcp/ip verbindingen die lange tijd idle blijven, en ik kom er nog niet uit wat hier tegen te doen.

Situatieschets:

Postgres server: Windows 2008, Postgres versie 9.4
Clients: Verschillende windows versies lopend van XP tot en met 7

Postgres server en clients zitten allemaal in hetzelfde LAN, maar wel in een ander netwerksegment.
Het zaakje is verbonden via een aantal switches/firewalls enz.
Server en clients heb ik direct beheer over, de rest van de netwerkinfra niet.

Probleem:

Als een client een zware query afvuurt op de server (hetzij via eigen software (gebruikmakend van libpq_fe), hetzij via pgadmin) die lang duurt voordat er resultaat terugkomt, krijgt de client het resultaat niet meer terug.

Queries die korter duren (orde-grootte enkele minuten) geven geen enkel probleem.

Experimenten:

Ik heb in de config van postgres op de server al aangegeven dat de tcp_keepalives_idle naar een half uur of zo moet, maar dat heeft geen effect gehad.
Ook al geprobeerd om op de client KeepAliveTime in te stellen in de registry, maar dat heeft ook niet mogen helpen.

Volgens de beheerders van de firewall staat de max idle time voordat een verbinding opgeruimd wordt op 1 uur, die hebben ze al eens verhoogd naar 2.5 uur, maar dat heeft ook niks opgeleverd.

Wat ik wel zie als ik op de server en de client een wireshark laat lopen, dat (ongeacht de instellingen op de server,client of firewall) exact na 2 uur 5 of 6 keepalive packets verstuurd worden, maar dat die niet aan de andere kant aankomen.
Op dat moment krijgt de applicatie die de query afvuurt door dat de verbinding weg is, en stopt dan met een melding (query blijft dan wel netjes doorlopen op de server).

Ik heb nog niet geprobeerd om met setsockopt volgens hier: MSDN: SO_KEEPALIVE socket option (Windows) te spelen, voornamelijk omdat ik wel al keepalive packets verstuurd zie worden na 2 uur.

Er zijn dus concreet een paar vragen:
- Waarom reageert postgres niet op de keepalive instellingen?
- Waarom reageert de client niet op de keepalive instellingen?
- Hoe krijg ik het voor elkaar om keepalive packets te versturen binnen het uur?
- Wordt door windows altijd keepalive packets na 2 uur verstuurd ongeacht de so_keepalive socketoption?
- Zijn er nog andere zaken die ik kan uitproberen?

Wie o wie kan mij hier verder mee helpen?

Edit: Ik zie nu pas dat ik dit misschien beter in een andere thread had kunnen zetten...

[pedorus]

Een half uur lijkt me al wat lang, meestal is na een kwartiertje een nat router oid al klaar met een verbinding. Is de tijd niet een stuk korter, waardoor de keep-alive pakketjes van de server al niet meer aankomen? En lukt de query vanaf de server zelf wel?

Maar eigenlijk zou ik me meer afvragen wat voor query er gebeurd, want een select van 2+ uur lijkt me niet gezond. Enkele minuten vind ik al lang. Het is mogelijk dat keep-alives alleen verstuurd worden bij idle connecties, want dit is een vrij ongewoon scenario.

[Damic]

Ik zou die query dan toch eens bekijken, want niemand zit te wachten op data waar je 2u op moet wachten.

[BCC]

^^ of het resultaat van de query in een ander tabelletje wegschrijven

[doskabouter]

Dank voor jullie meedenken, maar het blijkt dat ik nog niet helemaal volledig ben geweest met de probleemstelling.

Queries die inderdaad een 15-30 minuten duren gaan gewoon goed, ook het draaien van een zware query op de server zelf gaat perfect.
Het zit hem echt in de tussenliggende apparatuur die de verbinding om zeep helpt.

Het zijn zware queries, het gaat om ver- en bewerken van grote hoeveelheden vectordata. Ze zijn al helemaal geoptimaliseerd met indexen etc. en uitgaande van de queryplannen is er niets meer te winnen.

De resultaten worden altijd naar een tabel geschreven, maar het zou wel fijn zijn als ik te horen krijg dat ie klaar is, zodat ik de volgende stappen kan zetten.
Ook bv een vacuum, of het zetten van een zooi indexen op vers geimporteerde data kan wel eens lang duren. Ik kan ze allemaal wel op gaan splitsen zodat ze (met de huidige data/belasting) onder het uur blijven, maar dat is dus absoluut geen toekomstvaste oplossing.

Het feit dat het lang duurt, is geen enkel probleem. Deze queries hoeven maar af en toe te draaien, en als ze er dan een nacht (of voor mijn part een weekend) over doen is dat goed genoeg.

En als bonus vraag (minder acuut, maar zo mogelijk wel irritanter): Iemand een idee waarom pgadmin al binnen het uur klaagt dat de connectie met de database gereset is? En daar pas na een timeout van weet ik hoe lang achterkomt, en in die tijd geen enkel sql venster reageert/leesbaar/pastebaar is?

[pedorus]

Ik zou anders eens testen of het wel werkt over een ssh tunnel of vpn oplossing waarbij keep alives wel aanstaan. Als extra voordeel beveiligd dit ook nog eens de verbinding. Nu is dat met een windows server wat lastiger op te zetten, maar ik zie hier bijvoorbeeld een ssh serveroplossing voor windows: https://www.bitvise.com/port-forwarding

Een andere oplossing is alleen vanaf de server zelf uitvoeren.

Nog een andere oplossing is wellicht niet de database misbruiken voor rekenwerk, of datgene dat er voor zorgt dat je zulke lange queries doet.

[doskabouter]

Beveiligde verbinding is geen issue hier, het gaat alleen maar over ons eigen LAN.

Ik wil graag de database laten doen waar die goed in is, en heb eigenlijk niet zo heel veel behoefte om allerlei code te schrijven die de functies van de database kopieert. Ook zit ik dan waarschijnlijk met memory issues op de clients want de data waar mee gerekend word is behoorlijk groot.
Kan natuurlijk wel deels weer op disk gooien, maar dat is nog meer software die gemaakt/getest/gedocumenteerd:) moet worden.

Ik heb net wel even laatste strohalm gehad, je kan namelijk met getsockopt de keepalive aanzetten van een connectie, maar die blijkt dus al aan te staan als ik een connectie naar de server leg.

Vraag is dus: waarom heeft dit geen effect?
Ik zie in de documentatie van microsoft wel het volgende:

A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way.

Maar daar wordt ik dus niet erg blij van...

[farlane]

Als het de tussenliggende apparatuur is, probeer dan eens (indien mogelijk) of het met een (bijna) directe verbinding wel werkt, of zet de keepalive interval extreem klein ( orde seconden) te zetten. Wel monitoren of ze daadwerkelijk gestuurd worden.

[johnkeates]

Als je wil weten of je het in Windows wel of niet kan oplossen kan je kijken of je met Linux hetzelfde probleem hebt. Zo ja: probleem ligt buiten je server. Zo nee: dan is het probleem windows-only en kan je het ergens in de TCP/IP stack van Windows zoeken. Dat maakt het een stuk makkelijker zoeken.

Heb je trouwens al een wireshark gedaan? Kan ook helpen om te kijken wat er qua verkeer gebeurt.

[farlane]

johnkeates schreef op woensdag 20 mei 2015 @ 16:15:
Als je wil weten of je het in Windows wel of niet kan oplossen kan je kijken of je met Linux hetzelfde probleem hebt. Zo ja: probleem ligt buiten je server. Zo nee: dan is het probleem windows-only en kan je het ergens in de TCP/IP stack van Windows zoeken. Dat maakt het een stuk makkelijker zoeken.

Heb je trouwens al een wireshark gedaan? Kan ook helpen om te kijken wat er qua verkeer gebeurt.

De TS heeft al geconstateerd dat het in de tussenliggende apparatuur zit

[doskabouter]

Ik heb op dit moment even te weinig resources om het op linux te proberen, ook directere verbindingen vallen even buiten mijn jurisdictie

Wireshark heb ik al aan beide zijden laten lopen (zoals in op). Ik zie daar dat na 2 uur keepalive pakketjes verzonden worden, en dat na 5 pakketjes erachter gekomen wordt dat de verbinding verdwenen is. Zo komen dus nooit aan de andere kant aan.

Keepalive interval heb ik ook al aangepast in windows, maar dat lijkt genegeerd te worden. (Had de tijd op 30min gezet, maar de pakketjes worden nog steeds na 2 uur (geprobeerd te) versturen

[EddoH]

Heb je ook naar de KeepAliveTime gekeken? Zie onder andere

http://blogs.technet.com/...about-tcp-keepalives.aspx

Default staat deze op 2 uur.

[farlane]

Hier Lees ik:

Even if TCP KeepaliveTime and TCPKeepAliveInterval registry keys are set to a specific value (TCPIP driver uses the deafult values even if we don't set these registry keys from the registry), TCPIP driver won't start sending TCP Keepalives until Keepalives are enabled via various methods at upper layers (layers above TCPIP driver).

M.a.w. KeepAlives worden (altijd?) verstuurd met default interval tenzij setsockopt( .. SO_KEEPALIVES... ) wordt gebruikt.

Ik vraag me de volgende dingen af:
- Vanaf waar (server en/of client) komen die keepalives?
- Als de tussenliggende apparatuur de idle timeout op 2,5 uur heeft gehad en de keepalives komen na 2 uur, waarom komen in dat geval de pakketjes niet aan? ( Misschien werkt die idle timeout anders dan men denkt? )
- Heb je een manier om uit te vinden tot waar de pakketjes komen? ( Maw tot welke hop in de route van je client naar de server )

[doskabouter]

Keepalivetime heb ik (zoals vermeld in de start) al geprobeerd, maar daar lijkt windows niet naar te luisteren.
En over de setsockopt: Met de SO_KEEPALIVE kan je voor zover ik begrijp alleen de keepalives aan of uitzetten, geen tijd specificeren. Ik heb met GetSockOpt al gekeken, en gezien dat de SO_KEEPALIVE op 1 staat, en ik zie ook na 2 uur keepalives verzonden worden.

De wireshark captures tonen mij dat van beide kanten de keepalives na 2 uur verstuurd worden, maar doordat de verbinding na 1 uur al weg is, komen ze dus nergens meer aan.

Ik kan de club die die timeout op 2.5 uur gezet heeft eens even vragen of ze 100% zeker weten dat dit zo ingesteld was, maar ga er toch even van uit dat ze dat wel goed hebben gedaan... Maar ik geloof niet dat hun kunnen kijken tot waar die pakketten komen, ik had ze dat inderdaad al eerder gevraagd.

[Feanathiel]

doskabouter schreef op maandag 18 mei 2015 @ 23:14:
[...]
Het zijn zware queries, het gaat om ver- en bewerken van grote hoeveelheden vectordata. Ze zijn al helemaal geoptimaliseerd met indexen etc. en uitgaande van de queryplannen is er niets meer te winnen.
[...]

Query splitsen is geen optie? Hierbij heb ik het dan specifiek over het aantal te verwerken records. Dit zie je vaak ook bij het versturen van e-mails (om maar even een voorbeeld te noemen). Per keer, zeg 100.000 of 1.000.000, records verwerken.

[doskabouter]

nope

[EddoH]

doskabouter schreef op donderdag 21 mei 2015 @ 08:55:
Keepalivetime heb ik (zoals vermeld in de start) al geprobeerd, maar daar lijkt windows niet naar te luisteren.

Excuus, overheen gelezen. Echter zou ik wel proberen uit te vinden waarom de waarde dan genegeerd wordt, adv tips van farlane en die Microsoft blog.

Als dat allemaal geen soelaas bied zou ik proberen de query te splitsen. Feit blijft dat als een standaard TCP timeout optreed, je wat aan je architectuur/aanpak moet doen, in plaats van platform specifieke 'hacks' toe te passen.

[farlane]

doskabouter schreef op donderdag 21 mei 2015 @ 08:55:
Keepalivetime heb ik (zoals vermeld in de start) al geprobeerd, maar daar lijkt windows niet naar te luisteren.

Dat had ik meegekregen, maar de link die ik plaatste zegt in feite dat Windows altijd KeepAlives verstuurt met de default interval van 2 uur, tenzij je een setsockopt doet, alleen dan neem hij je custom interval.

Lees ook het SO_KEEPALIVE gedeelte eens aandachtig door op MSDN:

The SO_KEEPALIVE socket option is valid only for protocols that support the notion of keep-alive (connection-oriented protocols). For TCP, the default keep-alive timeout is 2 hours and the keep-alive interval is 1 second. The default number of keep-alive probes varies based on the version of Windows.

The SIO_KEEPALIVE_VALS control code enables or disables the per-connection setting of the TCP keep-alive option which specifies the TCP keep-alive timeout and interval. If TCP keep-alive is enabled with SO_KEEPALIVE, then the default TCP settings are used for keep-alive timeout and interval unless these values have been changed using SIO_KEEPALIVE_VALS.

[ Voor 5% gewijzigd door farlane op 21-05-2015 09:30 ]

[doskabouter]

Die blog had ik al doorheen gelezen, maar kon daar niet direct een verklaring vinden.

Ik las daar wel wat over WSAIoctl, en dat ziet er toch wel veelbelovend uit, daar ga ik eens wat mee experimenteren.

Edit: Met WSAIoctl lukt het inderdaad om de instellingen van windows te overrulen!
Probleem opgelost (of op zijn minst worked-around) dus.

Dank voor het meedenken!

[ Voor 28% gewijzigd door doskabouter op 21-05-2015 15:47 ]