Well there was this huge IO wait like over 140% spike. IO wait rose slowly for couple hours then at some time it spiked at 140% and then after IO wait dropped back to "normal" the CPU 1min 5min 15min spiked to like 3 times the number of cores for a bit.
We where at "peek" operation. I.e we where running a batch job when this hapenned. On average operation the "business" requests per second from our services is about 15 RPS when we do batches we can hit 600 RPS for a few hours and then back down. Each business request underneath does a few round trips back and forth between Kafka, cache systems Flink, DBs etc... So Flink jobs are a subset of some parts of that 600 RPS. On Flink side we 3 task managers of 4 cores 8GB which are configured as 8 slots, 5.4GB JVM, 3.77GB flink managed mem per task manager. We have 8 jobs and 9 slots free. So the cluster isn't full yet. But we do see one node is full. We use disk FS state (backed by GlusterFS) not rocks DB. We had enabled 5 second checkpointing for 6 of the jobs... So just wondering if that was possibly the reason for the IO wait... But regardless of the RPS mentioned above the jobs will always checkpoint every 5 seconds... I had the chance to increase checkpointing for a few of the jobs before the holidays. I am back on Monday... On Fri., Jan. 3, 2020, 11:16 a.m. Chesnay Schepler, <ches...@apache.org> wrote: > The logs show 2 interesting pieces of information: > > <tasks are submitted> > ... > 2019-12-19 18:33:23,278 INFO > org.apache.kafka.clients.FetchSessionHandler - [Consumer > clientId=consumer-4, groupId=ccccccdb-prod-import] Error sending fetch > request (sessionId=INVALID, epoch=INITIAL) to node 0: > org.apache.kafka.common.errors.DisconnectException. > ... > 2019-12-19 19:37:06,732 INFO > org.apache.flink.runtime.taskexecutor.TaskExecutor - Could not > resolve ResourceManager address > akka.tcp://flink@xxxxxx-job-0002:36835/user/resourcemanager, > retrying in 10000 ms: Ask timed out on > [ActorSelection[Anchor(akka.tcp://flink@xxxxxx-job-0002:36835/), > Path(/user/resourcemanager)]] after [10000 ms]. Sender[null] sent message > of type "akka.actor.Identify".. > > This reads like the machine lost network connectivity for some reason. The > tasks start failing because kafka cannot be reached, and the TM then shuts > down because it can neither reach the ResourceManager. > > On 25/12/2019 04:34, Zhijiang wrote: > > If you use rocksDB state backend, it might consume extra native memory. > Some resource framework cluster like yarn would kill the container if the > memory usage exceeds some threshold. You can also double check whether it > exists in your case. > > ------------------------------------------------------------------ > From:John Smith <java.dev....@gmail.com> <java.dev....@gmail.com> > Send Time:2019 Dec. 25 (Wed.) 03:40 > To:Zhijiang <wangzhijiang...@aliyun.com> <wangzhijiang...@aliyun.com> > Cc:user <user@flink.apache.org> <user@flink.apache.org> > Subject:Re: Flink task node shut it self off. > > The shutdown happened after the massive IO wait. I don't use any state > Checkpoints are disk based... > > On Mon., Dec. 23, 2019, 1:42 a.m. Zhijiang, <wangzhijiang...@aliyun.com> > wrote: > Hi John, > > Thanks for the positive comments of Flink usage. No matter at least-once > or exactly-once you used for checkpoint, it would never lose one message > during failure recovery. > > Unfortunatelly I can not visit the logs you posted. Generally speaking the > longer internal checkpoint would mean replaying more source data after > failure recovery. > In my experience the 5 seconds interval for checkpoint is too frequently > in my experience, and you might increase it to 1 minute or so. You can also > monitor how long will the checkpoint finish in your application, then you > can adjust the interval accordingly. > > Concerning of the node shutdown you mentioned, I am not quite sure whether > it is relevant to your short checkpoint interval. Do you config to use heap > state backend? The hs_err file really indicated that you job had > encountered the memory issue, then it is better to somehow increase your > task manager memory. But if you can analyze the dump hs_err file via some > profiler tool for checking the memory usage, it might be more helpful to > find the root cause. > > Best, > Zhijiang > > ------------------------------------------------------------------ > From:John Smith <java.dev....@gmail.com> > Send Time:2019 Dec. 21 (Sat.) 05:26 > To:user <user@flink.apache.org> > Subject:Flink task node shut it self off. > > Hi, using Flink 1.8.0 > > 1st off I must say Flink resiliency is very impressive, we lost a node and > never lost one message by using checkpoints and Kafka. Thanks! > > The cluster is a self hosted cluster and we use our own zookeeper cluster. > We have... > 3 zookeepers: 4 cpu, 8GB (each) > 3 job nodes: 4 cpu, 8GB (each) > 3 task nodes: 4 cpu, 8GB (each) > The nodes also share GlusterFS for storing savepoints and checkpoints, > GlusterFS is running on the same machines. > > Yesterday a node shut itself off we the following log messages... > - Stopping TaskExecutor > akka.tcp://fl...@xxx.xxx.xxx.73:34697/user/taskmanager_0. > - Stop job leader service. > - Stopping ZooKeeperLeaderRetrievalService /leader/resource_manager_lock. > - Shutting down TaskExecutorLocalStateStoresManager. > - Shutting down BLOB cache > - Shutting down BLOB cache > - removed file cache directory > /tmp/flink-dist-cache-4b60d79b-1cef-4ffb-8837-3a9c9a205000 > - I/O manager removed spill file directory > /tmp/flink-io-c9d01b92-2809-4a55-8ab3-6920487da0ed > - Shutting down the network environment and its components. > > Prior to the node shutting off we noticed massive IOWAIT of 140% and CPU > load 1minute of 15. And we also got an hs_err file which sais we should > increase the memory. > > I'm attaching the logs here: > https://www.dropbox.com/sh/vp1ytpguimiayw7/AADviCPED47QEy_4rHsGI1Nya?dl=0 > > I wonder if my 5 second checkpointing is too much for gluster. > > Any thoughts? > > > > > > > >
