HBase ਤੋਂ 3 ਗੁਣਾ ਤੱਕ ਅਤੇ HDFS ਤੋਂ 5 ਗੁਣਾ ਤੱਕ ਪੜ੍ਹਨ ਦੀ ਗਤੀ ਕਿਵੇਂ ਵਧਾਈ ਜਾਵੇ

ਵੱਡੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਖ ਲੋੜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। Sberbank 'ਤੇ ਡਾਟਾ ਲੋਡਿੰਗ ਵਿਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਲਗਭਗ ਸਾਰੇ ਲੈਣ-ਦੇਣ ਨੂੰ ਸਾਡੇ Hadoop-ਅਧਾਰਿਤ ਡਾਟਾ ਕਲਾਊਡ ਵਿੱਚ ਪੰਪ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਲਈ ਜਾਣਕਾਰੀ ਦੇ ਅਸਲ ਵਿੱਚ ਵੱਡੇ ਪ੍ਰਵਾਹ ਨਾਲ ਨਜਿੱਠਦੇ ਹਾਂ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਹਮੇਸ਼ਾ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਭਾਲ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਹੁਣ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਰੀਜਨਸਰਵਰ HBase ਅਤੇ HDFS ਕਲਾਇੰਟ ਨੂੰ ਪੈਚ ਕਰਨ ਲਈ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ, ਜਿਸ ਲਈ ਅਸੀਂ ਰੀਡ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਗਤੀ ਨੂੰ ਵਧਾਉਣ ਦੇ ਯੋਗ ਹੋਏ ਹਾਂ।


ਹਾਲਾਂਕਿ, ਸੁਧਾਰਾਂ ਦੇ ਤੱਤ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਪਾਬੰਦੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹੈ ਜੋ, ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਜੇ ਤੁਸੀਂ ਐਚਡੀਡੀ' ਤੇ ਬੈਠਦੇ ਹੋ ਤਾਂ ਇਸ ਨੂੰ ਰੋਕਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ.

HDD ਅਤੇ ਤੇਜ਼ ਰੈਂਡਮ ਐਕਸੈਸ ਰੀਡਸ ਅਸੰਗਤ ਕਿਉਂ ਹਨ
ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, HBase, ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾਬੇਸ, ਆਕਾਰ ਵਿੱਚ ਕਈ ਦਸ ਕਿਲੋਬਾਈਟ ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰ ਕਰਦੇ ਹਨ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ ਲਗਭਗ 64 KB ਹੈ। ਹੁਣ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਨੂੰ ਸਿਰਫ 100 ਬਾਈਟਸ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਅਸੀਂ HBase ਨੂੰ ਇੱਕ ਖਾਸ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹ ਡੇਟਾ ਦੇਣ ਲਈ ਕਹਿੰਦੇ ਹਾਂ। ਕਿਉਂਕਿ HFiles ਵਿੱਚ ਬਲਾਕ ਦਾ ਆਕਾਰ 64 KB ਹੈ, ਬੇਨਤੀ ਲੋੜ ਨਾਲੋਂ 640 ਗੁਣਾ ਵੱਡੀ (ਸਿਰਫ਼ ਇੱਕ ਮਿੰਟ!) ਹੋਵੇਗੀ।

ਅੱਗੇ, ਕਿਉਂਕਿ ਬੇਨਤੀ HDFS ਅਤੇ ਇਸਦੇ ਮੈਟਾਡੇਟਾ ਕੈਚਿੰਗ ਵਿਧੀ ਰਾਹੀਂ ਜਾਵੇਗੀ ਸ਼ਾਰਟ ਸਰਕਟ ਕੈਚ (ਜੋ ਫਾਈਲਾਂ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ), ਇਹ ਡਿਸਕ ਤੋਂ ਪਹਿਲਾਂ ਹੀ 1 MB ਨੂੰ ਪੜ੍ਹਨ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਨੂੰ ਪੈਰਾਮੀਟਰ ਨਾਲ ਐਡਜਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ dfs.client.read.shortcircuit.buffer.size ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਸ ਮੁੱਲ ਨੂੰ ਘਟਾਉਣ ਦਾ ਮਤਲਬ ਬਣਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ 126 KB ਤੱਕ।

ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਦੋਂ ਅਸੀਂ FileChannel.read ਵਰਗੇ ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਲ, java api ਰਾਹੀਂ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਡੇਟਾ ਦੀ ਨਿਰਧਾਰਤ ਮਾਤਰਾ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ, ਤਾਂ ਇਹ 2 ਗੁਣਾ ਜ਼ਿਆਦਾ "ਸਿਰਫ਼ ਕੇਸ ਵਿੱਚ" ਘਟਾਉਂਦਾ ਹੈ। , i.e. ਸਾਡੇ ਕੇਸ ਵਿੱਚ 256 KB. ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਜਾਵਾ ਕੋਲ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਰੋਕਣ ਲਈ FADV_RANDOM ਫਲੈਗ ਸੈੱਟ ਕਰਨ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ 100 ਬਾਈਟਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਹੁੱਡ ਦੇ ਹੇਠਾਂ 2600 ਗੁਣਾ ਜ਼ਿਆਦਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ. ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਹੱਲ ਸਪੱਸ਼ਟ ਹੈ, ਆਓ ਬਲਾਕ ਦੇ ਆਕਾਰ ਨੂੰ ਇੱਕ ਕਿਲੋਬਾਈਟ ਤੱਕ ਘਟਾਈਏ, ਜ਼ਿਕਰ ਕੀਤੇ ਝੰਡੇ ਨੂੰ ਸੈਟ ਕਰੀਏ ਅਤੇ ਮਹਾਨ ਗਿਆਨ ਪ੍ਰਵੇਗ ਪ੍ਰਾਪਤ ਕਰੀਏ। ਪਰ ਮੁਸੀਬਤ ਇਹ ਹੈ ਕਿ ਬਲਾਕ ਦੇ ਆਕਾਰ ਨੂੰ 2 ਗੁਣਾ ਘਟਾ ਕੇ, ਅਸੀਂ ਸਮੇਂ ਦੀ ਪ੍ਰਤੀ ਯੂਨਿਟ ਰੀਡ ਬਾਈਟਸ ਦੀ ਗਿਣਤੀ ਵੀ 2 ਗੁਣਾ ਘਟਾ ਦਿੰਦੇ ਹਾਂ।

FADV_RANDOM ਫਲੈਗ ਨੂੰ ਸੈਟ ਕਰਨ ਤੋਂ ਕੁਝ ਲਾਭ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਉੱਚ ਮਲਟੀ-ਥ੍ਰੈਡਿੰਗ ਅਤੇ 128 KB ਦੇ ਬਲਾਕ ਆਕਾਰ ਨਾਲ, ਪਰ ਇਹ ਵੱਧ ਤੋਂ ਵੱਧ ਕੁਝ ਪ੍ਰਤੀਸ਼ਤ ਹੈ:

ਟੈਸਟ 100 ਫਾਈਲਾਂ 'ਤੇ ਕੀਤੇ ਗਏ ਸਨ, ਹਰੇਕ ਦਾ ਆਕਾਰ 1 GB ਹੈ ਅਤੇ 10 HDDs 'ਤੇ ਸਥਿਤ ਹੈ।

ਆਓ ਅਸੀਂ ਇਸ ਗਤੀ 'ਤੇ, ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ ਦੀ ਗਣਨਾ ਕਰੀਏ:
ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ 10 ਡਿਸਕਾਂ ਤੋਂ 280 MB/sec ਦੀ ਗਤੀ ਨਾਲ ਪੜ੍ਹਦੇ ਹਾਂ, ਯਾਨੀ. 3 ਮਿਲੀਅਨ ਗੁਣਾ 100 ਬਾਈਟ। ਪਰ ਜਿਵੇਂ ਕਿ ਸਾਨੂੰ ਯਾਦ ਹੈ, ਸਾਨੂੰ ਜੋ ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਪੜ੍ਹੇ ਜਾਣ ਨਾਲੋਂ 2600 ਗੁਣਾ ਘੱਟ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ 3 ਮਿਲੀਅਨ ਨੂੰ 2600 ਨਾਲ ਵੰਡਦੇ ਹਾਂ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ 1100 ਰਿਕਾਰਡ ਪ੍ਰਤੀ ਸਕਿੰਟ।

ਨਿਰਾਸ਼ਾਜਨਕ, ਹੈ ਨਾ? ਇਹ ਕੁਦਰਤ ਹੈ ਰੈਂਡਮ ਐਕਸੈਸ HDD 'ਤੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ - ਬਲਾਕ ਆਕਾਰ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ। ਇਹ ਬੇਤਰਤੀਬੇ ਪਹੁੰਚ ਦੀ ਭੌਤਿਕ ਸੀਮਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਡੇਟਾਬੇਸ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਹੋਰ ਨਿਚੋੜ ਨਹੀਂ ਸਕਦਾ ਹੈ।

ਫਿਰ ਡੇਟਾਬੇਸ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਪੀਡ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ? ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ, ਆਓ ਦੇਖੀਏ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ:

ਇੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਪਹਿਲੇ ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਗਤੀ ਅਸਲ ਵਿੱਚ ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਹਜ਼ਾਰ ਰਿਕਾਰਡ ਹੈ। ਹਾਲਾਂਕਿ, ਅੱਗੇ, ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਸੀ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੜ੍ਹਿਆ ਗਿਆ ਹੈ, ਡੇਟਾ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ (ਲੀਨਕਸ) ਦੇ ਬੱਫ/ਕੈਸ਼ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਗਤੀ ਵੱਧ ਕੇ 60 ਹਜ਼ਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਵੱਧ ਜਾਂਦੀ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਅੱਗੇ ਅਸੀਂ ਸਿਰਫ ਉਹਨਾਂ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਨਾਲ ਨਜਿੱਠਾਂਗੇ ਜੋ OS ਕੈਸ਼ ਵਿੱਚ ਹਨ ਜਾਂ ਤੁਲਨਾਤਮਕ ਐਕਸੈਸ ਸਪੀਡ ਦੇ SSD / NVMe ਸਟੋਰੇਜ ਵਿੱਚ ਸਥਿਤ ਹਨ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ 4 ਸਰਵਰਾਂ ਦੇ ਬੈਂਚ 'ਤੇ ਟੈਸਟਾਂ ਦਾ ਆਯੋਜਨ ਕਰਾਂਗੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੂੰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਚਾਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ਥ੍ਰੈੱਡਸ।
ਮੈਮੋਰੀ: 730 ਜੀ.ਬੀ.
java ਸੰਸਕਰਣ: 1.8.0_111

ਅਤੇ ਇੱਥੇ ਮੁੱਖ ਬਿੰਦੂ ਟੇਬਲ ਵਿੱਚ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਹੈ ਜਿਸਨੂੰ ਪੜ੍ਹਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਤੱਥ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਟੇਬਲ ਤੋਂ ਡੇਟਾ ਪੜ੍ਹਦੇ ਹੋ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ HBase ਕੈਸ਼ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਬੱਫ/ਕੈਸ਼ ਤੋਂ ਪੜ੍ਹਨ ਲਈ ਵੀ ਨਹੀਂ ਆਵੇਗਾ। ਕਿਉਂਕਿ HBase ਮੂਲ ਰੂਪ ਵਿੱਚ 40% ਮੈਮੋਰੀ ਨੂੰ ਬਲਾਕਕੈਚ ਨਾਮਕ ਢਾਂਚੇ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਇਹ ਇੱਕ ConcurrentHashMap ਹੈ, ਜਿੱਥੇ ਕੁੰਜੀ ਬਲਾਕ ਦਾ ਫਾਈਲ ਨਾਮ + ਆਫਸੈੱਟ ਹੈ, ਅਤੇ ਮੁੱਲ ਇਸ ਆਫਸੈੱਟ 'ਤੇ ਅਸਲ ਡੇਟਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਸਿਰਫ ਇਸ ਢਾਂਚੇ ਤੋਂ ਪੜ੍ਹਦੇ ਹਾਂ, ਅਸੀਂ ਅਸੀਂ ਸ਼ਾਨਦਾਰ ਗਤੀ ਦੇਖਦੇ ਹਾਂ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਵਾਂਗ। ਪਰ ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਦੀਆਂ ਲੋੜਾਂ ਲਈ ਸੈਂਕੜੇ ਗੀਗਾਬਾਈਟ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਸਰਵਰਾਂ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਹੋਰ ਉਪਯੋਗੀ ਚੀਜ਼ਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇੱਕ RS ਉੱਤੇ ਬਲਾਕਕੈਚ ਦੀ ਮਾਤਰਾ ਲਗਭਗ 12 GB ਹੈ। ਅਸੀਂ ਇੱਕ ਨੋਡ 'ਤੇ ਦੋ ਆਰਐਸ ਉਤਾਰੇ, i.e. ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ ਬਲਾਕਕੈਚ ਲਈ 96 GB ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ। ਅਤੇ ਇੱਥੇ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਡੇਟਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਨੂੰ 4 ਟੇਬਲ, 130 ਖੇਤਰ ਹਰੇਕ ਵਿੱਚ ਹੋਣ ਦਿਓ, ਜਿਸ ਵਿੱਚ ਫਾਈਲਾਂ ਦਾ ਆਕਾਰ 800 MB ਹੈ, FAST_DIFF ਦੁਆਰਾ ਸੰਕੁਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਯਾਨੀ. ਕੁੱਲ 410 GB (ਇਹ ਸ਼ੁੱਧ ਡੇਟਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ)।

ਇਸ ਤਰ੍ਹਾਂ, ਬਲਾਕਕੈਚ ਕੁੱਲ ਡਾਟਾ ਵਾਲੀਅਮ ਦਾ ਸਿਰਫ 23% ਹੈ ਅਤੇ ਇਹ ਬਿਗਡਾਟਾ ਕਹੇ ਜਾਣ ਵਾਲੀਆਂ ਅਸਲ ਸਥਿਤੀਆਂ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹੈ। ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮਜ਼ੇ ਦੀ ਸ਼ੁਰੂਆਤ ਹੁੰਦੀ ਹੈ - ਕਿਉਂਕਿ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਘੱਟ ਕੈਸ਼ ਹਿੱਟ, ਪ੍ਰਦਰਸ਼ਨ ਓਨਾ ਹੀ ਬੁਰਾ ਹੁੰਦਾ ਹੈ। ਆਖ਼ਰਕਾਰ, ਜੇ ਤੁਸੀਂ ਖੁੰਝ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕਰਨਾ ਪਏਗਾ - ਯਾਨੀ. ਕਾਲਿੰਗ ਸਿਸਟਮ ਫੰਕਸ਼ਨਾਂ 'ਤੇ ਹੇਠਾਂ ਜਾਓ। ਹਾਲਾਂਕਿ, ਇਸ ਤੋਂ ਬਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਆਓ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੇ ਪਹਿਲੂ ਨੂੰ ਵੇਖੀਏ - ਕੈਸ਼ ਦੇ ਅੰਦਰਲੇ ਡੇਟਾ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ?

ਆਉ ਸਥਿਤੀ ਨੂੰ ਸਰਲ ਕਰੀਏ ਅਤੇ ਇਹ ਮੰਨੀਏ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੈਸ਼ ਹੈ ਜੋ ਸਿਰਫ 1 ਵਸਤੂ ਨੂੰ ਫਿੱਟ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਕਿ ਕੀ ਹੋਵੇਗਾ ਜਦੋਂ ਅਸੀਂ ਕੈਸ਼ ਤੋਂ 3 ਗੁਣਾ ਵੱਡੇ ਡੇਟਾ ਵਾਲੀਅਮ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਸਾਨੂੰ ਇਹ ਕਰਨਾ ਪਵੇਗਾ:

1. ਬਲਾਕ 1 ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੋ
2. ਕੈਸ਼ ਤੋਂ ਬਲਾਕ 1 ਨੂੰ ਹਟਾਓ
3. ਬਲਾਕ 2 ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੋ
4. ਕੈਸ਼ ਤੋਂ ਬਲਾਕ 2 ਨੂੰ ਹਟਾਓ
5. ਬਲਾਕ 3 ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੋ

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

ਉਦੋਂ ਕੀ ਜੇ ਤੁਸੀਂ ਸਾਰੇ ਬਲਾਕਾਂ ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦੇ, ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪ੍ਰਤੀਸ਼ਤ, ਤਾਂ ਜੋ ਕੈਸ਼ ਓਵਰਫਲੋ ਨਾ ਹੋਵੇ? ਆਉ ਬਲਾਕਕੈਚ ਵਿੱਚ ਡੇਟਾ ਪਾਉਣ ਲਈ ਫੰਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕੋਡ ਦੀਆਂ ਕੁਝ ਲਾਈਨਾਂ ਜੋੜ ਕੇ ਸ਼ੁਰੂਆਤ ਕਰੀਏ:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

ਇੱਥੇ ਬਿੰਦੂ ਹੇਠਾਂ ਦਿੱਤਾ ਗਿਆ ਹੈ: ਆਫਸੈੱਟ ਫਾਈਲ ਵਿੱਚ ਬਲਾਕ ਦੀ ਸਥਿਤੀ ਹੈ ਅਤੇ ਇਸਦੇ ਆਖਰੀ ਅੰਕ 00 ਤੋਂ 99 ਤੱਕ ਬੇਤਰਤੀਬੇ ਅਤੇ ਬਰਾਬਰ ਵੰਡੇ ਗਏ ਹਨ। ਇਸਲਈ, ਅਸੀਂ ਸਿਰਫ ਉਹਨਾਂ ਨੂੰ ਛੱਡਾਂਗੇ ਜੋ ਸਾਨੂੰ ਲੋੜੀਂਦੀ ਸੀਮਾ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, cacheDataBlockPercent = 20 ਸੈੱਟ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ:

ਨਤੀਜਾ ਸਪੱਸ਼ਟ ਹੈ. ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ਼ਾਂ ਵਿੱਚ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਅਜਿਹਾ ਪ੍ਰਵੇਗ ਕਿਉਂ ਹੋਇਆ - ਅਸੀਂ ਸਿਰਫ ਇਸ ਨੂੰ ਮੰਗਲ ਦੇ ਕੁੱਤਿਆਂ ਦੇ ਨਾਲੇ ਵਿੱਚ ਤੁਰੰਤ ਸੁੱਟਣ ਲਈ ਕੈਸ਼ ਵਿੱਚ ਡੇਟਾ ਰੱਖਣ ਦਾ ਸਿਸੀਫੀਅਨ ਕੰਮ ਕੀਤੇ ਬਿਨਾਂ ਬਹੁਤ ਸਾਰੇ GC ਸਰੋਤਾਂ ਦੀ ਬਚਤ ਕਰਦੇ ਹਾਂ:

ਉਸੇ ਸਮੇਂ, CPU ਉਪਯੋਗਤਾ ਵਧਦੀ ਹੈ, ਪਰ ਉਤਪਾਦਕਤਾ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਹੈ:

ਇਹ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਬਲਾਕਕੈਚ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਬਲਾਕ ਵੱਖਰੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ, ਲਗਭਗ 95%, ਆਪਣੇ ਆਪ ਵਿੱਚ ਡੇਟਾ ਹੈ। ਅਤੇ ਬਾਕੀ ਮੈਟਾਡੇਟਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਬਲੂਮ ਫਿਲਟਰ ਜਾਂ LEAF_INDEX ਅਤੇ ਆਦਿ. ਇਹ ਡੇਟਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਉਪਯੋਗੀ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਐਕਸੈਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, HBase ਇਹ ਸਮਝਣ ਲਈ ਮੈਟਾ ਵੱਲ ਮੁੜਦਾ ਹੈ ਕਿ ਕੀ ਇੱਥੇ ਹੋਰ ਖੋਜ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ, ਜੇ ਅਜਿਹਾ ਹੈ, ਤਾਂ ਦਿਲਚਸਪੀ ਦਾ ਬਲਾਕ ਕਿੱਥੇ ਸਥਿਤ ਹੈ.

ਇਸ ਲਈ, ਕੋਡ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਜਾਂਚ ਸਥਿਤੀ ਦੇਖਦੇ ਹਾਂ buf.getBlockType().isData() ਅਤੇ ਇਸ ਮੈਟਾ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਕੈਸ਼ ਵਿੱਚ ਛੱਡ ਦੇਵਾਂਗੇ।

ਆਉ ਹੁਣ ਲੋਡ ਨੂੰ ਵਧਾ ਦੇਈਏ ਅਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਕੱਸ ਦੇਈਏ। ਪਹਿਲੇ ਟੈਸਟ ਵਿੱਚ ਅਸੀਂ ਕਟੌਫ ਪ੍ਰਤੀਸ਼ਤ = 20 ਬਣਾਇਆ ਅਤੇ ਬਲਾਕਕੈਸ਼ ਨੂੰ ਥੋੜ੍ਹਾ ਘੱਟ ਉਪਯੋਗ ਕੀਤਾ ਗਿਆ ਸੀ। ਆਉ ਹੁਣ ਇਸਨੂੰ 23% ਤੇ ਸੈਟ ਕਰੀਏ ਅਤੇ ਹਰ 100 ਮਿੰਟ ਵਿੱਚ 5 ਥ੍ਰੈੱਡ ਜੋੜੀਏ ਤਾਂ ਕਿ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਸੰਤ੍ਰਿਪਤਾ ਕਿਸ ਬਿੰਦੂ ਤੇ ਹੁੰਦੀ ਹੈ:

ਇੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਅਸਲ ਸੰਸਕਰਣ ਲਗਭਗ ਤੁਰੰਤ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 100 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ 'ਤੇ ਛੱਤ ਨੂੰ ਮਾਰਦਾ ਹੈ। ਜਦੋਂ ਕਿ ਪੈਚ 300 ਹਜ਼ਾਰ ਤੱਕ ਦਾ ਪ੍ਰਵੇਗ ਦਿੰਦਾ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਹੋਰ ਪ੍ਰਵੇਗ ਹੁਣ ਇੰਨਾ "ਮੁਫ਼ਤ" ਨਹੀਂ ਹੈ; CPU ਉਪਯੋਗਤਾ ਵੀ ਵਧ ਰਹੀ ਹੈ.

ਹਾਲਾਂਕਿ, ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸ਼ਾਨਦਾਰ ਹੱਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਿੰਨੇ ਪ੍ਰਤੀਸ਼ਤ ਬਲਾਕਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਲੋਡ ਪ੍ਰੋਫਾਈਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸਲਈ, ਰੀਡਿੰਗ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਗਤੀਵਿਧੀ ਦੇ ਅਧਾਰ ਤੇ ਇਸ ਪੈਰਾਮੀਟਰ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਲਾਗੂ ਕੀਤੀ ਗਈ ਸੀ।

ਇਸ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਤਿੰਨ ਵਿਕਲਪ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ:

hbase.lru.cache.heavy.eviction.count.limit — ਸੈੱਟ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਓਪਟੀਮਾਈਜੇਸ਼ਨ (ਜਿਵੇਂ ਕਿ ਬਲਾਕਾਂ ਨੂੰ ਛੱਡਣਾ) ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਤੋਂ ਡਾਟਾ ਕੱਢਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਿੰਨੀ ਵਾਰ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ MAX_INT = 2147483647 ਦੇ ਬਰਾਬਰ ਹੈ ਅਤੇ ਅਸਲ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਵਿਸ਼ੇਸ਼ਤਾ ਕਦੇ ਵੀ ਇਸ ਮੁੱਲ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰੇਗੀ। ਕਿਉਂਕਿ ਬੇਦਖਲੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹਰ 5 - 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ (ਇਹ ਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ) ਅਤੇ 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 ਸਾਲਾਂ ਵਿੱਚ. ਹਾਲਾਂਕਿ, ਅਸੀਂ ਇਸ ਪੈਰਾਮੀਟਰ ਨੂੰ 0 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਫੀਚਰ ਨੂੰ ਲਾਂਚ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕੰਮ ਕਰ ਸਕਦੇ ਹਾਂ।

ਹਾਲਾਂਕਿ, ਇਸ ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਇੱਕ ਪੇਲੋਡ ਵੀ ਹੈ। ਜੇਕਰ ਸਾਡਾ ਲੋਡ ਅਜਿਹਾ ਹੈ ਕਿ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਰੀਡਜ਼ (ਦਿਨ ਦੇ ਦੌਰਾਨ ਕਹੋ) ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਰੀਡਜ਼ (ਰਾਤ ਨੂੰ) ਲਗਾਤਾਰ ਇੰਟਰਸਪਰਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਾਂ ਕਿ ਵਿਸ਼ੇਸ਼ਤਾ ਉਦੋਂ ਹੀ ਚਾਲੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਲੰਬੇ ਪੜ੍ਹਨ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਚੱਲ ਰਹੀਆਂ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਛੋਟੀ ਮਿਆਦ ਦੀਆਂ ਰੀਡਿੰਗਾਂ ਆਮ ਤੌਰ 'ਤੇ ਲਗਭਗ 1 ਮਿੰਟ ਰਹਿੰਦੀਆਂ ਹਨ। ਬਲਾਕਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਣਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਕੈਸ਼ ਕੋਲ ਪੁਰਾਣਾ ਹੋਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ ਅਤੇ ਫਿਰ ਅਸੀਂ ਇਸ ਪੈਰਾਮੀਟਰ ਨੂੰ ਬਰਾਬਰ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, 10. ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਜਾਵੇਗਾ ਕਿ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇਗੀ ਜਦੋਂ ਲੰਬੇ- ਮਿਆਦ ਸਰਗਰਮ ਰੀਡਿੰਗ ਸ਼ੁਰੂ ਹੋ ਗਈ ਹੈ, ਯਾਨੀ. 100 ਸਕਿੰਟਾਂ ਵਿੱਚ. ਇਸ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਪੜ੍ਹਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਸਾਰੇ ਬਲਾਕ ਕੈਸ਼ ਵਿੱਚ ਜਾਣਗੇ ਅਤੇ ਉਪਲਬਧ ਹੋਣਗੇ (ਉਨ੍ਹਾਂ ਨੂੰ ਛੱਡ ਕੇ ਜੋ ਸਟੈਂਡਰਡ ਐਲਗੋਰਿਦਮ ਦੁਆਰਾ ਬੇਦਖਲ ਕੀਤੇ ਜਾਣਗੇ)। ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪੜ੍ਹਦੇ ਹਾਂ, ਤਾਂ ਵਿਸ਼ੇਸ਼ਤਾ ਚਾਲੂ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਦਰਸ਼ਨ ਹੋਵੇਗਾ।

hbase.lru.cache.heavy.eviction.mb.size.limit — ਸੈੱਟ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਕੈਸ਼ (ਅਤੇ, ਬੇਸ਼ਕ, ਬੇਦਖਲ) ਵਿੱਚ ਕਿੰਨੇ ਮੈਗਾਬਾਈਟ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਵਿਸ਼ੇਸ਼ਤਾ ਇਸ ਮੁੱਲ ਤੱਕ ਪਹੁੰਚਣ ਅਤੇ ਇਸਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗੀ। ਬਿੰਦੂ ਇਹ ਹੈ: ਜੇ ਅਸੀਂ ਗੀਗਾਬਾਈਟਸ ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਧੱਕਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਗੀਗਾਬਾਈਟ ਨੂੰ ਬਾਹਰ ਕੱਢਣਾ ਪਵੇਗਾ, ਅਤੇ ਇਹ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉੱਪਰ ਦੇਖਿਆ ਹੈ, ਬਹੁਤ ਮਹਿੰਗਾ ਹੈ. ਹਾਲਾਂਕਿ, ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਬਹੁਤ ਛੋਟਾ ਸੈੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਬਲਾਕ ਸਕਿਪ ਮੋਡ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਬੰਦ ਹੋ ਜਾਵੇਗਾ। ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਰਵਰਾਂ ਲਈ (ਲਗਭਗ 20-40 ਭੌਤਿਕ ਕੋਰ), ਲਗਭਗ 300-400 MB ਸੈੱਟ ਕਰਨਾ ਅਨੁਕੂਲ ਹੈ। ਮੱਧ ਵਰਗ (~10 ਕੋਰ) ਲਈ 200-300 MB। ਕਮਜ਼ੋਰ ਸਿਸਟਮਾਂ (2-5 ਕੋਰ) ਲਈ 50-100 MB ਆਮ ਹੋ ਸਕਦਾ ਹੈ (ਇਨ੍ਹਾਂ 'ਤੇ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ)।

ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਮੰਨ ਲਓ ਅਸੀਂ hbase.lru.cache.heavy.eviction.mb.size.limit = 500 ਸੈਟ ਕਰਦੇ ਹਾਂ, ਇੱਥੇ ਕੁਝ ਕਿਸਮ ਦਾ ਲੋਡ (ਪੜ੍ਹਨ) ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਹਰ ~10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਅਸੀਂ ਗਣਨਾ ਕਰਦੇ ਹਾਂ ਕਿ ਕਿੰਨੇ ਬਾਈਟ ਸਨ ਫਾਰਮੂਲੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੇਦਖਲ ਕੀਤਾ ਗਿਆ:

ਓਵਰਹੈੱਡ = ਫ੍ਰੀਡ ਬਾਈਟ ਜੋੜ (MB) * 100 / ਸੀਮਾ (MB) - 100;

ਜੇਕਰ ਅਸਲ ਵਿੱਚ 2000 MB ਨੂੰ ਬੇਦਖਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਓਵਰਹੈੱਡ ਇਸਦੇ ਬਰਾਬਰ ਹੈ:

2000 * 100 / 500 - 100 = 300%

ਐਲਗੋਰਿਦਮ ਕੁਝ ਦਸਾਂ ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ ਵੱਧ ਨਹੀਂ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਇਸਲਈ ਵਿਸ਼ੇਸ਼ਤਾ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕਾਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਘਟਾ ਦੇਵੇਗੀ, ਜਿਸ ਨਾਲ ਇੱਕ ਆਟੋ-ਟਿਊਨਿੰਗ ਵਿਧੀ ਲਾਗੂ ਹੋਵੇਗੀ।

ਹਾਲਾਂਕਿ, ਜੇਕਰ ਲੋਡ ਘੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਮੰਨ ਲਓ ਕਿ ਸਿਰਫ 200 MB ਨੂੰ ਬੇਦਖਲ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਓਵਰਹੈੱਡ ਨਕਾਰਾਤਮਕ ਬਣ ਜਾਂਦਾ ਹੈ (ਅਖੌਤੀ ਓਵਰਸ਼ੂਟਿੰਗ):

200 * 100 / 500 - 100 = -60%

ਇਸ ਦੇ ਉਲਟ, ਵਿਸ਼ੇਸ਼ਤਾ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕਾਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਨੂੰ ਵਧਾਏਗੀ ਜਦੋਂ ਤੱਕ ਓਵਰਹੈੱਡ ਸਕਾਰਾਤਮਕ ਨਹੀਂ ਹੋ ਜਾਂਦਾ.

ਹੇਠਾਂ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਕਿ ਇਹ ਅਸਲ ਡੇਟਾ 'ਤੇ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। 0% ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਇਹ ਅਸੰਭਵ ਹੈ. ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਲਗਭਗ 30 - 100% ਹੁੰਦਾ ਹੈ, ਇਹ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਵਾਧੇ ਦੇ ਦੌਰਾਨ ਅਨੁਕੂਲਨ ਮੋਡ ਤੋਂ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰ ਨਿਕਲਣ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

hbase.lru.cache.heavy.eviction.overhead.coefficient - ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਜੇਕਰ ਅਸੀਂ ਪੱਕਾ ਜਾਣਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਰੀਡਜ਼ ਜ਼ਿਆਦਾਤਰ ਲੰਬੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਡੀਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਅਸੀਂ ਇਸ ਅਨੁਪਾਤ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇਸ ਗੁਣਾਂਕ = 0.01 ਨੂੰ ਸੈੱਟ ਕਰਦੇ ਹਾਂ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਓਵਰਹੈੱਡ (ਉੱਪਰ ਦੇਖੋ) ਨੂੰ ਇਸ ਸੰਖਿਆ ਨਾਲ ਨਤੀਜੇ ਵਜੋਂ ਗੁਣਾ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕਾਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਘਟਾਈ ਜਾਵੇਗੀ। ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਓਵਰਹੈੱਡ = 300% ਅਤੇ ਗੁਣਾਂਕ = 0.01, ਤਾਂ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕਾਂ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ 3% ਘੱਟ ਜਾਵੇਗੀ।

ਇੱਕ ਸਮਾਨ “ਬੈਕਪ੍ਰੈਸ਼ਰ” ਤਰਕ ਨਕਾਰਾਤਮਕ ਓਵਰਹੈੱਡ (ਓਵਰਸ਼ੂਟਿੰਗ) ਮੁੱਲਾਂ ਲਈ ਵੀ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਰੀਡਜ਼ ਅਤੇ ਬੇਦਖਲੀ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਹਮੇਸ਼ਾ ਸੰਭਵ ਹੁੰਦੇ ਹਨ, ਇਹ ਵਿਧੀ ਤੁਹਾਨੂੰ ਅਨੁਕੂਲਤਾ ਮੋਡ ਤੋਂ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰ ਜਾਣ ਤੋਂ ਬਚਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਬੈਕਪ੍ਰੈਸ਼ਰ ਦਾ ਇੱਕ ਉਲਟ ਤਰਕ ਹੁੰਦਾ ਹੈ: ਓਵਰਸ਼ੂਟਿੰਗ ਜਿੰਨਾ ਮਜ਼ਬੂਤ ​​ਹੁੰਦਾ ਹੈ, ਓਨੇ ਹੀ ਜ਼ਿਆਦਾ ਬਲਾਕ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਲਾਗੂ ਕਰਨ ਦਾ ਕੋਡ

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

ਆਉ ਹੁਣ ਇੱਕ ਅਸਲੀ ਉਦਾਹਰਣ ਵਰਤ ਕੇ ਇਸ ਸਭ ਨੂੰ ਵੇਖੀਏ। ਸਾਡੇ ਕੋਲ ਹੇਠਾਂ ਦਿੱਤੇ ਟੈਸਟ ਦ੍ਰਿਸ਼ ਹਨ:

1. ਸਕੈਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ (25 ਥ੍ਰੈਡ, ਬੈਚ = 100)
2. 5 ਮਿੰਟ ਬਾਅਦ, ਮਲਟੀ-ਗੇਟਸ (25 ਥਰਿੱਡ, ਬੈਚ = 100) ਸ਼ਾਮਲ ਕਰੋ
3. 5 ਮਿੰਟਾਂ ਬਾਅਦ, ਮਲਟੀ-ਗੇਟਸ ਨੂੰ ਬੰਦ ਕਰੋ (ਸਿਰਫ ਦੁਬਾਰਾ ਸਕੈਨ ਬਾਕੀ ਹੈ)

ਅਸੀਂ ਦੋ ਰਨ ਕਰਦੇ ਹਾਂ, ਪਹਿਲਾਂ hbase.lru.cache.heavy.eviction.count.limit = 10000 (ਜੋ ਅਸਲ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ), ਅਤੇ ਫਿਰ ਸੀਮਾ = 0 ਸੈੱਟ ਕਰੋ (ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ)।

ਹੇਠਾਂ ਦਿੱਤੇ ਲੌਗਸ ਵਿੱਚ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਵਿਸ਼ੇਸ਼ਤਾ ਕਿਵੇਂ ਚਾਲੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਓਵਰਸ਼ੂਟਿੰਗ ਨੂੰ 14-71% ਤੱਕ ਰੀਸੈਟ ਕਰਦਾ ਹੈ। ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਲੋਡ ਘਟਦਾ ਹੈ, ਜੋ ਬੈਕਪ੍ਰੈਸ਼ਰ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ ਅਤੇ HBase ਦੁਬਾਰਾ ਹੋਰ ਬਲਾਕਾਂ ਨੂੰ ਕੈਚ ਕਰਦਾ ਹੈ।

ਰੀਜਨ ਸਰਵਰ ਲੌਗ ਕਰੋ
ਬੇਦਖਲ (MB): 0, ਅਨੁਪਾਤ 0.0, ਓਵਰਹੈੱਡ (%): -100, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 0, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 100
ਬੇਦਖਲ (MB): 0, ਅਨੁਪਾਤ 0.0, ਓਵਰਹੈੱਡ (%): -100, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 0, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 100
ਬੇਦਖਲ (MB): 2170, ਅਨੁਪਾਤ 1.09, ਓਵਰਹੈੱਡ (%): 985, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 1, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 91 < ਸ਼ੁਰੂ
ਬੇਦਖਲ (MB): 3763, ਅਨੁਪਾਤ 1.08, ਓਵਰਹੈੱਡ (%): 1781, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 2, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 76
ਬੇਦਖਲ (MB): 3306, ਅਨੁਪਾਤ 1.07, ਓਵਰਹੈੱਡ (%): 1553, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 3, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 61
ਬੇਦਖਲ (MB): 2508, ਅਨੁਪਾਤ 1.06, ਓਵਰਹੈੱਡ (%): 1154, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 4, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 50
ਬੇਦਖਲ (MB): 1824, ਅਨੁਪਾਤ 1.04, ਓਵਰਹੈੱਡ (%): 812, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 5, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 42
ਬੇਦਖਲ (MB): 1482, ਅਨੁਪਾਤ 1.03, ਓਵਰਹੈੱਡ (%): 641, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 6, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 36
ਬੇਦਖਲ (MB): 1140, ਅਨੁਪਾਤ 1.01, ਓਵਰਹੈੱਡ (%): 470, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 7, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 32
ਬੇਦਖਲ (MB): 913, ਅਨੁਪਾਤ 1.0, ਓਵਰਹੈੱਡ (%): 356, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 8, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 29
ਬੇਦਖਲ (MB): 912, ਅਨੁਪਾਤ 0.89, ਓਵਰਹੈੱਡ (%): 356, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 9, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 26
ਬੇਦਖਲ (MB): 684, ਅਨੁਪਾਤ 0.76, ਓਵਰਹੈੱਡ (%): 242, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 10, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 24
ਬੇਦਖਲ (MB): 684, ਅਨੁਪਾਤ 0.61, ਓਵਰਹੈੱਡ (%): 242, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 11, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.51, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 12, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 21
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.42, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 13, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 20
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 14, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 15, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.32, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 16, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.31, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 17, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.3, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 18, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.29, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 19, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.27, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 20, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.25, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 21, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.24, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 22, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.22, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 23, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.21, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 24, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.2, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 25, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.17, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 26, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.17, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 27, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18 < ਜੋੜੇ ਗਏ (ਪਰ ਸਾਰਣੀ ਉਹੀ)
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.15, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 28, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.13, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 29, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.11, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 30, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.09, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 31, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.08, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 32, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.07, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 33, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.06, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 34, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.05, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 35, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.05, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 36, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.04, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 37, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 109, ਅਨੁਪਾਤ 0.04, ਓਵਰਹੈੱਡ (%): -46, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 37, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22 < ਪਿੱਛੇ ਦਬਾਅ
ਬੇਦਖਲ (MB): 798, ਅਨੁਪਾਤ 0.24, ਓਵਰਹੈੱਡ (%): 299, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 38, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 20
ਬੇਦਖਲ (MB): 798, ਅਨੁਪਾਤ 0.29, ਓਵਰਹੈੱਡ (%): 299, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 39, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 570, ਅਨੁਪਾਤ 0.27, ਓਵਰਹੈੱਡ (%): 185, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 40, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 17
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.22, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 41, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.16, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 42, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.11, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 43, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.09, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 44, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.07, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 45, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.05, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 46, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 222, ਅਨੁਪਾਤ 0.04, ਓਵਰਹੈੱਡ (%): 11, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 47, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 16
ਬੇਦਖਲ (MB): 104, ਅਨੁਪਾਤ 0.03, ਓਵਰਹੈੱਡ (%): -48, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 47, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 21 < ਇੰਟਰੱਪਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ
ਬੇਦਖਲ (MB): 684, ਅਨੁਪਾਤ 0.2, ਓਵਰਹੈੱਡ (%): 242, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 48, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 19
ਬੇਦਖਲ (MB): 570, ਅਨੁਪਾਤ 0.23, ਓਵਰਹੈੱਡ (%): 185, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 49, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.22, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 50, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.21, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 51, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.2, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 52, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.18, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 53, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.16, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 54, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 228, ਅਨੁਪਾਤ 0.14, ਓਵਰਹੈੱਡ (%): 14, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 55, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 18
ਬੇਦਖਲ (MB): 112, ਅਨੁਪਾਤ 0.14, ਓਵਰਹੈੱਡ (%): -44, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 55, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 23 < ਪਿੱਛੇ ਦਬਾਅ
ਬੇਦਖਲ (MB): 456, ਅਨੁਪਾਤ 0.26, ਓਵਰਹੈੱਡ (%): 128, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 56, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.31, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 57, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 58, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 59, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 60, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 61, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 62, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 63, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.32, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 64, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 65, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 66, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.32, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 67, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 68, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.32, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 69, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.32, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 70, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 71, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 72, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 73, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 74, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 75, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 342, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): 71, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 76, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 22
ਬੇਦਖਲ (MB): 21, ਅਨੁਪਾਤ 0.33, ਓਵਰਹੈੱਡ (%): -90, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 76, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 32
ਬੇਦਖਲ (MB): 0, ਅਨੁਪਾਤ 0.0, ਓਵਰਹੈੱਡ (%): -100, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 0, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 100
ਬੇਦਖਲ (MB): 0, ਅਨੁਪਾਤ 0.0, ਓਵਰਹੈੱਡ (%): -100, ਭਾਰੀ ਬੇਦਖਲੀ ਕਾਊਂਟਰ: 0, ਮੌਜੂਦਾ ਕੈਚਿੰਗ ਡੇਟਾਬਲਾਕ (%): 100

ਦੋ ਕੈਸ਼ ਭਾਗਾਂ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧ ਦੇ ਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਸਕੈਨ ਦੀ ਲੋੜ ਸੀ - ਸਿੰਗਲ (ਜਿੱਥੇ ਬਲਾਕ ਜਿਨ੍ਹਾਂ ਦੀ ਪਹਿਲਾਂ ਕਦੇ ਬੇਨਤੀ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ) ਅਤੇ ਮਲਟੀ (ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ "ਬੇਨਤੀ ਕੀਤੀ ਗਈ" ਡੇਟਾ ਇੱਥੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ):

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਸੰਚਾਲਨ ਇੱਕ ਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਤੁਲਨਾ ਲਈ, ਕੈਸ਼ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਫਿਰ HBase ਨੂੰ ਕੈਚਿੰਗ ਦੇ ਨਾਲ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ 5 ਮਿੰਟ (30 ਬੇਦਖਲੀ ਚੱਕਰ) ਦੁਆਰਾ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕੰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਦੇਰੀ ਕੀਤੀ ਗਈ ਸੀ।

ਪੂਰਾ ਕੋਡ ਪੁੱਲ ਬੇਨਤੀ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ HBASE 23887 github 'ਤੇ.

ਹਾਲਾਂਕਿ, 300 ਹਜ਼ਾਰ ਰੀਡ ਪ੍ਰਤੀ ਸਕਿੰਟ ਇਹ ਸਭ ਕੁਝ ਨਹੀਂ ਹੈ ਜੋ ਇਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਇਸ ਹਾਰਡਵੇਅਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਤੁਹਾਨੂੰ HDFS ਦੁਆਰਾ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ShortCircuitCache (ਇਸ ਤੋਂ ਬਾਅਦ SSC ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਵਿਧੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਇੰਟਰੈਕਸ਼ਨਾਂ ਤੋਂ ਬਚਦੇ ਹੋਏ, ਸਿੱਧੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

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

ਇਸ ਨੂੰ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਸੁਤੰਤਰ SSCs ਦੀ ਇੱਕ ਲੜੀ ਬਣਾ ਕੇ ਸਮੱਸਿਆ ਨੂੰ ਦੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰੋ, ਚੌਰਾਹੇ ਨੂੰ ਛੱਡ ਕੇ ਆਖਰੀ ਆਫਸੈੱਟ ਅੰਕਾਂ 'ਤੇ ਵੀ:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

ਹੁਣ ਤੁਸੀਂ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ HDFS ਤੋਂ ਫਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹਾਂਗੇ। ਪੈਰਾਮੀਟਰ ਸੈੱਟ ਕਰੋ:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

ਅਤੇ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹੋ:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

ਇਹ ਕੋਡ ਵੱਖਰੇ ਥ੍ਰੈੱਡਾਂ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇੱਕੋ ਸਮੇਂ ਪੜ੍ਹੀਆਂ ਗਈਆਂ ਫਾਈਲਾਂ (10 ਤੋਂ 200 ਤੱਕ - ਹਰੀਜੱਟਲ ਐਕਸਿਸ ਤੱਕ) ਅਤੇ ਕੈਚਾਂ ਦੀ ਗਿਣਤੀ (1 ਤੋਂ 10 ਤੱਕ - ਗ੍ਰਾਫਿਕਸ) ਨੂੰ ਵਧਾਵਾਂਗੇ। ਲੰਬਕਾਰੀ ਧੁਰਾ ਉਸ ਪ੍ਰਵੇਗ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਕੇਸ ਦੇ ਮੁਕਾਬਲੇ SSC ਵਿੱਚ ਵਾਧੇ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਿਰਫ਼ ਇੱਕ ਕੈਸ਼ ਹੁੰਦਾ ਹੈ।

ਗ੍ਰਾਫ ਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਨਾ ਹੈ: ਇੱਕ ਕੈਸ਼ ਦੇ ਨਾਲ 100 KB ਬਲਾਕਾਂ ਵਿੱਚ 64 ਹਜ਼ਾਰ ਰੀਡਜ਼ ਲਈ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ 78 ਸਕਿੰਟ ਦੀ ਲੋੜ ਹੈ। ਜਦੋਂ ਕਿ 5 ਕੈਚਾਂ ਦੇ ਨਾਲ ਇਸ ਨੂੰ 16 ਸਕਿੰਟ ਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਉਹ. ਇੱਥੇ ~ 5 ਗੁਣਾ ਦਾ ਪ੍ਰਵੇਗ ਹੈ। ਜਿਵੇਂ ਕਿ ਗ੍ਰਾਫ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸਮਾਂਤਰ ਰੀਡਜ਼ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸੰਖਿਆ ਲਈ ਪ੍ਰਭਾਵ ਬਹੁਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ ਹੈ; ਇਹ ਇੱਕ ਧਿਆਨ ਦੇਣ ਯੋਗ ਭੂਮਿਕਾ ਨਿਭਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜਦੋਂ 50 ਤੋਂ ਵੱਧ ਥ੍ਰੈਡ ਰੀਡ ਹੁੰਦੇ ਹਨ। ਇਹ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ 6 ਤੋਂ ਐਸਐਸਸੀ ਦੀ ਗਿਣਤੀ ਵਧ ਰਹੀ ਹੈ. ਅਤੇ ਉੱਪਰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਛੋਟਾ ਪ੍ਰਦਰਸ਼ਨ ਵਾਧਾ ਦਿੰਦਾ ਹੈ।

ਨੋਟ 1: ਕਿਉਂਕਿ ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਕਾਫ਼ੀ ਅਸਥਿਰ ਹਨ (ਹੇਠਾਂ ਦੇਖੋ), 3 ਦੌੜਾਂ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮੁੱਲ ਔਸਤ ਕੀਤੇ ਗਏ ਸਨ।

ਨੋਟ 2: ਬੇਤਰਤੀਬ ਪਹੁੰਚ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਤੋਂ ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ ਇੱਕੋ ਜਿਹਾ ਹੈ, ਹਾਲਾਂਕਿ ਪਹੁੰਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਥੋੜੀ ਹੌਲੀ ਹੈ।

ਹਾਲਾਂਕਿ, ਇਹ ਸਪੱਸ਼ਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ, HBase ਦੇ ਮਾਮਲੇ ਦੇ ਉਲਟ, ਇਹ ਪ੍ਰਵੇਗ ਹਮੇਸ਼ਾ ਮੁਫਤ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਅਸੀਂ ਲਾਕ 'ਤੇ ਲਟਕਣ ਦੀ ਬਜਾਏ, CPU ਦੀ ਹੋਰ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ "ਅਨਲਾਕ" ਕਰਦੇ ਹਾਂ।

ਇੱਥੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ, ਆਮ ਤੌਰ 'ਤੇ, ਕੈਚਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਵਾਧਾ CPU ਉਪਯੋਗਤਾ ਵਿੱਚ ਲਗਭਗ ਅਨੁਪਾਤਕ ਵਾਧਾ ਦਿੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਥੋੜੇ ਹੋਰ ਜਿੱਤਣ ਵਾਲੇ ਸੰਜੋਗ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਆਉ ਸੈਟਿੰਗ SSC = 3 'ਤੇ ਇੱਕ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ. ਸੀਮਾ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ ਲਗਭਗ 3.3 ਗੁਣਾ ਹੈ. ਹੇਠਾਂ ਸਾਰੀਆਂ ਤਿੰਨ ਵੱਖਰੀਆਂ ਦੌੜਾਂ ਦੇ ਨਤੀਜੇ ਹਨ।

ਜਦੋਂ ਕਿ CPU ਦੀ ਖਪਤ ਲਗਭਗ 2.8 ਗੁਣਾ ਵਧ ਜਾਂਦੀ ਹੈ। ਫਰਕ ਬਹੁਤ ਵੱਡਾ ਨਹੀਂ ਹੈ, ਪਰ ਛੋਟੀ ਗ੍ਰੇਟਾ ਪਹਿਲਾਂ ਹੀ ਖੁਸ਼ ਹੈ ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਕੂਲ ਅਤੇ ਪਾਠਾਂ ਵਿੱਚ ਜਾਣ ਦਾ ਸਮਾਂ ਹੋਵੇਗਾ.

ਇਸ ਤਰ੍ਹਾਂ, ਇਹ ਕਿਸੇ ਵੀ ਟੂਲ ਲਈ ਸਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪਾਵੇਗਾ ਜੋ HDFS (ਉਦਾਹਰਨ ਲਈ ਸਪਾਰਕ, ​​ਆਦਿ) ਦੀ ਬਲਕ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਹਲਕਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਪਲੱਗ HDFS ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਹੈ) ਅਤੇ ਮੁਫਤ CPU ਪਾਵਰ ਹੈ। . ਜਾਂਚ ਕਰਨ ਲਈ, ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ HBase ਤੋਂ ਪੜ੍ਹਨ ਲਈ BlockCache ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਅਤੇ SSC ਟਿਊਨਿੰਗ ਦੀ ਸੰਯੁਕਤ ਵਰਤੋਂ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ।

ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪ੍ਰਭਾਵ ਇੰਨਾ ਵਧੀਆ ਨਹੀਂ ਹੁੰਦਾ ਜਿੰਨਾ ਰਿਫਾਈਨਡ ਟੈਸਟਾਂ ਵਿੱਚ (ਕਿਸੇ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹਨਾ), ਪਰ ਇੱਥੇ ਇੱਕ ਵਾਧੂ 80K ਨੂੰ ਨਿਚੋੜਨਾ ਕਾਫ਼ੀ ਸੰਭਵ ਹੈ। ਇਕੱਠੇ, ਦੋਵੇਂ ਅਨੁਕੂਲਨ 4x ਸਪੀਡਅੱਪ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਇਸ ਅਨੁਕੂਲਤਾ ਲਈ ਇੱਕ PR ਵੀ ਬਣਾਇਆ ਗਿਆ ਸੀ [HDFS-15202], ਜਿਸ ਨੂੰ ਮਿਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਭਵਿੱਖ ਦੀਆਂ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਉਪਲਬਧ ਹੋਵੇਗੀ।

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਇੱਕ ਸਮਾਨ ਵਾਈਡ-ਕਾਲਮ ਡੇਟਾਬੇਸ, ਕੈਸੈਂਡਰਾ ਅਤੇ ਐਚਬੇਸ ਦੇ ਰੀਡਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਦਿਲਚਸਪ ਸੀ.

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਦੋ ਮੇਜ਼ਬਾਨਾਂ (ਕੁੱਲ 800 ਥ੍ਰੈਡਸ) ਤੋਂ ਮਿਆਰੀ YCSB ਲੋਡ ਟੈਸਟਿੰਗ ਉਪਯੋਗਤਾ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਲਾਂਚ ਕੀਤੀਆਂ ਹਨ। ਸਰਵਰ ਸਾਈਡ 'ਤੇ - 4 ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਰੀਜਨਸਰਵਰ ਅਤੇ ਕੈਸੈਂਡਰਾ ਦੀਆਂ 4 ਉਦਾਹਰਣਾਂ (ਉਹ ਨਹੀਂ ਜਿੱਥੇ ਗਾਹਕ ਚੱਲ ਰਹੇ ਹਨ, ਉਨ੍ਹਾਂ ਦੇ ਪ੍ਰਭਾਵ ਤੋਂ ਬਚਣ ਲਈ)। ਰੀਡਿੰਗ ਆਕਾਰ ਦੀਆਂ ਟੇਬਲਾਂ ਤੋਂ ਆਈਆਂ:

HBase - HDFS 'ਤੇ 300 GB (100 GB ਸ਼ੁੱਧ ਡਾਟਾ)

ਕੈਸੈਂਡਰਾ - 250 GB (ਰਿਪਲੀਕੇਸ਼ਨ ਫੈਕਟਰ = 3)

ਉਹ. ਵਾਲੀਅਮ ਲਗਭਗ ਸਮਾਨ ਸੀ (HBase ਵਿੱਚ ਥੋੜਾ ਹੋਰ)।

HBase ਪੈਰਾਮੀਟਰ:

dfs.client.short.circuit.num = 5 (HDFS ਕਲਾਇੰਟ ਓਪਟੀਮਾਈਜੇਸ਼ਨ)

hbase.lru.cache.heavy.eviction.count.limit = 30 - ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੈਚ 30 ਬੇਦਖਲੀ (~ 5 ਮਿੰਟ) ਤੋਂ ਬਾਅਦ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ।

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - ਕੈਚਿੰਗ ਅਤੇ ਬੇਦਖਲੀ ਦਾ ਟੀਚਾ ਵਾਲੀਅਮ

YCSB ਲੌਗਾਂ ਨੂੰ ਐਕਸਲ ਗ੍ਰਾਫਾਂ ਵਿੱਚ ਪਾਰਸ ਅਤੇ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਸੀ:

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਇਹ ਅਨੁਕੂਲਤਾ ਇਹਨਾਂ ਸਥਿਤੀਆਂ ਦੇ ਅਧੀਨ ਇਹਨਾਂ ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 450 ਹਜ਼ਾਰ ਰੀਡ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ.

ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਉਤਪਾਦਕਤਾ ਲਈ ਦਿਲਚਸਪ ਸੰਘਰਸ਼ ਦੌਰਾਨ ਇਹ ਜਾਣਕਾਰੀ ਕਿਸੇ ਲਈ ਉਪਯੋਗੀ ਹੋ ਸਕਦੀ ਹੈ.

ਸਰੋਤ: www.habr.com