network saturation

------=_Part_38785_32233379.1138353297494
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,
We have a fully switched 100mbps network, and communication between clients
running vb6 apps via odbc (08.01.02, i.e., the latest stable) are taking up
from 20 to 40% of the bandwidth - per APP!. The server is 8.1.1 running on
mandrake 10.1.
The offending apps are not coded well but this is just enormous. Even worse=
,
the apps do an OCR which takes about 5 seconds (during which no db access
takes place) and for some reason it seems there is still a lot of traffic
(we have HP switches and port usage NEVER falls below 15%).
Can anyone shed some light on this? When 4+ apps start hitting the db
performance starts to degrade quite considerably.
Cheers
Antoine

--
This is where I should put some witty comment.

------=_Part_38785_32233379.1138353297494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,
We have a fully switched 100mbps network, and communication between =
clients running vb6 apps via odbc (08.01.02, i.e., the latest stable) are t=
aking up from 20 to 40% of the bandwidth - per APP!. The server is 8.1.1
running on mandrake 10.1.
The offending apps are not coded well but th=
is is just enormous. Even worse, the apps do an OCR which takes about 5 sec=
onds (during which no db access takes place) and for some reason it seems t=
here is still a lot of traffic (we have HP switches and port usage NEVER fa=
lls below 15%).

Can anyone shed some light on this? When 4+ apps start hi=
tting the db performance starts to degrade quite considerably.
Cheers >Antoine

--
This is where I should put some witty comment.

------=_Part_38785_32233379.1138353297494--

Re: network saturation

------=_Part_38809_21466756.1138353637932
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 27/01/06, Antoine wrote:
>
> Hi,
> We have a fully switched 100mbps network, and communication between
> clients running vb6 apps via odbc (08.01.02, i.e., the latest stable) are
> taking up from 20 to 40% of the bandwidth - per APP!. The server is 8.1.1=
running on mandrake
> 10.1.
> The offending apps are not coded well but this is just enormous. Even
> worse, the apps do an OCR which takes about 5 seconds (during which no db
> access takes place) and for some reason it seems there is still a lot of
> traffic (we have HP switches and port usage NEVER falls below 15%).
> Can anyone shed some light on this? When 4+ apps start hitting the db
> performance starts to degrade quite considerably.


For info, these apps have a transaction open pretty much constantly (none o=
f
the other apps have this, and don't seem to use much bandwidth). Originally=
,
they were open for 1.5hrs and now opened and closed every two minutes (as
soon is one is closed another is opened)
Chrs



--
This is where I should put some witty comment.

------=_Part_38809_21466756.1138353637932
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Re: network saturation

> > We have a fully switched 100mbps network, and communication between
> > clients running vb6 apps via odbc (08.01.02, i.e., the latest stable) are
> > taking up from 20 to 40% of the bandwidth - per APP!. The server is
> > 8.1.1running on mandrake 10.1.

You forgot specify the client OS ;-) But the network bandwidth isn't
psqlODBC related. We use libpq for communication with backend.

I have seen similar problem a few days ago and Magnus Hagander wrote:

| We've seen this a couple of times before with Windows 2000, but it's
| always been slow in both psql and pgadmin then ;-) Search the archives,
| there's something about the QoS driver.

I hope this helps you

Luf

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: network saturation

------=_Part_39542_32135710.1138360165770
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 27/01/06, Ludek Finstrle wrote:
>
> > > We have a fully switched 100mbps network, and communication between
> > > clients running vb6 apps via odbc (08.01.02, i.e., the latest stable)
> are
> > > taking up from 20 to 40% of the bandwidth - per APP!. The server is
> > > 8.1.1running on mandrake 10.1.
>
> You forgot specify the client OS ;-)


Yeah, windows xp (I think we have one with no SP, and the rest with SP1). W=
e
have some win2000 sp4s but they don't run the offending app (rather other
ones that don't show the problem).

But the network bandwidth isn't
> psqlODBC related. We use libpq for communication with backend.
>
> I have seen similar problem a few days ago and Magnus Hagander wrote:
>
> | We've seen this a couple of times before with Windows 2000, but it's
> | always been slow in both psql and pgadmin then ;-) Search the archives,
> | there's something about the QoS driver.


I looked and it didn't seem particularly related, seeing as they are XP
boxen.
CPU usage for the postgres machine is also very high, getting regularly up
to 50% for a single connection. I will try a vacuum full but I am pretty
sure that won't make much difference. Maybe it is related to network
traffic?
I will have a look with ethereal and see what I can gather.
Chrs
Antoine

--
This is where I should put some witty comment.

------=_Part_39542_32135710.1138360165770
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Re: network saturation

> I looked and it didn't seem particularly related, seeing as they are XP
> boxen.
> CPU usage for the postgres machine is also very high, getting regularly up
> to 50% for a single connection. I will try a vacuum full but I am pretty
> sure that won't make much difference. Maybe it is related to network
> traffic?
> I will have a look with ethereal and see what I can gather.

Agrh I'm stupid. You feel too high HW load. Do you know what exactly
the app makes? Feel free to create mylog output or you can log on
the server side to have better idea what's going on.
Than you can try simulate the situation via psql client. So you
can decide where is the problem.

If you don't understand the mylog output you could send it to me
privately.

It could be interesting to see what settings do you use for psqlodbc.
BTW 08.01.0102 isn't very good. Please try 08.01.0107 development
snapshot from pgfoundry.org. There is fixed a lot of bugs
(Parse Statement, get values, stability, ...).
Then you can try different options like use declare/fetch, Parse Statement,
.... Different tasks need different options turned on.

We're planning to release new psqlodbc official release next week.
The new official release will be based on the 08.01.0107.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: network saturation

------=_Part_41363_5811816.1138372806803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>
>
> It could be interesting to see what settings do you use for psqlodbc.
> BTW 08.01.0102 isn't very good. Please try 08.01.0107 development
> snapshot from pgfoundry.org. There is fixed a lot of bugs
> (Parse Statement, get values, stability, ...).
> Then you can try different options like use declare/fetch, Parse
> Statement,
> ... Different tasks need different options turned on.
>

I would love to try it, seeing as declaire/fetch doesn't change anything...
Do I simple replace the dlls in C:\Program Files\psqlODBC\bin?
Cheers
Antoine


--
This is where I should put some witty comment.

------=_Part_41363_5811816.1138372806803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Re: network saturation

Fri, Jan 27, 2006 at 03:40:06PM +0100, Antoine napsal(a):
> > It could be interesting to see what settings do you use for psqlodbc.
> > BTW 08.01.0102 isn't very good. Please try 08.01.0107 development
> > snapshot from pgfoundry.org. There is fixed a lot of bugs
> > (Parse Statement, get values, stability, ...).
> > Then you can try different options like use declare/fetch, Parse
> > Statement,
> > ... Different tasks need different options turned on.
>
> I would love to try it, seeing as declaire/fetch doesn't change anything...
> Do I simple replace the dlls in C:\Program Files\psqlODBC\bin?

Yes. It's enough.

But it's strange that declare/fetch doesn't change anything.
Driver fetch "cache size" (option on Page1 in left bottom corner) rows
from backend after open. "cache size" is 100 by default. So if you have
less rows in selects you could try to play with the cache size parameter.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: network saturation

------=_Part_117_25662231.1138374430337
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 27/01/06, Ludek Finstrle wrote:
>
> Fri, Jan 27, 2006 at 03:40:06PM +0100, Antoine napsal(a):
> > > It could be interesting to see what settings do you use for psqlodbc.
> > > BTW 08.01.0102 isn't very good. Please try 08.01.0107 development
> > > snapshot from pgfoundry.org. There is fixed a lot of bugs
> > > (Parse Statement, get values, stability, ...).
> > > Then you can try different options like use declare/fetch, Parse
> > > Statement,
> > > ... Different tasks need different options turned on.
> >
> > I would love to try it, seeing as declaire/fetch doesn't change
> anything...
> > Do I simple replace the dlls in C:\Program Files\psqlODBC\bin?
>
> Yes. It's enough.
>
> But it's strange that declare/fetch doesn't change anything.
> Driver fetch "cache size" (option on Page1 in left bottom corner) rows
> from backend after open. "cache size" is 100 by default. So if you have
> less rows in selects you could try to play with the cache size parameter.
>

I have tested with the dlls changed (107) and WOW - what a difference!
Thanks! We tried with 102 on another system and it didn't work. We aren't
going to search to hard though cos, hey, we have the best solution!
Thanks heaps
Antoine


--
This is where I should put some witty comment.

------=_Part_117_25662231.1138374430337
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline