Re: Large database help

Поиск
Список
Период
Сортировка
От xbdelacour@yahoo.com
Тема Re: Large database help
Дата
Msg-id 5.0.2.1.0.20010423180546.02ad3a40@pop.mail.yahoo.com
обсуждение исходный текст
Ответ на Re: Large database help  (Ragnar Kjørstad <postgres@ragnark.vestdata.no>)
Ответы Re: Large database help  (Ragnar Kjørstad <postgres@ragnark.vestdata.no>)
Re: Large database help  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Below are snippets from:

strace postmaster -i -D `pwd` -B 48000

A large snippet:
.
.
.
socket(PF_UNIX, SOCK_STREAM, 0)         = 4
bind(4, {sun_family=AF_UNIX, sun_path="/tmp/.s.PGSQL.5432"}, 20) = 0
listen(4, 128)                          = 0
chmod("/tmp/.s.PGSQL.5432", 0777)       = 0
shmget(5432010, 144, IPC_CREAT|0x1c0|0600) = 2944
shmat(2944, 0, 0)                       = 0x40014000
shmget(5432001, 400385024, IPC_CREAT|0x180|0600) = 2945
shmget(5432001, 400385024, 0)           = 2945
shmat(2945, 0, 0)                       = 0x40176000
brk(0x81b7000)                          = 0x81b7000
mmap(0, 192512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x57f4d000
brk(0x81c3000)                          = 0x81c3000
mmap(0, 577536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x57f7c000
mmap(0, 3076096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x58009000
brk(0x81cf000)                          = 0x81cf000
semget(5432014, 0, 0)                   = -1 ENOENT (No such file or directory)
semget(5432014, 16, IPC_CREAT|0x180|0600) = 1792
semctl(1792, 0, SETALL, 0xbffff750)     = 0
semget(5432015, 0, 0)                   = -1 ENOENT (No such file or directory)
semget(5432015, 16, IPC_CREAT|0x180|0600) = 1793
semctl(1793, 0, SETALL, 0xbffff750)     = 0
shmget(5432007, 0, 0)                   = -1 ENOENT (No such file or directory)
shmget(5432007, 66060, IPC_CREAT|0x180|0600) = 2946
shmat(2946, 0, 0)                       = 0x582f8000
getpid()                                = 2909
open("/home/mg/pgsql/postmaster.pid", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
write(5, "2909", 4)                     = 4
close(5)                                = 0
open("/home/mg/pgsql/postmaster.opts", O_RDWR|O_CREAT|O_TRUNC, 0600) = 5
.
.
.

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 do need to get this to work however, and firing up a debugger is becoming
my only option rather quickly..

-Xavier

At 06:15 PM 4/23/01 +0200, Ragnar Kjørstad wrote:
>On Sun, Apr 22, 2001 at 06:52:26PM -0400, xbdelacour@yahoo.com wrote:
> > I'm spawning 6 backends to query the data. top lists 6 postmaster
> processes
> > working, and therefore the idle time should hit 0% easily. Also, the hard
> > drive light goes nuts when I'm running this.
> >
> > Here is the pertinent information from top. To be clear, I'm NOT
> spawning a
> > new postmaster per chunk. These same six processes are alive and kicking
> > for over 4 minutes.
> >
> > I hope the formatting works ok.
> >
> >    PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
> >   2379 mg        13   0 14476  14M 12908 S       0  5.8  2.7   0:01
> postmaster
> >   2380 mg        10   0 14436  14M 12868 S       0  2.9  2.7   0:01
> postmaster
> >   2381 mg        10   0 13572  13M 12012 S       0  2.9  2.6   0:00
> postmaster
> >   2377 mg        10   0 13640  13M 12072 S       0  2.4  2.6   0:01
> postmaster
> >   2378 mg        11   0 14476  14M 12908 S       0  2.4  2.7   0:01
> postmaster
> >   2376 mg         8   0 13556  13M 11984 S       0  1.9  2.6   0:00
> postmaster
>
>The processes should have ~ 400M shared memory, not ~ 10M, right?
>stracing (or maybe just running with debugging enabled) should tell you
>what went wrong. My first guess is that the OS is not able to provide a
>single 400M block of memory, and postgres falls back to some lower
>setting.
>
>You could also verify this by writing a small program that just
>allocates different sizes of shared memory, and see what the biggest
>size you can allocate is.
>
>
>
>--
>Ragnar Kjørstad


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Предыдущее
От: Jie Liang
Дата:
Сообщение: Re: Connecting via perl gives "root" does not exist
Следующее
От: xbdelacour@yahoo.com
Дата:
Сообщение: Re: Large database help