Thread: Extraordinarily slow!!
I'm running postgresql 8.03 under Gentoo Linux and find that all actions take at least a MINUTE (even dropdb and createdb). During this time, the posgres account is locked up to the extent that one cannot even su to it. (The su suceeds when the db operation completes.) I assume something is misconfigured and Postgres is waiting for something with each action I perform and then timing out. Unfortunately, the system is unusable in this form... It's also interesting that the actions eventually complete properly --- they just take an incredibly long time. I ran the same version of postgres under FreeBSD and it was lightning fast. No error messages appear in any of the logs --- just the normal messages one expects. Any suggestions?
"Justin R. Smith" <jsmith@drexel.edu> writes:
> I'm running postgresql 8.03 under Gentoo Linux and find that all actions
> take at least a MINUTE (even dropdb and createdb). During this time, the
> posgres account is locked up to the extent that one cannot even su to
> it. (The su suceeds when the db operation completes.)
Bizarre.
> Any suggestions?
Don't use Gentoo? Seriously, that distribution is completely
unsupportable because no one else has the faintest idea what you are
really running. You've probably got some system component that is
either broken in itself or incompatible with some other component,
but there's no way to tell which.
regards, tom lane
> >Bizarre. > Question: Does the problem happen when you just type psql? What if you pass the host option? e.g; psql -h 127.0.0.1 What type of auth are you running? >Don't use Gentoo? Seriously, that distribution is completely >unsupportable because no one else has the faintest idea what you are >really running. You've probably got some system component that is >either broken in itself or incompatible with some other component, >but there's no way to tell which. > I would have to agree with Tom here. Gentoo is a great development machine and a fun toy but if you don't want unknowns in your environment and Gentoo will easily introduce them. You really should look at something like Fedora Core or Ubuntu if you want FREE. If you don't mind paying the SuSE is a good choice. If you want RHE look and feel but don't want to pay, look at CentOS. Sincerely, Joshua D. Drake > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 5: don't forget to increase your free space map settings > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Tom Lane wrote: >"Justin R. Smith" <jsmith@drexel.edu> writes: > > >>I'm running postgresql 8.03 under Gentoo Linux and find that all actions >>take at least a MINUTE (even dropdb and createdb). During this time, the >>posgres account is locked up to the extent that one cannot even su to >>it. (The su suceeds when the db operation completes.) >> >> > >Bizarre. > > > >>Any suggestions? >> >> > >Don't use Gentoo? Seriously, that distribution is completely >unsupportable because no one else has the faintest idea what you are >really running. You've probably got some system component that is >either broken in itself or incompatible with some other component, >but there's no way to tell which. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 5: don't forget to increase your free space map settings > > > > I have been running Postgresql on Gentoo for several years and it works great, better than RH EL. You must have seriously messed up your install somehow. I suggest you install on a clean system. Did you fool around with the Kernel scheduler by chance? Right out of the box Gentoo works very well. I highly recommend Gentoo, the trick for a server install is just to use the base system, don't install unneeded desktop managers etc. I have current uptimes of 250+ days on all my Gentoo boxes and we import and update 350,000 records every day for a large financial application that uses 8.03 as the backend. You did increase the kernels shared memory right, and properly setup your postgresql.conf file for performance? Are you using the autovaccum daemon? There are a few guides available on how to setup your postgresql.conf file for performance, just do a search on google. Tony Caduto AM Software Design Home of PG Lightning Admin (PGLA) http://www.amsoftwaredesign.com
Tom Lane wrote: > Don't use Gentoo? Seriously, that distribution is completely > unsupportable because no one else has the faintest idea what you are > really running. You've probably got some system component that is > either broken in itself or incompatible with some other component, > but there's no way to tell which. I'm not looking to start a distro war, but we're successfully running postgres on Gentoo on a handful of machines, both Intel and AMD, without trouble. I suppose compiling by hand from source is equally unsupportable. As for not knowing what's running, it's fairly trivial to deduce the compile time options based on USE flags. Heck, you've even got full compile/install logs if you want them... Just saying. ;) -- Peter Fein pfein@pobox.com 773-575-0694 Basically, if you're not a utopianist, you're a schmuck. -J. Feldman
Joshua D. Drake wrote: > >> >> Bizarre. >> > Question: > > Does the problem happen when you just type psql? > What if you pass the host option? e.g; psql -h 127.0.0.1 > What type of auth are you running? > >> Don't use Gentoo? Seriously, that distribution is completely >> unsupportable because no one else has the faintest idea what you are >> really running. You've probably got some system component that is >> either broken in itself or incompatible with some other component, >> but there's no way to tell which. >> > I would have to agree with Tom here. Gentoo is a great > development machine and a fun toy but if you don't want > unknowns in your environment and Gentoo will easily introduce > them. > > You really should look at something like Fedora Core or Ubuntu > if you want FREE. If you don't mind paying the SuSE is a good choice. > If you want RHE look and feel but don't want to pay, look at CentOS. > > Sincerely, > > Joshua D. Drake I guess I would agree for a Linux Newbie, but the only unknowns are those that the user would introduce. Like I said before Gentoo makes a extremely stable and powerful OS, but it must be setup properly, and in my experience if you follow the install docs and don't mess around with things like the kernel scheduler and what not Postgresql runs extremely well and is super easy to update with the Portage emerge. Later, Tony
You really should look at something like Fedora Core or Ubuntu > if you want FREE. If you don't mind paying the SuSE is a good choice. > If you want RHE look and feel but don't want to pay, look at CentOS. > > Sincerely, > > Joshua D. Drake > >> >> > > Just as a FYI, you don't have to pay for Suse anymore, unless you want support: http://www.opensuse.org The 10.0 release will be next month. -- Tony Caduto http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql 8.x
"Justin R. Smith" <jsmith@drexel.edu> writes:
> I've solved the problem.
> I was accessing Postgres over an ssh connection and had enabled X
> forwarding in the sshd server (not the default configuration). For
> reasons that pass understanding, psql attempts to establish an X
> connection with EACH elementary operation it performs (unless no such
> connection is possible). It doesn't actually USE this X connection for
> anything as far as I know, but the attempt to make the connection over a
> slow communication line creates an enormous delay,
> Reconfiguring the sshd server to NOT forward X connections solved the
> problem. Database operations take fractions of a second now...
> Interestingly, it does NOT help to have X forwarding turned off only in
> the client: sshd itself must not do any forwarding.
[ scratches head... ] That makes no sense at all. psql doesn't even
know what X is, let alone try to open X connections for every database
operation.
Is it conceivable that the openssl library would do this? That would
seem pretty broken too.
How are you using ssh to access the database, exactly? Is psql running
through a tunnel port, or what? What versions of ssl/ssh at each end of
the connection?
regards, tom lane
On Tue, Sep 27, 2005 at 09:38:46AM -0400, Tom Lane wrote: > "Justin R. Smith" <jsmith@drexel.edu> writes: > > Interestingly, it does NOT help to have X forwarding turned off only in > > the client: sshd itself must not do any forwarding. > > [ scratches head... ] That makes no sense at all. psql doesn't even > know what X is, let alone try to open X connections for every database > operation. What's the PAGER? The only thing I can think of is that the pager is some program that tries to detect if it can launch an X viewer instead of less... > How are you using ssh to access the database, exactly? Is psql running > through a tunnel port, or what? What versions of ssl/ssh at each end of > the connection? And the value of the PAGER variable and where it points to if it's a link. -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
Tom Lane wrote: >"Justin R. Smith" <jsmith@drexel.edu> writes: > > >>I've solved the problem. >> >> > > > >>I was accessing Postgres over an ssh connection and had enabled X >>forwarding in the sshd server (not the default configuration). For >>reasons that pass understanding, psql attempts to establish an X >>connection with EACH elementary operation it performs (unless no such >>connection is possible). It doesn't actually USE this X connection for >>anything as far as I know, but the attempt to make the connection over a >>slow communication line creates an enormous delay, >> >> Now this was happening with external commands like create_user and create_db? If so, I would expect you have a really weird library issue. In this case, a stack trace on a hung process might be very informative. If not, check your PAGER settings (I find that although I normally prefer less, more is better in this case). > > > >>Reconfiguring the sshd server to NOT forward X connections solved the >>problem. Database operations take fractions of a second now... >> >> It still seems likely that you will want to track this down in case something else is wrong that you only discover later. > > > >>Interestingly, it does NOT help to have X forwarding turned off only in >>the client: sshd itself must not do any forwarding. >> >> > >[ scratches head... ] That makes no sense at all. psql doesn't even >know what X is, let alone try to open X connections for every database >operation. > >Is it conceivable that the openssl library would do this? That would >seem pretty broken too. > > > Something is broken. That is for sure. And it probably isn't PostgreSQL.... >How are you using ssh to access the database, exactly? Is psql running >through a tunnel port, or what? What versions of ssl/ssh at each end of >the connection? > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > > > >