Menu
▾
▴
Re: [Postgres-xc-developers] Question on gtm-proxy
|
From: Koichi S. <koi...@gm...> - 2012-07-10 04:51:43
|
Yes. Although we don't have to care application partitioning based upon the distribution key, it's a good idea to make all the coordinator workload as even as possible. In the case of DBT-1, we ran several DBT-1 process, each produces random transaction but goes to specific coordinator. I think pgbench can do the similar. Regards; ---------- Koichi Suzuki 2012/7/10 Ashutosh Bapat <ash...@en...>: > Hi Shankar, > Will it be possible for you to change the pgbench code to dynamically fire > on all available coordinators? > > Since we use modified DBT-1 for our benchmarking, we haven't got to the > point where we can modify pg_bench to suite XC. But that's something, we > will welcome if anybody is interested. > > > On Mon, Jul 9, 2012 at 9:41 PM, Shankar Hariharan > <har...@ya...> wrote: >> >> Thanks Ashutosh. You are right, while running this test i just had pgbench >> running against one coordinator. Looks like pgbench by itself may not be an >> apt tool for this kind of testing, I will instead run pgbench's underlying >> sql script from cmdline against either coordinators. Thanks for that tip. >> >> I got a lot of input on my problem from a lot of folks on the list, the >> feedback is much appreciated. Thanks everybody! >> >> On max_prepared_transactions, I will factor in the number of coordinators >> and the max_connections on each coordinator while arriving at a figure. >> Will also try out Koichi Suzuki's suggestion to have multiple NICs on the >> GTM. I will post my findings here for the same cluster configuration as >> before. >> >> thanks, >> Shankar >> >> ________________________________ >> From: Ashutosh Bapat <ash...@en...> >> To: Shankar Hariharan <har...@ya...> >> Cc: "pos...@li..." >> <pos...@li...> >> Sent: Sunday, July 8, 2012 11:02 PM >> >> Subject: Re: [Postgres-xc-developers] Question on gtm-proxy >> >> Hi Shankar, >> You have got answers to the prepared transaction problem, I guess. I have >> something else below. >> >> On Sat, Jul 7, 2012 at 1:44 AM, Shankar Hariharan >> <har...@ya...> wrote: >> >> As planned I ran some tests using PGBench on this setup : >> >> Node 1 - Coord1, Datanode1, gtm-proxy1 >> Node 2- Coord2, Datanode2, gtm-proxy2 >> Node 3- Datanode3, gtm >> >> I was connecting via Coord1 for these tests: >> - scale factor of 30 used >> - tests run using the following input parameters for pgbench: >> >> >> Try connecting to both the coordinators, it should give you better >> performance, esp, when you are using distributed tables. With distributed >> tables, coordinator gets involved in query execution more than that in the >> case of replicated tables. So, balancing load across two coordinators would >> help. >> >> >> >> Clients Threads Duration Transactions >> 1 1 100 6204 >> 2 2 100 9960 >> 4 4 100 12880 >> 6 6 100 1676 >> >> >> >> 8 >> 8 8 100 19758 >> 10 10 100 21944 >> 12 12 100 20674 >> >> The run went well until the 8 clients. I started seeing errors on 10 >> clients onwards and eventually the 14 client run has been hanging around for >> over an hour now. The errors I have been seeing on console are the following >> : >> >> pgbench console : >> Client 8 aborted in state 12: ERROR: GTM error, could not obtain snapshot >> Client 0 aborted in state 13: ERROR: maximum number of prepared >> transactions reached >> Client 7 aborted in state 13: ERROR: maximum number of prepared >> transactions reached >> Client 11 aborted in state 13: ERROR: maximum number of prepared >> transactions reached >> Client 9 aborted in state 13: ERROR: maximum number of prepared >> transactions reached >> >> node console: >> ERROR: GTM error, could not obtain snapshot >> STATEMENT: INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) >> VALUES (253, 26, 1888413, -817, CURRENT_TIMESTAMP); >> ERROR: maximum number of prepared transactions reached >> HINT: Increase max_prepared_transactions (currently 10). >> STATEMENT: PREPARE TRANSACTION 'T201428' >> ERROR: maximum number of prepared transactions reached >> STATEMENT: END; >> ERROR: maximum number of prepared transactions reached >> STATEMENT: END; >> ERROR: maximum number of prepared transactions reached >> STATEMENT: END; >> ERROR: maximum number of prepared transactions reached >> STATEMENT: END; >> ERROR: GTM error, could not obtain snapshot >> STATEMENT: INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) >> VALUES (140, 29, 2416403, -4192, CURRENT_TIMESTAMP); >> >> I was also watching the processes on each node and see the following for >> the 14 client run: >> >> >> Node1 : >> postgres 25571 10511 0 04:41 ? 00:00:02 postgres: postgres >> postgres ::1(33481) TRUNCATE TABLE waiting >> postgres 25620 11694 0 04:46 ? 00:00:00 postgres: postgres >> postgres pgbench-address (50388) TRUNCATE TABLE >> >> Node2: >> postgres 10979 9631 0 Jul05 ? 00:00:42 postgres: postgres >> postgres coord1-address(57357) idle in transaction >> >> Node3: >> postgres 20264 9911 0 08:35 ? 00:00:05 postgres: postgres >> postgres coord1-address(51406) TRUNCATE TABLE waiting >> >> >> I was going to restart the processes on all nodes and start over but did >> not want to lose this data as it could be useful information. >> >> Any explanation on the above issue is much appreciated. I will try the >> next run with a higher value set for max_prepared_transactions. Any >> recommendations for a good value on this front? >> >> thanks, >> Shankar >> >> >> ________________________________ >> From: Shankar Hariharan <har...@ya...> >> To: Ashutosh Bapat <ash...@en...> >> Cc: "pos...@li..." >> <pos...@li...> >> Sent: Friday, July 6, 2012 8:22 AM >> >> Subject: Re: [Postgres-xc-developers] Question on gtm-proxy >> >> Hi Ashutosh, >> I was trying to size the load on a server and was wondering if a GTM >> could be shared w/o much performance overhead between a small number of >> datanodes and coordinators. I will post my findings here. >> thanks, >> Shankar >> >> ________________________________ >> From: Ashutosh Bapat <ash...@en...> >> To: Shankar Hariharan <har...@ya...> >> Cc: "pos...@li..." >> <pos...@li...> >> Sent: Friday, July 6, 2012 12:25 AM >> Subject: Re: [Postgres-xc-developers] Question on gtm-proxy >> >> Hi Shankar, >> Running gtm-proxy has shown to improve the performance, because it lessens >> the load on GTM, by serving requests locally. Why do you want the >> coordinators to connect directly to the GTM? Are you seeing any performance >> improvement from doing that? >> >> On Fri, Jul 6, 2012 at 10:08 AM, Shankar Hariharan >> <har...@ya...> wrote: >> >> Follow up to earlier email. In the setup described below, can I avoid >> using a gtm-proxy? That is, can I just simply point coordinators to the one >> gtm running on node 3 ? >> My initial plan was to just run the gtm on node 3 then I thought I could >> try a datanode without a local coordinator which was why I put these two >> together on node 3. >> thanks, >> Shankar >> >> ________________________________ >> From: Shankar Hariharan <har...@ya...> >> To: "pos...@li..." >> <pos...@li...> >> Sent: Thursday, July 5, 2012 11:35 PM >> Subject: Question on multiple coordinators >> >> Hello, >> >> Am trying out XC 1.0 in the following configuraiton. >> Node 1 - Coord1, Datanode1, gtm-proxy1 >> Node 2- Coord2, Datanode2, gtm-proxy2 >> Node 3- Datanode3, gtm >> >> I setup all nodes but forgot to add Coord1 to Coord2 and vice versa. In >> addition I missed the pg_hba edit as well. So the first table T1 that I >> created for distribution from Coord1 was not "visible| from Coord2 but was >> on all the data nodes. >> I tried to get Coord2 backinto business in various ways but the first >> table I created refused to show up on Coord2 : >> - edit pg_hba and add node on both coord1 and 2. Then run select >> pgxc_pool_reload(); >> - restart coord 1 and 2 >> - drop node c2 from c1 and c1 from c2 and add them back followed by select >> pgxc_pool_reload(); >> >> So I tried to create the same table T1 from Coord2 to observe behavior and >> it did not like it clearly as all nodes it "wrote" to reported that the >> table already existed which was good. At this point I could understand that >> Coord2 and Coord1 are not talking alright so I created a new table from >> coord1 with replication. This table was visible from both now. >> >> Question is should I expect to see the first table, let me call it T1 >> after a while from Coord2 also? >> >> >> thanks, >> Shankar >> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Enterprise Postgres Company >> >> >> >> >> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Enterprise Postgres Company >> >> >> > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Enterprise Postgres Company > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
