-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[YSQL] Extremely high planning times for simple queries #16313
Comments
But you said you used with 2 regions in your text? Can you paste the output of all your explain analyze statements? Both fast & slow? What is the hardware of the yb-master & yb-tserver nodes? Can you paste your cluster-config and all the queries you used (for everything including tablespaces)? What version of yugabytedb are you using?
Where is the client located? How far is it from the follower(s) and leader(s)? Do note that "leader" is per-tablet, not "cluster wide" https://docs.yugabyte.com/preview/architecture/docdb-replication/replication/ |
Yeah sorry, I meant with 2 regions there (edited and forgot to replace that part).
Yup! Here's EXPLAIN ANALYZE for the leader which is fast, then the follower which is slow and then fast (presumably because the query plan is then cached?). Leader:
Follower (slow):
Follower (cached query plan, fast):
It's 3 nodes running on Azure,
The client is
Sure! Command for master:
Command for tserver:
3-region table (I dropped it beforehand, now recreating):
2-region table (dropped beforehand, now recreated) in Canada/US (excluding Europe which the 3-region table above was also in):
Thanks for the help: let me know if you need any more details! |
You didn't mention the tablespace on your
Please read https://docs.yugabyte.com/preview/deploy/checklist/#replication:
Please read https://docs.yugabyte.com/preview/explore/ysql-language-features/going-beyond-sql/tablespaces/ and also set leader preference. Or set_preferred_zones if no tablespace is used https://docs.yugabyte.com/preview/admin/yb-admin/#set-preferred-zones |
Oh whoops! You're indeed correct, sorry about that 😅 Regardless though, if the default
As for RF, the default is 3 and I have 3 nodes here, so I wouldn't expect to need to change it?
I guess this links back to above: is the default configuration of spreading tablets evenly expected to cause this latency? I can understand wanting to set a preferred zone for a table but then the non-preferred zones would be higher latency, correct? |
The reason is so I can know exactly how many replicas there are on the tablespace and which is the preferred region if there is any. The third replica wasn't specified where it should be set in the tablespace. It's clearer to have it concrete. Yes, I can reproduce with a multi-region cluster internally (EU(preferred zone),US,CA) using ysqlsh running on EU server: yugabyte=# \timing
Timing is on.
yugabyte=# CREATE TABLE test(id SERIAL PRIMARY KEY, test INTEGER);
CREATE TABLE
Time: 5037.370 ms (00:05.037)
yugabyte=# INSERT INTO test (test) VALUES (25);
INSERT 0 1
Time: 248.381 ms
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
--------------------------------------------------------------------------------
-------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=0.315..0.7
72 rows=1 loops=1)
Planning Time: 4.500 ms
Execution Time: 0.817 ms
Peak Memory Usage: 8 kB
(4 rows)
Time: 5.708 ms
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
--------------------------------------------------------------------------------
-------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=0.425..0.9
09 rows=1 loops=1)
Planning Time: 0.036 ms
Execution Time: 0.948 ms
Peak Memory Usage: 0 kB
(4 rows)
Time: 1.299 ms
yugabyte=# ysqlsh running on CA server: yugabyte=# \timing
Timing is on.
yugabyte=# CREATE TABLE test(id SERIAL PRIMARY KEY, test INTEGER);
CREATE TABLE
Time: 13950.182 ms (00:13.950)
yugabyte=# INSERT INTO test (test) VALUES (25);
INSERT 0 1
Time: 1465.436 ms (00:01.465)
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
--------------------------------------------------------------------------------
----------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=91.816..27
6.834 rows=1 loops=1)
Planning Time: 732.498 ms
Execution Time: 276.899 ms
Peak Memory Usage: 8 kB
(4 rows)
Time: 1009.878 ms (00:01.010)
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=91.692..275.206 rows=1 loops=1)
Planning Time: 0.031 ms
Execution Time: 275.245 ms
Peak Memory Usage: 0 kB
(4 rows)
Time: 275.608 ms
yugabyte=# CA, exiting the ysqlsh cli and entering again: ysqlsh (11.2-YB-2.17.3.0-b0)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
--------------------------------------------------------------------------------
----------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=92.025..27
5.794 rows=1 loops=1)
Planning Time: 1095.668 ms
Execution Time: 276.165 ms
Peak Memory Usage: 16 kB
(4 rows)
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
--------------------------------------------------------------------------------
----------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=90.737..27
5.290 rows=1 loops=1)
Planning Time: 0.042 ms
Execution Time: 275.345 ms
Peak Memory Usage: 0 kB
(4 rows) Another try on CA again: yugabyte=# explain analyze select * from test where id=25;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Index Scan using test_pkey on test (cost=0.00..4.11 rows=1 width=8) (actual time=92.191..92.192 rows=0 loops=1)
Index Cond: (id = 25)
Planning Time: 1277.416 ms
Execution Time: 92.309 ms
Peak Memory Usage: 16 kB
(5 rows)
Time: 3648.353 ms (00:03.648)
|
This is being worked on #10821, which is committed but it's not yet in any release. See change after enabling First session: yugabyte=# \timing
Timing is on.
yugabyte=# explain analyze select * from test where id=25;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Index Scan using test_pkey on test (cost=0.00..4.11 rows=1 width=8) (actual time=180.609..180.609 rows=0 loops=1)
Index Cond: (id = 25)
Planning Time: 727.751 ms
Execution Time: 180.715 ms
Peak Memory Usage: 16 kB
(5 rows)
Time: 1544.445 ms (00:01.544)
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=91.217..271.813 rows=1 loops=1)
Planning Time: 0.042 ms
Execution Time: 271.860 ms
Peak Memory Usage: 0 kB
(4 rows)
Time: 272.292 ms Second session: yugabyte=# \timing
Timing is on.
yugabyte=# EXPLAIN ANALYZE SELECT * FROM test;
QUERY PLAN
------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..100.00 rows=1000 width=8) (actual time=90.587..275.054 rows=1 loops=1)
Planning Time: 181.859 ms
Execution Time: 275.415 ms
Peak Memory Usage: 16 kB
(4 rows)
Time: 547.684 ms
|
Jira Link: DB-5741
Description
On a geo-distributed cluster (1 node each in Canada, US, and Europe), planning time for simple queries is extremely high (1600ms). This occurs even if a Tablespace is used to restrict a table to two regions.
Reproduction:
CREATE TABLE test (id SERIAL PRIMARY KEY, test INTEGER);
INSERT INTO test (test) VALUES (10);
EXPLAIN ANALYZE SELECT * FROM test
ysqlsh
clears the cache and the issue is present again.This issue only seems to occur on followers, not the leader, but is consistently reproducable.
The text was updated successfully, but these errors were encountered: