This is an automated email from the ASF dual-hosted git repository.
pnowojski pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/flink-web.git
The following commit(s) were added to refs/heads/asf-site by this push:
new f541958 Fix formating in backpressure blog
f541958 is described below
commit f541958916c52de22d41bef30d496eb1bb251ffd
Author: Piotr Nowojski <[email protected]>
AuthorDate: Wed Jul 7 20:22:54 2021 +0200
Fix formating in backpressure blog
---
_posts/2021-07-07-backpressure.md | 3 +++
content/2021/07/07/backpressure.html | 25 ++++++++++++++++---------
content/blog/feed.xml | 25 ++++++++++++++++---------
3 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/_posts/2021-07-07-backpressure.md
b/_posts/2021-07-07-backpressure.md
index b144d1b..94977fd 100644
--- a/_posts/2021-07-07-backpressure.md
+++ b/_posts/2021-07-07-backpressure.md
@@ -97,9 +97,11 @@ happening with your Job :) However, there are a couple of
more details worth exp
If you are curious how it works underneath, we can go a little deeper. At the
base of this new mechanism
we have three [new
metrics](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/metrics/#io)
that are exposed and calculated by each subtask:
+
- `idleTimeMsPerSecond`
- `busyTimeMsPerSecond`
- `backPressuredTimeMsPerSecond`
+
Each of them measures the average time in milliseconds per second that the
subtask spent being idle,
busy, or backpressured respectively. Apart from some rounding errors they
should complement each other and
add up to 1000ms/s. In essence, they are quite similar to, for example, CPU
usage metrics.
@@ -166,6 +168,7 @@ In short, there are two high-level ways of dealing with
backpressure. Either add
faster CPU, more RAM, better network, using SSDs…) or optimize usage of the
resources you already have
(optimize the code, tune the configuration, avoid data skew). In either case,
you first need to analyze
what is causing backpressure by:
+
1. Identifying the presence of backpressure.
2. Locating which subtask(s) or machines are causing it.
3. Digging deeper into what part of the code is causing it and which resource
is scarce.
diff --git a/content/2021/07/07/backpressure.html
b/content/2021/07/07/backpressure.html
index 1f7f6b4..9507831 100644
--- a/content/2021/07/07/backpressure.html
+++ b/content/2021/07/07/backpressure.html
@@ -303,11 +303,15 @@ happening with your Job :) However, there are a couple of
more details worth exp
<p>If you are curious how it works underneath, we can go a little deeper. At
the base of this new mechanism
we have three <a
href="https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/metrics/#io";>new
metrics</a>
-that are exposed and calculated by each subtask:
-- <code>idleTimeMsPerSecond</code>
-- <code>busyTimeMsPerSecond</code>
-- <code>backPressuredTimeMsPerSecond</code>
-Each of them measures the average time in milliseconds per second that the
subtask spent being idle,
+that are exposed and calculated by each subtask:</p>
+
+<ul>
+ <li><code>idleTimeMsPerSecond</code></li>
+ <li><code>busyTimeMsPerSecond</code></li>
+ <li><code>backPressuredTimeMsPerSecond</code></li>
+</ul>
+
+<p>Each of them measures the average time in milliseconds per second that the
subtask spent being idle,
busy, or backpressured respectively. Apart from some rounding errors they
should complement each other and
add up to 1000ms/s. In essence, they are quite similar to, for example, CPU
usage metrics.</p>
@@ -372,10 +376,13 @@ addressed in <a
href="https://flink.apache.org/2019/07/23/flink-network-stack-2.
In short, there are two high-level ways of dealing with backpressure. Either
add more resources (more machines,
faster CPU, more RAM, better network, using SSDs…) or optimize usage of the
resources you already have
(optimize the code, tune the configuration, avoid data skew). In either case,
you first need to analyze
-what is causing backpressure by:
-1. Identifying the presence of backpressure.
-2. Locating which subtask(s) or machines are causing it.
-3. Digging deeper into what part of the code is causing it and which resource
is scarce.</p>
+what is causing backpressure by:</p>
+
+<ol>
+ <li>Identifying the presence of backpressure.</li>
+ <li>Locating which subtask(s) or machines are causing it.</li>
+ <li>Digging deeper into what part of the code is causing it and which
resource is scarce.</li>
+</ol>
<p>Backpressure monitoring improvements and metrics can help you with the
first two points. To tackle the
last one, profiling the code can be the way to go. To help with profiling,
also starting from Flink 1.13,
diff --git a/content/blog/feed.xml b/content/blog/feed.xml
index dcf63e1..2a709f9 100644
--- a/content/blog/feed.xml
+++ b/content/blog/feed.xml
@@ -110,11 +110,15 @@ happening with your Job :) However, there are a couple of
more details worth exp
<p>If you are curious how it works underneath, we can go a little
deeper. At the base of this new mechanism
we have three <a
href="https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/metrics/#io">new
metrics</a>
-that are exposed and calculated by each subtask:
-- <code>idleTimeMsPerSecond</code>
-- <code>busyTimeMsPerSecond</code>
-- <code>backPressuredTimeMsPerSecond</code>
-Each of them measures the average time in milliseconds per second that the
subtask spent being idle,
+that are exposed and calculated by each subtask:</p>
+
+<ul>
+ <li><code>idleTimeMsPerSecond</code></li>
+ <li><code>busyTimeMsPerSecond</code></li>
+ <li><code>backPressuredTimeMsPerSecond</code></li>
+</ul>
+
+<p>Each of them measures the average time in milliseconds per second
that the subtask spent being idle,
busy, or backpressured respectively. Apart from some rounding errors they
should complement each other and
add up to 1000ms/s. In essence, they are quite similar to, for example, CPU
usage metrics.</p>
@@ -179,10 +183,13 @@ addressed in <a
href="https://flink.apache.org/2019/07/23/flink-network-
In short, there are two high-level ways of dealing with backpressure. Either
add more resources (more machines,
faster CPU, more RAM, better network, using SSDs…) or optimize usage of the
resources you already have
(optimize the code, tune the configuration, avoid data skew). In either case,
you first need to analyze
-what is causing backpressure by:
-1. Identifying the presence of backpressure.
-2. Locating which subtask(s) or machines are causing it.
-3. Digging deeper into what part of the code is causing it and which resource
is scarce.</p>
+what is causing backpressure by:</p>
+
+<ol>
+ <li>Identifying the presence of backpressure.</li>
+ <li>Locating which subtask(s) or machines are causing it.</li>
+ <li>Digging deeper into what part of the code is causing it and which
resource is scarce.</li>
+</ol>
<p>Backpressure monitoring improvements and metrics can help you with
the first two points. To tackle the
last one, profiling the code can be the way to go. To help with profiling,
also starting from Flink 1.13,
