core file found...

A core file was also found in postgres's Home directory

regds
mallah.

On Friday 10 May 2002 05:13 pm, Rajesh Kumar Mallah. wrote:
> Hi
> my postmaster died just now,
>
> only a bunch of backends running
>
> [rmallah(at)server rmallah]$ psql -h 130.94.22.209 -U tradein
> tradein_clients psql: could not connect to server: Connection refused
> Is the server running on host 130.94.22.209 and accepting
> TCP/IP connections on port 5432?
> [rmallah(at)server rmallah]$
>
> output of ps
> ============
>
> [root(at)linux10320 root2]# ps auxwww| grep post
> postgres 5598 0.0 0.0 140412 4 ? D May07 2:31 postgres:
> stats buffer process
> postgres 5599 1.1 0.0 142396 20 ? R May07 48:48 postgres:
> stats collector process
> postgres 12262 0.0 0.0 238712 4 ? D May09 0:19 postgres:
> tradein tradein_clients 130.94.20.27 SELECT
> postgres 13039 0.0 0.0 139812 4 ? D May09 0:00 postgres:
> checkpoint subprocess
> postgres 29440 0.0 0.8 140664 9256 ? S 14:35 0:01 postgres:
> tradein tradein_clients 203.196.129.235 idle
> postgres 6805 0.0 0.0 140196 4 ? S 16:08 0:00 postgres:
> tradein tradein_clients 203.196.129.235 idle
> postgres 10154 0.0 0.0 140196 4 ? S 16:38 0:00 postgres:
> tradein tradein_clients 203.196.129.235 idle
> postgres 10446 0.0 0.0 140164 4 ? S 16:43 0:00 postgres:
> postgres tradein_clients 203.196.129.235 idle
> [root(at)linux10320 root2]#
>
> =============
> output of top
> =============
> 5:29pm up 3 days, 24 min, 4 users, load average: 5.68, 5.61, 5.70
> 54 processes: 52 sleeping, 2 running, 0 zombie, 0 stopped
> CPU states: 5.8% user, 44.3% system, 0.0% nice, 49.8% idle
> Mem: 1028484K av, 900084K used, 128400K free, 0K shrd, 2968K
> buff Swap: 971004K av, 99288K used, 871716K free
> 857220K cached
>
> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
> 5599 postgres 17 0 2064 20 20 R 0 99.9 0.0 53:25
> postmaster 5598 postgres 9 0 1440 4 4 D 0 0.0 0.0
> 2:31 postmaster 12262 postgres 9 0 88564 4 4 D 0 0.0 0.0
> 0:19 postmaster 13039 postgres 9 0 656 4 4 D 0 0.0
> 0.0 0:00 postmaster 29440 postgres 9 0 10512 9256 9256 S 0
> 0.0 0.8 0:01 postmaster 6805 postgres 9 0 972 4 4 S 0
> 0.0 0.0 0:00 postmaster 10154 postgres 9 0 968 4 4 S
> 0 0.0 0.0 0:00 postmaster 10446 postgres 9 0 964 4 4 S
> 0 0.0 0.0 0:00 postmaster
> ==========================================================================
>
> On Friday 10 May 2002 04:18 pm, Jan Wieck wrote:
> > Rajesh Kumar Mallah. wrote:
> > > Hi Folks,
> > > please help ,
> > >
> > > therse seems to be too much lag between the access collector
> > > and system status. even the pids of backend does not seems to be
> > > matching.
> >
> > The delay is on average 250 milliseconds for a busy database
> > (1/4 second). The controlling definition is in
> >
> > src/include/pgstat.h:
> > #define PGSTAT_STAT_INTERVAL 500
> >
> > This means, from the moment ANY statistic packet has arrived
> > in the collector, it waits 500 milliseconds before writing
> > out all information. Thus, the above 250 milliseconds
> > average is only true assuming a constant flow of packets.
> >
> > And, before you discover this one: The backends send their
> > statistic collection information via UDP packets. In the case
> > of heavy database load, some of these packets can get lost so
> > that the statistics will not be 100% accurate. This is a
> > wanted feature and implemented on purpose! It is because
> > counting the number of scans isn't considered as much
> > important as responding to the client as fast as possible
> > during the rushhour.
> >
> >
> > Jan
> >
> > > tradein_clients=# SELECT pg_stat_get_backend_pid(s.backendid) AS
> > > procpid, pg_stat_get_backend_activity(s.backendid) AS current_query
> > > FROM (SELECT pg_stat_get_backend_idset() AS backendid) s;
> > >
> > > procpid | current_query
> > > ---------+-------------------------------
> > > 27134 | <IDLE> in transaction
> > > 26958 | <IDLE> in transaction
> > > 26953 | <IDLE> in transaction
> > > 26960 | <IDLE> in transaction
> > > 27008 | <IDLE> in transaction
> > > 12839 | <IDLE>
> > > 26977 | <IDLE> in transaction
> > > 27012 | <IDLE> in transaction
> > > 31354 | <IDLE>
> > > 27014 | <IDLE> in transaction
> > > 27015 | <IDLE> in transaction
> > > 26978 | <IDLE> in transaction
> > > 26985 | <IDLE> in transaction
> > > 27135 | select count(*) from ( select distinct on (email_id)
> > > email_id,email,contact from email_bank a join (select email_id from
> > > email_export_category where category_id in (1, 2, 3, 4, 5, 6, 7, 8, 9,
> > > 10, 12, 14, 16, 17, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 1
> > > 12262 | SELECT source_id , cnt from (SELECT
> > > source_id,count(source_id) as cnt from email_source group by source_id
> > > ) subsel join sources
> > > using(source_id) order by source_id
> > > 27136 | <IDLE> in transaction
> > > (16 rows)
> > >
> > >
> > >
> > > tradein_clients=#
> > > why does the above not match with the "top" output at
> > > the same time:
> > >
> > > =======================================================================
> > >== ===== 4:10pm up 2 days, 23:06, 2 users, load average: 6.21, 6.06,
> > > 5.60 69 processes: 66 sleeping, 3 running, 0 zombie, 0 stopped
> > > CPU states: 55.6% user, 2.0% system, 0.0% nice, 42.3% idle
> > > Mem: 1028484K av, 980320K used, 48164K free, 0K shrd,
> > > 3744K buff Swap: 971004K av, 102532K used, 868472K free
> > > 912724K cached
> > >
> > > PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME
> > > COMMAND 5456 postgres 17 0 59456 57M 57156 R 0 99.1 5.7
> > > 3:12 postmaster 6601 postgres 9 0 79964 77M 78328 S 0 3.3
> > > 7.7 0:01 postmaster 6779 postgres 9 0 88412 86M 86752 S 0
> > > 1.9 8.5 0:00 postmaster 6703 postgres 9 0 81668 79M 80276 S
> > > 0 1.7 7.9 0:01 postmaster 6943 postgres 9 0 78732 76M 77520 S
> > > 0 1.7 7.6 0:01 postmaster 6940 postgres 9 0 44180 42M 42668 S
> > > 0 0.5 4.2 0:00 postmaster 6776 postgres 9 0 121M 121M 119M S
> > > 0 0.3 12.0 0:01 postmaster 5597 postgres 8 0 624 248 216 S
> > > 0 0.0 0.0 0:24 postmaster 5598 postgres 9 0 1440 4 4 D
> > > 0 0.0 0.0 2:31 postmaster 5599 postgres 9 0 2052 4 4
> > > S 0 0.0 0.0 28:05 postmaster 12262 postgres 9 0 88564 4
> > > 4 D 0 0.0 0.0 0:19 postmaster 13039 postgres 9 0 656
> > > 4 4 D 0 0.0 0.0 0:00 postmaster 29440 postgres 9 0
> > > 20928 19M 20332 S 0 0.0 1.9 0:01 postmaster 1652 postgres
> > > 9 0 3356 2324 2144 S 0 0.0 0.2 3:21 postmaster 2219
> > > postgres 9 0 2744 2120 2068 S 0 0.0 0.2 0:00 postmaster
> > > 6772 postgres 9 0 100M 100M 99.3M S 0 0.0 9.9 0:00
> > > postmaster 6805 postgres 9 0 4440 4168 3532 S 0 0.0 0.4
> > > 0:00 postmaster 6809 postgres 9 0 35280 34M 33948 S 0 0.0
> > > 3.4 0:00 postmaster 6846 postgres 9 0 98.9M 98M 99804 S 0 0.0
> > > 9.8 0:01 postmaster 6931 postgres 9 0 21744 20M 20428 S 0 0.0
> > > 2.0 0:02 postmaster 6934 postgres 9 0 19020 18M 17868 S 0 0.0
> > > 1.8 0:00 postmaster 6941 postgres 9 0 63280 61M 61756 S 0
> > > 0.0 6.1 0:01 postmaster
> > > =======================================================================
> > >== =======
> > >
> > >
> > > [root(at)linux10320 root2]# kill -INT 27135
> > > bash: kill: (27135) - No such pid
> > > [root(at)linux10320 root2]#
> > >
> > >
> > > and # kill -INT 12262 does not actually kills it ??
> > >
> > > regds
> > > mallah.
> > >
> > >
> > > --
> > > Rajesh Kumar Mallah,
> > > Project Manager (Development)
> > > Infocom Network Limited, New Delhi
> > > phone: +91(11)6152172 (221) (L) ,9811255597 (M)
> > >
> > > Visit http://www.trade-india.com ,
> > > India's Leading B2B eMarketplace.
> > >
> > >
> > >
> > > ---------------------------(end of
> > > broadcast)--------------------------- TIP 3: if posting/reading through
> > > Usenet, please send an appropriate subscribe-nomail command to
> > > majordomo(at)postgresql(dot)org so that your message can get through to the
> > > mailing list cleanly

--
Rajesh Kumar Mallah,
Project Manager (Development)
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.