So long and thanks for all the fish

Поиск
Список
Период
Сортировка
От Daryl W. Dunbar
Тема So long and thanks for all the fish
Дата
Msg-id 008501be64ea$7673ad90$1445e59b@ddunbar.eni.net
обсуждение исходный текст
Список pgsql-hackers
Thank you to each of you who helped me with my PostgreSQL and
Solaris7 troubles.  A special thank you goes out to Marc Fournier,
Tatsuo Ishii and especially Tom Lane, without whom I would have lost
what is left of my mind.

After much research, it was determined that the primary cause of my
distress was incomplete transactions.  Coding in perl and using
DBI/DBD seems to encapsulate every command (including SELECTs) in a
transaction.  Apparently we were abandoning the transactions,
leaving the database to rollback, but not until after holding the
lock for a very long time.  Given the lock-happy behavior of the
current release, this made the database basically unusable under any
load.  As a matter of fact, a single insert amid dozens of queries
could throw the backend so far out to lunch that it never recovers
and had to be restarted.  We closed those holes and even tried every
other access method available in DBI/DBD.  Unfortunately, in a
benchmark, MySQL still outperformed PostgreSQL by such:

One Minute trial, 60 readers, one writer:
Each reader attempts to retrieve ten rows:            mysql        pgsql
# of inserts performed  19,000    26
# of random seek reads  4,000        7

Not to say this was the only error.  We still saw lots and lots of
this behavior:

Feb 28 13:17:19 constantinople POSTMASTER:
Feb 28 13:17:19 constantinople POSTMASTER: FATAL: s_lock(ef68004d)
at
spin.c:125, stuck spinlock. Aborting.

Which leads me to think there are still some aberrant IPC issues
lurking in Solaris7.  I'm not sure if any of you are aware, but Sun
went back to sockets and away from streams in the 2.6-2.7 upgrade.
This fact alone could count for some of the behavior we have seen.
When we reproduced our problem on Linux, we did not see any of the
stuck spinlock messages.

I know the new locking methods will improve this greatly, but for
what we hope will be one of the busiest portals on the Internet,
speed is very important.  We have taken our database portion of the
site down in order to port to MySQL.  <Sigh>  A sad move on my part,
now that I know PostgreSQL so well.

Thank you all again, be well.  See you all on the flip side...

DwD
--
Daryl W. Dunbar
VP of Engineering/Chief Technology Officer
http://www.com, Where the Web Begins!
mailto:daryl@www.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vadim Mikheev
Дата:
Сообщение: Re: [HACKERS] copyObject() ? again
Следующее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] NUMERIC and Perl