Thread: 'Fastest' PC's are slowest in the house
I have five PC's accessing a PG database that is mounted on a Dell Windows 2003 server. The PC's are accessing the database with a Fujitsu cobol program via ODBC (all machines have same (newest) ODBC driver from PG). 2 of the machines are the newest I have and both pretty identically configured but are very slow by comparison to the others. My colleagues and I are still in the exploration / decision process, we have been working with and learning the database about 2 months.
I'm looking to see if anyone knows of O/S or hardware issues right off the bat or can recommend a debug method, log checking, etc. path we might follow.
The program in question reads the PG database and displays matching query results on a cobol screen, for the point of this topic that is all it is doing. We run the same query from each PC which returns 15 records out of a 6,000 record customer DB.
The machines:
- 2 are 2.0 Ghz Dells with 512 Ram & XP SP2 - they take just over 2 minutes
- 1 AMD 2.4 with 256 Ram & XP SP2 - just under 2 secs.
- 1 AMD 900 Mhz with 256 Ram & XP SP 1 - just under 2 secs
- 1 Intel 266 Mhz with 256 Ram & Windows 2000 - 11-13 secs
Thanks,
Justin Davis
Rapid Systems, Inc.
800.356.8952
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 5/30/2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justin Davis wrote: | I have five PC's accessing a PG database that is mounted on a | Dell Windows 2003 server. The PC's are accessing the database with a | Fujitsu cobol program via ODBC (all machines have same (newest) ODBC | driver from PG). 2 of the machines are the newest I have and both | pretty identically configured but are very slow by comparison to the | others. My colleagues and I are still in the exploration / decision | process, we have been working with and learning the database about 2 months. | | I'm looking to see if anyone knows of O/S or hardware issues right off | the bat or can recommend a debug method, log checking, etc. path we | might follow. | | The program in question reads the PG database and displays matching | query results on a cobol screen, for the point of this topic that is all | it is doing. We run the same query from each PC which returns 15 | records out of a 6,000 record customer DB. | | The machines: | | - 2 are 2.0 Ghz Dells with 512 Ram & XP SP2 - they take just over 2 minutes | - 1 AMD 2.4 with 256 Ram & XP SP2 - just under 2 secs. | - 1 AMD 900 Mhz with 256 Ram & XP SP 1 - just under 2 secs | - 1 Intel 266 Mhz with 256 Ram & Windows 2000 - 11-13 secs | Hello, Justin. While re-reading your post, I was (still) under the impression that those machines are all client machines and that there is only one database they are all accessing. Is my impression true? If so, then I'm afraid there must be some other issue you've been hitting, because from the viewpoint of a postmaster, it is completely irrelevant who the client is. Unless so, can you please provide some evidence that the issue at hand really has to do with the PostgreSQL query shipping to those Dells (profiling, for example), so we have something to work from? My assertion though is that there's either an issue in the ODBC layer, or the COBOL program you're running (be it your code or the runtime). While at it, and completely unrelated, I'm not sure that, both from the performance and reliability viewpoint, running production PostgreSQL on a Windows machine may be the best possible decision. If you have the luxury of experimenting, and unless your side-goal is to run-proof the Windows version of PostgreSQL, I'd suggest you try a couple of alternatives, such as Linux, BSD or even Solaris, whichever you feel will offer you better future support. If you choose to run it on Windows afterall, I'd kindly advise you to do your best to stay on the safe side of the story with a double-checked backup strategy, solely because the Windows version of PostgreSQL is a new product and not widely used in production environments, so there is not much expertise yet in the specifics of keeping it performant, stable and most of all, how to tackle things after the worst has happened. Kind regards, - -- Grega Bremec gregab at p0f dot net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCnqfgfu4IwuB3+XoRApSRAJ0aJYEIEnJZlw2TeLtSO/1+qmoLHACbBAjS LahS3A/YMgVthkvnQ3AJcXg= =Cl6f -----END PGP SIGNATURE-----