On Tuesday July 11 2006 3:16 pm, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
