Skip site navigation (1) Skip section navigation (2)

Re: RES: pg_dump slow

From: Ron <rjpeace(at)earthlink(dot)net>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Franklin Haut" <franklin(dot)haut(at)gmail(dot)com>
Subject: Re: RES: pg_dump slow
Date: 2005-12-01 01:14:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
At 05:13 PM 11/30/2005, Merlin Moncure wrote:
> > By default W2K systems often had a default TCP/IP packet size of 576B
> > and a tiny RWIN.  Optimal for analog modems talking over noisy POTS
> > lines, but horrible for everything else
>wrong. default MTU for windows 2000 server is 1500, as was NT4.
LOL.  Good to see it is now.  I got bit by the problem when it wasn't.

>However tweaking rwin is certainly something to look at.
> > >If you're happy that doesn't affect you then I'd look at the disk
> > >system - perhaps XP has newer drivers than Win2k.
> > I'll reiterate: Do _not_ run a production DB server on W2K.  M$ has
> > obsoleted the platform and that it is not supported _nor_ any of
> > reliable, secure, etc. etc.
>wrong again. WIN2k gets free security hotfixes and paid support until

I've _lived_ what I'm talking about.  I've built some of the largest 
M$ installations in existence at the time of their deployment.

Type of Support Availability
    * Paid-per-incident support
    * Free hotfix support
June 30, 2005
    * Hourly support
    * Paid hotfix support
June 30, 2010
Security hotfixes Free to all customers through March 31, 2010

 From your own source.  And good luck getting M$ to give you free 
support for anything except what _They_ consider to be Their Fault 
without paying them a boatload of $$$$.  The standard M$ party line 
at this point is "Upgrade, Upgrade, Upgrade.  ...Or pay us so much 
$$$$ to do it that we feel it makes economic sense for M$ to Play Ball".

> > A W2K based DB server, particularly one with a connection to the
> > Internet, is a ticking time bomb at this point.
> > Get off W2K as a production platform ASAP.  Take to your
> > CEO/Dean/whatever you call your Fearless Leader if you have to.
>wrong again!!  There is every reason to believe win2k is *more* secure
>than win2003 sever because it is a more stable platform.  This of course
>depends on what other services are running, firewall issues, etc etc.
You evidently do not have a very serious background in network or 
systems security or professional experience would tell you that your 
above sentence is dangerously misguided.

Reality is that platforms stay marginally secure _only_ by constant 
patching of newly discovered exploits and never ceasing vigilance 
looking for new exploits to patch.  Regardless of platform.

Obsoleted platforms are at greater risk because the White Hats are no 
longer paying as much attention to them and the Black Hats are 
basically opportunistic parasites.  They play with anything and 
everything they can get their hands on in the hopes of finding 
exploitable security flaws.

> >> Economically and probably performance wise, it's best to use an Open
> > Source OS like Linux or *BSD.  However, if you must use M$, at least
> > use OS's that M$ is actively supporting.
>I encourage use of open source software.  However encouraging other
>people to spontaneously switch hardware/software platforms (especially
>when they just stated when win2k is a requirement) is just or at least
>not helpful.
> > Despite M$ marketing propaganda and a post in this thread to the
> > contrary, you =CAN= often run a production DB server under WinXP and
> > not pay M$ their usurious licensing fees for W2003 Server or any of
> > their other products with "server" in the title.  How much RAM and
>you are on a roll here.  You must not be aware of 10 connection limit
>for win2k pro and winxp pro.
I'm excruciatingly aware of the 10 connection limit AND how stupid it 
is.  It's one of the reasons, along with what M$ thought they could 
get away with charging to increase it, M$ got thrown out of my server rooms.

Also, we are talking about a _DB_ server.  Not a web server or some 
other function that deals with relatively light load per 
connection.  Just how many open active DB connections do want active 
concurrently?  Not Many.  Once all the HW is being utilized to full 
capacity, DBs get best performance by being asked to do as little as 
possible concurrently beyond that.

Long before you will want more than 10 active open DB connections 
banging on modest HW you are going to want a queuing system in front 
of the DB in order to smooth behavior.    By the time you _really_ 
need to support lots of open active DB connections, you will in a 
position to spend more money (and probably will have to on both 
better HW and better SW).

>There are hackerish ways of getting around this which are illegal.
>Cheating to get around this by pooling connections via tcp proxy for
>example is also against EULA (and, in my opinion, unethical).
I'm sorry you evidently feel your income stream is threatened, but 
there is no way that is either immoral or illegal for anyone to use 
the industry standard layered architecture of having a DB connection 
layer separate from a Queuing system.   M$MQ is provided 
_specifically_ for that use.

Certainly "twiddling the bits" inside a M$ OS violates the EULA, and 
I'm not advocating anything of the kind.

OTOH, that Draconian EULA is yet _another_ reason to get rid of M$ 
OS's in one's organization.  When I buy something, it is _mine_.  You 
can tell me you won't support it if I modify it, but it's the height 
of Hubris to tell me that I'm not allowed to modify SW I paid for and 
own.  Tell your managers/employers at M$ that Customer Service and 
Respecting Customers =keeps= customers.  The reverse loses them.  Period.

> > how many CPUs you want in your DB server is the main issue.  For a
> > 1P, <= 4GB RAM vanilla box, WinXp will work just fine.
>Now, who is guilty of propaganda here?

There is no propaganda here.  The statement is accurate in terms of 
the information given.  The biggest differentiations among M$ 
licenses is the CPU and RAM limit.

>Also, your comments regarding hard disks while correct in the 
>general sense are not helpful.  This is clearly not a disk bandwidth problem.
As Evidenced By?  His IO numbers are p*ss poor for any reasonable 
RAID setup, and 375KBps is bad even for a single HD.  He's claiming 
this is local IO, not network, so that possibility is out.  If you 
feel this is "clearly not a disk bandwidth problem", I fail to see 
your evidence or your alternative hypothesis.

> > >What do the MS performance-charts show is happening? Specifically,
> > >CPU and disk I/O.
> > His original post said ~3% CPU under W2K and ~70% CPU under WinXP
>Slow performance in extraction of bytea column strongly suggests tcp/ip.
>issue.  I bet if you blanked out bytea column pg_dump will be fast.
>Franlin: are you making pg_dump from local or remote box and is this a
>clean install?  Try fresh patched win2k install and see what happens.
He claimed this was local, not network.  It is certainly an 
intriguing possibility that W2K and WinXP handle bytea 
differently.  I'm not competent to comment on that however.


In response to


pgsql-performance by date

Next:From: Ralph MasonDate: 2005-12-01 01:17:06
Subject: Query is 800 times slower when running in function!
Previous:From: Merlin MoncureDate: 2005-11-30 22:13:08
Subject: Re: RES: pg_dump slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group