VPN ਰਾਹੀਂ psql ਸਮਾਂ-ਮਾਪ: ਨੈੱਟਵਰਕ ਦੀ ਉਡੀਕ ਨੂੰ ਕੁਐਰੀ ਦੇ ਕੰਮ ਤੋਂ ਵੱਖ ਕਰਨਾ

ਤੁਹਾਡੀ ਰਿਪੋਰਟ ਡੇਟਾਬੇਸ ਹੋਸਟ 'ਤੇ ਲਗਭਗ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਅਤੇ VPN ਰਾਹੀਂ ਚਾਰ ਵਿੱਚ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ psql ਜੋ ਸੰਖਿਆ ਛਾਪਦਾ ਹੈ ਉਹ ਸਿੱਧੀ ਡੇਟਾਬੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। ਉਹ ਸੰਖਿਆ ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਸਟਾਪਵਾਚ ਹੈ, ਸਰਵਰ ਦਾ ਮਾਪ ਨਹੀਂ। ਇਹ ਸਟੇਟਮੈਂਟ ਦੇ ਬਾਹਰ ਜਾਣ ਦੇ ਰਾਹ, ਜਵਾਬ ਦੀ ਉਡੀਕ ਅਤੇ ਵਾਪਸ ਆਉਂਦੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਸਮੇਟਦੀ ਹੈ। ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹੀ ਇਹ ਜਾਣਨ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਟਿਊਨ ਕਰਨਾ ਹੈ।

psql ਟਾਈਮਰ ਅਸਲ ਵਿੱਚ ਕੀ ਮਾਪਦਾ ਹੈ

\timing on ਕਲਾਇੰਟ ਦੇ ਸਟੇਟਮੈਂਟ ਨੂੰ ਸਾਕਟ ਵਿੱਚ ਲਿਖਣ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਸਟਾਪਵਾਚ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਨਤੀਜੇ ਦੀ ਆਖਰੀ ਕਤਾਰ ਪੜ੍ਹੀ ਜਾਣ 'ਤੇ ਰੋਕਦਾ ਹੈ। ਸਰਵਰ ਦੀ ਆਪਣੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਉਸ ਵਿੰਡੋ ਵਿੱਚ ਕਿਤੇ ਬੈਠੀ ਹੈ, ਅਤੇ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਜੋ ਹਰ ਮਿਲੀਸਕਿੰਟ ਬਿਤਾਉਂਦੇ ਹਨ ਉਹ ਵੀ। ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੁਝ ਵੀ ਇਹਨਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰਦਾ। EXPLAIN ਵੀ ਸੰਖਿਆ ਛਾਪਦਾ ਹੈ, ਪਰ ਉਹ ਸਰਵਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਉਡੀਕ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਦੋ ਸੰਖਿਆਵਾਂ, ਦੋ ਵੱਖਰੇ ਸਵਾਲ।

ਇੱਕ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ, ਸਮਾਂ-ਮਾਪ ਚਾਲੂ ਰੱਖੋ, ਅਤੇ ਜਿਸ ਸਟੇਟਮੈਂਟ ਦੀ ਤੁਹਾਨੂੰ ਪਰਵਾਹ ਹੈ ਉਸਨੂੰ ਉਸੇ ਦੇ ਅੰਦਰੋਂ ਚਲਾਓ। ਸੈਸ਼ਨ ਦੁਬਾਰਾ ਵਰਤਣ ਨਾਲ ਕਨੈਕਟ ਦਾ ਖਰਚ ਪਹਿਲੇ ਮਾਪ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।

psql "host=db.internal port=5432 dbname=appdb user=app" \
  -c "\timing on" \
  -c "select count(*) from orders where created_at > now() - interval '1 day';"

ਸੰਖਿਆ ਵਿੱਚ ਹਾਲੇ ਵੀ ਨਤੀਜੇ ਦਾ ਟ੍ਰਾਂਸਫਰ ਸ਼ਾਮਲ ਹੈ, ਜੋ ਇੱਥੇ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਹੁਣ ਉਹ ਕਨੈਕਟ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਦਲ-ਬਦਲ ਸ਼ਾਮਲ ਨਹੀਂ ਜੋ ਨਵਾਂ ਕਾਲ ਜੋੜਦਾ।

ਇੱਕ ਸਟੇਟਮੈਂਟ ਦੀ ਤਿੰਨ ਰਾਹਾਂ 'ਤੇ ਤੁਲਨਾ ਕਰੋ

ਉਹੀ ਸਟੇਟਮੈਂਟ Unix ਸਾਕਟ, LAN ਪਤੇ ਅਤੇ VPN ਹੋਸਟ ਨਾਮ ਰਾਹੀਂ ਚਲਾਓ ਅਤੇ ਤਿੰਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਸਿਰਫ਼ ਆਖਰੀ ਹੌਲੀ ਹੈ, ਤਾਂ ਕੁਐਰੀ ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ।

ਹਰ ਕਾਲ ਪਹਿਲਾਂ ਕਨੈਕਟ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਹੀ ਸਟੇਟਮੈਂਟ ਮਾਪਦੀ ਹੈ, ਇਸ ਲਈ ਕਨੈਕਟ ਦਾ ਖਰਚ ਸੰਖਿਆ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਟ੍ਰਾਂਸਫਰ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ। WHERE ਧਾਰਾ, ਕਤਾਰ ਗਿਣਤੀ ਅਤੇ ਕਲਾਇੰਟ ਮਸ਼ੀਨ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਰਾਹਾਂ ਦੀ ਨਹੀਂ, ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ।

psql -h /var/run/postgresql -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h 10.40.0.12 -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h db.vpn.internal -U app -d appdb -c "\timing on" -c "select count(*) from orders;"

LAN 'ਤੇ ਫ਼ਰਕ ਆਮ ਤੌਰ 'ਤੇ ਅਣਡਿੱਠ ਕਰਨ ਜੋਗਾ ਛੋਟਾ ਹੁੰਦਾ ਹੈ; VPN ਰਾਹੀਂ ਅਕਸਰ ਨਹੀਂ। ਤਿੰਨਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਤਰਤੀਬ ਦੇਣ ਨਾਲ ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਉਡੀਕ 'ਤੇ ਹਮਲਾ ਕਰਨਾ ਹੈ।

ਹੌਲੀ ਸਥਾਨਕ ਸਾਕਟ ਦਾ ਮਤਲਬ ਸਰਵਰ ਦਾ ਕੰਮ ਜਾਂ ਯੋਜਨਾ ਹੈ। ਹੌਲੀ LAN ਨਤੀਜੇ ਦਾ ਮਤਲਬ ਕੁਐਰੀ ਜਾਂ ਉਹ ਆਇਤਨ ਜੋ ਇਹ ਸਰਕਾਉਂਦੀ ਹੈ। ਸਿਰਫ਼ VPN ਨਤੀਜੇ ਦਾ ਹੌਲੀ ਹੋਣਾ ਮਤਲਬ ਰਾਹ 'ਤੇ ਦੇਰੀ, MTU ਜਾਂ ਉਪਲਬਧ ਬੈਂਡਵਿਡਥ, ਅਤੇ ਕੋਈ ਇੰਡੈਕਸ ਤਬਦੀਲੀ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।

ਸਰਵਰ ਦਾ ਆਪਣਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਕੱਢੋ

ਸਰਵਰ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਉਸਨੇ ਕਿੰਨਾ ਸਮਾਂ ਲਾਇਆ, ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਸੰਖਿਆ ਦੇ ਸਾਹਮਣੇ ਰੱਖਣ ਵਾਲੀ ਸੰਖਿਆ ਉਹੀ ਹੈ। ANALYZE ਨਾਲ EXPLAIN ਸਟੇਟਮੈਂਟ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਯੋਜਨਾ ਦੇ ਅੰਦਰ ਯੋਜਨਾ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਛਾਪਦਾ ਹੈ, ਜਦੋਂ ਕਿ BUFFERS ਕੈਸ਼ ਵਿਵਹਾਰ ਜੋੜਦਾ ਹੈ ਜੋ ਅਕਸਰ ਗਰਮ ਦੌੜ ਨੂੰ ਠੰਡੀ ਦੇ ਸਾਹਮਣੇ ਸਮਝਾਉਂਦਾ ਹੈ। ਜੇ ਲਿਖਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਤਾਂ ਇਸਨੂੰ ਲਿਖਣ ਸਟੇਟਮੈਂਟਾਂ ਵੱਲ ਨਾ ਮੋੜੋ। ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀ ਰੈਪਲਿਕਾ 'ਤੇ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਥਾਂ ਇਹੀ ਹੈ, ਅਤੇ psql ਹਵਾਲਾ ਟਾਈਮਰ ਦੇ ਕਲਾਇੰਟ ਪਾਸੇ ਦੇ ਦਾਇਰੇ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ।

ਉਹਨਾਂ ਸਟੇਟਮੈਂਟਾਂ ਲਈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਚਲਾਉਂਦੀ ਹੈ, pg_stat_statements ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਚਲਾਏ ਬਿਨਾਂ ਸਰਵਰ ਪਾਸੇ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਇਕੱਠੀ ਕਰਦਾ ਹੈ। ਕਤਾਰਾਂ ਪ੍ਰਤੀ ਸਧਾਰਨ ਕੀਤੀ ਕੁਐਰੀ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਐਂਟਰੀ ਕਈ ਕਾਲ ਥਾਵਾਂ ਨੂੰ ਕਵਰ ਕਰ ਸਕਦੀ ਹੈ।

select calls, round(mean_exec_time::numeric, 2) as mean_ms, rows
from pg_stat_statements
order by mean_exec_time desc
limit 5;

ਕਾਲਮ ਨਾਮ ਸੰਸਕਰਣ ਅਨੁਸਾਰ ਬਦਲਦੇ ਹਨ: PostgreSQL 13 ਅਤੇ ਬਾਅਦ ਵਾਲੇ mean_exec_time ਦਿਖਾਉਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਇਸਨੂੰ mean_time ਕਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਜਾਂਚੋ \d pg_stat_statements ਨਾਲ, ਜੇ ਉਹ ਕੁਐਰੀ ਗਲਤੀ ਦਿੰਦੀ ਹੈ। ਇਹ ਮੁੱਲ ਯੋਜਨਾ ਨੂੰ ਬਾਹਰ ਰੱਖਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਤੱਕ ਦੀ ਯਾਤਰਾ ਵੀ ਬਾਹਰ ਰੱਖਦੇ ਹਨ। ਇਹੀ ਬਾਹਰ ਰੱਖਣਾ ਉਹਨਾਂ ਨੂੰ ਤੁਲਨਾ ਲਈ ਲਾਹੇਵੰਦ ਬਣਾਉਂਦਾ ਹੈ।

ਆਉਣ-ਜਾਣ ਦੀ ਗਿਣਤੀ ਕਰੋ, ਸਿਰਫ਼ ਮਿਲੀਸਕਿੰਟ ਨਹੀਂ

ਦੋ ਸੌ ਛੋਟੇ ਨਿਰਭਰ ਸਟੇਟਮੈਂਟਾਂ ਨਾਲ ਬਣੀ ਰਿਪੋਰਟ ਰਾਹ ਦੇ ਜੋੜੇ ਕਿਸੇ ਵੀ ਦੇਰੀ ਨੂੰ ਦੋ ਸੌ ਨਾਲ ਗੁਣਾ ਕਰਦੀ ਹੈ। ਦਸ ਲੱਖ ਕਤਾਰਾਂ ਵਾਪਸ ਦੇਣ ਵਾਲਾ ਇੱਕ ਸਟੇਟਮੈਂਟ ਉਸ ਦੇਰੀ ਨੂੰ ਇੱਕ ਵਾਰ ਭਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਲੰਮਾ ਸਮਾਂ ਬੈਂਡਵਿਡਥ ਭਰਦਾ ਹੈ। ਦੋਵੇਂ ਕਲਾਇੰਟ ਟਾਈਮਰ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਉਲਟੇ ਸੁਧਾਰ ਚਾਹੀਦੇ ਹਨ।

ਸਟੇਟਮੈਂਟਾਂ ਦੀ ਗਿਣਤੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਮਾਪੋ। ਕੁੱਲ ਪੜ੍ਹੋ, ਰਿਪੋਰਟ ਇੱਕ ਵਾਰ ਚਲਾਓ, ਫਿਰ ਦੁਬਾਰਾ ਪੜ੍ਹੋ ਅਤੇ ਘਟਾਓ।

select sum(calls) as calls from pg_stat_statements;
-- run the report here
select sum(calls) as calls from pg_stat_statements;

ਜੇ ਡੈਲਟਾ ਵੱਡਾ ਹੈ ਅਤੇ ਸਰਵਰ 'ਤੇ ਹਰ ਸਟੇਟਮੈਂਟ ਸਸਤਾ ਹੈ, ਤਾਂ ਬੈਚਿੰਗ ਉਹ ਸੁਧਾਰ ਹੈ ਜੋ ਫਲ ਦਿੰਦਾ ਹੈ। ਨਿਰਭਰ ਕੁਐਰੀਆਂ ਜੋੜੋ, ਇੱਕ ਸੈੱਟ-ਅਧਾਰਿਤ ਸਟੇਟਮੈਂਟ ਵਰਤੋ, ਜਾਂ ਕਰਸਰ ਤੋਂ ਲੂਪ ਚਲਾਓ। ਇੰਟਰਐਕਟਿਵ psql ਵਿੱਚ, \set FETCH_COUNT 1000 ਵੱਡਾ ਨਤੀਜਾ ਬੈਚਾਂ ਵਿੱਚ ਆਉਣ ਦਿੰਦਾ ਹੈ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਤੇ ਕਲਾਇੰਟ ਮੈਮੋਰੀ ਦਾ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ। ਇਹ ਸਰਵਰ ਦਾ ਕੰਮ ਘਟਾਉਂਦਾ ਨਹੀਂ, ਇਸ ਲਈ ਹੌਲੀ ਕੁਐਰੀ ਨੂੰ ਨਹੀਂ ਬਚਾਏਗਾ।

ਟਨਲ ਦੀ ਮੁੜ-ਭੇਜਣ ਅਤੇ MTU ਰੁਕਾਵਟਾਂ ਲਈ ਜਾਂਚ ਕਰੋ

ਜਦੋਂ ਛੋਟੇ ਸਟੇਟਮੈਂਟ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਅਤੇ ਵੱਡੇ ਨਤੀਜੇ ਅੱਧ ਰਾਹ 'ਤੇ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕੁਐਰੀ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰਾਹ ਨਹੀਂ। ਜਿਸ ਟਨਲ ਦਾ MTU ਹੇਠਲੀ ਕੜੀ ਤੋਂ ਘੱਟ ਹੈ, ਉਸ ਵਿੱਚ ਰੋਕਿਆ ICMP ਮਿਲ ਕੇ ਠੀਕ ਉਹੀ ਨਮੂਨਾ ਬਣਾਉਂਦਾ ਹੈ: ਪਹਿਲੇ ਪੈਕਟ ਆਉਂਦੇ ਹਨ, ਵੱਡੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰਨ ਤੱਕ ਲਟਕਦਾ ਰਹਿੰਦਾ ਹੈ। ਕਲਾਇੰਟ ਪਾਸੇ ਦੇ ਮੁੜ-ਭੇਜਣ ਕਾਊਂਟਰ ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ।

ਜਾਣ-ਬੁੱਝ ਕੇ ਹੌਲੀ ਟ੍ਰਾਂਸਫਰ ਚੱਲਦਿਆਂ ਸਾਕਟ ਅਤੇ ਕਰਨਲ ਕਾਊਂਟਰ ਦੇਖੋ। ਮੁੜ-ਭੇਜਣ ਦੇ ਜੋੜ ਸੰਚਿਤ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਨਮੂਨਾ ਪੜ੍ਹਨ ਦੀ ਬਜਾਏ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨੋਟ ਕਰੋ।

ss -tin dst 10.40.0.12
netstat -s | grep -iE "retransmit|segments retransmitted"
ping -M do -s 1400 -c 3 10.40.0.12

ਟ੍ਰਾਂਸਫਰ ਦੌਰਾਨ ਵੱਧਦੀਆਂ ਮੁੜ-ਭੇਜਣਾਂ, 1400 ਬਾਈਟ 'ਤੇ ਸਫਲ ਪਰ 1472 'ਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ping ਨਾਲ, ਡੇਟਾਬੇਸ ਸਮੱਸਿਆ ਨਹੀਂ ਬਲਕਿ MTU ਸਮੱਸਿਆ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ। ਟਨਲ ਇੰਟਰਫੇਸ ਦਾ MTU ਘਟਾਉਣਾ ਜਾਂ ਗੇਟਵੇ 'ਤੇ MSS ਦਬਾਉਣਾ ਆਮ ਸੁਧਾਰ ਹੈ, ਅਤੇ ਉਹੀ ਤਿੰਨ ਆਦੇਸ਼ ਬਾਅਦ ਵਿੱਚ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਜੇ ਟ੍ਰਾਂਸਫਰ ਅਜੇ ਵੀ ਹੌਲੀ ਹੁੰਦਿਆਂ ਮੁੜ-ਭੇਜਣਾਂ ਸਮਤਲ ਰਹਿਣ, ਤਾਂ ਨੁਕਸਾਨ ਵੱਲ ਨਹੀਂ ਸਗੋਂ ਟਨਲ ਨੂੰ ਦਿੱਤੀ ਬੈਂਡਵਿਡਥ ਵੱਲ ਦੇਖੋ।

ਛੋਟਾ ਕ੍ਰਮ ਅਗਲੀ ਹੌਲੀ ਰਿਪੋਰਟ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ: ਇੱਕ ਸਟੇਟਮੈਂਟ ਦੀ ਸਥਾਨਕ, LAN 'ਤੇ ਅਤੇ VPN ਰਾਹੀਂ ਤੁਲਨਾ ਕਰੋ; EXPLAIN ਜਾਂ pg_stat_statements ਤੋਂ ਸਰਵਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪੜ੍ਹੋ; ਇੱਕ ਵਾਰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕਾਲ ਗਿਣੋ; ਅਤੇ ਵੱਡਾ ਨਤੀਜਾ ਸਰਕਦਿਆਂ ਮੁੜ-ਭੇਜਣਾਂ ਦੇਖੋ। ਹਰ ਕਦਮ ਰਾਹ ਦਾ ਇੱਕ ਪਾਸਾ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾਉਣ ਦਿੰਦਾ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ।