Re: [PERFORM] PostgreSQL 9.6 wals management

Thank you for the clarification. בתאריך 20 בנוב׳ 2017 14:28,‏ "Michael Paquier" כתב: > On Mon, Nov 20, 2017 at 6:02 PM, Mariel Cherkassky > wrote: > > This morning , I set the wal_keep_segments to 100 and I set the > > archive_timeout to 6 minutes. Now, after setting those settings and > starti

Re: [PERFORM] PostgreSQL 9.6 wals management

On Mon, Nov 20, 2017 at 6:02 PM, Mariel Cherkassky wrote: > This morning , I set the wal_keep_segments to 100 and I set the > archive_timeout to 6 minutes. Now, after setting those settings and starting > the cluster wals switch is working fine and I didnt see that many wals were > However, doesnt

[PERFORM] PostgreSQL 9.6 wals management

Hi, I'm trying to understand my wals behavior on my postgresql environment. My wal settings are : wal_keep_segments = 200 max_wal_size = 3GB min_wal_size = 80MB archive_command = 'cp %p /PostgreSQL-wal/9.6/pg_xlog/wal_archives/%f' archive_timeout = 10 #checkpoint_flush_afte

Re: [PERFORM] postgresql tuning with perf

Once again you are speaking about edb port of postgresql. The edb pl sql code is not public. This is not the good place to get support: please ask your edb contract manager. If you want support hère: please rewrite your oracle proc in pl pqsql, share that code and commit strategy ... Postgres doesn

Re: [PERFORM] postgresql tuning with perf

We record like this: perf record -g -u enterprisedb We report like this: perf report -g -i perf.data Is this what you were looking for? Sorry, we are new to perf so we might be sharing something different as compared to what you asked. We already shared the SP code in the original post. Thanks

Re: [PERFORM] postgresql tuning with perf

Please share how you monitor your perfs. At less duration for each plpgsql proc / oracle proc. Please share your plpgsql code, and commit strategy. (for support with edb please check with your contract manager) -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.ht

Re: [PERFORM] postgresql tuning with perf

Hi Pascal, Do you mean the sample program that acts as the application, do you want me to share that? I can do that, but I guess my post will get blocked. Yes, c1 is the PK. Pls see below: bmdb=# desc dept_new Table "public.dept_new" Column | Type | Modifiers +

Re: [PERFORM] postgresql tuning with perf

The language used for stored procedures is EDBSPL. Even if we dont use EDBSPL, and instead use PLPgPSQL, the performance is still the same. Thanks On 24 October 2017 at 03:29, Steve Atkins wrote: > > > On Oct 23, 2017, at 12:19 PM, Purav Chovatia wrote: > > > > Hello Experts, > > > > We are tr

Re: [PERFORM] postgresql tuning with perf

> On Oct 23, 2017, at 12:19 PM, Purav Chovatia wrote: > > Hello Experts, > > We are trying to tune our postgresql DB using perf. We are running a C > program that connects to postgres DB and calls very simple StoredProcs, one > each for SELECT, INSERT & UPDATE. > > The SPs are very simple.

Re: [PERFORM] postgresql tuning with perf

On 10/23/2017 09:19 PM, Purav Chovatia wrote: > Hello Experts, > > We are trying to tune our postgresql DB using perf. Can you share some of the perf reports, then? > We are running a C program that connects to postgres DB and calls > very simple StoredProcs, one each for SELECT, INSERT & UPDA

Re: [PERFORM] postgresql tuning with perf

Hi, could you providence the code used with PG ? Has table dept_new an index/pk on c1 ? Do you analyze this table after loading it ? Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html -- Sent via pgsql-performance mailing list (pgsql-performa

[PERFORM] postgresql tuning with perf

Hello Experts, We are trying to tune our postgresql DB using perf. We are running a C program that connects to postgres DB and calls very simple StoredProcs, one each for SELECT, INSERT & UPDATE. The SPs are very simple. *SELECT_SP*: CREATE OR REPLACE PROCEDURE query_dept_new(p1 IN numeric, p2 OU

Re: [PERFORM] postgresql 9.6 data directory fs becomes full

Mariel Cherkassky writes: > I want to check something regarding postgresql performance during my > app is running. > > My app does the next things on 20 tables in a loop : > > 1.truncate table. > 2.drop constraints on table > 3.drop indexes on table > 4.insert into local_table select * from remot

Re: [PERFORM] postgresql 9.6 data directory fs becomes full

Mariel Cherkassky writes: > My app does the next things on 20 tables in a loop : > 1.truncate table. > 2.drop constraints on table > 3.drop indexes on table > 4.insert into local_table select * from remote_oracle_table > 4.1.Recently I'm getting an error in this part : SQLERRM = could not extend

[PERFORM] Postgresql, and ODBC handles

Summary: I am facing a contention problem with ODBC on the client side. strace and perf top show we are serializing over what appears to be accesses to the ODBC statement handle. Contention goes down if I use multiple processes instead of multiple threads within a process. Also, all the threads

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 9/28/2016 13:42, trafdev wrote: > Thanks Jov and Karl! > > What do you think about: > > primarycache=all > > for SELECT queries over same data sets? > >> Yes. >> >> Non-default stuff... >> >> dbms/ticker-9.5 compressratio 1.88x - >> dbms/ticker-9.5 mounted

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

Thanks Jov and Karl! What do you think about: primarycache=all for SELECT queries over same data sets? Yes. Non-default stuff... dbms/ticker-9.5 compressratio 1.88x - dbms/ticker-9.5 mounted yes- dbms/ticker-9.5 quota

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 9/27/2016 23:06, Jov wrote: > > +1 > larger record size can increase compression ratio，so reduce the io. > > Did you set atime off for zfs? > > > 2016年9月28日 6:16 AM，"Karl Denninger" >写道： > > On 9/27/2016 16:38, Tomas Vondra wrote: >> On 09/27/2016 06:00 PM, To

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

using zfs，you can tune full page write off for pg，which can save wal write io. 2016年7月29日 2:05 PM，"trafdev" 写道： > Hi. > > I have an OLAP-oriented DB (light occasional bulk writes and heavy > aggregated selects over large periods of data) based on Postgres 9.5.3. > > Server is a FreeBSD 10.3 with

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

+1 larger record size can increase compression ratio，so reduce the io. Did you set atime off for zfs? 2016年9月28日 6:16 AM，"Karl Denninger" 写道： > On 9/27/2016 16:38, Tomas Vondra wrote: > > On 09/27/2016 06:00 PM, Torsten Zuehlsdorff wrote: > > > > On 29.07.2016 08:30, Tomas Vondra wrote: > > > >

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 9/27/2016 16:38, Tomas Vondra wrote: > On 09/27/2016 06:00 PM, Torsten Zuehlsdorff wrote: >> >> >> On 29.07.2016 08:30, Tomas Vondra wrote: >>> >>> >>> On 07/29/2016 08:04 AM, trafdev wrote: Hi. I have an OLAP-oriented DB (light occasional bulk writes and heavy aggregated sel

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 09/27/2016 06:00 PM, Torsten Zuehlsdorff wrote: On 29.07.2016 08:30, Tomas Vondra wrote: On 07/29/2016 08:04 AM, trafdev wrote: Hi. I have an OLAP-oriented DB (light occasional bulk writes and heavy aggregated selects over large periods of data) based on Postgres 9.5.3. Server is a Fre

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 29.07.2016 08:30, Tomas Vondra wrote: On 07/29/2016 08:04 AM, trafdev wrote: Hi. I have an OLAP-oriented DB (light occasional bulk writes and heavy aggregated selects over large periods of data) based on Postgres 9.5.3. Server is a FreeBSD 10.3 with 64GB of RAM and 2x500GB SSD (root on

Re: [PERFORM] Postgresql 8.4 optimize for heavy select load

You might wanted to upgrade to new version 9.5 with small effort by using pg_upgrade, we have done upgrading and achieve more than 20x faster from 8.4 to 9.5 (it depends on the type of sql statement actually) Jul. Julyanto SUTANDANG Equnix Business Solutions, PT (An Open Source and Open Mind

Re: [PERFORM] Postgresql 8.4 optimize for heavy select load

On 19.09.2016 10:23, Mark Kirkwood wrote: On 19/09/16 19:40, Job wrote: Hello, i would please like to have some suggestions to optimize Postgres 8.4 for a very heavy number of select (with join) queries. The queries read data, very rarely they write. We probably need to see schema and query

Re: [PERFORM] Postgresql 8.4 optimize for heavy select load

On 19/09/16 19:40, Job wrote: Hello, i would please like to have some suggestions to optimize Postgres 8.4 for a very heavy number of select (with join) queries. The queries read data, very rarely they write. We probably need to see schema and query examples to help you (with EXPLAIN ANALY

[PERFORM] Postgresql 8.4 optimize for heavy select load

Hello, i would please like to have some suggestions to optimize Postgres 8.4 for a very heavy number of select (with join) queries. The queries read data, very rarely they write. Thank you! Francesco -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

> - from what I can see, Postgres uses memory too carefully. I would like > somehow to force it to keep accessed data in memory as long as possible. > Instead I often see that even frequently accessed data is pushed out of > memory cache for no apparent reasons. > This is probably a consequence o

Re: [PERFORM] PostgreSQL on ZFS: performance tuning

On 07/29/2016 08:04 AM, trafdev wrote: Hi. I have an OLAP-oriented DB (light occasional bulk writes and heavy aggregated selects over large periods of data) based on Postgres 9.5.3. Server is a FreeBSD 10.3 with 64GB of RAM and 2x500GB SSD (root on ZFS, mirror). The largest table is 13GB (wi

[PERFORM] PostgreSQL on ZFS: performance tuning

Hi. I have an OLAP-oriented DB (light occasional bulk writes and heavy aggregated selects over large periods of data) based on Postgres 9.5.3. Server is a FreeBSD 10.3 with 64GB of RAM and 2x500GB SSD (root on ZFS, mirror). The largest table is 13GB (with a 4GB index on it), other tables ar

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

Hi again, /*Hedayat Vatankhah*/ wrote on Sun, 31 Jan 2016 01:20:53 +0330: Hi, /*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300: On 31 January 2016 at 01:30, Hedayat Vatankhah wrote: Personally, I expect both queries below to perform exactly the same: SELECT t1.id, * FROM

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

Hi, /*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300: On 31 January 2016 at 01:30, Hedayat Vatankhah wrote: Personally, I expect both queries below to perform exactly the same: SELECT t1.id, * FROM t1 INNER JOIN t2 ON t1.id = t2.id where t1.id > -92233720365134113

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

Well, as I can see it was just few phrases unless I miss something. May be it's worth to bring it to -hackers for a wider discussion? Best regards, Vitalii Tymchyshyn Сб, 30 січ. 2016 12:31 David Rowley пише: > On 31 January 2016 at 06:14, Vitalii Tymchyshyn wrote: > > It may be more for -hack

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

On 31 January 2016 at 06:14, Vitalii Tymchyshyn wrote: > It may be more for -hackers, but I often hear "this wont be used because of > planning time increase". Now as I know we have statistics on real query time > after few runs that is used to decide if plan should be switched. > Can this statist

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

It may be more for -hackers, but I often hear "this wont be used because of planning time increase". Now as I know we have statistics on real query time after few runs that is used to decide if plan should be switched. Can this statistics be used to apply advanced planning features for relatively l

Re: [PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

On 31 January 2016 at 01:30, Hedayat Vatankhah wrote: > Personally, I expect both queries below to perform exactly the same: > > SELECT > t1.id, * > FROM > t1 > INNER JOIN > t2 ON t1.id = t2.id > where t1.id > -9223372036513411363; > > And: > > SELECT > t1.id, * > FROM > t1

[PERFORM] PostgreSQL seems to create inefficient plans in simple conditional joins

Dear all, First of all, I should apologize if my email doesn't follow all the guidelines. I'm trying to do that though! If referencing to links is OK, you can find the full description of the issue at: http://dba.stackexchange.com/questions/127082/postgresql-seems-to-create-inefficient-plans-in-si

[PERFORM] postgresql upgrade from 9.3 to 9.4 error

Guys I m trying to upgrade postgresql 9.3 -> 9.4 OS VERSION : CentOS release 6.3 (Final) (2.6.32-279.el6.x86_64.x86_64) When I run the upgrade script /usr/pgsql-9.4/bin/pg_upgrade It gives me this error in the log file. pg_restore: creating VIEW tables pg_restore: [archiver (db)] Error whi

Re: [PERFORM] PostgreSQL limitation

On Mon, Nov 2, 2015 at 7:52 PM, FattahRozzaq wrote: > If I install the PostgreSQL on Linux (Debian), > How much the limit of max_connections that PostgreSQL can take? > How much the limit of max_prepared_transactions that PostgreSQL can take? Per definition, those parameters have a max value of 2

[PERFORM] PostgreSQL limitation

Hi all, If I install the PostgreSQL on Linux (Debian), How much the limit of max_connections that PostgreSQL can take? How much the limit of max_prepared_transactions that PostgreSQL can take? How much the limit of max_files_per_process that PostgreSQL can take? Regards, Fattah -- -- Sent via

Re: [PERFORM] PostgreSQL Tuning for Messaging/Messenger/Chatting Application

With server configuration and application functional we cannot conclude postgresql.conf, application behavior need to consider(mandatory) but, can give some ideal way of calculation 1) shared_buffers can be 7-8% of database size under condition having proper indexes with size not greater then 10-

[PERFORM] PostgreSQL Tuning for Messaging/Messenger/Chatting Application

Dear all, I have server as below: - OS Debian 7.0 (Wheezy) - CPU 24 cores - RAM 128GB - SSD 128GB - 1 Gigabit Ethernet I need to tune the Postgres with hardware specification above for my Messaging/Messenger/Chatting Application that will run separately in another server. Can you give me the rec

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 05/21/2015 01:39 PM, Andres Freund wrote: > On 2015-05-21 11:54:40 -0700, Josh Berkus wrote: >> This has been talked about as a feature, but would require major work on >> PostgreSQL to make it possible. You'd be looking at several months of >> effort by a really good hacker, and then a whole b

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

It may be even easier. AFAIR, it's possible just to tell OS expected allocation without doing it. This way nothing changes for general code, it's only needed to specify expected file size on creation. Please see FILE_ALLOCATION_INFO: https://msdn.microsoft.com/en-us/library/windows/desktop/aa36421

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 2015-05-21 11:54:40 -0700, Josh Berkus wrote: > This has been talked about as a feature, but would require major work on > PostgreSQL to make it possible. You'd be looking at several months of > effort by a really good hacker, and then a whole bunch of performance > testing. If you have the bu

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 04/23/2015 12:47 PM, Jan Gunnar Dyrset wrote: > I think that preallocating lumps of a given, configurable size, say 4 > MB, for the tables would remove this problem. The max number of > fragments on a 1 GB file would then be 250, which is no problem. Is > this possible to configure in PostgreSQ

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 04/29/2015 10:35 AM, k...@rice.edu wrote: On Wed, Apr 29, 2015 at 07:07:04AM -0700, Joshua D. Drake wrote: On 04/29/2015 01:08 AM, Andres Freund wrote: Which OS and filesystem is this done on? Because many halfway modern systems, like e.g ext4 and xfs, implement this in the background as '

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On Wed, Apr 29, 2015 at 07:07:04AM -0700, Joshua D. Drake wrote: > > On 04/29/2015 01:08 AM, Andres Freund wrote: > > >>Which OS and filesystem is this done on? Because many halfway modern > >>systems, like e.g ext4 and xfs, implement this in the background as > >>'delayed allocation'. > > > >Oh,

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 04/29/2015 01:08 AM, Andres Freund wrote: Which OS and filesystem is this done on? Because many halfway modern systems, like e.g ext4 and xfs, implement this in the background as 'delayed allocation'. Oh, it's in the subject. Stupid me, sorry for that. I'd consider testing how much better

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

On 2015-04-29 10:06:39 +0200, Andres Freund wrote: > Hi, > > On 2015-04-23 19:47:06 +, Jan Gunnar Dyrset wrote: > > I am using PostgreSQL to log data in my application. A number of rows > > are added periodically, but there are no updates or deletes. There are > > several applications that log

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

Hi, On 2015-04-23 19:47:06 +, Jan Gunnar Dyrset wrote: > I am using PostgreSQL to log data in my application. A number of rows > are added periodically, but there are no updates or deletes. There are > several applications that log to different databases. > > This causes terrible disk fragmen

[PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

I am using PostgreSQL to log data in my application. A number of rows are added periodically, but there are no updates or deletes. There are several applications that log to different databases. This causes terrible disk fragmentation which again causes performance degradation when retrieving d

Re: [PERFORM] Postgresql Host Swapping Hard With Abundant Free Memory

On 4/17/15 1:25 PM, Christian Gough wrote: Here are our competing theories of why we are swapping as much as 10-15GB with 6GB-10GB of free memory: How are you determining that you're swapping? How are you measuring 'free memory'? 1.) maintenance_work_mem and work_mem are set too high causing

[PERFORM] Postgresql Host Swapping Hard With Abundant Free Memory

Greetings, We have been having some pretty painful site outages related to heavy swapping, even though the system may appear to have as much as 10GB of free memory. It seems that as soon as the system hits ~22GB (of 32GB) of memory usage it starts to swap. As soon as we go below ~22GB, swap is

Re: [PERFORM] Postgresql 9.3 for a Mobile Backend

On 8.5.2014 09:10, Rajiv Kasera wrote: > Dear Community friends, > > > > We are planning to use postgresql 9.3 for building a mobile backend. Can > we get a benchmark on the level of concurrency that can be supported by > Postgres 9.3 and it will be able to handle the spike in traffic if the >

Re: [PERFORM] Postgresql 9.3 for a Mobile Backend

2014-05-08 9:10 GMT+02:00 Rajiv Kasera : > Dear Community friends, > > > > We are planning to use postgresql 9.3 for building a mobile backend. Can > we get a benchmark on the level of concurrency that can be supported by > Postgres 9.3 and it will be able to handle the spike in traffic if the app

[PERFORM] Postgresql 9.3 for a Mobile Backend

Dear Community friends, We are planning to use postgresql 9.3 for building a mobile backend. Can we get a benchmark on the level of concurrency that can be supported by Postgres 9.3 and it will be able to handle the spike in traffic if the app gets popular. Any help regarding the same will

Re: [PERFORM] Postgresql tunning-- help needed

On 21.2.2014 13:22, Ashutosh Durugkar wrote: > Hello Postgresql experts, > > We are facing issues with our PostgreSQL databases running on Ubuntu > server, right after we shifted our databases from OpenSuse O/S. > > It's a new database servers runs fine for most of the time (Avg. > Load 0.5 to 1.0

[PERFORM] Postgresql tunning-- help needed

Hello Postgresql experts, We are facing issues with our PostgreSQL databases running on Ubuntu server, right after we shifted our databases from OpenSuse O/S. It's a new database servers runs fine for most of the time (Avg. Load 0.5 to 1.0) but suddenly spikes once/twice a day.This happens four t

Re: [PERFORM] PostgreSQL 9.3.2 Performance tuning for 32 GB server

On Fri, Jan 31, 2014 at 8:55 AM, Julien Cigar wrote: > On Sat, Jan 25, 2014 at 12:02:59PM +0530, RAMAKRISHNAN KANDASAMY wrote: > > Hi All, > > > > I have configured the blow parameters for a 32 GB server . I this > correct ? > > > > shared_buffers = 6GB > > going over 2GB probably doesn't help >

Re: [PERFORM] PostgreSQL 9.3.2 Performance tuning for 32 GB server

On Sat, Jan 25, 2014 at 12:02:59PM +0530, RAMAKRISHNAN KANDASAMY wrote: > Hi All, > > I have configured the blow parameters for a 32 GB server . I this correct ? > > shared_buffers = 6GB going over 2GB probably doesn't help > work_mem = 24MB maintenance_work_mem = 250MB work_mem depends a lot

[PERFORM] PostgreSQL 9.3.2 Performance tuning for 32 GB server

Hi All, I have configured the blow parameters for a 32 GB server . I this correct ? shared_buffers = 6GB work_mem = 24MB maintenance_work_mem = 250MB effective_cache_size = 16GB shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 1 pg_stat_statements.track = all wal_buffe

Re: [PERFORM] PostgreSQL 9.3.2 Performance issues

"fburg...@radiantblue.com" wrote: > We have 64GB of Memory on RHEL 6.4 > > shared_buffers = 8GB > work_mem = 64MB > maintenance_work_mem = 1GB > effective_cache_size = 48GB > Do these settings look correct for 9.3.2? Maybe. What is your max_connections setting? I find that a good place to sta

[PERFORM] PostgreSQL 9.3.2 Performance issues

We have 64GB of Memory on RHEL 6.4 shared_buffers = 8GB work_mem = 64MB maintenance_work_mem = 1GB effective_cache_size = 48GBI found this list of recommended parameters for memory management in PostgreSQL. About shared_buffers: Below 2GB, set to 20% of total system memory.Below 32GB, set to 25%

[PERFORM] PostgreSQL query for cache performance counters?

Can any one teel me the query to get value for *Number of cached blocks read, Number of cached index blocks read, Number of cached sequence blocks read* in Postgresql? I just find all other queries, except this. so if you know kindly help me. Thanks in advance. -- View this message in context:

Re: [PERFORM] Postgresql in a Virtual Machine

On Fri, Nov 29, 2013 at 3:40 AM, Scott Marlowe wrote: > On Wed, Nov 27, 2013 at 7:58 PM, Dong Ye wrote: > >> As Heikki commented, VMware recently compared Postgres performance in >> an ESX (5.1) VM versus in a comparable native Linux. We saw 1. >> ESX-level locking causes no vertical scalability

Re: [PERFORM] Postgresql in a Virtual Machine

On Wed, Nov 27, 2013 at 7:58 PM, Dong Ye wrote: > As Heikki commented, VMware recently compared Postgres performance in > an ESX (5.1) VM versus in a comparable native Linux. We saw 1. > ESX-level locking causes no vertical scalability degradation, 2. FYI Vmware has an optimized version of Postg

Re: [PERFORM] Postgresql in a Virtual Machine

> There was some earlier comment in this discussion about not using NFS > datastores for Postgres VMDK's. Would you think you'd see a difference in > scalability behavior or performance in these tests if a NFS datastore would > be used instead? Provided the architecture is properly setup for tha

Re: [PERFORM] Postgresql in a Virtual Machine

> > > > I would also make sure to check that the hypervisor does write to > permanent storage before returning to the VM with acknowledgement. > > > In the case of ESX, there is no such concern per > http://kb.vmware.com/kb/1008542. Very useful info! > As Heikki commented, VMware recently comp

Re: [PERFORM] Postgresql in a Virtual Machine

On Mon, Nov 25, 2013 at 4:00 PM, Gudmundsson Martin (mg) wrote: > > I would also make sure to check that the hypervisor does write to permanent > storage before returning to the VM with acknowledgement. > In the case of ESX, there is no such concern per http://kb.vmware.com/kb/1008542. As Heikki

Re: [PERFORM] Postgresql in a Virtual Machine

On Tue, Nov 26, 2013 at 11:18:41AM -0800, Craig James wrote: - On Tue, Nov 26, 2013 at 10:40 AM, Ben Chobot wrote: - - > On Nov 26, 2013, at 9:24 AM, Craig James wrote: - > - > So far I'm impressed by what I've read about Amazon's Postgres instances. - > Maybe the reality will be disappointing, b

Re: [PERFORM] Postgresql in a Virtual Machine

On Tue, Nov 26, 2013 at 10:40 AM, Ben Chobot wrote: > On Nov 26, 2013, at 9:24 AM, Craig James wrote: > > So far I'm impressed by what I've read about Amazon's Postgres instances. > Maybe the reality will be disappointing, but (for example) the idea of > setting up streaming replication with one

Re: [PERFORM] Postgresql in a Virtual Machine

On Nov 26, 2013, at 9:24 AM, Craig James wrote: > So far I'm impressed by what I've read about Amazon's Postgres instances. > Maybe the reality will be disappointing, but (for example) the idea of > setting up streaming replication with one click is pretty appealing. Where did you hear this was

Re: [PERFORM] Postgresql in a Virtual Machine

On Tue, Nov 26, 2013 at 11:31 AM, Josh Berkus wrote: > On 11/25/2013 12:01 PM, Lee Nguyen wrote: >> Hi, >> >> Having attended a few PGCons, I've always heard the remark from a few >> presenters and attendees that Postgres shouldn't be run inside a VM. That >> bare metal is the only way to go. > >

Re: [PERFORM] Postgresql in a Virtual Machine

On 11/25/2013 12:01 PM, Lee Nguyen wrote: > Hi, > > Having attended a few PGCons, I've always heard the remark from a few > presenters and attendees that Postgres shouldn't be run inside a VM. That > bare metal is the only way to go. This is pretty dated advice. Early VMs had horrible performanc

Re: [PERFORM] Postgresql in a Virtual Machine

On Tue, Nov 26, 2013 at 8:29 AM, David Boreham wrote: > On 11/26/2013 7:26 AM, Craig James wrote: > >> >> For those of us with small (a few to a dozen servers), we'd like to get >> out of server maintenance completely. Can anyone with experience on a cloud >> VM solution comment? ... >> > > I've

Re: [PERFORM] Postgresql in a Virtual Machine

On 11/26/2013 7:26 AM, Craig James wrote: For those of us with small (a few to a dozen servers), we'd like to get out of server maintenance completely. Can anyone with experience on a cloud VM solution comment? Do the VM solutions provided by the major hosting companies have the same good pe

Re: [PERFORM] Postgresql in a Virtual Machine

On 11/26/2013 08:51 AM, Boszormenyi Zoltan wrote: 2013-11-25 21:19 keltezéssel, Heikki Linnakangas írta: On 25.11.2013 22:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That

Re: [PERFORM] Postgresql in a Virtual Machine

On 11/26/2013 09:26 AM, Craig James wrote: On 25.11.2013 22:01, Lee Nguyen wrote: Why shouldn't we run Postgres in a VM? What are the downsides? Does anyone have any metrics or benchmarks with the latest Postgres? For those of us with small (a fe

Re: [PERFORM] Postgresql in a Virtual Machine

> > On 25.11.2013 22:01, Lee Nguyen wrote: >> >>> >>> Why shouldn't we run Postgres in a VM? What are the downsides? Does >>> anyone >>> have any metrics or benchmarks with the latest Postgres? >>> >> For those of us with small (a few to a dozen servers), we'd like to get out of server maintenance

Re: [PERFORM] Postgresql in a Virtual Machine

Zoltan, * Boszormenyi Zoltan (z...@cybertec.at) wrote: > When the virtual disk is a disk file on the host machine, we've measured > 20% or lower. The host used Fedora 19/x86_64 with IIRC a 3.10.x Linux kernel > with EXT4 filesystem (this latter is sure, not IIRC). The effect was observed > both un

Re: [PERFORM] Postgresql in a Virtual Machine

2013-11-25 21:19 keltezéssel, Heikki Linnakangas írta: On 25.11.2013 22:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we we

Re: [PERFORM] Postgresql in a Virtual Machine

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2013 09:01 PM, Lee Nguyen wrote: > Hi, > > Having attended a few PGCons, I've always heard the remark from a > few presenters and attendees that Postgres shouldn't be run inside > a VM. That bare metal is the only way to go. > []

Re: [PERFORM] Postgresql in a Virtual Machine

Which scenario do you have in mind? We don't add servers to scale out, we only scale up in each single project. We use SAN for storage, so if we need to increase disk space we provide more through LVM. There is one case we need to move data around, when we relocate projects over to new storage (eg

Re: [PERFORM] Postgresql in a Virtual Machine

On Tue, 26 Nov 2013, Xenofon Papadopoulos wrote: We have been running several Postgres databases on VMs for the last 9 months. The largest one currently has a few hundreds of millions of rows (~1.5T of data, ~100G of frequently queried data ) and performs at ~1000 tps. Most of our transactions a

Re: [PERFORM] Postgresql in a Virtual Machine

We have been running several Postgres databases on VMs for the last 9 months. The largest one currently has a few hundreds of millions of rows (~1.5T of data, ~100G of frequently queried data ) and performs at ~1000 tps. Most of our transactions are part of a 2PC, which effectively results to high

Re: [PERFORM] Postgresql in a Virtual Machine

On Mon, Nov 25, 2013 at 4:57 PM, David Lang wrote: > On Mon, 25 Nov 2013, Merlin Moncure wrote: > >> On Mon, Nov 25, 2013 at 2:01 PM, Lee Nguyen wrote: >>> >>> Hi, >>> >>> Having attended a few PGCons, I've always heard the remark from a few >>> presenters and attendees that Postgres shouldn't be

Re: [PERFORM] Postgresql in a Virtual Machine

On Mon, 25 Nov 2013, Merlin Moncure wrote: On Mon, Nov 25, 2013 at 2:01 PM, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we

Re: [PERFORM] Postgresql in a Virtual Machine

On Mon, Nov 25, 2013 at 2:01 PM, Lee Nguyen wrote: > Hi, > > Having attended a few PGCons, I've always heard the remark from a few > presenters and attendees that Postgres shouldn't be run inside a VM. That > bare metal is the only way to go. > > Here at work we were entertaining the idea of runni

Re: [PERFORM] Postgresql in a Virtual Machine

On 26/11/13 09:28, Andrew Dunstan wrote: On 11/25/2013 03:19 PM, Heikki Linnakangas wrote: On 25.11.2013 22:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is t

Re: [PERFORM] Postgresql in a Virtual Machine

Hi! We have virtualized several hundreds of production databases, mostly Oracle and DB2 but a few postgres as well, and we have seen a very positive effect in doing this. We might loose a little bit in virtualization overhead but have gained a lot in flexibility and managebility. My tips are t

Re: [PERFORM] Postgresql in a Virtual Machine

On 11/25/2013 03:19 PM, Heikki Linnakangas wrote: On 25.11.2013 22:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we were

Re: [PERFORM] Postgresql in a Virtual Machine

On 25.11.2013 22:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we were entertaining the idea of running our Postgres databas

Re: [PERFORM] Postgresql in a Virtual Machine

On 26/11/13 09:01, Lee Nguyen wrote: Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we were entertaining the idea of running our Postgres datab

[PERFORM] Postgresql in a Virtual Machine

Hi, Having attended a few PGCons, I've always heard the remark from a few presenters and attendees that Postgres shouldn't be run inside a VM. That bare metal is the only way to go. Here at work we were entertaining the idea of running our Postgres database on our VM farm alongside our applicatio

Re: [PERFORM] postgresql recommendation memory

Sergey i will try to monitor my pgsql activity for several days. Scott about pooling connection. Yesterday i start read about spring implementation of jdbc our app use dbcp implementation: http://commons.apache.org/proper/commons-dbcp/configuration.html So i have this parameter in config

Re: [PERFORM] postgresql recommendation memory

On Thu, Nov 7, 2013 at 2:13 AM, Евгений Селявка wrote: > All my sar statistics > ... > sar -u ALL > 11:40:02 AM CPU %usr %nice %sys %iowait%steal > %irq %soft%guest %idle > 01:15:01 PM all 8.57 0.00 1.52 1.46 0.00 > 0.00 0.05

Re: [PERFORM] postgresql recommendation memory

On Mon, Nov 11, 2013 at 8:14 AM, Scott Marlowe wrote: > well you can hopefully reduce connections from jdbc pooling then. The > fact that the connections are idle is good. > > The problem you run into is what happens when things go into > "overload" I.e. when the db server starts to slow down, mor

Re: [PERFORM] postgresql recommendation memory

On Sun, Nov 10, 2013 at 11:48 PM, Евгений Селявка wrote: > Sergey, yes this is all of my kernel setting. I don't use THP intentionally. > I think that i need a special library to use THP with postgresql like this > http://code.google.com/p/pgcookbook/wiki/Database_Server_Configuration. This > i

Re: [PERFORM] postgresql recommendation memory

On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote: > On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка > wrote: > > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections > > from components wich use jdbc. I don't think that this is a good idea use > > pgbouncer, be

  1   2   3   4   5   6   7   8   9   10   >