Re: [ADMIN] open source ERD for postgresql database
Looks interesting, how well does MICRO-OLAP support the full range of PostgreSQL's types? Things like "cidr" for instance. On Mon, 2008-09-15 at 15:06 -0400, Anibal David Acosta wrote: > MICRO-OLAP Database designer for postgres is a great tool. > > > > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Carol Walter > Enviado el: lunes, 15 de septiembre de 2008 02:58 p.m. > Para: Thomas Jacob > CC: Barbara Stephenson; pgsql-admin@postgresql.org > Asunto: Re: [ADMIN] open source ERD for postgresql database > > This sort of depends on what you want to do with the ERD. If I want > to document an existing system, I use Aqua Data Studio. It's not > free, but it will take an existing system and draw the ERD for you > based on the relationships it finds in the database. There are > things that I don't like about it. It puts the tables into the ERD > in alpha order. This leads to some spaghetti ERD's. You can move > the tables around and then save them. The problem is that once they > are saved, it's an image and you can't move them anymore. If you > recreate the ERD you have to begin again to move the tables around. > Another tool that some people like, but that I haven't used is called > SQL-EZ. It's cost is trivial. > > Carol > > On Sep 12, 2008, at 10:24 AM, Thomas Jacob wrote: > > > I've been using GNU ferret for a while, it's OK > > for simple tasks, and can produce table graphs and > > even output rudimentary PostgreSQL DDL in Version 0.6, > > but it doesn't support PostgreSQL's full range of types yet > > and the handling is somewhat awkward. > > > > Version 0.7 looks much more promising, at least from > > the screen shots, but that hasn't been release yet: > > > > http://www.gnuferret.org/ > > > > > > > > On Fri, 2008-09-12 at 09:59 -0400, Barbara Stephenson wrote: > >> I would like to use an ERD tool for postgres and it be open > >> source. Any > >> suggestions? > >> -- > >> Regards, > >> > >> Barbara Stephenson > >> EDI Specialist/Programmer > >> Turbo, division of Ozburn-Hessey Logistics > >> 2251 Jesse Jewell Pkwy NE > >> Gainesville, GA 30507 > >> tel: (678)989-3020 fax: (404)935-6171 > >> [EMAIL PROTECTED] > >> www.ohlogistics.com > >> > > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Help request: how to tune performance?
Hi,
We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the
database completely own machine. And the users still complain that it is
dog slow. :-( I installed pg_top and it seems that at the beginning of
the ticket display RT-issues a query that eats everything the database
has. Query is as follows:
SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN
Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN
CachedGroupMembers CachedGroupMembers_3 ON
( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE
(Principals_1.Disabled = '0') AND (ACL_2.PrincipalId =
CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND
(ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType =
'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType =
'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType =
'RT::System')) ORDER BY main.Name ASC
and explain tells me that:
-> Nested Loop (cost=16.17..9953.51 rows=1 width=4318)
Join Filter: ("outer".principalid = "inner".groupid)
-> Index Scan using acl1 on acl acl_2 (cost=0.00..49.38
rows=1 width=4)
Index Cond: ((principaltype)::text = 'Group'::text)
Filter: rightname)::text = 'OwnTicket'::text) OR
((rightname)::text = 'SuperUser'::text)) AND (((objecttype)::text =
'RT::Queue'::text) OR ((objecttype)::text = 'RT::System'::text)))
-> Nested Loop (cost=16.17..9903.98 rows=12 width=4322)
-> Nested Loop (cost=0.00..6343.98 rows=1
width=4322)
-> Seq Scan on principals principals_1
(cost=0.00..6308.00 rows=6 width=4)
Filter: ((disabled = 0) AND (id <> 1)
AND ((principaltype)::text = 'User'::text))
-> Index Scan using users_pkey on users main
(cost=0.00..5.98 rows=1 width=4318)
Index Cond: ("outer".id = main.id)
-> Bitmap Heap Scan on cachedgroupmembers
cachedgroupmembers_3 (cost=16.17..3527.23 rows=2621 width=8)
Recheck Cond: (cachedgroupmembers_3.memberid =
"outer".id)
-> Bitmap Index Scan on cachedgroupmembers2
(cost=0.00..16.17 rows=2621 width=0)
Index Cond:
(cachedgroupmembers_3.memberid = "outer".id)
Is there something I can do to improve performance with tuning something
on postgresql.conf? Or adding/dropping indexes? What I read from that
query plan is that the single most expensive thing is sequential scan on
Principals. Principals already has indexes for both id and object.id!
Database version:
Name: postgresql-serverRelocations: (not
relocatable)
Version : 8.1.11Vendor: CentOS
Release : 1.el5_1.1 Build Date: Sat 12 Jan 2008
04:45:09 PM EET
pg_top:
last pid: 7201; load avg: 0.62, 0.90, 0.62; up 0+19:17:00
11:28:10
13 processes: 1 running, 12 sleeping
CPU states: 8.2% user, 0.0% nice, 42.4% system, 49.5% idle, 0.0%
iowait
Memory: 1083M used, 2722M free, 234M buffers, 759M cached
Swap: 1024M free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
6015 postgres 170 22M 12M run 0:32 13.28% 99.82% postgres:
rt rt
6018 postgres 150 22M 12M sleep 3:25 0.01% 0.00% postgres:
rt rt
6035 postgres 150 22M 12M sleep 2:11 1.31% 0.00% postgres:
rt rt
6037 postgres 150 22M 12M sleep 1:33 0.01% 0.00% postgres:
rt rt
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Heavy postgres process
Thanks for the information so far My Application runs on FreeBSd box and main technological component are Apache and mod Perl, database is postgres. I have already scanned pg_stat_activity and pg_listener table but could get any clue. Pg_stat_activity shows list of all idle processes but command (current_query) column is empty. So I cannot make out what these processes are doing. TOP on this server doesn't have any option available to further break down processes. And hitting 'M; did change anything because this is not available with top on this server. Following is the output of top if filtered for only postgres user * last pid: 92308; load averages: 0.00, 0.03, 0.05 78 processes: 2 running, 76 sleeping CPU states: 1.6% user, 0.0% nice, 3.4% system, 0.0% interrupt, 94.9% idle Mem: 413M Active, 2122M Inact, 534M Wired, 140M Cache, 199M Buf, 533M Free Swap: 4096M Total, 3880K Used, 4092M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 90976 postgres2 0 83568K 76016K sbwait 2 0:32 2.83% 2.83% postgres 90963 postgres2 0 83396K 75876K sbwait 2 0:25 1.37% 1.37% postgres 90919 postgres2 0 83808K 76244K sbwait 1 0:32 0.39% 0.39% postgres 87341 postgres2 0 6388K 756K select 3 2:35 0.00% 0.00% postgres 87340 postgres2 0 7200K 1224K select 0 1:41 0.00% 0.00% postgres 90961 postgres2 0 83580K 76008K sbwait 0 0:30 0.00% 0.00% postgres 90920 postgres2 0 83636K 76068K sbwait 0 0:29 0.00% 0.00% postgres 90934 postgres2 0 83664K 76012K sbwait 0 0:27 0.00% 0.00% postgres 90924 postgres2 0 83408K 75872K sbwait 0 0:25 0.00% 0.00% postgres 90915 postgres2 0 79292K 72664K sbwait 0 0:23 0.00% 0.00% postgres 90955 postgres2 0 79644K 73040K sbwait 0 0:22 0.00% 0.00% postgres 90979 postgres2 0 78904K 72260K sbwait 0 0:17 0.00% 0.00% postgres 87339 postgres2 0 74756K 672K select 1 0:12 0.00% 0.00% postgres 90921 postgres2 0 75504K 59848K sbwait 3 0:01 0.00% 0.00% postgres 90927 postgres2 0 75540K 59296K sbwait 3 0:01 0.00% 0.00% postgres 90962 postgres2 0 75524K 56960K sbwait 0 0:01 0.00% 0.00% postgres 90923 postgres2 0 75540K 57584K sbwait 1 0:01 0.00% 0.00% postgres 90914 postgres2 0 75552K 57776K sbwait 1 0:01 0.00% 0.00% postgres 90917 postgres2 0 75524K 57256K sbwait 3 0:01 0.00% 0.00% postgres 90922 postgres2 0 75504K 57352K sbwait 1 0:01 0.00% 0.00% postgres 90918 postgres2 0 75508K 57748K sbwait 3 0:01 0.00% 0.00% postgres 90933 postgres2 0 75540K 53728K sbwait 2 0:01 0.00% 0.00% postgres 90926 postgres2 0 75484K 54928K sbwait 3 0:01 0.00% 0.00% postgres 90931 postgres2 0 75512K 20880K sbwait 3 0:00 0.00% 0.00% postgres 90977 postgres2 0 75512K 20584K sbwait 0 0:00 0.00% 0.00% postgres 91005 postgres2 0 75512K 19956K sbwait 0 0:00 0.00% 0.00% postgres 90966 postgres2 0 75488K 19056K sbwait 1 0:00 0.00% 0.00% postgres 90986 postgres2 0 75512K 19348K sbwait 1 0:00 0.00% 0.00% postgres 90973 postgres2 0 75512K 18140K sbwait 1 0:00 0.00% 0.00% postgres 90989 postgres2 0 75512K 18668K sbwait 2 0:00 0.00% 0.00% postgres 90956 postgres2 0 75488K 18320K sbwait 2 0:00 0.00% 0.00% postgres 90998 postgres2 0 75512K 17564K sbwait 3 0:00 0.00% 0.00% postgres 90925 postgres2 0 75488K 17412K sbwait 1 0:00 0.00% 0.00% postgres 1 postgres2 0 75528K 7920K sbwait 0 0:00 0.00% 0.00% postgres * Output of vmstat command procs memory pagedisks faults cpu r b w avmfre flt re pi po fr sr da0 da1 in sy cs us sy id 0 0 0 423492 688492 40 0 0 0 52 57 0 0 50 11 50 53 47 -0 * Output of systat command > systat /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 postgres postgres X * entries in pg_stat_activities datid | datname | procpid | usesysid | usename | current_query | query_start ---+-+-+--+--+---+- 17142 | wasdb | 90914 | 103 | was | | 17142 | wasdb | 90917 | 103 | was | | 17142 | wasdb | 90915 | 103 | was | | 17142 | wasdb | 90918 | 103 | was | | 17142 | wasdb | 90919 | 103 | was | | 17142 | wasdb | 90920 | 103 | was |
[ADMIN] pgBee - a Postgresql Bulk Updater in Java
"pgBee is a set of Java classes I wrote for automating bulk updates of Postgresql databases on Linux servers. It requires Java (doh!) and Ant (as a build/execute front-end), it is cronnable and performs very well, especially in multi-threaded mode, which takes full advantage of multi-core CPUs in modern servers." inspiration for this has come from http://archives.postgresql.org/pgsql-jdbc/2007-04/msg00076.php and my own tests... until pgBee is hosted in pgFoundry, you may find the source code here: http://freeyourtech.wordpress.com/2008/09/16/pgbee-a-postgresql-bulk-updater-in-java/ comments, suggestions welcome Michael
Re: [ADMIN] Heavy postgres process
On Tue, Sep 16, 2008 at 1:41 AM, Vivek_Sharan <[EMAIL PROTECTED]> wrote: > Thanks for the information so far > My Application runs on FreeBSd box and main technological component are > Apache and mod Perl, database is postgres. I have already scanned > pg_stat_activity and pg_listener table but could get any clue. > Pg_stat_activity shows list of all idle processes but command (current_query) > column is empty. So I cannot make out what these processes are doing. > TOP on this server doesn't have any option available to further break down > processes. And hitting 'M; did change anything because this is not available > with top on this server. Following is the output of top if filtered for only > postgres user > > * > last pid: 92308; load averages: 0.00, 0.03, 0.05 > 78 processes: 2 running, 76 sleeping > CPU states: 1.6% user, 0.0% nice, 3.4% system, 0.0% interrupt, 94.9% idle > Mem: 413M Active, 2122M Inact, 534M Wired, 140M Cache, 199M Buf, 533M Free > Swap: 4096M Total, 3880K Used, 4092M Free > > PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND > 90976 postgres2 0 83568K 76016K sbwait 2 0:32 2.83% 2.83% postgres > 90963 postgres2 0 83396K 75876K sbwait 2 0:25 1.37% 1.37% postgres > 90919 postgres2 0 83808K 76244K sbwait 1 0:32 0.39% 0.39% postgres > 87341 postgres2 0 6388K 756K select 3 2:35 0.00% 0.00% postgres > 87340 postgres2 0 7200K 1224K select 0 1:41 0.00% 0.00% postgres > 90961 postgres2 0 83580K 76008K sbwait 0 0:30 0.00% 0.00% postgres > 90920 postgres2 0 83636K 76068K sbwait 0 0:29 0.00% 0.00% postgres > 90934 postgres2 0 83664K 76012K sbwait 0 0:27 0.00% 0.00% postgres > 90924 postgres2 0 83408K 75872K sbwait 0 0:25 0.00% 0.00% postgres > 90915 postgres2 0 79292K 72664K sbwait 0 0:23 0.00% 0.00% postgres > 90955 postgres2 0 79644K 73040K sbwait 0 0:22 0.00% 0.00% postgres > 90979 postgres2 0 78904K 72260K sbwait 0 0:17 0.00% 0.00% postgres > 87339 postgres2 0 74756K 672K select 1 0:12 0.00% 0.00% postgres > 90921 postgres2 0 75504K 59848K sbwait 3 0:01 0.00% 0.00% postgres > 90927 postgres2 0 75540K 59296K sbwait 3 0:01 0.00% 0.00% postgres > 90962 postgres2 0 75524K 56960K sbwait 0 0:01 0.00% 0.00% postgres > 90923 postgres2 0 75540K 57584K sbwait 1 0:01 0.00% 0.00% postgres > 90914 postgres2 0 75552K 57776K sbwait 1 0:01 0.00% 0.00% postgres > 90917 postgres2 0 75524K 57256K sbwait 3 0:01 0.00% 0.00% postgres > 90922 postgres2 0 75504K 57352K sbwait 1 0:01 0.00% 0.00% postgres > 90918 postgres2 0 75508K 57748K sbwait 3 0:01 0.00% 0.00% postgres > 90933 postgres2 0 75540K 53728K sbwait 2 0:01 0.00% 0.00% postgres > 90926 postgres2 0 75484K 54928K sbwait 3 0:01 0.00% 0.00% postgres > 90931 postgres2 0 75512K 20880K sbwait 3 0:00 0.00% 0.00% postgres > 90977 postgres2 0 75512K 20584K sbwait 0 0:00 0.00% 0.00% postgres > 91005 postgres2 0 75512K 19956K sbwait 0 0:00 0.00% 0.00% postgres > 90966 postgres2 0 75488K 19056K sbwait 1 0:00 0.00% 0.00% postgres > 90986 postgres2 0 75512K 19348K sbwait 1 0:00 0.00% 0.00% postgres > 90973 postgres2 0 75512K 18140K sbwait 1 0:00 0.00% 0.00% postgres > 90989 postgres2 0 75512K 18668K sbwait 2 0:00 0.00% 0.00% postgres > 90956 postgres2 0 75488K 18320K sbwait 2 0:00 0.00% 0.00% postgres > 90998 postgres2 0 75512K 17564K sbwait 3 0:00 0.00% 0.00% postgres > 90925 postgres2 0 75488K 17412K sbwait 1 0:00 0.00% 0.00% postgres > 1 postgres2 0 75528K 7920K sbwait 0 0:00 0.00% 0.00% postgres > * > > Output of vmstat command > > procs memory pagedisks faults cpu > r b w avmfre flt re pi po fr sr da0 da1 in sy cs us sy id > 0 0 0 423492 688492 40 0 0 0 52 57 0 0 50 11 50 53 47 -0 > > * > Output of systat command > >> systat > > >/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 > Load Average | > >/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > postgres postgres X > * > entries in pg_stat_activities > > datid | datname | procpid | usesysid | usename | current_query | query_start > ---+-+-+--+--+---+- > 17142 | wasdb | 90914 | 103 | was | | > 17142 | wasdb | 90917 | 103 | was | | > 17142 | wasdb | 90915 | 103 | was
[ADMIN] Setting Effective Cache Size
Hi All; Is there an easy way to determine the actual OS disk cache size or at least a set of guidelines based on the OS and disk subsystem type ? Thanks in advance... /Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Help request: how to tune performance?
On Tue, Sep 16, 2008 at 2:31 AM, Mauri Sahlberg <[EMAIL PROTECTED]> wrote: > Hi, > > We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the > database completely own machine. And the users still complain that it is > dog slow. Moved up from below: > Version : 8.1.11Vendor: CentOS So, you built it its own machine, but you didn't upgrade to at least 8.2? Last place I worked we ran rt 3.6.1 and got a noticeable performance boost from switching to 8.2 but the only thing that was ever really slow was viewing the rather large approval queue. > :-( I installed pg_top and it seems that at the beginning of > the ticket display RT-issues a query that eats everything the database > has. Query is as follows: > > SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN > Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN > CachedGroupMembers CachedGroupMembers_3 ON > ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE > (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId = > CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND > (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType = > 'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType = > 'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType = > 'RT::System')) ORDER BY main.Name ASC Please post the output of explain analyze as an attachment. explain is only half the answer. > Is there something I can do to improve performance with tuning something > on postgresql.conf? Or adding/dropping indexes? What I read from that > query plan is that the single most expensive thing is sequential scan on > Principals. Principals already has indexes for both id and object.id! Possibly. explain analyze will help you identify where stats are wrong. sometimes just cranking the stats target on a few columns and re-analyzing gets you a noticeable performance boost. It's cheap and easy. When the estimated and actual number of rows are fairly close, then look for the slowest thing and see if an index can help. What have to already done to tune the install? shared_buffers, work_mem, random_page_cost, effective_cache_size. Is your db bloating during the day? Why no try 8.3 on this? Are you running on a single SATA hard drive?How big's the database directory? I'm guessing from your top output that the db is about 500 meg or so. it should all fit in memory. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Heavy postgres process
On Tue, Sep 16, 2008 at 8:37 AM, Guido Barosio <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 1:41 AM, Vivek_Sharan <[EMAIL PROTECTED]> wrote: >> Thanks for the information so far OK, I'm not BSD expert (Tom Lane might help out here) but I'm guessing that what we see in the following lines of top: >> 87340 postgres2 0 7200K 1224K select 0 1:41 0.00% 0.00% postgres >> 90961 postgres2 0 83580K 76008K sbwait 0 0:30 0.00% 0.00% postgres >> 90920 postgres2 0 83636K 76068K sbwait 0 0:29 0.00% 0.00% postgres Is that the number on the left, like 83636K is the total memory used, and the number to the right 76068K is how much is shared buffers etc... which would mean that each of those processes above are using about 7 megs a piece, and the rest is repeated. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Setting Effective Cache Size
On Tue, Sep 16, 2008 at 9:30 AM, kevin kempter <[EMAIL PROTECTED]> wrote: > Hi All; > > Is there an easy way to determine the actual OS disk cache size or at least > a set of guidelines based on the OS and disk subsystem type ? On a DB only machine, you can expect the OS to use most of the spare memory for disk cache eventually. So, if you've got a 16Gig machine and pgsql and the OS are using ~ 2 Gigs or so, the effective cache size will be what's left. OTOH, if the machine does other things (file / print server, web server, etc...) then you kinda have to fudge factor it. Generally pgsql will still use more disk cache than those other things, due to having more disk access going on all the time, but really it depends on your usage patterns. Luckily Effective cache size is a big course knob so being off by a gig or three isn't a really big deal. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Help request: how to tune performance?
On Tue, Sep 16, 2008 at 11:10:01AM -0600, Scott Marlowe wrote: > On Tue, Sep 16, 2008 at 2:31 AM, Mauri Sahlberg > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the > > database completely own machine. And the users still complain that it is > > dog slow. > > Moved up from below: > > > Version : 8.1.11Vendor: CentOS > > So, you built it its own machine, but you didn't upgrade to at least 8.2? > > Last place I worked we ran rt 3.6.1 and got a noticeable performance > boost from switching to 8.2 but the only thing that was ever really > slow was viewing the rather large approval queue. > > > :-( I installed pg_top and it seems that at the beginning of > > the ticket display RT-issues a query that eats everything the database > > has. Query is as follows: > > > > SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN > > Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN > > CachedGroupMembers CachedGroupMembers_3 ON > > ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE > > (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId = > > CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND > > (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType = > > 'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType = > > 'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType = > > 'RT::System')) ORDER BY main.Name ASC > What is your version of DBIx-SearchBuilder? In particular, the DISTINCT definition was changed from: $$statementref = "SELECT DISTINCT main.* FROM $$statementref"; to: $$statementref = "SELECT main.* FROM ( SELECT DISTINCT main.id FROM $$statementref ) distinctquery, $table main WHERE (main.id = distinctquery.id) "; You can change the line in your version of SearchBuilder and restart RT with a cache flush to get approximately the same benefit. Ken -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Postgres && Swap
Hi All I recently made a change to my Postgres Server and upped the max_fsm_page size to 6 Since then, Postgres has been using about 30-80MB of swap space. This box has 4GB of RAM. All up Postgres has not been allocated no more than 3G Is this swapping something to be worried about? Cheers Steve. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Postgres && Swap
On Tue, Sep 16, 2008 at 11:30 PM, <[EMAIL PROTECTED]> wrote: > Hi All > > > I recently made a change to my Postgres Server and upped the max_fsm_page > size to 6 > Since then, Postgres has been using about 30-80MB of swap space. > > This box has 4GB of RAM. All up Postgres has not been allocated no more > than 3G > > Is this swapping something to be worried about? I recommend turning swappiness down in linux that should stop pg from getting prematurely swapped out like that. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
