Re: troubleshooting 8.1.2

Поиск
Список
Период
Сортировка
От Ed L.
Тема Re: troubleshooting 8.1.2
Дата
Msg-id 200607151518.19358.pgsql@bluepolka.net
обсуждение исходный текст
Ответ на Re: troubleshooting 8.1.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Tuesday July 11 2006 3:16 pm, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > We are wondering if our swap space was too small, and when
> > the swap reservation failed, the OS was sending SIGINT??
>
> You'd have to check your OS documentation ...  I thought HPUX
> would just return ENOMEM to brk() for such cases.  It doesn't
> do memory overcommit does it?

ENOMEM is correct for our brk(), too.  We're running with
psuedoswap, but I guess our swapspace was too small, and appears
to be what we ran into.  The SIGINT is still a mystery.  Our
truss output for one of these SIGINTs is at the bottom of this
message, for what its worth.

BTW, here's a conversation of possible interest that conflicts
with advice I've heard here of keeping shared_buffers small
and letting the OS do all the caching.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1042336

Their argument appears
to be that there are HPUX kernel inefficiencies for OS caches
larger than 1.5gb.  You once argued that it would be unreasonable
to expect user-space shared memory to be any more efficient than
the kernel cache.  I don't know one way or the other, and
solid benchmarking that simulates our loads appears troublesome.
I guess I could write a little C program to measure shared
memory random access times as the size of the cache grows...

Anyway, here's the truss output:

( Attached to process 20787 ("postmaster -D /users/...") [64-bit] )
select(7, 0x9fffffffffffe670, NULL, NULL, 0x9fffffffffffe640)
                    [sleeping] 
  Received signal 2, SIGINT, in select(), [caught], no siginfo
sigprocmask(SIG_SETMASK, 0x60000000000708c0, NULL)
                    = 0 
gettimeofday(0x9fffffffffff9460, NULL)
                    = 0 
stat("/usr/lib/tztab", 0x9fffffffffff9300)
                    = 0 
open("/usr/lib/tztab", O_RDONLY|0x800, 01210)
                    = 9 
mmap(NULL, 13197, PROT_READ, MAP_PRIVATE, 9, 0)
                    = 0x9fffffffbb14c0 
00
close(9)
                    = 0 
write(2, "2 0 0 6 - 0 7 - 1 1   1 3 : 5 5 ".., 76)
                    = 76 
kill(20793, SIGUSR2)
                    = 0 
kill(20794, SIGQUIT)
                    = 0 
...

Ed

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: apparent wraparound
Следующее
От: "Ed L."
Дата:
Сообщение: Log actual params for prepared queries: TO-DO item?