FreeTDS Development Group

["Brian Johnson" <serversage AT gmail.com>]

Wow guys, you nailed it on the head!  I started doing some digging into the
issue (tcpdumps, tdsdumps, etc...) and discovered it kind of looked like it
was a buffer filling up.  So I started playing with sysctl.conf values, and
here is what I came up with that seems to be the magical cure:


net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 2500

After that, things are working great.  I'm suspect that this may have
something to do with the system running under VMWare.  Thanks again for
pointing me in the right direction!  Hopefully my pain will be somebody
else's gain down the road.

-Brian

On Tue, Apr 8, 2008 at 10:11 AM, Brian Johnson <serversage AT gmail.com> wrote:

> Alrighty guys, I'm on the network bandwagon.  I'll start putting feelers
> out into the pfSense community to see if any of them have ideas (pfSense is
> the firewall/router we are currently using).  It's possible Racoon has an
> issue with this particular VPN endpoint the client has or something.
>
> Unfortunately, the Windows end isn't a system/network we have any kind of
> access to, other than the database.  It's in a doctor's office, and our
> chances of finding an IT guy that is willing to either let us look at it, or
> to do it himself, are pretty much 0.
>
> I will try the SACK setting when I get home tonight and see if any magic
> happens.  I'll also see if we can get one of their IT guys to be "cool".  :)
>
>
> Thanks guys, your help has been greatly appreciated.  And I mean GREATLY.
> Helping with a problem that exists outside the scope of the software was
> above and beyond the "call of duty".
>
> -Brian
>
>
>
> On Tue, Apr 8, 2008 at 7:03 AM, James K. Lowden <jklowden AT freetds.org>
> wrote:
>
> > Brian Johnson wrote:
> > > The Windoze system works great (returns
> > > all the rows).  But both linux systems choke.
> >
> > Consistent with a network issue, pointing to the firewall.  :-/
> >
> > > The log
> > > created when setting TDSDUMP did indeed seem to indicate that there
> > was
> > > no problem, data just stopped flowing.  ...
> > >
> > > Any ideas?  Any where I can point a finger and say, "Aha!  I have
> > > something to update!"?
> >
> > You may find that something simple, say, ftp, fails if the file is large
> > enough.  That would eliminate the whole application layer and focus
> > attention on the network.
> >
> > In case Hildo's selective ACK suggestion doesn't do the trick, the
> > technical path would be to use tdsdump(8) to log the connection, and
> > watch
> > the server stop sending when it shouldn't.  For extra credit, scope the
> > server's side, too.  It's work, and some shops don't have the chops.
> >  With
> > luck you'll find either the "stuck" packet, the one the server sent that
> > the client never received, or you'll see the server mysteriously stop
> > sending even though the client is waiting and has abided by the TCP/IP
> > RFCs.
> >
> > (Windump works pretty well if you have the tcpdump man page handy, but I
> > have  never used it with a VPN.)
> >
> > Lament: Observe the negative network effect of Windows.  Your firewall
> > "works great" with the Windows machines, but not with Linux.  Your
> > choice
> > is to fight or switch, and fighting requires knowledge and patience ...
> > and possibly new VPN software.  Who can blame the person who looks at
> > that
> > scenario before it even begins, and decides not to go there?
> >
> > Anyway, good luck.  Please post the outcome if you would.  Someone else
> > might benefit.
> >
> > --jkl
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> >
>
>