Re: [PERFORM] - why only 9.1?
W dniu 2013-04-21 19:28, Scott Marlowe pisze: My DB version is little old - 8.1.18. Well upgrade as soon as possible. 9.1 is pretty darn stable. Scott, excuse me this somewhat off-topic question. Good to hear that 9.1 is so stable, because this is what I currently use in production. But why I still use it, is only because I failed to manage my task to migrate to 9.2, so far. Anyway, this task in on my long-term agenda. So, let me understand why, as you recommend the OP upgrading, you only mention the 9.1, while there have already been a few releases of 9.2. Isn't 9.2 stable enough? Best regards Irek. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] template1 vacuuming consuming much time compared to another production DBs
Hi, I am using postgresql 8.1 DB. I have a large DB and i run the vacuum every hour with vocuumdb --analyze -a option. Some times template1 consumes much time in comparison to my own DB.I think at these times the load on OS is higher. But from iostat logs i can see that the load on the partition where DB resides is not too much. I would like to know why such thing happens? What are the processing that is carried out with the template1 vacuuming. When the entries in template1 is updated and inserted? What should be the frequency of template1 vacuuming? Is template1 is updated as frequent as my own DB is updated? Thanks, Pradeep -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] template1 vacuuming consuming much time compared to another production DBs
On 04/22/2013 07:31 AM, pradeep singh wrote: Hi, I am using postgresql 8.1 DB. Why are you using a release of Postgres that is way out of date and unsupported? cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] Performance with the new security release
Hi, We are seeing some overall performance degradation in our application since we installed the security release. Other commits were also done at the same time in the application so we don't know yet if the degradation has any relationship with the security release. While we are digging into this, I would like to know if it is possible that the release has some impact on performance. After reading this It was created as a side effect of a refactoring effort to make establishing new connections to a PostgreSQL server faster, and the associated code more maintainable., I am thinking it is quite possible. Please let me know. Thanks, Anne
Re: [PERFORM] Performance with the new security release
On 22.04.2013 19:48, Anne Rosset wrote: Hi, We are seeing some overall performance degradation in our application since we installed the security release. Other commits were also done at the same time in the application so we don't know yet if the degradation has any relationship with the security release. While we are digging into this, I would like to know if it is possible that the release has some impact on performance. After reading this It was created as a side effect of a refactoring effort to make establishing new connections to a PostgreSQL server faster, and the associated code more maintainable., I am thinking it is quite possible. I doubt that particular commit, the one that fixed the security issue, could cause any meaningful slowdown. But it's not impossible that some other fix included in the release would cause a regression, although we try to be careful to avoid that. If you narrow the culprit down to the new PostgreSQL version, we're going to need more details to find the root cause. - Heikki -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Issues with OSX and SHMMAX?
On 04/21/2013 02:33 PM, Evgeny Shishkin wrote: On Apr 22, 2013, at 1:29 AM, Josh Berkus j...@agliodbs.com wrote: Folks, I've heard a rumor that the most recent update of OSX mountain lion lowers the installed SHMMAX to 4MB, which prevents PostgreSQL from installing. Can anyone verify this? kern.sysv.shmmax: 4194304 That would be 4MB. Can anyone else verify this? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Issues with OSX and SHMMAX?
On Apr 22, 2013, at 11:19 AM, Josh Berkus j...@agliodbs.com wrote: On 04/21/2013 02:33 PM, Evgeny Shishkin wrote: On Apr 22, 2013, at 1:29 AM, Josh Berkus j...@agliodbs.com wrote: Folks, I've heard a rumor that the most recent update of OSX mountain lion lowers the installed SHMMAX to 4MB, which prevents PostgreSQL from installing. Can anyone verify this? kern.sysv.shmmax: 4194304 That would be 4MB. Can anyone else verify this? It's the default setting on my 10.8.3 box. (I'm setting it higher in /etc/sysctl.conf and have no problems, but it stopped postgres.app starting when I removed that). Cheers, Steve -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Issues with OSX and SHMMAX?
Steve Atkins st...@blighty.com writes: On Apr 22, 2013, at 11:19 AM, Josh Berkus j...@agliodbs.com wrote: On 04/21/2013 02:33 PM, Evgeny Shishkin wrote: On Apr 22, 2013, at 1:29 AM, Josh Berkus j...@agliodbs.com wrote: I've heard a rumor that the most recent update of OSX mountain lion lowers the installed SHMMAX to 4MB, which prevents PostgreSQL from installing. Can anyone verify this? kern.sysv.shmmax: 4194304 That would be 4MB. Can anyone else verify this? It's the default setting on my 10.8.3 box. (I'm setting it higher in /etc/sysctl.conf and have no problems, but it stopped postgres.app starting when I removed that). AFAIR, the default setting has been that or lower in every previous version of OSX, so it seems unlikely that mountain lion per se broke anything. It might've appeared that way if you did a reinstall and forgot to copy your old /etc/sysctl.conf. A different theory, if things used to work and now don't, is that somewhere recently we crossed a threshold in memory usage between will start at 4MB and won't start at 4MB. If so, 9.3 ought to make things better (since we're mostly getting out from under SysV shared memory limits), but in existing releases manually fixing the limit will be the only recourse. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] template1 vacuuming consuming much time compared to another production DBs
I am using this DB since last 3 or 4 years. And suddenly we can't update it. We are planning it at the end of year. Recently we faced the template1 wraparound issue. So we added template1 also for vacuuming. We are vacuuming the DB each hour with 'vacuumdb --analyze -a' options. Now the vacuuming of template1 consumes time. And the queries become slow. From the logs i find that during this we period there are lot of backend processes in startup state. so i think connection open is slow. They are waiting on WCHAN log_wait_. So could you please recommend what may be the problem. FYI there is much load on OS this time. And why vacuuming of template1 only consumes time not other DBs? On Mon, Apr 22, 2013 at 9:08 PM, Andrew Dunstan and...@dunslane.net wrote: On 04/22/2013 07:31 AM, pradeep singh wrote: Hi, I am using postgresql 8.1 DB. Why are you using a release of Postgres that is way out of date and unsupported? cheers andrew -- pradeep singh biet jhansi
