ਪ੍ਰੋਮੀਥੀਅਸ 2 ਵਿੱਚ TSDB ਵਿਸ਼ਲੇਸ਼ਣ

ਪ੍ਰੋਮੀਥੀਅਸ 2 ਵਿੱਚ ਟਾਈਮ ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ (ਟੀਐਸਡੀਬੀ) ਇੱਕ ਇੰਜਨੀਅਰਿੰਗ ਹੱਲ ਦਾ ਇੱਕ ਸ਼ਾਨਦਾਰ ਉਦਾਹਰਨ ਹੈ ਜੋ ਪ੍ਰੋਮੀਥੀਅਸ 2 ਵਿੱਚ v1 ਸਟੋਰੇਜ਼ ਵਿੱਚ ਡਾਟਾ ਇਕੱਤਰ ਕਰਨ ਦੀ ਗਤੀ, ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਅਤੇ ਸਰੋਤ ਕੁਸ਼ਲਤਾ ਦੇ ਰੂਪ ਵਿੱਚ ਵੱਡੇ ਸੁਧਾਰਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਪਰਕੋਨਾ ਮਾਨੀਟਰਿੰਗ ਐਂਡ ਮੈਨੇਜਮੈਂਟ (PMM) ਵਿੱਚ Prometheus 2 ਨੂੰ ਲਾਗੂ ਕਰ ਰਹੇ ਸੀ ਅਤੇ ਮੈਨੂੰ Prometheus 2 TSDB ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਸਮਝਣ ਦਾ ਮੌਕਾ ਮਿਲਿਆ। ਇਸ ਲੇਖ ਵਿਚ ਮੈਂ ਇਹਨਾਂ ਨਿਰੀਖਣਾਂ ਦੇ ਨਤੀਜਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ.

ਔਸਤ ਪ੍ਰੋਮੀਥੀਅਸ ਵਰਕਲੋਡ

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

ਲੋਡ ਟੈਸਟ

ਟੈਸਟਿੰਗ ਦੌਰਾਨ, ਮੈਂ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਦੀ ਯੋਗਤਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕੀਤਾ। ਮੈਂ ਇਸ ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਲਿਨੋਡ ਸੇਵਾ 'ਤੇ ਗੋ 2.3.2 (PMM 1.10.1 ਦੇ ਹਿੱਸੇ ਵਜੋਂ) ਦੇ ਨਾਲ ਕੰਪਾਇਲ ਕੀਤੇ ਪ੍ਰੋਮੀਥੀਅਸ 1.14 ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ ਹੈ: ਸਟੈਕਸਕ੍ਰਿਪਟ. ਸਭ ਤੋਂ ਯਥਾਰਥਵਾਦੀ ਲੋਡ ਪੀੜ੍ਹੀ ਲਈ, ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਟੈਕਸਕ੍ਰਿਪਟ ਮੈਂ ਇੱਕ ਅਸਲੀ ਲੋਡ (Sysbench TPC-C ਟੈਸਟ) ਦੇ ਨਾਲ ਕਈ MySQL ਨੋਡ ਲਾਂਚ ਕੀਤੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ 10 ਨੋਡਾਂ ਦੀ ਨਕਲ ਕੀਤੀ। Linux/ਮਾਈਐਸਕਿਊਐਲ।
ਹੇਠਾਂ ਦਿੱਤੇ ਸਾਰੇ ਟੈਸਟ ਅੱਠ ਵਰਚੁਅਲ ਕੋਰ ਅਤੇ 32 GB ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਲਿਨੋਡ ਸਰਵਰ 'ਤੇ ਕੀਤੇ ਗਏ ਸਨ, ਦੋ ਸੌ MySQL ਮੌਕਿਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਵਾਲੇ 20 ਲੋਡ ਸਿਮੂਲੇਸ਼ਨ ਚਲਾ ਰਹੇ ਸਨ। ਜਾਂ, ਪ੍ਰੋਮੀਥੀਅਸ ਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, 800 ਟੀਚੇ, 440 ਸਕ੍ਰੈਪਸ ਪ੍ਰਤੀ ਸਕਿੰਟ, 380 ਹਜ਼ਾਰ ਰਿਕਾਰਡ ਪ੍ਰਤੀ ਸਕਿੰਟ, ਅਤੇ 1,7 ਮਿਲੀਅਨ ਕਿਰਿਆਸ਼ੀਲ ਸਮਾਂ ਲੜੀ।

ਡਿਜ਼ਾਈਨ

ਪਰੰਪਰਾਗਤ ਡੇਟਾਬੇਸ ਦੀ ਆਮ ਪਹੁੰਚ, ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਮੀਥੀਅਸ 1.x ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਹੈ ਮੈਮੋਰੀ ਸੀਮਾ. ਜੇ ਇਹ ਲੋਡ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉੱਚ ਲੇਟੈਂਸੀ ਦਾ ਅਨੁਭਵ ਕਰੋਗੇ ਅਤੇ ਕੁਝ ਬੇਨਤੀਆਂ ਅਸਫਲ ਹੋ ਜਾਣਗੀਆਂ। ਪ੍ਰੋਮੀਥੀਅਸ 2 ਵਿੱਚ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕੁੰਜੀ ਦੁਆਰਾ ਸੰਰਚਿਤ ਹੈ storage.tsdb.min-block-duration, ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨੀ ਦੇਰ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇਗਾ (ਡਿਫੌਲਟ 2 ਘੰਟੇ ਹੈ)। ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਨੈੱਟ ਇਨਕਮਿੰਗ ਸਟ੍ਰੀਮ ਵਿੱਚ ਜੋੜੀ ਗਈ ਸਮਾਂ ਲੜੀ, ਲੇਬਲਾਂ ਅਤੇ ਸਕ੍ਰੈਪਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰੇਗੀ। ਡਿਸਕ ਸਪੇਸ ਦੇ ਰੂਪ ਵਿੱਚ, ਪ੍ਰੋਮੀਥੀਅਸ ਦਾ ਉਦੇਸ਼ 3 ਬਾਈਟ ਪ੍ਰਤੀ ਰਿਕਾਰਡ (ਨਮੂਨਾ) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਮੈਮੋਰੀ ਦੀਆਂ ਲੋੜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਨ.

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

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

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

ਸੰਕੁਚਿਤ

ਪ੍ਰੋਮੀਥੀਅਸ TSDB ਨੂੰ ਇੱਕ LSM (ਲੌਗ ਸਟ੍ਰਕਚਰਡ ਮਰਜ) ਸਟੋਰ ਵਾਂਗ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਹੈੱਡ ਬਲਾਕ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਕੰਪੈਕਸ਼ਨ ਮਕੈਨਿਜ਼ਮ ਸਵਾਲਾਂ ਦੇ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੇ ਬਲਾਕਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ ਕਈ ਬਲਾਕਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਬਲਾਕਾਂ ਦੀ ਸੰਖਿਆ ਦੇਖ ਸਕਦੇ ਹੋ ਜੋ ਮੈਂ ਇੱਕ ਦਿਨ ਦੇ ਲੋਡ ਤੋਂ ਬਾਅਦ ਟੈਸਟ ਸਿਸਟਮ 'ਤੇ ਦੇਖਿਆ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਸਟੋਰ ਬਾਰੇ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ meta.json ਫਾਈਲ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਉਪਲਬਧ ਬਲਾਕਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਬਣੇ।

{
       "ulid": "01CPZDPD1D9R019JS87TPV5MPE",
       "minTime": 1536472800000,
       "maxTime": 1536494400000,
       "stats": {
               "numSamples": 8292128378,
               "numSeries": 1673622,
               "numChunks": 69528220
       },
       "compaction": {
               "level": 2,
               "sources": [
                       "01CPYRY9MS465Y5ETM3SXFBV7X",
                       "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                       "01CPZ6NR4Q3PDP3E57HEH760XS"
               ],
               "parents": [
                       {
                               "ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
                               "minTime": 1536472800000,
                               "maxTime": 1536480000000
                       },
                       {
                               "ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                               "minTime": 1536480000000,
                               "maxTime": 1536487200000
                       },
                       {
                               "ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
                               "minTime": 1536487200000,
                               "maxTime": 1536494400000
                       }
               ]
       },
       "version": 1
}

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

ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਕੰਪੈਕਸ਼ਨ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸੀਮਿਤ ਨਹੀਂ ਹਨ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ ਵੱਡੀ ਡਿਸਕ I/O ਸਪਾਈਕ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ।

CPU ਲੋਡ ਸਪਾਈਕਸ

ਬੇਸ਼ੱਕ, ਇਸਦਾ ਸਿਸਟਮ ਦੀ ਗਤੀ 'ਤੇ ਇੱਕ ਨਾਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਹੈ, ਅਤੇ ਇਹ LSM ਸਟੋਰੇਜ ਲਈ ਇੱਕ ਗੰਭੀਰ ਚੁਣੌਤੀ ਵੀ ਹੈ: ਬਹੁਤ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਉੱਚ ਬੇਨਤੀ ਦਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਕੰਪੈਕਸ਼ਨ ਕਿਵੇਂ ਕਰੀਏ?
ਸੰਕੁਚਿਤ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਵੀ ਕਾਫ਼ੀ ਦਿਲਚਸਪ ਲੱਗਦੀ ਹੈ.

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

ਇੱਕ ਅਸਫਲਤਾ ਦੇ ਬਾਅਦ ਰਿਕਵਰੀ

ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਰਿਕਵਰੀ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਚੰਗੇ ਕਾਰਨ ਕਰਕੇ. ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਮਿਲੀਅਨ ਰਿਕਾਰਡਾਂ ਦੀ ਆਉਣ ਵਾਲੀ ਸਟ੍ਰੀਮ ਲਈ, ਮੈਨੂੰ ਲਗਭਗ 25 ਮਿੰਟ ਉਡੀਕ ਕਰਨੀ ਪਈ ਜਦੋਂ ਕਿ SSD ਡਰਾਈਵ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਰਿਕਵਰੀ ਕੀਤੀ ਗਈ ਸੀ।

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."

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

ਗਰਮ ਹੋਣਾ

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

ਮੈਮੋਰੀ ਵਰਤੋਂ ਵਿੱਚ ਅੰਤਰ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਪ੍ਰੋਮੀਥੀਅਸ ਸ਼ੁਰੂ ਤੋਂ ਸਾਰੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ਸੰਰਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਜਾਣਕਾਰੀ ਗੁੰਮ ਹੋ ਗਈ ਹੈ।
ਮੈਂ ਉੱਚ CPU ਅਤੇ ਮੈਮੋਰੀ ਲੋਡ ਦੇ ਸਹੀ ਕਾਰਨਾਂ ਦਾ ਪਤਾ ਨਹੀਂ ਲਗਾਇਆ ਹੈ। ਮੈਨੂੰ ਸ਼ੱਕ ਹੈ ਕਿ ਇਹ ਉੱਚ ਫ੍ਰੀਕੁਐਂਸੀ ਦੇ ਨਾਲ ਹੈੱਡ ਬਲਾਕ ਵਿੱਚ ਨਵੀਂ ਸਮਾਂ ਲੜੀ ਬਣਾਉਣ ਦੇ ਕਾਰਨ ਹੈ.

CPU ਲੋਡ ਵਧਦਾ ਹੈ

ਕੰਪੈਕਸ਼ਨਾਂ ਤੋਂ ਇਲਾਵਾ, ਜੋ ਕਾਫ਼ੀ ਉੱਚ I/O ਲੋਡ ਬਣਾਉਂਦੇ ਹਨ, ਮੈਂ ਹਰ ਦੋ ਮਿੰਟਾਂ ਵਿੱਚ CPU ਲੋਡ ਵਿੱਚ ਗੰਭੀਰ ਸਪਾਈਕਸ ਦੇਖੇ ਹਨ। ਬਰਸਟ ਲੰਬੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਇਨਪੁਟ ਦਾ ਪ੍ਰਵਾਹ ਉੱਚਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗੋ ਦੇ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਦੇ ਕਾਰਨ ਜਾਪਦਾ ਹੈ, ਘੱਟੋ ਘੱਟ ਕੁਝ ਕੋਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੋਡ ਹੋਣ ਦੇ ਨਾਲ।

ਇਹ ਛਾਲ ਇੰਨੇ ਮਾਮੂਲੀ ਨਹੀਂ ਹਨ. ਅਜਿਹਾ ਪ੍ਰਤੀਤ ਹੁੰਦਾ ਹੈ ਕਿ ਜਦੋਂ ਇਹ ਵਾਪਰਦੇ ਹਨ, ਪ੍ਰੋਮੀਥੀਅਸ ਦੇ ਅੰਦਰੂਨੀ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇਹਨਾਂ ਸਮਿਆਂ ਦੇ ਸਮੇਂ ਦੌਰਾਨ ਡੇਟਾ ਅੰਤਰ ਪੈਦਾ ਹੁੰਦੇ ਹਨ।

ਤੁਸੀਂ ਇਹ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਪ੍ਰੋਮੀਥੀਅਸ ਨਿਰਯਾਤਕ ਇੱਕ ਸਕਿੰਟ ਲਈ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ.

ਅਸੀਂ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ (GC) ਨਾਲ ਸਬੰਧ ਦੇਖ ਸਕਦੇ ਹਾਂ।

ਸਿੱਟਾ

Prometheus 2 ਵਿੱਚ TSDB ਤੇਜ਼ ਹੈ, ਲੱਖਾਂ ਟਾਈਮ ਸੀਰੀਜ਼ ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਸਮਰੱਥ ਹੈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਕਾਫ਼ੀ ਮਾਮੂਲੀ ਹਾਰਡਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹਜ਼ਾਰਾਂ ਰਿਕਾਰਡ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈ। CPU ਅਤੇ ਡਿਸਕ I/O ਉਪਯੋਗਤਾ ਵੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ। ਮੇਰੀ ਉਦਾਹਰਣ ਨੇ ਪ੍ਰਤੀ ਕੋਰ ਪ੍ਰਤੀ ਸਕਿੰਟ 200 ਮੀਟ੍ਰਿਕਸ ਦਿਖਾਇਆ.

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

ਬੇਸ਼ੱਕ, CPU ਅਤੇ ਡਿਸਕ I/O ਸਪਾਈਕਸ ਨੂੰ ਕਾਬੂ ਕਰਨ ਲਈ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕੀਤਾ ਜਾਣਾ ਬਾਕੀ ਹੈ, ਅਤੇ ਇਹ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਕਿਵੇਂ ਨੌਜਵਾਨ TSDB Prometheus 2 ਦੀ ਤੁਲਨਾ InnoDB, TokuDB, RocksDB, WiredTiger ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਉਹਨਾਂ ਸਾਰਿਆਂ ਦੇ ਸਮਾਨ ਸਨ। ਉਹਨਾਂ ਦੇ ਜੀਵਨ ਚੱਕਰ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ.

ਸਰੋਤ: www.habr.com