Re: [GENERAL] Memory consumption for Query

>> Other operations don't really consume much memory. Is there any way to find out that as well. >> You can run "EXPLAIN (ANALYZE) SELECT ..." to see how much memory is used for memory intense operations like sort, hash or materialize. I am aware of it. Sent from Outlook

Re: [GENERAL] Memory consumption for Query

dhaval jaiswal wrote: > How to check how much memory query is consuming. > > Is there tool can check of query consuming memory for the execution or output. > > Let's say for following query how to calculate memory consumption. > > select * from test where id=1; That query will not consume memor

[GENERAL] Memory consumption for Query

How to check how much memory query is consuming. Is there tool can check of query consuming memory for the execution or output. Let's say for following query how to calculate memory consumption. select * from test where id=1; Sent from Outlook

Re: [GENERAL] Memory usage per session

Hi >I think the "problem" that he is having is fixable only by changing how >PostgreSQL itself works. >His problem is a PL/pgSQL function which is 11K lines in length. >When invoked, this function is "compiled" into a large tokenized parse tree. >This parse tree is only usable in the session whic

Re: [GENERAL] Memory usage per session

Hi > On Jul 08, John McKown modulated: > ... >> I think the "problem" that he is having is fixable only by changing how >> PostgreSQL itself works. His problem is a PL/pgSQL function which is >> 11K lines in length. When invoked, this function is "compiled" into a >> large tokenized parse tree. Th

Re: [GENERAL] Memory usage per session

On 7/8/2016 12:00 PM, Karl Czajkowski wrote: 3. Rewrite or refactor such complex stored procedures in a different programming language such as C or Python, so your PL/pgsql stored procedures remain small glue around libraries of code. Postgres makes it very trivial to extend the syst

Re: [GENERAL] Memory usage per session

On Jul 08, John McKown modulated: ... > I think the "problem" that he is having is fixable only by changing how > PostgreSQL itself works. His problem is a PL/pgSQL function which is > 11K lines in length. When invoked, this function is "compiled" into a > large tokenized parse tree. This parse tre

Re: [GENERAL] Memory usage per session

2016-07-08 17:49 GMT+02:00 : > Hi > > > >> Oracle: about 5M > >> postgreSql: about 160М > > > > >The almost session memory is used for catalog caches. So you should to > have big catalog and long living sessions. > > >What do you do exactly? > > I've generate test code that emulates instruction t

Re: [GENERAL] Memory usage per session

On Fri, Jul 8, 2016 at 11:26 AM, Melvin Davidson wrote: > > > On Fri, Jul 8, 2016 at 11:49 AM, wrote: > >> Hi >> >> >> >> Oracle: about 5M >> >> postgreSql: about 160М >> >> >> >> >The almost session memory is used for catalog caches. So you should to >> have big catalog and long living sessions

Re: [GENERAL] Memory usage per session

On Fri, Jul 8, 2016 at 11:49 AM, wrote: > Hi > > > >> Oracle: about 5M > >> postgreSql: about 160М > > > > >The almost session memory is used for catalog caches. So you should to > have big catalog and long living sessions. > > >What do you do exactly? > > I've generate test code that emulates i

Re: [GENERAL] Memory usage per session

Title: Re: [GENERAL] Memory usage per session Hi >> Oracle: about 5M >> postgreSql: about 160М >The almost session memory is used for catalog caches. So you should to have big catalog and long living sessions.  >What do you do exactly? I've generate test code tha

Re: [GENERAL] Memory usage per session

Title: Re: [GENERAL] Memory usage per session Hi >> >> The test performs about 11K lines of code >> >> Oracle: about 5M >> >> postgreSql: about 160М >What is the actual O/S that PostgreSQL is installed on?  >How much total memory is on the server? 

Re: [GENERAL] Memory usage per session

On 08/07/2016 17:07, amatv...@bitec.ru wrote: Hi The test performs about 11K lines of code Oracle: about 5M postgreSql: about 160М Do you have 100 CPUs on this system which apparently doesn't have 16G of RAM available for PG to use? We can say at fact: We currently work at oracle. Our code

Re: [GENERAL] Memory usage per session

On Fri, Jul 8, 2016 at 10:07 AM, wrote: > Hi > > >> >> The test performs about 11K lines of code > >> >> Oracle: about 5M > >> >> postgreSql: about 160М > > > > Do you have 100 CPUs on this system which apparently doesn't have 16G > > of RAM available for PG to use? > We can say at fact: > We cur

Re: [GENERAL] Memory usage per session

Title: Re: [GENERAL] Memory usage per session Здравствуйте. >> Oracle: about 5M >> postgreSql: about 160М >​I'm admittedly ignorant of this type of testing. But if the memory usage for PostgreSQL is in the server, perhaps due to caching (how to test?), then it likely

Re: [GENERAL] Memory usage per session

Hi >> >> The test performs about 11K lines of code >> >> Oracle: about 5M >> >> postgreSql: about 160М > Do you have 100 CPUs on this system which apparently doesn't have 16G > of RAM available for PG to use? We can say at fact: We currently work at oracle. Our code base about 4000 k line of co

Re: [GENERAL] Memory usage per session

* amatv...@bitec.ru (amatv...@bitec.ru) wrote: > > On 08/07/2016 14:11, amatv...@bitec.ru wrote: > >> The test performs about 11K lines of code > >> Memory usage per session: > >> Oracle: about 5M > >> MSSqlServer: about 4M > >> postgreSql: about 160М > > > Visual C??? > > You will have to run Pos

Re: [GENERAL] Memory usage per session

On Fri, Jul 8, 2016 at 8:16 AM, wrote: > Hi > > > On 08/07/2016 14:11, amatv...@bitec.ru wrote: > >> Hi. > >> The test performs about 11K lines of code > >> Memory usage per session: > >> Oracle: about 5M > >> MSSqlServer: about 4M > >> postgreSql: about 160М > > > > Visual C??? > > You will have

Re: [GENERAL] Memory usage per session

Hi 2016-07-08 15:16 GMT+02:00 : > Hi > > > On 08/07/2016 14:11, amatv...@bitec.ru wrote: > >> Hi. > >> The test performs about 11K lines of code > >> Memory usage per session: > >> Oracle: about 5M > >> MSSqlServer: about 4M > >> postgreSql: about 160М > > > > Visual C??? > > You will have to run

Re: [GENERAL] Memory usage per session

Hi > On 08/07/2016 14:11, amatv...@bitec.ru wrote: >> Hi. >> The test performs about 11K lines of code >> Memory usage per session: >> Oracle: about 5M >> MSSqlServer: about 4M >> postgreSql: about 160М > Visual C??? > You will have to run PostgreSQL on a proper Unix system to test for > perfor

Re: [GENERAL] Memory usage per session

On 08/07/2016 14:11, amatv...@bitec.ru wrote: Hi. We have tested postgreSql,Oracle,MSSqlServer. The test performs about 11K lines of code Memory usage per session: Oracle: about 5M MSSqlServer: about 4M postgreSql: about 160М The result of postgreSql is very sad(Our typical business logic has abo

[GENERAL] Memory usage per session

Hi. We have tested postgreSql,Oracle,MSSqlServer. The test performs about 11K lines of code Memory usage per session: Oracle: about 5M MSSqlServer: about 4M postgreSql: about 160М The result of postgreSql is very sad(Our typical business logic has about 30K lines of code). How can I reduce memory

Re: [GENERAL] memory problem with refresh materialized view

Enrico Pirozzi wrote: > I have a new postgresql 9.5.0 installation on a new virtual server debian 8.3 > x64 with 4gb RAM, I have > compiled postgresql from source. > > When I import a dump with materialized views I see that postgres process > takes about all 4 Gb and then > I have this error >

[GENERAL] memory problem with refresh materialized view

Hi I have a new postgresql 9.5.0 installation on a new virtual server debian 8.3 x64 with 4gb RAM, I have compiled postgresql from source. When I import a dump with materialized views I see that postgres process takes about all 4 Gb and then I have this error fork: Cannot allocate memory Can a

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 12/13/2015 01:23 PM, Gerhard Wiesinger wrote: On 13.12.2015 21:14, Bill Moran wrote: Wait ... this is a combined HTTP/Postgres server? You didn't mention that earlier, and it's kind of important. What evidence do you have that Postgres is actually the part of this system running out of memor

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 22:23:19 +0100 Gerhard Wiesinger wrote: > On 13.12.2015 21:14, Bill Moran wrote: > > Wait ... this is a combined HTTP/Postgres server? You didn't mention that > > earlier, and it's kind of important. > > > > What evidence do you have that Postgres is actually the part of > > t

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 13.12.2015 21:14, Bill Moran wrote: Wait ... this is a combined HTTP/Postgres server? You didn't mention that earlier, and it's kind of important. What evidence do you have that Postgres is actually the part of this system running out of memory? For me the complete picture doesn't look cons

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 20:09:04 +0100 Gerhard Wiesinger wrote: > On 13.12.2015 18:17, Tom Lane wrote: > > Gerhard Wiesinger writes: > >>> Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free > >>> Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse > >> OK, but why do we then g

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On 13.12.2015 18:17, Tom Lane wrote: Gerhard Wiesinger writes: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse OK, but why do we then get: kernel: swap_pager_getswapspace(4): failed? Just judging from the name of th

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Gerhard Wiesinger writes: >> Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free >> Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse > OK, but why do we then get: kernel: swap_pager_getswapspace(4): failed? Just judging from the name of the function, I would bet this is

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 16:35:08 +0100 Gerhard Wiesinger wrote: > Hello Bill, > > Thank you for your response, comments inline: > > On 13.12.2015 16:05, Bill Moran wrote: > > On Sun, 13 Dec 2015 09:57:21 +0100 > > Gerhard Wiesinger wrote: > >> some further details from the original FreeBSD 10.1 ma

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Hello Bill, Thank you for your response, comments inline: On 13.12.2015 16:05, Bill Moran wrote: On Sun, 13 Dec 2015 09:57:21 +0100 Gerhard Wiesinger wrote: some further details from the original FreeBSD 10.1 machine: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

On Sun, 13 Dec 2015 09:57:21 +0100 Gerhard Wiesinger wrote: > > some further details from the original FreeBSD 10.1 machine: > > Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free > Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse > >PID USERNAMETHR PRI NICE

Re: [GENERAL] Memory Leak executing small queries without closing the connection - FreeBSD

Hello, some further details from the original FreeBSD 10.1 machine: Mem: 7814M Active, 20G Inact, 2982M Wired, 232M Cache, 1661M Buf, 30M Free Swap: 512M Total, 506M Used, 6620K Free, 98% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 77941 pgsql 5 20

[GENERAL] Memory Leak executing small queries without closing the connection

Hello, We are running PostgreSQL 9.4.5 on FreeBSD 10.1 and have multiple worker processes connected via persistent connections to PostgreSQL, they perform just simple queries with SELECT on primary keys and simple INSERTS/UPDATES. Normally nearly all the workers are idle but they still consum

Re: [GENERAL] Memory for BYTEA returned by C function is not released until connection is dropped

2015-09-21 4:31 GMT+02:00 John Leiseboer : > I have written a number of functions in C that return BYTEA type. I have > compiled and run on both Windows and Linux, 32-bit and 64-bit, PostgreSQL > versions 9.3 and 9.4. > > My functions return BYTEA data to the caller. The problem is that memory > u

[GENERAL] Memory for BYTEA returned by C function is not released until connection is dropped

I have written a number of functions in C that return BYTEA type. I have compiled and run on both Windows and Linux, 32-bit and 64-bit, PostgreSQL versions 9.3 and 9.4. My functions return BYTEA data to the caller. The problem is that memory usage grows until there is no memory left on the host

Re: [GENERAL] Memory for BYTEA returned by C function is not released until connection is dropped

Tom Lane [mailto:t...@sss.pgh.pa.us] writes: > But at any rate, bottom line is that your problem is client-side not > server-side, and no amount of fooling with the function innards will change > it. I wish it were. While monitoring memory on Linux and Windows machines I see that psql memory us

Re: [GENERAL] Memory for BYTEA returned by C function is not released until connection is dropped

John Leiseboer writes: > I have written a number of functions in C that return BYTEA type. I have > compiled and run on both Windows and Linux, 32-bit and 64-bit, PostgreSQL > versions 9.3 and 9.4. > My functions return BYTEA data to the caller. The problem is that memory > usage grows until th

[GENERAL] Memory for BYTEA returned by C function is not released until connection is dropped

I have written a number of functions in C that return BYTEA type. I have compiled and run on both Windows and Linux, 32-bit and 64-bit, PostgreSQL versions 9.3 and 9.4. My functions return BYTEA data to the caller. The problem is that memory usage grows until there is no memory left on the host

Re: [GENERAL] Memory Utilization Issue

Could you also please check the Transparent huge page(THP) are enabled on the server or not, they can also result in intermittent poor performance along with high system cpu time counted against the database processes. This can be confirmed by below command: cat /sys/kernel/mm/redhat_transparent_

Re: [GENERAL] Memory Utilization Issue

What is the output of 'free -m' ? Look at the third column second row (+/- cache). This is the most relevant number. Even if you are swapping that can happen with plenty of RAM available if 'swappiness' is set too low. Sent from my iPhone > On May 20, 2015, at 2:25 AM, Sachin Srivastava > wr

Re: [GENERAL] Memory Utilization Issue

Sachin Srivastava wrote: > Always my server memory utilization is remain >99%. I have 4 DB server and > RAM of the server is (32 > GB, 64 GB, 64 GB and 132 GB). In every server always we are getting the > memory utilization > 99%. > Kindly suggest why this problem is and which parameter will reso

[GENERAL] Memory Utilization Issue

Dear Concern, Always my server memory utilization is remain >99%. I have 4 DB server and RAM of the server is (32 GB, 64 GB, 64 GB and 132 GB*). In every server always we are getting the memory utilization > 99%. *Kindly suggest why this problem is and which parameter will resolve this problem.

[GENERAL] Memory management in postgres (with liblwgeom functions in particular)

Hello, I am developing a C++ extension (most of the code is C++) for postgres that links dynamically with liblwgeom, without linking to postgis. I call liblwgeom functions that serialize/deserialize LWGEOM* (and similar structures) that don't need a backend like GEOS. I wonder how is the memory f

Re: [GENERAL] memory leak while trying to update/alter column in postgresql

On Sat, Jul 5, 2014 at 11:06 AM, Madhurima Das wrote: > int main() > { > PGconn *conn; >PGresult *res; > int i=0,nFields=0,row=0,col=0; > > conn = PQconnectdb("dbname=test1 host=localhost user=postgres > password=yyy"); >if(PQstatus(conn) == CONNECTION_BAD) >{ > fprintf(stderr, "Co

[GENERAL] memory leak while trying to update/alter column in postgresql

I am trying to update/alter two columns-comment and id in a table called xxx using postgresql. Though the compiler does not show any errors but Valgrind gives major memory leak errors. The code is: int main() { PGconn *conn; PGresult *res; int i=0,nFields=0,row=0,col=0; conn = PQconnectdb

Re: [GENERAL] Memory leak with CREATE TEMP TABLE ON COMMIT DROP?

Eric Ridge writes: > As best I can guess, Postgres has some kind of memory leak around (at least) > temporary tables flagged to drop on commit. It's fairly easy to reproduce: I don't see any memory leak with this example. What I do see is the process's use of shared memory grows slowly until i

[GENERAL] Memory leak with CREATE TEMP TABLE ON COMMIT DROP?

# select version(); version --- PostgreSQL 9.

Re: [GENERAL] memory leaking ?

Zhemin Zhou writes: > We met a problem after running the website for one week. We used a > function to convert and save binary files into the database (as bytea). > This function worked well in the old version but sometimes makes the new > version of postgres crash. This random crash is not fil

[GENERAL] memory leaking ?

Hi all We have been using postgreSQL version 8.1.11 for 6 years and have to move our website to another server recently. We did not manage to get the version 8.1.11 thus have to use version 8.4.12 in the new server. This version is still quite old but we cannot make the databases running in

[GENERAL] memory issues with BYTEAs in JSON and hstore

Hey, I've developed a database auditing/versioning using the JSON data type (http://github.com/fxku/audit) and doing some tests now. Unfortunately I'm facing some problems when dealing with tables that store images as BYTEA. Some of them are around 15 MB big. My tool logs changes to JSON and ca

Re: [GENERAL] Memory usage per postmaster process

=?UTF-8?B?R3J6ZWdvcnogVGHFhGN6eWs=?= writes: > On 11/02/2013 08:47 PM, Tom Lane wrote: >> Author: Tom Lane >> Branch: master Release: REL9_1_BR [3e5f9412d] 2010-10-06 19:31:05 -0400 >> >> Reduce the memory requirement for large ispell dictionaries. > I checked this patch: > http://www.postgresql.

Re: [GENERAL] Memory usage per postmaster process

On 11/02/2013 08:47 PM, Tom Lane wrote: Author: Tom Lane Branch: master Release: REL9_1_BR [3e5f9412d] 2010-10-06 19:31:05 -0400 Reduce the memory requirement for large ispell dictionaries. I checked this patch: http://www.postgresql.org/message-id/AANLkTi=4fUi1zoFMpZ==yf14rjdv_g1xgakvqmdy

Re: [100% SPAM] Re: [GENERAL] Memory usage per postmaster process

=?UTF-8?B?R3J6ZWdvcnogVGHFhGN6eWs=?= writes: > Did tsearch2 dictionary caching implementation improve after 8.3 on this > matter? Well, there was this: Author: Tom Lane Branch: master Release: REL9_1_BR [3e5f9412d] 2010-10-06 19:31:05 -0400 Reduce the memory requirement for large ispell d

Re: [100% SPAM] Re: [GENERAL] Memory usage per postmaster process

On 11/02/2013 07:47 PM, John R Pierce wrote: On 11/2/2013 11:03 AM, Grzegorz Tańczyk wrote: Is there any way to limit total memory usage by postgres and keep maximum connections limit? Postgresql.conf settings are default for 8.3.23. I need to have 100 connections in pool. the size of your

Re: [GENERAL] Memory usage per postmaster process

On 11/2/2013 11:03 AM, Grzegorz Tańczyk wrote: Is there any way to limit total memory usage by postgres and keep maximum connections limit? Postgresql.conf settings are default for 8.3.23. I need to have 100 connections in pool. the size of your connection pool shouldn't be much more than 2

[GENERAL] Memory usage per postmaster process

Hello, Recently I had some problem with tsearch2 in postgres 8.3. Application was using JDBC connection pool and it was possible that each connection from the pool used tsearch2(with dictionary) in some query. This resulted in almost every postmaster process using >0.5g memory. Solution of thi

[GENERAL] Memory usage per postmaster process

Hello, Recently I had some problem with tsearch2 in postgres 8.3. Application was using JDBC connection pool and it was possible that each connection from the pool used tsearch2(with dictionary) in some query. This resulted in almost every postmaster process using >0.5g memory. Solution of thi

Re: [GENERAL] Memory Issue with array_agg?

Hi Pavel, Here are the explains you asked for: explain analyze select string_agg(id::text,',') from things group by guid; QUERY PLAN ---

Re: [GENERAL] Memory Issue with array_agg?

Can you send a EXPLAIN result in both use cases? Pavel 2013/8/19 Robert Sosinski > At the moment, all guids are distinct, however before I zapped the > duplicates, there were 280 duplicates. > > Currently, there are over 2 million distinct guids. > > -Robert > > > On Mon, Aug 19, 2013 at 11:12

Re: [GENERAL] Memory Issue with array_agg?

Hello It is strange. I am trying to simulate it without success. On 1 M rows where every id is 2 times duplicated processing string_agg .. cca 30MB processing array_agg cca 32MB postgres=# create table foo(a int, b varchar); CREATE TABLE postgres=# insert into foo select i, md5(i::text) from ge

Re: [GENERAL] Memory Issue with array_agg?

At the moment, all guids are distinct, however before I zapped the duplicates, there were 280 duplicates. Currently, there are over 2 million distinct guids. -Robert On Mon, Aug 19, 2013 at 11:12 AM, Pavel Stehule wrote: > > > > 2013/8/19 Robert Sosinski > >> Hi Pavel, >> >> What kind of exam

Re: [GENERAL] Memory Issue with array_agg?

2013/8/19 Robert Sosinski > Hi Pavel, > > What kind of example do you need? I cant give you the actual data I have > in the table, but I can give you an example query and the schema attached > below. From there, I would just put in 2 million rows worth 1.2 Gigs of > data. Average size of the t

Re: [GENERAL] Memory Issue with array_agg?

Hi Pavel, What kind of example do you need? I cant give you the actual data I have in the table, but I can give you an example query and the schema attached below. From there, I would just put in 2 million rows worth 1.2 Gigs of data. Average size of the the extended columns (using the pg_colum

Re: [GENERAL] Memory Issue with array_agg?

Hello please, can you send some example or test? Regards Pavel Stehule 2013/8/19 Robert Sosinski > When using array_agg on a large table, memory usage seems to spike up > until Postgres crashes with the following error: > > 2013-08-17 18:41:02 UTC [2716]: [2] WARNING: terminating connection

Re: [GENERAL] Memory Issue with array_agg?

## Robert Sosinski (rsosin...@ticketevolution.com): > When using array_agg on a large table, memory usage seems to spike up until > Postgres crashes with the following error: This sounds like bug #7916. http://www.postgresql.org/message-id/e1uceeu-0004hy...@wrigleys.postgresql.org As noted in tha

[GENERAL] Memory Issue with array_agg?

When using array_agg on a large table, memory usage seems to spike up until Postgres crashes with the following error: 2013-08-17 18:41:02 UTC [2716]: [2] WARNING: terminating connection because of crash of another server process 2013-08-17 18:41:02 UTC [2716]: [3] DETAIL: The postmaster has comma

Re: [GENERAL] Memory usage after upgrade to 9.2.4

I found where the problem is: http://www.postgresql.org/docs/9.1/static/release-9-1-6.html It could be nice if something is added to the 9.2 release notes to warn the admins. 2013/4/24 Adrian Klaver > On 04/24/2013 11:20 AM, Daniel Cristian Cruz wrote: > >> I've done an explain analyze under

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/24/2013 11:20 AM, Daniel Cristian Cruz wrote: I've done an explain analyze under the test environment, and there is no aggressive memory usage. So I dropped the database in the new cluster and restored a fresh dump from production (in theory, that's the difference between the two environme

Re: [GENERAL] Memory usage after upgrade to 9.2.4

I've done an explain analyze under the test environment, and there is no aggressive memory usage. So I dropped the database in the new cluster and restored a fresh dump from production (in theory, that's the difference between the two environments). Some minutes after I got an answer: after a dum

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/23 Adrian Klaver > On 04/23/2013 04:23 AM, Daniel Cristian Cruz wrote: > >> 2013/4/22 Daniel Cristian Cruz > > >> >> >> query1: >> EXPLAIN ANALYZE SELECT ced.id_evento, ced.inicio, ced.termino, >> ced.evento, ced.id_eventos IS NOT NULL AS aul

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/23/2013 04:23 AM, Daniel Cristian Cruz wrote: 2013/4/22 Daniel Cristian Cruz mailto:danielcrist...@gmail.com>> query1: EXPLAIN ANALYZE SELECT ced.id_evento, ced.inicio, ced.termino, ced.evento, ced.id_eventos IS NOT NULL AS aula_dividida, ac.titulo, ced.id_tipo_evento, ced.

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/22 Daniel Cristian Cruz > query1: > EXPLAIN ANALYZE SELECT ced.id_evento, ced.inicio, ced.termino, ced.evento, > ced.id_eventos IS NOT NULL AS aula_dividida, ac.titulo, ced.id_tipo_evento, > ced.tipo_evento, ac.media_referencia, p.nome, ef.nome AS nomeEspacoFisico, > ( SELECT count ( pre2.

Re: [GENERAL] Memory usage after upgrade to 9.2.4

I'm running pgBadger over the log, and will get some queries to explain analyze them. The 9.2 cluster is running in the same server as the production, so I will try to compare some critical explains and publish on explain.depesz.com. 2013/4/21 Adrian Klaver > On 04/21/2013 09:29 AM, Daniel Cris

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/21/2013 09:29 AM, Daniel Cristian Cruz wrote: 2013/4/21 Adrian Klaver mailto:adrian.kla...@gmail.com>> 1) Major upgrade from 9.1.4 to 9.2.4. Used pg_upgrade Tested on VM with 9.2.4 and no problems. Same machine used for production server 9.1.4 and 9.2.4 When

Fwd: [GENERAL] Memory usage after upgrade to 9.2.4

And this one only to Adrian. Sorry to all. -- Forwarded message -- From: Daniel Cristian Cruz Date: 2013/4/20 Subject: Re: [GENERAL] Memory usage after upgrade to 9.2.4 To: Adrian Klaver 2013/4/20 Adrian Klaver > On 04/20/2013 04:30 PM, Daniel Cristian Cruz wr

Fwd: [GENERAL] Memory usage after upgrade to 9.2.4

Sorry, I answered to Tomas only... -- Forwarded message -- From: Daniel Cristian Cruz Date: 2013/4/21 Subject: Re: [GENERAL] Memory usage after upgrade to 9.2.4 To: Tomas Vondra I had the same environment, almost: 2013/4/21 Tomas Vondra > > 2) What are the hardware

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/21 Adrian Klaver > On 04/21/2013 07:50 AM, Daniel Cristian Cruz wrote: > >> >> >> >> 2013/4/21 Adrian Klaver > > >> >> >> On 04/21/2013 06:37 AM, Daniel Cristian Cruz wrote: >> >> 2013/4/21 Tom Lane mailto:t...@sss.pgh.pa.us> >>

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/21/2013 07:50 AM, Daniel Cristian Cruz wrote: 2013/4/21 Adrian Klaver mailto:adrian.kla...@gmail.com>> On 04/21/2013 06:37 AM, Daniel Cristian Cruz wrote: 2013/4/21 Tom Lane mailto:t...@sss.pgh.pa.us> >>

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/21 Adrian Klaver > On 04/21/2013 06:37 AM, Daniel Cristian Cruz wrote: > >> 2013/4/21 Tom Lane mailto:t...@sss.pgh.pa.us>> >> >> >> Tomas Vondra mailto:t...@fuzzy.cz>> writes: >> > I do have a log with the memory context info printed after the OOM >> > killed the session - se

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 21.4.2013 15:14, Tom Lane wrote: > Tomas Vondra writes: >> I do have a log with the memory context info printed after the OOM >> killed the session - see it attached. > > The only thing that seems rather bloated is the CacheMemoryContext, > which seems to be because the backend has cached info

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/21/2013 06:37 AM, Daniel Cristian Cruz wrote: 2013/4/21 Tom Lane mailto:t...@sss.pgh.pa.us>> Tomas Vondra mailto:t...@fuzzy.cz>> writes: > I do have a log with the memory context info printed after the OOM > killed the session - see it attached. The only thing that seems

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/20/2013 05:19 PM, Daniel Cristian Cruz wrote: Copying to list to fill in blanks. 2013/4/20 Adrian Klaver mailto:adrian.kla...@gmail.com>> On 04/20/2013 04:30 PM, Daniel Cristian Cruz wrote: 2013/4/20 Adrian Klaver mailto:adrian.kla...@gmail.com>

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/21 Tom Lane > Tomas Vondra writes: > > I do have a log with the memory context info printed after the OOM > > killed the session - see it attached. > > The only thing that seems rather bloated is the CacheMemoryContext, > which seems to be because the backend has cached info about several

Re: [GENERAL] Memory usage after upgrade to 9.2.4

Tomas Vondra writes: > I do have a log with the memory context info printed after the OOM > killed the session - see it attached. The only thing that seems rather bloated is the CacheMemoryContext, which seems to be because the backend has cached info about several thousand tables and indexes. G

Re: [GENERAL] Memory usage after upgrade to 9.2.4

Hi, we got a report of (probably) the same issue on a local mailing list. Maybe it'll help in finding the root cause, so I'm resending the info here too. On 21.4.2013 01:19, Adrian Klaver wrote: > On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote: >> I think I didn't make it clear: the session m

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/20/2013 04:30 PM, Daniel Cristian Cruz wrote: 2013/4/20 Adrian Klaver mailto:adrian.kla...@gmail.com>> On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote: I think I didn't make it clear: the session memory usage is growing up too fast, until all server memor

Re: [GENERAL] Memory usage after upgrade to 9.2.4

2013/4/20 Adrian Klaver > On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote: > >> I think I didn't make it clear: the session memory usage is growing up >> too fast, until all server memory got used and swap occurs. >> >> Never saw something like that. The version is under a test enviroment >> f

Re: [GENERAL] Memory usage after upgrade to 9.2.4

On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote: I think I didn't make it clear: the session memory usage is growing up too fast, until all server memory got used and swap occurs. Never saw something like that. The version is under a test enviroment for a long time... Thanks if someone could

Re: [GENERAL] Memory usage after upgrade to 9.2.4

I think I didn't make it clear: the session memory usage is growing up too fast, until all server memory got used and swap occurs. Never saw something like that. The version is under a test enviroment for a long time... Thanks if someone could help me. 2013/4/20 Daniel Cristian Cruz > Hi all,

[GENERAL] Memory usage after upgrade to 9.2.4

Hi all, I've upgrade from 9.1.4 to 9.2.4, and got some very weird issue. My server got connections with RES (column from top utility) with too much memory: top - 19:50:58 up 384 days, 23:55, 2 users, load average: 4.28, 6.51, 7.68 Tasks: 417 total, 1 running, 416 sleeping, 0 stopped, 0 z

Re: [GENERAL] Memory issue on FreeBSD

Thanx for the link. I just think that it would be a good idea, instead of posting the links at this list, to include a dense but detailed summary of the situation in your machine, and give as much data as possible. In short, you might do a quantitative compilation of this thread, and present it

Re: [GENERAL] Memory issue on FreeBSD

FYI http://freebsd.1045724.n5.nabble.com/Postgresql-related-memory-question-td5759467.html Am 2012-11-07 10:28, schrieb Achilleas Mantzios: On Τετ 07 Νοε 2012 09:42:47 Frank Broniewski wrote: Hey, this is really cool. I directly tried the script and there's a line from the output that caught

Re: [GENERAL] Memory issue on FreeBSD

Vick, fantastic script, thanx! FreeBSD sysctl system is awesome! On Τρι 06 Νοε 2012 14:33:43 Vick Khera wrote: On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote: and this is after a few hours of running: Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free Swap: 4

Re: [GENERAL] Memory issue on FreeBSD

On Τετ 07 Νοε 2012 09:42:47 Frank Broniewski wrote: > Hey, this is really cool. I directly tried the script and there's a line > from the output that caught my eye: > > > mem_gap_vm: + 8812892160 ( 8404MB) [ 26%] Memory gap: UNKNOWN > > is this the shared buffers? I guess so, but I want to

Re: [GENERAL] Memory issue on FreeBSD

Hey, this is really cool. I directly tried the script and there's a line from the output that caught my eye: > mem_gap_vm: + 8812892160 ( 8404MB) [ 26%] Memory gap: UNKNOWN is this the shared buffers? I guess so, but I want to confirm my guess ... Frank Am 2012-11-07 09:26, schrieb Achil

Re: [GENERAL] Memory issue on FreeBSD

Vick, fantastic script, thanx! FreeBSD sysctl system is awesome! On Τρι 06 Νοε 2012 14:33:43 Vick Khera wrote: On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote: and this is after a few hours of running: Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free Swap: 4

Re: [GENERAL] Memory issue on FreeBSD

On Mon, Nov 5, 2012 at 10:11 AM, Frank Broniewski wrote: > and this is after a few hours of running: > > Mem: 91M Active, 17G Inact, 3983M Wired, 1526M Cache, 3283M Buf, 155M Free > Swap: 4096M Total, 828K Used, 4095M Free > > For comparison, here is the output of a 32GB FreeBSD 9.0/amd64 server,

Re: [GENERAL] Memory issue on FreeBSD

Since the top reporting goes back to normal when postgresql is stopped , and since postgresql is special due to the use of IPC, i would be inclined to think that the culprit here is the shared memory. I don't know where maintenance_work_mem really lives (process normal address space or IPC share

  1   2   3   4   >