Postgres Pro
Downloads
Home   >   mailing lists

Really weird behaviour with 7.2 RC2 - Mailing list pgsql-hackers

From Christian Meunier
Subject Really weird behaviour with 7.2 RC2
Date
Msg-id 005c01c1ac0e$ba053e70$0200a8c0@hurrican
Whole thread Raw
Responses Re: Really weird behaviour with 7.2 RC2
List pgsql-hackers
Tree view
Hi,i re installed my server yesterday, upgrading mainly the os( RH 6.0 to RH7.2),Postgres 7.2b5 -> 7.2RC2 and some hardware.(raid controller)
 
I got like 30 000 visit / day with 2Millions hits.
 
the os is : RH 7.2, the cpu is an athlon 600MHz with 1.5Go SDRAM
got an Adaptec raid controller 3200S ( one array in raid 1 - 2x18Go IBM 10 000 rpm)
 
Top snapshot:
--------------------------------------------------------------------------------------------------------------------------------------------------------------
 
  4:41pm  up  2:43,  1 user,  load average: 62,01, 58,01, 48,15
262 processes: 230 sleeping, 32 running, 0 zombie, 0 stopped
CPU states: 15,4% user, 84,5% system,  0,0% nice,  0,0% idle
Mem:  1544452K av,  492688K used, 1051764K free,   62064K shrd,   36688K buff
Swap: 2096472K av,       0K used, 2096472K free                  171564K cached
 
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 3075 orion     18   0 14584  14M  2928 R     1,3  0,9   0:02 java
 3073 orion     17   0 14584  14M  2928 R     1,2  0,9   0:01 java
 3074 postgres  15   0 21864  21M 21156 R     1,2  1,4   0:02 postmaster
 3093 orion     18   0 14584  14M  2928 R     1,2  0,9   0:01 java
 1710 orion     17   0 77860  75M  2976 S     1,1  4,9   0:27 java
 3000 root      17   0  1184 1184   836 R     1,1  0,0   0:06 top
 3076 postgres  17   0 21192  20M 20516 R     1,1  1,3   0:01 postmaster
 3095 postgres  16   0 21696  21M 20996 R     1,1  1,4   0:01 postmaster
 2463 postgres  11   0 45404  44M 43936 S     1,0  2,9   0:29 postmaster
 1509 orion     12   0 77812  75M  2976 R     0,9  4,9   0:28 java
 1511 orion     11   0 77812  75M  2976 R     0,9  4,9   0:29 java
 1585 orion     18   0 77860  75M  2976 R     0,9  4,9   0:25 java
 2240 orion     13   0 77900  75M 65396 S     0,9  4,9   0:23 java
 2652 orion     11   0 77900  75M 63556 S     0,9  4,9   0:13 java
 2734 orion     20   0 77900  75M 55948 R     0,9  4,9   0:09 java
 3031 postgres  20   0 33344  32M 32188 R     0,9  2,1   0:03 postmaster
 3126 postgres  13   0 27988  27M 27300 S     0,9  1,8   0:00 postmaster
 2173 orion      9   0 77900  75M 65396 S     0,8  4,9   0:18 java
 2182 orion     12   0 77900  75M 65396 S     0,8  4,9   0:21 java
 2184 orion     14   0 77900  75M 65396 S     0,8  4,9   0:22 java
 2484 orion     10   0 77900  75M 63556 S     0,8  4,9   0:17 java
 2505 orion     11   0 77900  75M 63556 S     0,8  4,9   0:11 java
 2687 orion     10   0 77900  75M 55948 S     0,8  4,9   0:11 java
 2886 postgres  14   0 28032  27M 26520 S     0,8  1,8   0:09 postmaster
 2959 postgres  16   0 33128  32M 31984 R     0,8  2,1   0:04 postmaster
-----------------------------------------------------------------------------------------------------------------------------------------------------------
 
I was used to handle the load perfectly well and now its messy and i have no clue why.
The 2 things i have changed is the os: kernel 2.4.7-10 now and Postgresql 7.2RC2 instead of 7.2b5
 
I wonder why i have a system cpu state so high, leading to a very very high load average.
for this snapshot i started orion with no argument ( java -jar orion.jar)
As for postgres ( max backend set to the default 32):
    tcpip_socket = true
    shared_buffers = 16384
    sort_mem = 4096
    wal_buffers = 2048
    wal_files = 3
 
Atatched with this mail is the: ps -aux | grep postgres
 
First question looking at this list of process, how is possible to have such many backends with max backend set to 32 ?
 
the log from postgres:
 
DEBUG:  database system is shut down
DEBUG:  database system was shut down at 2002-02-02 13:35:26 GMT
DEBUG:  checkpoint record is at 0/71A93E4
DEBUG:  redo record is at 0/71A93E4; undo record is at 0/0; shutdown TRUE
DEBUG:  next transaction id: 358386; next oid: 339529
DEBUG:  database system is ready
DEBUG:  recycled transaction log file 0000000000000007
ERROR:  Cannot insert a duplicate key into unique index eq_perso_tradeskill_pkey
ERROR:  Cannot insert a duplicate key into unique index eq_perso_adv_pkey
FATAL 1:  cannot open /usr/local/pgsql/data/global/1262: Too many open files in system
FATAL 1:  cannot open /usr/local/pgsql/data/global/1262: Too many open files in system
 
 
 
If you have an idea of what is going on or how i could track down this issue..
 
Thx in advance
Best regards
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Per-database and per-user GUC settings
Next
From: Tom Lane
Date:
Subject: Re: Really weird behaviour with 7.2 RC2