Thread: Slow access to PostgreSQL server
Hi all,
I have an application that uses PostgreSQL to store its data. The
application and an instance of the database have been installed in three
different locations, and none of these three locations have anything to
do with any of the others. I'm observing a problem in that large
transfers to some machines on the network (specifically while running
pg_dump) are dead slow. In fact, the information is going from the
server to the client machine at dialup speeds over a 100 Mb LAN to some
machines, and full speed to others.
This not a universal problem. Obviously, I'm not experiencing it at my
development location, or I would have found and fixed it by now. One of
the production installations had no problems. The second of the
production environments experienced the problem on one out of 4 laptops
(all the desktop machines were OK) until their technical guy uninstalled
AVG (anti-virus). The third location has 4 laptops that are all slow in
transferring PostgreSQL data, while the desktop machines are OK. There
are no problems with copying files across the network. At the third
location, they have the same software installed on the laptops and
desktops, including the Vet security suite. Suspecting that something
was screwing up the transfers by fiddling with packets, we suspended
Vet, but that didn't help. We're going to try changing NICs and checking
to see what happens when Pg runs on port 80.
Has anyone experienced this sort of thing before? We're running with
8.0.4. My application uses libpg, while another application is using
OLEDB. Both the native and OLEDB layers exhibit the delay on the "slow"
machines, and have no problems on the "fast" machines. Note that the
laptops are in no way inferior to the desktop machines in terms of CPU,
RAM, etc.
TIA,
Phil (yak from the build farm).
On 8/10/06, Phil Cairns <phil@pagaros.notpartofaddress.com.au> wrote: > Hi all, > > I have an application that uses PostgreSQL to store its data. The > application and an instance of the database have been installed in three > different locations, and none of these three locations have anything to > do with any of the others. I'm observing a problem in that large > transfers to some machines on the network (specifically while running > pg_dump) are dead slow. In fact, the information is going from the > server to the client machine at dialup speeds over a 100 Mb LAN to some > machines, and full speed to others. there have been numerous problems reported on windows due to various applications, especially malware and virus scanners, that cause this problem. be especially cautious about anything that runs in kernel mode or runs as a LSP. merlin
Hi, Phil, Phil Cairns wrote: > Has anyone experienced this sort of thing before? We're running with > 8.0.4. My application uses libpg, while another application is using > OLEDB. Both the native and OLEDB layers exhibit the delay on the "slow" > machines, and have no problems on the "fast" machines. Note that the > laptops are in no way inferior to the desktop machines in terms of CPU, > RAM, etc. Can you try to rsync / netcat some large files / random data through nonstandard ports in both directions, and see whether that reproduces the behaviour? I also think using PostgreSQL on port 80 might be an interesting test. It might be a driver or "security software" issue... When http and network drive transfers work fast, but transfers on nonstandard ports (postgreSQL uses 5432) work slow, I'd suspect some personal firewall or antivirus network filtering software. HTH, Marku -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
Hi, On Thursday 10 August 2006 12:00, Phil Cairns wrote: | In fact, the information is going from the | server to the client machine at dialup speeds over a 100 Mb LAN to some | machines, and full speed to others. [...] | There are no problems with copying files across the network. and you are really really sure that this is not a network issue? I'd double check that this is not a duplex mismatch, misconfigured router or switch or something in that direction. Ciao, Thomas -- Thomas Pundt <thomas.pundt@rp-online.de> ---- http://rp-online.de/ ----