Menu
▾
▴
postgres-xc-general — General info and messages
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
| 2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
| 2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
| 2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jim M. <ji...@gm...> - 2013-03-19 17:06:41
|
For your XC test, are you splitting your connections across the
coordinators with half of your psql sessions pointing to q1 and half
to q2?
On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote:
> For PG (no-XC) it looks like I'm pegged on disk (still getting better
> instrumentation). I would expect that my disk usage would be nearly
> halved when striping data - still gathering info though.
>
> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote:
>
>>It may be easier to just concentrate on the PostgreSQL test to find
>>the bottleneck. The fact that the XC test (without GTM Proxy) and the
>>PostgreSQL test is so similar, is leading me to believe you're hitting
>>the same bottleneck.
>>
>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> wrote:
>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy
>>>boxes gets to around 85%. I'll need some more instrumentation to be
>>>sure - I'll get back to you with details.
>>>
>>> Chris...
>>>
>>> ________________________________________
>>> From: Jim Mlodgenski [ji...@gm...]
>>> Sent: March 19, 2013 8:32 AM
>>> To: Chris Brown
>>> Cc: pos...@li...
>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>
>>> When running the test against straight PostgreSQL, where is the
>>> bottleneck? Are you CPU bound or IO bound?
>>>
>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...>
>>>wrote:
>>>> I also just discovered that my assumption about postgres (non xc)
>>>>being 9.2 was incorrect:
>>>> postgresql-server-9.1.7-1.fc16.x86_64
>>>> Oops, sorry about the misinformation.
>>>>
>>>> Chris...
>>>> ________________________________________
>>>> From: Chris Brown [cb...@in...]
>>>> Sent: March 19, 2013 7:45 AM
>>>> To: Jim Mlodgenski
>>>> Cc: pos...@li...
>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>
>>>> Hi Jim,
>>>>
>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing
>>>>the inserts as actual inserts performed by psql. They are not batched
>>>>- there is one insert per line and each file contains about 10,000
>>>>inserts. This was a conscious choice since I was testing expected
>>>>transaction rate as opposed to import rate.
>>>>
>>>> I haven't done much tuning to postgres. Datanodes received this:
>>>> checkpoint_segements=32
>>>> effective_cache_size=4GB
>>>> shared_buffers=4GB
>>>> random_page_cost=3.0
>>>> For the coordinators, no tuning was done.
>>>> For xc, I also added:
>>>> max_prepared_transactions = 10
>>>> gtm_host = 'localhost' # or the remote host, as appropriate on
>>>>coordinators
>>>> gtm_port = 6666
>>>> Otherwise the postgresql.conf file is the default one provided by
>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am
>>>>using the defaults of wal_level(minimum), fsync(on),
>>>>wal_sync_method(fdatasync).
>>>>
>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and
>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables:
>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s test)
>>>>which leads me to believe that the 5m50s number is slightly in error.
>>>>
>>>> Chris...
>>>>
>>>> ________________________________________
>>>> From: Jim Mlodgenski [ji...@gm...]
>>>> Sent: March 19, 2013 7:26 AM
>>>> To: Chris Brown
>>>> Cc: Koichi Suzuki; pos...@li...
>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>
>>>> Can you send along some more details of the test? I find it odd that
>>>> in every scenario, the load times are consistent despite the change in
>>>> the number of threads. Are you committing your transaction after each
>>>> insert? If so, your limiting factor is probably the fsync to disk
>>>> which would account for why PostgreSQL 9.2 is about the same speed as
>>>> XC 1.0.
>>>>
>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...>
>>>>wrote:
>>>>> Here's a sample table:
>>>>>
>>>>> CREATE TABLE table_11 (
>>>>> "part" int not null,
>>>>> "key1" bigint not null,
>>>>> "key2" bigint not null,
>>>>> "col_1" varchar(23),
>>>>> "col_2" varchar(5),
>>>>> "col_3" varchar(32),
>>>>> "col_4" varchar(5),
>>>>> PRIMARY KEY(part,key1,key2)
>>>>> );
>>>>>
>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps
>>>>>incorrectly, that hash on the first element of the primary key would
>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY
>>>>>HASH(part).
>>>>>
>>>>> Chris...
>>>>> ________________________________________
>>>>> From: Koichi Suzuki [koi...@gm...]
>>>>> Sent: March 18, 2013 10:47 PM
>>>>> To: Chris Brown
>>>>> Cc: pos...@li...
>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>>
>>>>> What kind of distribution did you use in your case? If all the
>>>>> tables are replicated, all the inserts are associated with implicit
>>>>> 2PCs. Frequently-updated tables should be distributed (hash will be
>>>>> better if the table has a suitable column).
>>>>>
>>>>> Regards;
>>>>> ----------
>>>>> Koichi Suzuki
>>>>>
>>>>>
>>>>> 2013/3/19 Chris Brown <cb...@in...>:
>>>>>> Hi all,
>>>>>>
>>>>>> I've been doing some performance testing of PostgreSQL-XC. My
>>>>>>workload is
>>>>>> all insert in this case. I was expecting PG-XC to perform worse
>>>>>>than the
>>>>>> alternatives but I was shocked by how much worse it was than
>>>>>>PostgreSQL.
>>>>>> I'm well aware that NDB has durability and features issues so I
>>>>>>expected
>>>>>> it to perform better - I don't consider the 0.8 to be particularly
>>>>>> interesting. I'd like anyone's thoughts on this.
>>>>>>
>>>>>> Chris...
>>>>>>
>>>>>>
>>>>>> Results:
>>>>>>
>>>>>> All results are very approximate!
>>>>>> CPU is an estimate on the number of cores used by server processes
>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline
>>>>>>and is
>>>>>> intended to represent a comparative CPU cost for a single insert
>>>>>> transaction.
>>>>>>
>>>>>> Client PostgreSQL PostgreSQL-XC MySQL
>>>>>>Cluster
>>>>>> PostgreSQL-XC-2
>>>>>> Threads Time CPU TC Time CPU TC Time
>>>>>>CPU
>>>>>> TC Time CPU TC
>>>>>> 16 5m08s 4.3 cores 1.0
>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s
>>>>>>7.8
>>>>>> cores 0.8
>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s
>>>>>>8.0
>>>>>> cores 0.8 6m06s 10.2 cores 2.7
>>>>>> 64 5m01s 13.1 cores 2.9 2m11s
>>>>>>8.3
>>>>>> cores 0.8 5m50s 10.5 cores 2.7
>>>>>> 96 2m13s
>>>>>>8.4
>>>>>> cores 0.8
>>>>>>
>>>>>>
>>>>>> Configurations:
>>>>>>
>>>>>> PostgreSQL:
>>>>>> Datanodes q1
>>>>>> Version: 9.2.x (redhat)
>>>>>>
>>>>>> PostgreSQL-XC:
>>>>>> Datanodes q1-q2 (striped)
>>>>>> Coordinators q1-q2
>>>>>> GTM q3
>>>>>> Version 9.1.7 (tar)
>>>>>>
>>>>>> PostgreSQL-XC-2:
>>>>>> Datanodes q1-q2 (striped)
>>>>>> Coordinators q1-q2
>>>>>> GTM Proxy q1-q2
>>>>>> GTM q3
>>>>>> Version 9.1.7 (tar)
>>>>>>
>>>>>> MySQL Cluster:
>>>>>> ndbmtd q1-q2 (striped)
>>>>>> mysqld q1-q2
>>>>>> ndb_mgmd q1
>>>>>> Version 7.1.17 (oracle rhel 5)
>>>>>>
>>>>>> q1, q2, q3 are identical boxes each with:
>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram
>>>>>>and 3
>>>>>> platters in raid 5.
>>>>>> They are lan local with a vlan-aware switch (I don't know which one
>>>>>>and I
>>>>>> didn't check to see if it was saturated).
>>>>>>
>>>>>>
>>>>>> Tables & Data:
>>>>>>
>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not
>>>>>>null,
>>>>>> "key2" bigint not null). Each table has a selection of varchar
>>>>>>columns
>>>>>> typically less than varchar(80). All non-primary-key columns have
>>>>>> non-unique indexes. 5.8 million rows were imported with a different
>>>>>> number of rows to each table.
>>>>>>
>>>>>>
>>>>>>
>>>>>>----------------------------------------------------------------------
>>>>>>--------
>>>>>> Everyone hates slow websites. So do we.
>>>>>> Make your web apps faster with AppDynamics
>>>>>> Download AppDynamics Lite for free today:
>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>>> _______________________________________________
>>>>>> Postgres-xc-general mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>>
>>>>>
>>>>>-----------------------------------------------------------------------
>>>>>-------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>> _______________________________________________
>>>>> Postgres-xc-general mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
|
|
From: Chris B. <cb...@in...> - 2013-03-19 17:01:36
|
For PG (no-XC) it looks like I'm pegged on disk (still getting better
instrumentation). I would expect that my disk usage would be nearly
halved when striping data - still gathering info though.
On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote:
>It may be easier to just concentrate on the PostgreSQL test to find
>the bottleneck. The fact that the XC test (without GTM Proxy) and the
>PostgreSQL test is so similar, is leading me to believe you're hitting
>the same bottleneck.
>
>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> wrote:
>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy
>>boxes gets to around 85%. I'll need some more instrumentation to be
>>sure - I'll get back to you with details.
>>
>> Chris...
>>
>> ________________________________________
>> From: Jim Mlodgenski [ji...@gm...]
>> Sent: March 19, 2013 8:32 AM
>> To: Chris Brown
>> Cc: pos...@li...
>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>
>> When running the test against straight PostgreSQL, where is the
>> bottleneck? Are you CPU bound or IO bound?
>>
>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...>
>>wrote:
>>> I also just discovered that my assumption about postgres (non xc)
>>>being 9.2 was incorrect:
>>> postgresql-server-9.1.7-1.fc16.x86_64
>>> Oops, sorry about the misinformation.
>>>
>>> Chris...
>>> ________________________________________
>>> From: Chris Brown [cb...@in...]
>>> Sent: March 19, 2013 7:45 AM
>>> To: Jim Mlodgenski
>>> Cc: pos...@li...
>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>
>>> Hi Jim,
>>>
>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing
>>>the inserts as actual inserts performed by psql. They are not batched
>>>- there is one insert per line and each file contains about 10,000
>>>inserts. This was a conscious choice since I was testing expected
>>>transaction rate as opposed to import rate.
>>>
>>> I haven't done much tuning to postgres. Datanodes received this:
>>> checkpoint_segements=32
>>> effective_cache_size=4GB
>>> shared_buffers=4GB
>>> random_page_cost=3.0
>>> For the coordinators, no tuning was done.
>>> For xc, I also added:
>>> max_prepared_transactions = 10
>>> gtm_host = 'localhost' # or the remote host, as appropriate on
>>>coordinators
>>> gtm_port = 6666
>>> Otherwise the postgresql.conf file is the default one provided by
>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am
>>>using the defaults of wal_level(minimum), fsync(on),
>>>wal_sync_method(fdatasync).
>>>
>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and
>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables:
>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
>>> It didn't make an appreciable difference (~10 seconds on a 5m50s test)
>>>which leads me to believe that the 5m50s number is slightly in error.
>>>
>>> Chris...
>>>
>>> ________________________________________
>>> From: Jim Mlodgenski [ji...@gm...]
>>> Sent: March 19, 2013 7:26 AM
>>> To: Chris Brown
>>> Cc: Koichi Suzuki; pos...@li...
>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>
>>> Can you send along some more details of the test? I find it odd that
>>> in every scenario, the load times are consistent despite the change in
>>> the number of threads. Are you committing your transaction after each
>>> insert? If so, your limiting factor is probably the fsync to disk
>>> which would account for why PostgreSQL 9.2 is about the same speed as
>>> XC 1.0.
>>>
>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...>
>>>wrote:
>>>> Here's a sample table:
>>>>
>>>> CREATE TABLE table_11 (
>>>> "part" int not null,
>>>> "key1" bigint not null,
>>>> "key2" bigint not null,
>>>> "col_1" varchar(23),
>>>> "col_2" varchar(5),
>>>> "col_3" varchar(32),
>>>> "col_4" varchar(5),
>>>> PRIMARY KEY(part,key1,key2)
>>>> );
>>>>
>>>> I guess I'm not specifying a distribution key. I assumed, perhaps
>>>>incorrectly, that hash on the first element of the primary key would
>>>>be the default. I will try a run with an explicit DISTRIBUTE BY
>>>>HASH(part).
>>>>
>>>> Chris...
>>>> ________________________________________
>>>> From: Koichi Suzuki [koi...@gm...]
>>>> Sent: March 18, 2013 10:47 PM
>>>> To: Chris Brown
>>>> Cc: pos...@li...
>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>
>>>> What kind of distribution did you use in your case? If all the
>>>> tables are replicated, all the inserts are associated with implicit
>>>> 2PCs. Frequently-updated tables should be distributed (hash will be
>>>> better if the table has a suitable column).
>>>>
>>>> Regards;
>>>> ----------
>>>> Koichi Suzuki
>>>>
>>>>
>>>> 2013/3/19 Chris Brown <cb...@in...>:
>>>>> Hi all,
>>>>>
>>>>> I've been doing some performance testing of PostgreSQL-XC. My
>>>>>workload is
>>>>> all insert in this case. I was expecting PG-XC to perform worse
>>>>>than the
>>>>> alternatives but I was shocked by how much worse it was than
>>>>>PostgreSQL.
>>>>> I'm well aware that NDB has durability and features issues so I
>>>>>expected
>>>>> it to perform better - I don't consider the 0.8 to be particularly
>>>>> interesting. I'd like anyone's thoughts on this.
>>>>>
>>>>> Chris...
>>>>>
>>>>>
>>>>> Results:
>>>>>
>>>>> All results are very approximate!
>>>>> CPU is an estimate on the number of cores used by server processes
>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline
>>>>>and is
>>>>> intended to represent a comparative CPU cost for a single insert
>>>>> transaction.
>>>>>
>>>>> Client PostgreSQL PostgreSQL-XC MySQL
>>>>>Cluster
>>>>> PostgreSQL-XC-2
>>>>> Threads Time CPU TC Time CPU TC Time
>>>>>CPU
>>>>> TC Time CPU TC
>>>>> 16 5m08s 4.3 cores 1.0
>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s
>>>>>7.8
>>>>> cores 0.8
>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s
>>>>>8.0
>>>>> cores 0.8 6m06s 10.2 cores 2.7
>>>>> 64 5m01s 13.1 cores 2.9 2m11s
>>>>>8.3
>>>>> cores 0.8 5m50s 10.5 cores 2.7
>>>>> 96 2m13s
>>>>>8.4
>>>>> cores 0.8
>>>>>
>>>>>
>>>>> Configurations:
>>>>>
>>>>> PostgreSQL:
>>>>> Datanodes q1
>>>>> Version: 9.2.x (redhat)
>>>>>
>>>>> PostgreSQL-XC:
>>>>> Datanodes q1-q2 (striped)
>>>>> Coordinators q1-q2
>>>>> GTM q3
>>>>> Version 9.1.7 (tar)
>>>>>
>>>>> PostgreSQL-XC-2:
>>>>> Datanodes q1-q2 (striped)
>>>>> Coordinators q1-q2
>>>>> GTM Proxy q1-q2
>>>>> GTM q3
>>>>> Version 9.1.7 (tar)
>>>>>
>>>>> MySQL Cluster:
>>>>> ndbmtd q1-q2 (striped)
>>>>> mysqld q1-q2
>>>>> ndb_mgmd q1
>>>>> Version 7.1.17 (oracle rhel 5)
>>>>>
>>>>> q1, q2, q3 are identical boxes each with:
>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram
>>>>>and 3
>>>>> platters in raid 5.
>>>>> They are lan local with a vlan-aware switch (I don't know which one
>>>>>and I
>>>>> didn't check to see if it was saturated).
>>>>>
>>>>>
>>>>> Tables & Data:
>>>>>
>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not
>>>>>null,
>>>>> "key2" bigint not null). Each table has a selection of varchar
>>>>>columns
>>>>> typically less than varchar(80). All non-primary-key columns have
>>>>> non-unique indexes. 5.8 million rows were imported with a different
>>>>> number of rows to each table.
>>>>>
>>>>>
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>--------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>> _______________________________________________
>>>>> Postgres-xc-general mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>-------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>>>
>>>------------------------------------------------------------------------
>>>------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Jim M. <ji...@gm...> - 2013-03-19 15:40:50
|
It may be easier to just concentrate on the PostgreSQL test to find
the bottleneck. The fact that the XC test (without GTM Proxy) and the
PostgreSQL test is so similar, is leading me to believe you're hitting
the same bottleneck.
On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> wrote:
> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy boxes gets to around 85%. I'll need some more instrumentation to be sure - I'll get back to you with details.
>
> Chris...
>
> ________________________________________
> From: Jim Mlodgenski [ji...@gm...]
> Sent: March 19, 2013 8:32 AM
> To: Chris Brown
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> When running the test against straight PostgreSQL, where is the
> bottleneck? Are you CPU bound or IO bound?
>
> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> wrote:
>> I also just discovered that my assumption about postgres (non xc) being 9.2 was incorrect:
>> postgresql-server-9.1.7-1.fc16.x86_64
>> Oops, sorry about the misinformation.
>>
>> Chris...
>> ________________________________________
>> From: Chris Brown [cb...@in...]
>> Sent: March 19, 2013 7:45 AM
>> To: Jim Mlodgenski
>> Cc: pos...@li...
>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>
>> Hi Jim,
>>
>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing the inserts as actual inserts performed by psql. They are not batched - there is one insert per line and each file contains about 10,000 inserts. This was a conscious choice since I was testing expected transaction rate as opposed to import rate.
>>
>> I haven't done much tuning to postgres. Datanodes received this:
>> checkpoint_segements=32
>> effective_cache_size=4GB
>> shared_buffers=4GB
>> random_page_cost=3.0
>> For the coordinators, no tuning was done.
>> For xc, I also added:
>> max_prepared_transactions = 10
>> gtm_host = 'localhost' # or the remote host, as appropriate on coordinators
>> gtm_port = 6666
>> Otherwise the postgresql.conf file is the default one provided by initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am using the defaults of wal_level(minimum), fsync(on), wal_sync_method(fdatasync).
>>
>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and MODULO, confirming the obj_MODULO and obj_HASH in the tables:
>> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
>> It didn't make an appreciable difference (~10 seconds on a 5m50s test) which leads me to believe that the 5m50s number is slightly in error.
>>
>> Chris...
>>
>> ________________________________________
>> From: Jim Mlodgenski [ji...@gm...]
>> Sent: March 19, 2013 7:26 AM
>> To: Chris Brown
>> Cc: Koichi Suzuki; pos...@li...
>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>
>> Can you send along some more details of the test? I find it odd that
>> in every scenario, the load times are consistent despite the change in
>> the number of threads. Are you committing your transaction after each
>> insert? If so, your limiting factor is probably the fsync to disk
>> which would account for why PostgreSQL 9.2 is about the same speed as
>> XC 1.0.
>>
>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
>>> Here's a sample table:
>>>
>>> CREATE TABLE table_11 (
>>> "part" int not null,
>>> "key1" bigint not null,
>>> "key2" bigint not null,
>>> "col_1" varchar(23),
>>> "col_2" varchar(5),
>>> "col_3" varchar(32),
>>> "col_4" varchar(5),
>>> PRIMARY KEY(part,key1,key2)
>>> );
>>>
>>> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>>>
>>> Chris...
>>> ________________________________________
>>> From: Koichi Suzuki [koi...@gm...]
>>> Sent: March 18, 2013 10:47 PM
>>> To: Chris Brown
>>> Cc: pos...@li...
>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>
>>> What kind of distribution did you use in your case? If all the
>>> tables are replicated, all the inserts are associated with implicit
>>> 2PCs. Frequently-updated tables should be distributed (hash will be
>>> better if the table has a suitable column).
>>>
>>> Regards;
>>> ----------
>>> Koichi Suzuki
>>>
>>>
>>> 2013/3/19 Chris Brown <cb...@in...>:
>>>> Hi all,
>>>>
>>>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>>>> all insert in this case. I was expecting PG-XC to perform worse than the
>>>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>>>> I'm well aware that NDB has durability and features issues so I expected
>>>> it to perform better - I don't consider the 0.8 to be particularly
>>>> interesting. I'd like anyone's thoughts on this.
>>>>
>>>> Chris...
>>>>
>>>>
>>>> Results:
>>>>
>>>> All results are very approximate!
>>>> CPU is an estimate on the number of cores used by server processes
>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>>>> intended to represent a comparative CPU cost for a single insert
>>>> transaction.
>>>>
>>>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>>>> PostgreSQL-XC-2
>>>> Threads Time CPU TC Time CPU TC Time CPU
>>>> TC Time CPU TC
>>>> 16 5m08s 4.3 cores 1.0
>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>>>> cores 0.8
>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>>>> cores 0.8 6m06s 10.2 cores 2.7
>>>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>>>> cores 0.8 5m50s 10.5 cores 2.7
>>>> 96 2m13s 8.4
>>>> cores 0.8
>>>>
>>>>
>>>> Configurations:
>>>>
>>>> PostgreSQL:
>>>> Datanodes q1
>>>> Version: 9.2.x (redhat)
>>>>
>>>> PostgreSQL-XC:
>>>> Datanodes q1-q2 (striped)
>>>> Coordinators q1-q2
>>>> GTM q3
>>>> Version 9.1.7 (tar)
>>>>
>>>> PostgreSQL-XC-2:
>>>> Datanodes q1-q2 (striped)
>>>> Coordinators q1-q2
>>>> GTM Proxy q1-q2
>>>> GTM q3
>>>> Version 9.1.7 (tar)
>>>>
>>>> MySQL Cluster:
>>>> ndbmtd q1-q2 (striped)
>>>> mysqld q1-q2
>>>> ndb_mgmd q1
>>>> Version 7.1.17 (oracle rhel 5)
>>>>
>>>> q1, q2, q3 are identical boxes each with:
>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>>>> platters in raid 5.
>>>> They are lan local with a vlan-aware switch (I don't know which one and I
>>>> didn't check to see if it was saturated).
>>>>
>>>>
>>>> Tables & Data:
>>>>
>>>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>>>> "key2" bigint not null). Each table has a selection of varchar columns
>>>> typically less than varchar(80). All non-primary-key columns have
>>>> non-unique indexes. 5.8 million rows were imported with a different
>>>> number of rows to each table.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Chris B. <cb...@in...> - 2013-03-19 15:35:48
|
I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy boxes gets to around 85%. I'll need some more instrumentation to be sure - I'll get back to you with details.
Chris...
________________________________________
From: Jim Mlodgenski [ji...@gm...]
Sent: March 19, 2013 8:32 AM
To: Chris Brown
Cc: pos...@li...
Subject: Re: [Postgres-xc-general] PG-XC Performance
When running the test against straight PostgreSQL, where is the
bottleneck? Are you CPU bound or IO bound?
On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> wrote:
> I also just discovered that my assumption about postgres (non xc) being 9.2 was incorrect:
> postgresql-server-9.1.7-1.fc16.x86_64
> Oops, sorry about the misinformation.
>
> Chris...
> ________________________________________
> From: Chris Brown [cb...@in...]
> Sent: March 19, 2013 7:45 AM
> To: Jim Mlodgenski
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> Hi Jim,
>
> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing the inserts as actual inserts performed by psql. They are not batched - there is one insert per line and each file contains about 10,000 inserts. This was a conscious choice since I was testing expected transaction rate as opposed to import rate.
>
> I haven't done much tuning to postgres. Datanodes received this:
> checkpoint_segements=32
> effective_cache_size=4GB
> shared_buffers=4GB
> random_page_cost=3.0
> For the coordinators, no tuning was done.
> For xc, I also added:
> max_prepared_transactions = 10
> gtm_host = 'localhost' # or the remote host, as appropriate on coordinators
> gtm_port = 6666
> Otherwise the postgresql.conf file is the default one provided by initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am using the defaults of wal_level(minimum), fsync(on), wal_sync_method(fdatasync).
>
> I reran the 60 client test with explicit DISTRIBUTE BY HASH and MODULO, confirming the obj_MODULO and obj_HASH in the tables:
> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
> It didn't make an appreciable difference (~10 seconds on a 5m50s test) which leads me to believe that the 5m50s number is slightly in error.
>
> Chris...
>
> ________________________________________
> From: Jim Mlodgenski [ji...@gm...]
> Sent: March 19, 2013 7:26 AM
> To: Chris Brown
> Cc: Koichi Suzuki; pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> Can you send along some more details of the test? I find it odd that
> in every scenario, the load times are consistent despite the change in
> the number of threads. Are you committing your transaction after each
> insert? If so, your limiting factor is probably the fsync to disk
> which would account for why PostgreSQL 9.2 is about the same speed as
> XC 1.0.
>
> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
>> Here's a sample table:
>>
>> CREATE TABLE table_11 (
>> "part" int not null,
>> "key1" bigint not null,
>> "key2" bigint not null,
>> "col_1" varchar(23),
>> "col_2" varchar(5),
>> "col_3" varchar(32),
>> "col_4" varchar(5),
>> PRIMARY KEY(part,key1,key2)
>> );
>>
>> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>>
>> Chris...
>> ________________________________________
>> From: Koichi Suzuki [koi...@gm...]
>> Sent: March 18, 2013 10:47 PM
>> To: Chris Brown
>> Cc: pos...@li...
>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>
>> What kind of distribution did you use in your case? If all the
>> tables are replicated, all the inserts are associated with implicit
>> 2PCs. Frequently-updated tables should be distributed (hash will be
>> better if the table has a suitable column).
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>> 2013/3/19 Chris Brown <cb...@in...>:
>>> Hi all,
>>>
>>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>>> all insert in this case. I was expecting PG-XC to perform worse than the
>>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>>> I'm well aware that NDB has durability and features issues so I expected
>>> it to perform better - I don't consider the 0.8 to be particularly
>>> interesting. I'd like anyone's thoughts on this.
>>>
>>> Chris...
>>>
>>>
>>> Results:
>>>
>>> All results are very approximate!
>>> CPU is an estimate on the number of cores used by server processes
>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>>> intended to represent a comparative CPU cost for a single insert
>>> transaction.
>>>
>>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>>> PostgreSQL-XC-2
>>> Threads Time CPU TC Time CPU TC Time CPU
>>> TC Time CPU TC
>>> 16 5m08s 4.3 cores 1.0
>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>>> cores 0.8
>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>>> cores 0.8 6m06s 10.2 cores 2.7
>>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>>> cores 0.8 5m50s 10.5 cores 2.7
>>> 96 2m13s 8.4
>>> cores 0.8
>>>
>>>
>>> Configurations:
>>>
>>> PostgreSQL:
>>> Datanodes q1
>>> Version: 9.2.x (redhat)
>>>
>>> PostgreSQL-XC:
>>> Datanodes q1-q2 (striped)
>>> Coordinators q1-q2
>>> GTM q3
>>> Version 9.1.7 (tar)
>>>
>>> PostgreSQL-XC-2:
>>> Datanodes q1-q2 (striped)
>>> Coordinators q1-q2
>>> GTM Proxy q1-q2
>>> GTM q3
>>> Version 9.1.7 (tar)
>>>
>>> MySQL Cluster:
>>> ndbmtd q1-q2 (striped)
>>> mysqld q1-q2
>>> ndb_mgmd q1
>>> Version 7.1.17 (oracle rhel 5)
>>>
>>> q1, q2, q3 are identical boxes each with:
>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>>> platters in raid 5.
>>> They are lan local with a vlan-aware switch (I don't know which one and I
>>> didn't check to see if it was saturated).
>>>
>>>
>>> Tables & Data:
>>>
>>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>>> "key2" bigint not null). Each table has a selection of varchar columns
>>> typically less than varchar(80). All non-primary-key columns have
>>> non-unique indexes. 5.8 million rows were imported with a different
>>> number of rows to each table.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Jim M. <ji...@gm...> - 2013-03-19 15:32:36
|
When running the test against straight PostgreSQL, where is the
bottleneck? Are you CPU bound or IO bound?
On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> wrote:
> I also just discovered that my assumption about postgres (non xc) being 9.2 was incorrect:
> postgresql-server-9.1.7-1.fc16.x86_64
> Oops, sorry about the misinformation.
>
> Chris...
> ________________________________________
> From: Chris Brown [cb...@in...]
> Sent: March 19, 2013 7:45 AM
> To: Jim Mlodgenski
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> Hi Jim,
>
> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing the inserts as actual inserts performed by psql. They are not batched - there is one insert per line and each file contains about 10,000 inserts. This was a conscious choice since I was testing expected transaction rate as opposed to import rate.
>
> I haven't done much tuning to postgres. Datanodes received this:
> checkpoint_segements=32
> effective_cache_size=4GB
> shared_buffers=4GB
> random_page_cost=3.0
> For the coordinators, no tuning was done.
> For xc, I also added:
> max_prepared_transactions = 10
> gtm_host = 'localhost' # or the remote host, as appropriate on coordinators
> gtm_port = 6666
> Otherwise the postgresql.conf file is the default one provided by initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am using the defaults of wal_level(minimum), fsync(on), wal_sync_method(fdatasync).
>
> I reran the 60 client test with explicit DISTRIBUTE BY HASH and MODULO, confirming the obj_MODULO and obj_HASH in the tables:
> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
> It didn't make an appreciable difference (~10 seconds on a 5m50s test) which leads me to believe that the 5m50s number is slightly in error.
>
> Chris...
>
> ________________________________________
> From: Jim Mlodgenski [ji...@gm...]
> Sent: March 19, 2013 7:26 AM
> To: Chris Brown
> Cc: Koichi Suzuki; pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> Can you send along some more details of the test? I find it odd that
> in every scenario, the load times are consistent despite the change in
> the number of threads. Are you committing your transaction after each
> insert? If so, your limiting factor is probably the fsync to disk
> which would account for why PostgreSQL 9.2 is about the same speed as
> XC 1.0.
>
> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
>> Here's a sample table:
>>
>> CREATE TABLE table_11 (
>> "part" int not null,
>> "key1" bigint not null,
>> "key2" bigint not null,
>> "col_1" varchar(23),
>> "col_2" varchar(5),
>> "col_3" varchar(32),
>> "col_4" varchar(5),
>> PRIMARY KEY(part,key1,key2)
>> );
>>
>> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>>
>> Chris...
>> ________________________________________
>> From: Koichi Suzuki [koi...@gm...]
>> Sent: March 18, 2013 10:47 PM
>> To: Chris Brown
>> Cc: pos...@li...
>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>
>> What kind of distribution did you use in your case? If all the
>> tables are replicated, all the inserts are associated with implicit
>> 2PCs. Frequently-updated tables should be distributed (hash will be
>> better if the table has a suitable column).
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>> 2013/3/19 Chris Brown <cb...@in...>:
>>> Hi all,
>>>
>>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>>> all insert in this case. I was expecting PG-XC to perform worse than the
>>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>>> I'm well aware that NDB has durability and features issues so I expected
>>> it to perform better - I don't consider the 0.8 to be particularly
>>> interesting. I'd like anyone's thoughts on this.
>>>
>>> Chris...
>>>
>>>
>>> Results:
>>>
>>> All results are very approximate!
>>> CPU is an estimate on the number of cores used by server processes
>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>>> intended to represent a comparative CPU cost for a single insert
>>> transaction.
>>>
>>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>>> PostgreSQL-XC-2
>>> Threads Time CPU TC Time CPU TC Time CPU
>>> TC Time CPU TC
>>> 16 5m08s 4.3 cores 1.0
>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>>> cores 0.8
>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>>> cores 0.8 6m06s 10.2 cores 2.7
>>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>>> cores 0.8 5m50s 10.5 cores 2.7
>>> 96 2m13s 8.4
>>> cores 0.8
>>>
>>>
>>> Configurations:
>>>
>>> PostgreSQL:
>>> Datanodes q1
>>> Version: 9.2.x (redhat)
>>>
>>> PostgreSQL-XC:
>>> Datanodes q1-q2 (striped)
>>> Coordinators q1-q2
>>> GTM q3
>>> Version 9.1.7 (tar)
>>>
>>> PostgreSQL-XC-2:
>>> Datanodes q1-q2 (striped)
>>> Coordinators q1-q2
>>> GTM Proxy q1-q2
>>> GTM q3
>>> Version 9.1.7 (tar)
>>>
>>> MySQL Cluster:
>>> ndbmtd q1-q2 (striped)
>>> mysqld q1-q2
>>> ndb_mgmd q1
>>> Version 7.1.17 (oracle rhel 5)
>>>
>>> q1, q2, q3 are identical boxes each with:
>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>>> platters in raid 5.
>>> They are lan local with a vlan-aware switch (I don't know which one and I
>>> didn't check to see if it was saturated).
>>>
>>>
>>> Tables & Data:
>>>
>>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>>> "key2" bigint not null). Each table has a selection of varchar columns
>>> typically less than varchar(80). All non-primary-key columns have
>>> non-unique indexes. 5.8 million rows were imported with a different
>>> number of rows to each table.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Chris B. <cb...@in...> - 2013-03-19 14:59:13
|
I also just discovered that my assumption about postgres (non xc) being 9.2 was incorrect:
postgresql-server-9.1.7-1.fc16.x86_64
Oops, sorry about the misinformation.
Chris...
________________________________________
From: Chris Brown [cb...@in...]
Sent: March 19, 2013 7:45 AM
To: Jim Mlodgenski
Cc: pos...@li...
Subject: Re: [Postgres-xc-general] PG-XC Performance
Hi Jim,
I believe I'm doing an fsync (fdatasync) for each commit. I'm doing the inserts as actual inserts performed by psql. They are not batched - there is one insert per line and each file contains about 10,000 inserts. This was a conscious choice since I was testing expected transaction rate as opposed to import rate.
I haven't done much tuning to postgres. Datanodes received this:
checkpoint_segements=32
effective_cache_size=4GB
shared_buffers=4GB
random_page_cost=3.0
For the coordinators, no tuning was done.
For xc, I also added:
max_prepared_transactions = 10
gtm_host = 'localhost' # or the remote host, as appropriate on coordinators
gtm_port = 6666
Otherwise the postgresql.conf file is the default one provided by initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am using the defaults of wal_level(minimum), fsync(on), wal_sync_method(fdatasync).
I reran the 60 client test with explicit DISTRIBUTE BY HASH and MODULO, confirming the obj_MODULO and obj_HASH in the tables:
"table_11_obj_MODULO_idx" btree ("obj_MODULO")
It didn't make an appreciable difference (~10 seconds on a 5m50s test) which leads me to believe that the 5m50s number is slightly in error.
Chris...
________________________________________
From: Jim Mlodgenski [ji...@gm...]
Sent: March 19, 2013 7:26 AM
To: Chris Brown
Cc: Koichi Suzuki; pos...@li...
Subject: Re: [Postgres-xc-general] PG-XC Performance
Can you send along some more details of the test? I find it odd that
in every scenario, the load times are consistent despite the change in
the number of threads. Are you committing your transaction after each
insert? If so, your limiting factor is probably the fsync to disk
which would account for why PostgreSQL 9.2 is about the same speed as
XC 1.0.
On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
> Here's a sample table:
>
> CREATE TABLE table_11 (
> "part" int not null,
> "key1" bigint not null,
> "key2" bigint not null,
> "col_1" varchar(23),
> "col_2" varchar(5),
> "col_3" varchar(32),
> "col_4" varchar(5),
> PRIMARY KEY(part,key1,key2)
> );
>
> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>
> Chris...
> ________________________________________
> From: Koichi Suzuki [koi...@gm...]
> Sent: March 18, 2013 10:47 PM
> To: Chris Brown
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> What kind of distribution did you use in your case? If all the
> tables are replicated, all the inserts are associated with implicit
> 2PCs. Frequently-updated tables should be distributed (hash will be
> better if the table has a suitable column).
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2013/3/19 Chris Brown <cb...@in...>:
>> Hi all,
>>
>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>> all insert in this case. I was expecting PG-XC to perform worse than the
>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>> I'm well aware that NDB has durability and features issues so I expected
>> it to perform better - I don't consider the 0.8 to be particularly
>> interesting. I'd like anyone's thoughts on this.
>>
>> Chris...
>>
>>
>> Results:
>>
>> All results are very approximate!
>> CPU is an estimate on the number of cores used by server processes
>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>> intended to represent a comparative CPU cost for a single insert
>> transaction.
>>
>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>> PostgreSQL-XC-2
>> Threads Time CPU TC Time CPU TC Time CPU
>> TC Time CPU TC
>> 16 5m08s 4.3 cores 1.0
>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>> cores 0.8
>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>> cores 0.8 6m06s 10.2 cores 2.7
>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>> cores 0.8 5m50s 10.5 cores 2.7
>> 96 2m13s 8.4
>> cores 0.8
>>
>>
>> Configurations:
>>
>> PostgreSQL:
>> Datanodes q1
>> Version: 9.2.x (redhat)
>>
>> PostgreSQL-XC:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> PostgreSQL-XC-2:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM Proxy q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> MySQL Cluster:
>> ndbmtd q1-q2 (striped)
>> mysqld q1-q2
>> ndb_mgmd q1
>> Version 7.1.17 (oracle rhel 5)
>>
>> q1, q2, q3 are identical boxes each with:
>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>> platters in raid 5.
>> They are lan local with a vlan-aware switch (I don't know which one and I
>> didn't check to see if it was saturated).
>>
>>
>> Tables & Data:
>>
>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>> "key2" bigint not null). Each table has a selection of varchar columns
>> typically less than varchar(80). All non-primary-key columns have
>> non-unique indexes. 5.8 million rows were imported with a different
>> number of rows to each table.
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Postgres-xc-general mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Chris B. <cb...@in...> - 2013-03-19 14:45:58
|
Hi Jim,
I believe I'm doing an fsync (fdatasync) for each commit. I'm doing the inserts as actual inserts performed by psql. They are not batched - there is one insert per line and each file contains about 10,000 inserts. This was a conscious choice since I was testing expected transaction rate as opposed to import rate.
I haven't done much tuning to postgres. Datanodes received this:
checkpoint_segements=32
effective_cache_size=4GB
shared_buffers=4GB
random_page_cost=3.0
For the coordinators, no tuning was done.
For xc, I also added:
max_prepared_transactions = 10
gtm_host = 'localhost' # or the remote host, as appropriate on coordinators
gtm_port = 6666
Otherwise the postgresql.conf file is the default one provided by initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I am using the defaults of wal_level(minimum), fsync(on), wal_sync_method(fdatasync).
I reran the 60 client test with explicit DISTRIBUTE BY HASH and MODULO, confirming the obj_MODULO and obj_HASH in the tables:
"table_11_obj_MODULO_idx" btree ("obj_MODULO")
It didn't make an appreciable difference (~10 seconds on a 5m50s test) which leads me to believe that the 5m50s number is slightly in error.
Chris...
________________________________________
From: Jim Mlodgenski [ji...@gm...]
Sent: March 19, 2013 7:26 AM
To: Chris Brown
Cc: Koichi Suzuki; pos...@li...
Subject: Re: [Postgres-xc-general] PG-XC Performance
Can you send along some more details of the test? I find it odd that
in every scenario, the load times are consistent despite the change in
the number of threads. Are you committing your transaction after each
insert? If so, your limiting factor is probably the fsync to disk
which would account for why PostgreSQL 9.2 is about the same speed as
XC 1.0.
On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
> Here's a sample table:
>
> CREATE TABLE table_11 (
> "part" int not null,
> "key1" bigint not null,
> "key2" bigint not null,
> "col_1" varchar(23),
> "col_2" varchar(5),
> "col_3" varchar(32),
> "col_4" varchar(5),
> PRIMARY KEY(part,key1,key2)
> );
>
> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>
> Chris...
> ________________________________________
> From: Koichi Suzuki [koi...@gm...]
> Sent: March 18, 2013 10:47 PM
> To: Chris Brown
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> What kind of distribution did you use in your case? If all the
> tables are replicated, all the inserts are associated with implicit
> 2PCs. Frequently-updated tables should be distributed (hash will be
> better if the table has a suitable column).
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2013/3/19 Chris Brown <cb...@in...>:
>> Hi all,
>>
>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>> all insert in this case. I was expecting PG-XC to perform worse than the
>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>> I'm well aware that NDB has durability and features issues so I expected
>> it to perform better - I don't consider the 0.8 to be particularly
>> interesting. I'd like anyone's thoughts on this.
>>
>> Chris...
>>
>>
>> Results:
>>
>> All results are very approximate!
>> CPU is an estimate on the number of cores used by server processes
>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>> intended to represent a comparative CPU cost for a single insert
>> transaction.
>>
>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>> PostgreSQL-XC-2
>> Threads Time CPU TC Time CPU TC Time CPU
>> TC Time CPU TC
>> 16 5m08s 4.3 cores 1.0
>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>> cores 0.8
>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>> cores 0.8 6m06s 10.2 cores 2.7
>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>> cores 0.8 5m50s 10.5 cores 2.7
>> 96 2m13s 8.4
>> cores 0.8
>>
>>
>> Configurations:
>>
>> PostgreSQL:
>> Datanodes q1
>> Version: 9.2.x (redhat)
>>
>> PostgreSQL-XC:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> PostgreSQL-XC-2:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM Proxy q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> MySQL Cluster:
>> ndbmtd q1-q2 (striped)
>> mysqld q1-q2
>> ndb_mgmd q1
>> Version 7.1.17 (oracle rhel 5)
>>
>> q1, q2, q3 are identical boxes each with:
>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>> platters in raid 5.
>> They are lan local with a vlan-aware switch (I don't know which one and I
>> didn't check to see if it was saturated).
>>
>>
>> Tables & Data:
>>
>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>> "key2" bigint not null). Each table has a selection of varchar columns
>> typically less than varchar(80). All non-primary-key columns have
>> non-unique indexes. 5.8 million rows were imported with a different
>> number of rows to each table.
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Jim M. <ji...@gm...> - 2013-03-19 14:26:42
|
Can you send along some more details of the test? I find it odd that
in every scenario, the load times are consistent despite the change in
the number of threads. Are you committing your transaction after each
insert? If so, your limiting factor is probably the fsync to disk
which would account for why PostgreSQL 9.2 is about the same speed as
XC 1.0.
On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> wrote:
> Here's a sample table:
>
> CREATE TABLE table_11 (
> "part" int not null,
> "key1" bigint not null,
> "key2" bigint not null,
> "col_1" varchar(23),
> "col_2" varchar(5),
> "col_3" varchar(32),
> "col_4" varchar(5),
> PRIMARY KEY(part,key1,key2)
> );
>
> I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
>
> Chris...
> ________________________________________
> From: Koichi Suzuki [koi...@gm...]
> Sent: March 18, 2013 10:47 PM
> To: Chris Brown
> Cc: pos...@li...
> Subject: Re: [Postgres-xc-general] PG-XC Performance
>
> What kind of distribution did you use in your case? If all the
> tables are replicated, all the inserts are associated with implicit
> 2PCs. Frequently-updated tables should be distributed (hash will be
> better if the table has a suitable column).
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2013/3/19 Chris Brown <cb...@in...>:
>> Hi all,
>>
>> I've been doing some performance testing of PostgreSQL-XC. My workload is
>> all insert in this case. I was expecting PG-XC to perform worse than the
>> alternatives but I was shocked by how much worse it was than PostgreSQL.
>> I'm well aware that NDB has durability and features issues so I expected
>> it to perform better - I don't consider the 0.8 to be particularly
>> interesting. I'd like anyone's thoughts on this.
>>
>> Chris...
>>
>>
>> Results:
>>
>> All results are very approximate!
>> CPU is an estimate on the number of cores used by server processes
>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
>> intended to represent a comparative CPU cost for a single insert
>> transaction.
>>
>> Client PostgreSQL PostgreSQL-XC MySQL Cluster
>> PostgreSQL-XC-2
>> Threads Time CPU TC Time CPU TC Time CPU
>> TC Time CPU TC
>> 16 5m08s 4.3 cores 1.0
>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
>> cores 0.8
>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
>> cores 0.8 6m06s 10.2 cores 2.7
>> 64 5m01s 13.1 cores 2.9 2m11s 8.3
>> cores 0.8 5m50s 10.5 cores 2.7
>> 96 2m13s 8.4
>> cores 0.8
>>
>>
>> Configurations:
>>
>> PostgreSQL:
>> Datanodes q1
>> Version: 9.2.x (redhat)
>>
>> PostgreSQL-XC:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> PostgreSQL-XC-2:
>> Datanodes q1-q2 (striped)
>> Coordinators q1-q2
>> GTM Proxy q1-q2
>> GTM q3
>> Version 9.1.7 (tar)
>>
>> MySQL Cluster:
>> ndbmtd q1-q2 (striped)
>> mysqld q1-q2
>> ndb_mgmd q1
>> Version 7.1.17 (oracle rhel 5)
>>
>> q1, q2, q3 are identical boxes each with:
>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
>> platters in raid 5.
>> They are lan local with a vlan-aware switch (I don't know which one and I
>> didn't check to see if it was saturated).
>>
>>
>> Tables & Data:
>>
>> 161 tables with primary key ("part" int not null, "key1" bigint not null,
>> "key2" bigint not null). Each table has a selection of varchar columns
>> typically less than varchar(80). All non-primary-key columns have
>> non-unique indexes. 5.8 million rows were imported with a different
>> number of rows to each table.
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Chris B. <cb...@in...> - 2013-03-19 14:06:44
|
Here's a sample table:
CREATE TABLE table_11 (
"part" int not null,
"key1" bigint not null,
"key2" bigint not null,
"col_1" varchar(23),
"col_2" varchar(5),
"col_3" varchar(32),
"col_4" varchar(5),
PRIMARY KEY(part,key1,key2)
);
I guess I'm not specifying a distribution key. I assumed, perhaps incorrectly, that hash on the first element of the primary key would be the default. I will try a run with an explicit DISTRIBUTE BY HASH(part).
Chris...
________________________________________
From: Koichi Suzuki [koi...@gm...]
Sent: March 18, 2013 10:47 PM
To: Chris Brown
Cc: pos...@li...
Subject: Re: [Postgres-xc-general] PG-XC Performance
What kind of distribution did you use in your case? If all the
tables are replicated, all the inserts are associated with implicit
2PCs. Frequently-updated tables should be distributed (hash will be
better if the table has a suitable column).
Regards;
----------
Koichi Suzuki
2013/3/19 Chris Brown <cb...@in...>:
> Hi all,
>
> I've been doing some performance testing of PostgreSQL-XC. My workload is
> all insert in this case. I was expecting PG-XC to perform worse than the
> alternatives but I was shocked by how much worse it was than PostgreSQL.
> I'm well aware that NDB has durability and features issues so I expected
> it to perform better - I don't consider the 0.8 to be particularly
> interesting. I'd like anyone's thoughts on this.
>
> Chris...
>
>
> Results:
>
> All results are very approximate!
> CPU is an estimate on the number of cores used by server processes
> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
> intended to represent a comparative CPU cost for a single insert
> transaction.
>
> Client PostgreSQL PostgreSQL-XC MySQL Cluster
> PostgreSQL-XC-2
> Threads Time CPU TC Time CPU TC Time CPU
> TC Time CPU TC
> 16 5m08s 4.3 cores 1.0
> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
> cores 0.8
> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
> cores 0.8 6m06s 10.2 cores 2.7
> 64 5m01s 13.1 cores 2.9 2m11s 8.3
> cores 0.8 5m50s 10.5 cores 2.7
> 96 2m13s 8.4
> cores 0.8
>
>
> Configurations:
>
> PostgreSQL:
> Datanodes q1
> Version: 9.2.x (redhat)
>
> PostgreSQL-XC:
> Datanodes q1-q2 (striped)
> Coordinators q1-q2
> GTM q3
> Version 9.1.7 (tar)
>
> PostgreSQL-XC-2:
> Datanodes q1-q2 (striped)
> Coordinators q1-q2
> GTM Proxy q1-q2
> GTM q3
> Version 9.1.7 (tar)
>
> MySQL Cluster:
> ndbmtd q1-q2 (striped)
> mysqld q1-q2
> ndb_mgmd q1
> Version 7.1.17 (oracle rhel 5)
>
> q1, q2, q3 are identical boxes each with:
> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
> platters in raid 5.
> They are lan local with a vlan-aware switch (I don't know which one and I
> didn't check to see if it was saturated).
>
>
> Tables & Data:
>
> 161 tables with primary key ("part" int not null, "key1" bigint not null,
> "key2" bigint not null). Each table has a selection of varchar columns
> typically less than varchar(80). All non-primary-key columns have
> non-unique indexes. 5.8 million rows were imported with a different
> number of rows to each table.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Koichi S. <koi...@gm...> - 2013-03-19 05:47:37
|
What kind of distribution did you use in your case? If all the
tables are replicated, all the inserts are associated with implicit
2PCs. Frequently-updated tables should be distributed (hash will be
better if the table has a suitable column).
Regards;
----------
Koichi Suzuki
2013/3/19 Chris Brown <cb...@in...>:
> Hi all,
>
> I've been doing some performance testing of PostgreSQL-XC. My workload is
> all insert in this case. I was expecting PG-XC to perform worse than the
> alternatives but I was shocked by how much worse it was than PostgreSQL.
> I'm well aware that NDB has durability and features issues so I expected
> it to perform better - I don't consider the 0.8 to be particularly
> interesting. I'd like anyone's thoughts on this.
>
> Chris...
>
>
> Results:
>
> All results are very approximate!
> CPU is an estimate on the number of cores used by server processes
> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
> intended to represent a comparative CPU cost for a single insert
> transaction.
>
> Client PostgreSQL PostgreSQL-XC MySQL Cluster
> PostgreSQL-XC-2
> Threads Time CPU TC Time CPU TC Time CPU
> TC Time CPU TC
> 16 5m08s 4.3 cores 1.0
> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
> cores 0.8
> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
> cores 0.8 6m06s 10.2 cores 2.7
> 64 5m01s 13.1 cores 2.9 2m11s 8.3
> cores 0.8 5m50s 10.5 cores 2.7
> 96 2m13s 8.4
> cores 0.8
>
>
> Configurations:
>
> PostgreSQL:
> Datanodes q1
> Version: 9.2.x (redhat)
>
> PostgreSQL-XC:
> Datanodes q1-q2 (striped)
> Coordinators q1-q2
> GTM q3
> Version 9.1.7 (tar)
>
> PostgreSQL-XC-2:
> Datanodes q1-q2 (striped)
> Coordinators q1-q2
> GTM Proxy q1-q2
> GTM q3
> Version 9.1.7 (tar)
>
> MySQL Cluster:
> ndbmtd q1-q2 (striped)
> mysqld q1-q2
> ndb_mgmd q1
> Version 7.1.17 (oracle rhel 5)
>
> q1, q2, q3 are identical boxes each with:
> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
> platters in raid 5.
> They are lan local with a vlan-aware switch (I don't know which one and I
> didn't check to see if it was saturated).
>
>
> Tables & Data:
>
> 161 tables with primary key ("part" int not null, "key1" bigint not null,
> "key2" bigint not null). Each table has a selection of varchar columns
> typically less than varchar(80). All non-primary-key columns have
> non-unique indexes. 5.8 million rows were imported with a different
> number of rows to each table.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
|
|
From: Koichi S. <koi...@gm...> - 2013-03-19 05:45:04
|
In this case, even though each node can access to GTM, update transaction fails. If a transaction is involved by an unreachable node, such local update fails, and then global update fails. This maintains cluster-wide database consistency. Naturally, if a transaction is involved only by reachable nodes, such transaction succeeds and maintains cluster-wide consistency too. Serious split bran case is: if you run two different GTM at the same time and try to connect different coordinators to different GTMs. As in the case of almost other case, as Nikhil pointed out, this should be resolved by some external tools. ---------- Koichi Suzuki 2013/3/19 Nikhil Sontakke <ni...@st...>: > Hi Chris, > > Split brain is not solved internally by Postgres-XC. It's the job of > an external layer to ensure that such scenarios do not occur. > > For example, one can use Corosync/Pacemaker to monitor XC nodes and > then use proper mechanisms to ensure failover and STONITH steps. CS/PM > solve the tricky problem of node membership and consistent cluster > view pretty well. > > Regards, > Nikhils > > On Tue, Mar 19, 2013 at 2:16 AM, Chris Brown <cb...@in...> wrote: >> Hi all, >> >> I just read through: >> >> wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf >> >> and I wanted to know how PG-XC solves the problem of split brain. >> >> For example, let's say there is a pair: >> Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master >> Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave >> and communication is severed between the two boxes. >> >> Another example: >> Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy >> Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy >> Box 3: gtm (no slave exists for simplicity) >> and communication is severed between box 1 and 2, but both can still >> communicate with box 3. (Or another network outage scenario - there are >> obviously several.) >> >> Chris... >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > Postgres-XC Support and Service > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Nikhil S. <ni...@st...> - 2013-03-19 05:04:35
|
Hi Chris, Split brain is not solved internally by Postgres-XC. It's the job of an external layer to ensure that such scenarios do not occur. For example, one can use Corosync/Pacemaker to monitor XC nodes and then use proper mechanisms to ensure failover and STONITH steps. CS/PM solve the tricky problem of node membership and consistent cluster view pretty well. Regards, Nikhils On Tue, Mar 19, 2013 at 2:16 AM, Chris Brown <cb...@in...> wrote: > Hi all, > > I just read through: > > wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf > > and I wanted to know how PG-XC solves the problem of split brain. > > For example, let's say there is a pair: > Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master > Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave > and communication is severed between the two boxes. > > Another example: > Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy > Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy > Box 3: gtm (no slave exists for simplicity) > and communication is severed between box 1 and 2, but both can still > communicate with box 3. (Or another network outage scenario - there are > obviously several.) > > Chris... > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Chris B. <cb...@in...> - 2013-03-19 01:13:25
|
Hi all,
I've been doing some performance testing of PostgreSQL-XC. My workload is
all insert in this case. I was expecting PG-XC to perform worse than the
alternatives but I was shocked by how much worse it was than PostgreSQL.
I'm well aware that NDB has durability and features issues so I expected
it to perform better - I don't consider the 0.8 to be particularly
interesting. I'd like anyone's thoughts on this.
Chris...
Results:
All results are very approximate!
CPU is an estimate on the number of cores used by server processes
(ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
TC is a comparison of (Time*CPU) using PostgreSQL as the baseline and is
intended to represent a comparative CPU cost for a single insert
transaction.
Client PostgreSQL PostgreSQL-XC MySQL Cluster
PostgreSQL-XC-2
Threads Time CPU TC Time CPU TC Time CPU
TC Time CPU TC
16 5m08s 4.3 cores 1.0
24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s 7.8
cores 0.8
48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s 8.0
cores 0.8 6m06s 10.2 cores 2.7
64 5m01s 13.1 cores 2.9 2m11s 8.3
cores 0.8 5m50s 10.5 cores 2.7
96 2m13s 8.4
cores 0.8
Configurations:
PostgreSQL:
Datanodes q1
Version: 9.2.x (redhat)
PostgreSQL-XC:
Datanodes q1-q2 (striped)
Coordinators q1-q2
GTM q3
Version 9.1.7 (tar)
PostgreSQL-XC-2:
Datanodes q1-q2 (striped)
Coordinators q1-q2
GTM Proxy q1-q2
GTM q3
Version 9.1.7 (tar)
MySQL Cluster:
ndbmtd q1-q2 (striped)
mysqld q1-q2
ndb_mgmd q1
Version 7.1.17 (oracle rhel 5)
q1, q2, q3 are identical boxes each with:
24g ram, 1 cpu (6 cores), middle-tier raid with battery backed ram and 3
platters in raid 5.
They are lan local with a vlan-aware switch (I don't know which one and I
didn't check to see if it was saturated).
Tables & Data:
161 tables with primary key ("part" int not null, "key1" bigint not null,
"key2" bigint not null). Each table has a selection of varchar columns
typically less than varchar(80). All non-primary-key columns have
non-unique indexes. 5.8 million rows were imported with a different
number of rows to each table.
|
|
From: Chris B. <cb...@in...> - 2013-03-18 20:47:13
|
Hi all, I just read through: wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf<https://duckduckgo.com/k/?u=https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fwiki.postgresql.org%2Fimages%2F4%2F44%2FPgxc_HA_20121024.pdf> and I wanted to know how PG-XC solves the problem of split brain. For example, let's say there is a pair: Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave and communication is severed between the two boxes. Another example: Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy Box 3: gtm (no slave exists for simplicity) and communication is severed between box 1 and 2, but both can still communicate with box 3. (Or another network outage scenario - there are obviously several.) Chris... |
|
From: Koichi S. <koi...@gm...> - 2013-03-18 08:48:00
|
Circular configuration will not make any difference in the recovery. Good thing is this configuration can apply to odd number of datanodes/coordinators. Pair configuration may help to build failover system with Pacemaker/corosync because it have to take care of the resources in just two servers. However, I'm not sure if such configuration of Pacemaker/corosync can be applied to GTM/GTM-slave too. Regards; ---------- Koichi Suzuki 2013/3/18 Theodotos Andreou <th...@ub...>: > Thanks. It gets more clear now. > > On each node I have a master and a standby coordinator in a pair > configuration, just like the example in your slides. Can I use the catalog > of the standby server (which is a copy of the master coord on the active > node) to restore the failed master coord? In this way I will not have to > take the coordinator offline. > > Also would it make recovery easier if I use a circular configuration with 4 > nodes? > > Regards > > Theo > > > On 03/18/2013 07:15 AM, Koichi Suzuki wrote: >> >> Yes, you're correct. Because coordinator is essentially identical, >> you can leave failed coordinators as is and use remaining ones. If >> the failed server is back, you may have to stop the whole cluster, >> copies one of the coordinator to the new (restored) server, change the >> node name etc., to failback the coordinator. If you keep running >> two, when the failed server is back, you can build new slave to the >> restored server and then failover to it. >> >> It is not reasonable to keep using the same port. Instead, (in my >> case) I assign different port to coordinators at different server. >> For example, if you have the server1 and server2 and run coordinator >> master and slave, I'd assign the port as follows: >> >> 5432: coord1, master at server1 and slave at server2, >> 5433: coord2, master at server2 and slave at server1. >> >> You don't have to worry about port number after the failover. >> >> We're now implementing on-line node addition/removal feature. This >> will make things much simpler. You can use only remaining >> coordinators and later add new one to the restored server. >> >> Regards; >> ---------- >> Koichi Suzuki >> >> >> 2013/3/18 Nikhil Sontakke <ni...@st...>: >>> >>> Hi Theodotos, >>> >>>> Now I have two master coordinators running on the same node at different >>>> ports (5432 and 5433). Does that mean I will have to reconfigure the >>>> load >>>> balancer to round robin the traffic on the working node, at two >>>> different >>>> ports or is this taken care by the master node on port 5432? >>>> >>> Why do you want to run two coordinators on one single node? I do not >>> see any benefits to that. Also to answer your question, the master >>> node on port 5432 does not automatically load balance between itself >>> and the other local coordinator. >>> >>> Regards, >>> Nikhils >>> >>>> Expect more stupid questions as I move along the guide! :) >>>> >>>> Thanks >>>> >>>> Theo >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>> _______________________________________________ >>>> Postgres-xc-general mailing list >>>> Pos...@li... >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>> >>> >>> >>> -- >>> StormDB - http://www.stormdb.com >>> The Database Cloud >>> Postgres-XC Support and Service >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> Postgres-xc-general mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > |
|
From: Theodotos A. <th...@ub...> - 2013-03-18 05:45:00
|
Thanks. It gets more clear now. On each node I have a master and a standby coordinator in a pair configuration, just like the example in your slides. Can I use the catalog of the standby server (which is a copy of the master coord on the active node) to restore the failed master coord? In this way I will not have to take the coordinator offline. Also would it make recovery easier if I use a circular configuration with 4 nodes? Regards Theo On 03/18/2013 07:15 AM, Koichi Suzuki wrote: > Yes, you're correct. Because coordinator is essentially identical, > you can leave failed coordinators as is and use remaining ones. If > the failed server is back, you may have to stop the whole cluster, > copies one of the coordinator to the new (restored) server, change the > node name etc., to failback the coordinator. If you keep running > two, when the failed server is back, you can build new slave to the > restored server and then failover to it. > > It is not reasonable to keep using the same port. Instead, (in my > case) I assign different port to coordinators at different server. > For example, if you have the server1 and server2 and run coordinator > master and slave, I'd assign the port as follows: > > 5432: coord1, master at server1 and slave at server2, > 5433: coord2, master at server2 and slave at server1. > > You don't have to worry about port number after the failover. > > We're now implementing on-line node addition/removal feature. This > will make things much simpler. You can use only remaining > coordinators and later add new one to the restored server. > > Regards; > ---------- > Koichi Suzuki > > > 2013/3/18 Nikhil Sontakke <ni...@st...>: >> Hi Theodotos, >> >>> Now I have two master coordinators running on the same node at different >>> ports (5432 and 5433). Does that mean I will have to reconfigure the load >>> balancer to round robin the traffic on the working node, at two different >>> ports or is this taken care by the master node on port 5432? >>> >> Why do you want to run two coordinators on one single node? I do not >> see any benefits to that. Also to answer your question, the master >> node on port 5432 does not automatically load balance between itself >> and the other local coordinator. >> >> Regards, >> Nikhils >> >>> Expect more stupid questions as I move along the guide! :) >>> >>> Thanks >>> >>> Theo >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> Postgres-xc-general mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> >> >> >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> Postgres-XC Support and Service >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Koichi S. <koi...@gm...> - 2013-03-18 05:39:06
|
Please see my previous reply on running failed-over node at the same server. The following steps are not tested yet. 1. Stop all the cluster. 2. Copy all the material for remaining coordinator for the new coordinator. 3. Edit new coordinator's postgresql.conf, give new value of pgxc_node_name, 4. Edit new coordinator's postgresql.conf to configure gtm/gtm_proxy and pooler. 5. Edit other postgresql.conf if you feel necessary. 6. Edit pg_hba.conf if it is different from the original. 7. Start new coordinator. I'm not sure if the step 3 works fine. Now initdb initializes it's pgxc_node catalog. I'm afraid the step 3 main not update the catalog automatically. In this case, you may have to update pgxc_node using CREATE/UPDATE/DROP NODE. Please understand it is not tested yet either. So, at present, safest way is to run two coordinators at the same server until the failed server is back and then switch to the new server. Regards; ---------- Koichi Suzuki 2013/3/18 Theodotos Andreou <th...@ub...>: > On 03/18/2013 07:07 AM, Nikhil Sontakke wrote: >> Hi Theodotos, >> >>> Now I have two master coordinators running on the same node at different >>> ports (5432 and 5433). Does that mean I will have to reconfigure the load >>> balancer to round robin the traffic on the working node, at two different >>> ports or is this taken care by the master node on port 5432? >>> >> Why do you want to run two coordinators on one single node? I do not >> see any benefits to that. Also to answer your question, the master >> node on port 5432 does not automatically load balance between itself >> and the other local coordinator. >> >> Regards, >> Nikhils > Hi Nikhils, > > I am not sure if there is a benefit running two coordinators on a single > node. I was just following koichi's HA guide for a "pair configuration". > Maybe he can enlighten us. :) > > I was wondering, since all coordinators have a copy of the same catalog, > is there a real need for a standby coordinator? > > Also I would like to know the steps I need to take to restore the failed > coordinator because I am preparing automatic failover and restore scripts. >> >>> Expect more stupid questions as I move along the guide! :) >>> >>> Thanks >>> >>> Theo >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> Postgres-xc-general mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Theodotos A. <th...@ub...> - 2013-03-18 05:21:03
|
On 03/18/2013 07:07 AM, Nikhil Sontakke wrote: > Hi Theodotos, > >> Now I have two master coordinators running on the same node at different >> ports (5432 and 5433). Does that mean I will have to reconfigure the load >> balancer to round robin the traffic on the working node, at two different >> ports or is this taken care by the master node on port 5432? >> > Why do you want to run two coordinators on one single node? I do not > see any benefits to that. Also to answer your question, the master > node on port 5432 does not automatically load balance between itself > and the other local coordinator. > > Regards, > Nikhils Hi Nikhils, I am not sure if there is a benefit running two coordinators on a single node. I was just following koichi's HA guide for a "pair configuration". Maybe he can enlighten us. :) I was wondering, since all coordinators have a copy of the same catalog, is there a real need for a standby coordinator? Also I would like to know the steps I need to take to restore the failed coordinator because I am preparing automatic failover and restore scripts. > >> Expect more stupid questions as I move along the guide! :) >> >> Thanks >> >> Theo >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> > > |
|
From: Koichi S. <koi...@gm...> - 2013-03-18 05:16:04
|
Yes, you're correct. Because coordinator is essentially identical, you can leave failed coordinators as is and use remaining ones. If the failed server is back, you may have to stop the whole cluster, copies one of the coordinator to the new (restored) server, change the node name etc., to failback the coordinator. If you keep running two, when the failed server is back, you can build new slave to the restored server and then failover to it. It is not reasonable to keep using the same port. Instead, (in my case) I assign different port to coordinators at different server. For example, if you have the server1 and server2 and run coordinator master and slave, I'd assign the port as follows: 5432: coord1, master at server1 and slave at server2, 5433: coord2, master at server2 and slave at server1. You don't have to worry about port number after the failover. We're now implementing on-line node addition/removal feature. This will make things much simpler. You can use only remaining coordinators and later add new one to the restored server. Regards; ---------- Koichi Suzuki 2013/3/18 Nikhil Sontakke <ni...@st...>: > Hi Theodotos, > >> Now I have two master coordinators running on the same node at different >> ports (5432 and 5433). Does that mean I will have to reconfigure the load >> balancer to round robin the traffic on the working node, at two different >> ports or is this taken care by the master node on port 5432? >> > > Why do you want to run two coordinators on one single node? I do not > see any benefits to that. Also to answer your question, the master > node on port 5432 does not automatically load balance between itself > and the other local coordinator. > > Regards, > Nikhils > >> Expect more stupid questions as I move along the guide! :) >> >> Thanks >> >> Theo >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > Postgres-XC Support and Service > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Theodotos A. <th...@ub...> - 2013-03-18 05:12:10
|
"All the coordinators are essentially the same copy" right? But the failed coordinator is not the same copy as the others. What steps do I need to take in order to restore the failed coordinator? The guide says: "Failed coordinator can be restored offline ● Backup/restore ● Copy catalogue from a remaining coordinator" How is the above statement translated in commands? On 03/18/2013 04:25 AM, Koichi Suzuki wrote: > Because each coordinator is equivalent, both will bring the same > logical result (the same database contents). I've not tested which is > better (just use on e coordinator or both two) yet. > > Regards; > ---------- > Koichi Suzuki > > > 2013/3/17 Theodotos Andreou <th...@ub...>: >> Hi guys, >> >> I am using Koichi's HA guide to setup a two node pgxc cluster: >> >> wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf >> >> I am using a pair configuration according to page 36 >> >> I have two nodes (node1 and node2). The master coordinators run on port 5432 >> and the slave coordinators on port 5433. I have a TCP/IP loadbalancer (IPVS) >> that load balances (round robin) the traffic on both nodes on port 5432. >> >> When one of the nodes fail, the standby on the other is promoted to master. >> Now I have two master coordinators running on the same node at different >> ports (5432 and 5433). Does that mean I will have to reconfigure the load >> balancer to round robin the traffic on the working node, at two different >> ports or is this taken care by the master node on port 5432? >> >> Expect more stupid questions as I move along the guide! :) >> >> Thanks >> >> Theo >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> Postgres-xc-general mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >> |
|
From: Nikhil S. <ni...@st...> - 2013-03-18 05:08:20
|
Hi Theodotos, > Now I have two master coordinators running on the same node at different > ports (5432 and 5433). Does that mean I will have to reconfigure the load > balancer to round robin the traffic on the working node, at two different > ports or is this taken care by the master node on port 5432? > Why do you want to run two coordinators on one single node? I do not see any benefits to that. Also to answer your question, the master node on port 5432 does not automatically load balance between itself and the other local coordinator. Regards, Nikhils > Expect more stupid questions as I move along the guide! :) > > Thanks > > Theo > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Koichi S. <koi...@gm...> - 2013-03-18 02:25:54
|
Because each coordinator is equivalent, both will bring the same logical result (the same database contents). I've not tested which is better (just use on e coordinator or both two) yet. Regards; ---------- Koichi Suzuki 2013/3/17 Theodotos Andreou <th...@ub...>: > Hi guys, > > I am using Koichi's HA guide to setup a two node pgxc cluster: > > wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf > > I am using a pair configuration according to page 36 > > I have two nodes (node1 and node2). The master coordinators run on port 5432 > and the slave coordinators on port 5433. I have a TCP/IP loadbalancer (IPVS) > that load balances (round robin) the traffic on both nodes on port 5432. > > When one of the nodes fail, the standby on the other is promoted to master. > Now I have two master coordinators running on the same node at different > ports (5432 and 5433). Does that mean I will have to reconfigure the load > balancer to round robin the traffic on the working node, at two different > ports or is this taken care by the master node on port 5432? > > Expect more stupid questions as I move along the guide! :) > > Thanks > > Theo > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > |
|
From: Theodotos A. <th...@ub...> - 2013-03-17 13:10:12
|
Hi guys, I am using Koichi's HA guide to setup a two node pgxc cluster: wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf <https://duckduckgo.com/k/?u=https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fwiki.postgresql.org%2Fimages%2F4%2F44%2FPgxc_HA_20121024.pdf> I am using a pair configuration according to page 36 I have two nodes (node1 and node2). The master coordinators run on port 5432 and the slave coordinators on port 5433. I have a TCP/IP loadbalancer (IPVS) that load balances (round robin) the traffic on both nodes on port 5432. When one of the nodes fail, the standby on the other is promoted to master. Now I have two master coordinators running on the same node at different ports (5432 and 5433). Does that mean I will have to reconfigure the load balancer to round robin the traffic on the working node, at two different ports or is this taken care by the master node on port 5432? Expect more stupid questions as I move along the guide! :) Thanks Theo |
|
From: Theodotos A. <th...@ub...> - 2013-03-17 07:00:53
|
On 03/17/2013 08:25 AM, Michael Paquier wrote: > > > On Sun, Mar 17, 2013 at 3:08 PM, Theodotos Andreou <th...@ub... > <mailto:th...@ub...>> wrote: > > $ cat CN2/recovery.conf > standby_mode = on > primary_conninfo = 'host = node01 port = 5432 user = postgres-xc' > application_name = 'cnmaster01' > restore_command = 'cp CN2_ArchLog/%f %p' > archive_cleanup_command = 'pg_archivecleanup CN2_ArchLog %r' > > application_name is a parameter of the connection string > primary_conninfo, and not an independent parameter. Such a > configuration would also not work with normal Postgres ;) > -- > Michael I am also a postgresql newbie :) Thanks Michael |
|
From: Michael P. <mic...@gm...> - 2013-03-17 06:25:21
|
On Sun, Mar 17, 2013 at 3:08 PM, Theodotos Andreou <th...@ub...>wrote: > $ cat CN2/recovery.conf > standby_mode = on > primary_conninfo = 'host = node01 port = 5432 user = postgres-xc' > application_name = 'cnmaster01' > restore_command = 'cp CN2_ArchLog/%f %p' > archive_cleanup_command = 'pg_archivecleanup CN2_ArchLog %r' > application_name is a parameter of the connection string primary_conninfo, and not an independent parameter. Such a configuration would also not work with normal Postgres ;) -- Michael |
43 messages has been excluded from this view by a project administrator.
