Re: Large database help

On Mon, Apr 23, 2001 at 06:13:38PM -0400, xbdelacour@yahoo.com wrote:
> A smaller snippet:
>
> shmget(5432001, 400385024, IPC_CREAT|0x180|0600) = 2945
> shmget(5432001, 400385024, 0)           = 2945
> shmat(2945, 0, 0)                       = 0x40176000
>
> I'm no Unix expert, but this would seem to indicate that shmget is
> successfully allocating 400385024/1024/1024=381MB of shared memory. I don't
> know enough about how the postgres parent/child/shmem scheme works to know
> why this is working yet the children only register 12MB of shared memory
> under top.

I believe you're right that it allocates the memory (succesfully).

The reason top only show 12 MB shared memory may be that the process
haven't actually used the whole segment yet. (linux only allocates the
memory when it's first written to)

I suppose it could be that postgres doesn't write to the memory-segment,
because it doesn't need it. For read access to the file, the OS wil
cache the data anyway, and there is no need to use process memory to
access the file-data.

Maybe the whole shared-memory issue was a blind track - it should not be
related to disk activety in this case?

Note: some disk activety should be expected. Maybe postgresql updates
the log? Or at the very least it will update the atime timestamps for
the files everytime they're read. This shouldn't cause enough disk
activity to become a performance-problem, but if I remember your initial
post correctly, you indicated that one processor was fully saturated.

Maybe the problem is in fact related to locking and smp, and not related
to shared-memory and disk activity?



--
Ragnar Kjørstad