Re: [pgsql-hackers-win32] scalability issues on win32 - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: [pgsql-hackers-win32] scalability issues on win32
Date
Msg-id 200411230226.iAN2Q6i25020@candle.pha.pa.us
Whole thread Raw
In response to scalability issues on win32  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-performance
This was an intersting Win32/linux comparison. I expected Linux to scale
better, but I was surprised how poorly XP scaled.  It reinforces our
perception that Win32 is for low traffic servers.

---------------------------------------------------------------------------

Merlin Moncure wrote:
> Following is the promised writeup in performance related issues
> comparing win32 with linux x86 and linux x86-64.  Unfortunately, the 64
> bit portion of the test is not yet completed and won't be for a bit.
> However there are some telling things about the win32/linux comparison.
> If you are considering deploying postgres in a win32 environment read
> on...
>
> First a description of the client app:
> Our company develops an ERP/CRM written in cobol which we are porting to
> run on PostgreSQL.  Part of this porting effort was development of an
> ISAM 'driver' for our app to allow it to store/fetch data from the
> database in place of a traditional file system, which is complete.
>
> For those of you unfamiliar with COBOL/ISAM, applications written with
> it have a 'one record at a time' mentality, such the application tends
> to spam the server with queries of the select * from t where k = k1
> variety.  Our driver creates stored procedures as necessary and uses
> ExecParams wherever possible to cut down on server CPU time, which is a
> precious resource in our case.  Over time we plan to gradually redeploy
> our application logic to make better use of the sql server's server side
> power.  Our application is very rarely i/o bound because we will make
> sure our server has enough memory so that the data will be rarely, if
> ever, *not* run from the cache.
>
> A good benchmark of our application performance is the time it takes to
> read the entire bill of materials for a product.  This is a recursive
> read of about 2500 records in the typical case (2408 in the test case).
>
> Test platform:
> Pentium 4 3.06 GHz/HT
> 10k SATA Raptor
> 1Gb memory
> Windows XP Pro SP2/Redhat Fedora 3 (64 bit results coming soon)
>
> BOM traversal for product ***** (1 user):
> win32: runtime: 3.34 sec  avg cpu load: 60%
> redhat: runtime: 3.46 sec  avg cpu load: 20%
>
> Well, win32 wins this test.  There is some variability in the results
> meaning for a single user scenario there is basically no difference
> between win32 and linux in execution time.  However the cpu load is much
> lower for linux which spells problems for win32 with multiple users:
>
> BOM traversal for product ***** (6 users):
> win32: runtime (each): 7.29 sec  avg cpu load: 100%
> redhat: runtime (each): 4.56 sec  avg cpu load: 90%
>
> Here, the win32 problems with cpu load start to manifest.  The cpu meter
> stays pegged at 100% while the redhat hand around 90%.  The difference
> in times is telling.
>
> The third and final test is what I call the query 'surprise' factor, IOW
> surprise! your query takes forever!  The test involves a combination of
> the previous test with a query with a couple of joins that returns about
> 15k records.  On both redhat/win32, the query takes about .35 seconds to
> execute on a unloaded server...remember that figure.
>
>
>
> Item List generation while 6 clients generating BOM for multiple
> products:
> Redhat: 2.5 seconds
> Win32: 155 seconds (!)
>
> Here the win32 server is showing real problems.  Also, the query
> execution time is really variable, in some cases not returning until the
> 6 workhorse processes completed their tasks.  The linux server by
> contrast ran slower but never ran over 4 seconds after multiple runs.
>
> Also, on the purely subjective side, the linux server 'feels' faster and
> considerably more responsive under load, even under much higher load.
>
> Comments/Suggestions?
>
> Merlin
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: memcached and PostgreSQL
Next
From: Josh Berkus
Date:
Subject: Re: Data type to use for primary key