A colleague of mine has crash-landed in the valley of the dinosaurs.
Happily no injuries, but the local inhabitants have asked him to migrate
their Ingres 6.4 system off their rusty old IBM box onto something
that runs on electricity.

Interestingly an important query that takes 5 seconds when their W4GL
client runs it on the old box now takes 35 seconds when the same
client runs it on the new host.

He's tried various plausible checks and tests, and even got me to
remember the rundbms.opt file(!), but one possiblity that's still under
discussion is whether there is perhaps a problem with a 6.4 vintage Net
server talking to an Ingres 9.x Net server.

Any suggestions on any of this?

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Put the date in your diary today.

On Jan 11, 2011, at 12:59 PM, Roy Hann wrote:

If the query can be run in isolation, I suppose the initial
steps would be to verify that the QEP hasn't changed,
and to time the query running in a local terminal monitor
vs over Ingres-Net.

DMF cache settings could change the QEP, but if you've
remembered rundbms.opt, you have probably checked
that already.

Other random thoughts would be work or transaction log
file contention against the data area on the new
host, or raid-5 for a work area, or something equally
hideous in the disk setup.

I'm not really qualified to comment on net-to-net issues,
but I don't remember seeing any discussion of such a thing.

Karl

Hi Roy,

I'm probably late in saying this, but I'd suggest confirming that stats were loaded onto the new database. Then checking the query plans for any obvious deficiencies like a missing index in the new database.

Marty

________________________________________
From: Roy Hann [specially (AT) processed (DOT) almost.meat]
Sent: 11 January 2011 17:59
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: [Info-Ingres] Performance problems with ancient 6.4-era Ingres/Net?

A colleague of mine has crash-landed in the valley of the dinosaurs.
Happily no injuries, but the local inhabitants have asked him to migrate
their Ingres 6.4 system off their rusty old IBM box onto something
that runs on electricity.

Interestingly an important query that takes 5 seconds when their W4GL
client runs it on the old box now takes 35 seconds when the same
client runs it on the new host.

He's tried various plausible checks and tests, and even got me to
remember the rundbms.opt file(!), but one possiblity that's still under
discussion is whether there is perhaps a problem with a 6.4 vintage Net
server talking to an Ingres 9.x Net server.

Any suggestions on any of this?

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Put the date in your diary today.


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

Hi,

The w4gl V2 Clients are using what looks like 6.4/03'ish net,
specifying the TCP_FTP protocol running under windows. (NTVDM - wowexec
etc)

It only takes 35 odd seconds when there's a physical network between
the client and the Ingres 9.2 env.

If you run the W4GL V2 Client via terminal services on the Ingres 9.2
server, then it too manages five seconds, again using the ancient Ingres
net to talk to the local Ingres 9.2 server.

The dataset is 86 rows, if I isolate the query in an OpenROAD2006
development environment then it's sub second when running against the
9.2 server.

So I think the database is working OK, I'm begining to wonder if
there's something in the client/server comunication that is causing a
large delay, but the fact it works in a terminal session has me
scratching my head.

Thanks

Adrian


--
Adrian Williamson

On Jan 11, 2011, at 3:47 PM, Adrian wrote:


The 30 second difference sounds suspiciously like a timeout,
such as a DNS / reverse DNS type of lookup timeout.
I don't suppose you could snoop the wire to see what is going
back and forth?

Other than that, I'm out of ideas; maybe one of the Net guys
will chime in.

Karl

TCP_FTP, as I remember it, is an Ingres TCP/IP driver that used a
3rd-party TCP/IP stack. Prior to the days when Microsoft provided a
TCP/IP stack via the winsock interface, there were numerous vendors that
implemented TCP/IP on DOS and early Windows. I'm actually surprised it
works at all. The interface must have been a standard socket
implementation, which is why it still works at all (Windows has a
standard sockets interface plus winsock interface...latter highly
recommended and all we use anymore). This predates even the now
obsolete "wintcp" Ingres protocol driver. All that being said, I don't
have any real tips for what could be done to fix the performance.
Certainly, running a network trace would likely show where the delay is
occurring. You could also run an Ingres GCA trace on the Ingres 9.2
comsvr (iigcc) to see where the delay is occurring (connect, receiving
query, sending response). To set such a trace in Ingres 9.2, do the
following:
1. Add the following to config.dat:
ii.hostname.gcc.*.winsock2_trace_level 5
ii.hostname.gcc.*.gca_trace_level 5
ii.hostname.gcc.*.gca_trace_time 1
ii.hostname.gcc.*.gca_trace_log 'c:\somefilename'
where hostname is the hostname configured in your config.dat and
'c:\somefilename' is the path/filename where the output trace is to go.
TIP: Using RAMDISK as the target of the trace file will minimize the
impact that the tracing itself will have on performance.
2. Recycle the Ingres server (or at least iigcc).
3. Run your test from the slow environment and from the faster
environment and compare the trace results for the 2 runs. The GCA
entries in the trace will be timestamped.

Regards,
Bruce Lunsford (one of the Ingres/Net guys)


--
lunbr01

Karl Schendel wrote:
As long as you *know* the hostnames and ip addresses that the driver might
use, you don't need tcpdump(1) to confirm DNS is working. Running host(1)
for both the names and addresses on both the host and the client should
suffice.

The advantage of looking for traffic destined for port 53 is, obviously,
the possibility of finding out the name/address being resolved is not the
one expected.

Keep in mind, too, that DNS is not the whole story: /etc/hosts could have
an effect, too....

--jkl

Martin Bowes wrote:

Happily that's one of the first things he checked. The stats were
regenerated. Indices all present and accounted for.

But keep the ideas coming.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Put the date in your diary today.

Karl Schendel wrote:

Since I first posted the question it seems to have been narrowed down to
a problem just with the W4GL client talking to the new server.

Likewise.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Put the date in your diary today.

rhill (AT) hillconsult (DOT) com wrote:

Roger! Long time. Nice to hear from you.

WireShark is a tool I rate and keep handy on my key-ring flash drive but
I think the investigation is moving in a different direction now.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Put the date in your diary today.