From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: troubleshooting 8.1.2 |
Date: | 2006-07-15 21:18:19 |
Message-ID: | 200607151518.19358.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday July 11 2006 3:16 pm, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ed L. | 2006-07-15 21:29:56 | Log actual params for prepared queries: TO-DO item? |
Previous Message | Joshua D. Drake | 2006-07-15 17:14:55 | Re: apparent wraparound |