probs with postgres

Started by Christopher Kings-Lynnealmost 23 years ago4 messages
#1Christopher Kings-Lynne
chriskl@familyhealth.com.au

I keep getting this:

2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3196 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3197 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3198 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3199 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3200 -
fixing

What could be causing it?

It occurs during Vacuum I think. We have been having a lot of load problems
with Postgres since we launched our new site a day ago and now this problem
has cropped up. users_sessions is probably our most-written row.

Postgres 7.3.2.

Chris

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christopher Kings-Lynne (#1)
Re: probs with postgres

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing

Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2 problem:

http://fts.postgresql.org/db/mw/msg.html?mid=1357214

regards, tom lane

#3Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Christopher Kings-Lynne (#1)
Re: probs with postgres

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page

3195 -

fixing

Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2 problem:

http://fts.postgresql.org/db/mw/msg.html?mid=1357214

OK, well I can tell you this at the moment:

1. We're running 7.3.2
2. We do an hourly VACUUM ANALYZE. I do the odd VACUUM FULL (not on that
table) when I do large changes to tables.
3. users_sessions has heaps and heaps of reads and updates regular scan
deletes. There are lots of SELECT..FOR UPDATEs done on the table
4. Table def:

usa=# \d users_sessions
Table "public.users_sessions"
Column | Type | Modifiers
---------+--------------------------+------------------------
sid | character varying(32) | not null
name | character varying(32) | not null
val | text |
changed | timestamp with time zone | not null default 'now'
uid | integer | not null
Indexes: users_sessions_pkey primary key btree (sid, name),
users_sessions_cha_name_idx btree (changed, name),
users_sessions_uid_idx btree (uid)

5. We have been having load and stability problems with our Postgres since
we released a massive upgrade to our website. We did actually have one time
when Postgres crashed and the whole server rebooted when we got a bunch of
these:

Mar 20 09:25:54 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
Mar 20 09:27:09 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
Mar 20 09:28:29 serendipity last message repeated 2 times
Mar 20 09:29:42 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC

So I reduced our shared buffers by a few thousand and I'm waiting on our
sysadmin to up the max pages per proc in the kernel.

Any ideas on anything I can look into?

Chris

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christopher Kings-Lynne (#3)
Re: probs with postgres

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

5. We have been having load and stability problems with our Postgres since
we released a massive upgrade to our website. We did actually have one time
when Postgres crashed and the whole server rebooted when we got a bunch of
these:

Mar 20 09:25:54 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC

[blink...] Perhaps you should be asking hard questions about the
stability of your kernel. What are you running, anyway?

This is not to say that Postgres might not have its own problems --- but
Postgres is an unprivileged process. If your kernel is crashing, it is
not Postgres that's broken.

regards, tom lane