Thank you for your response Kevin & Jeff.
I could not figure out a way to get the original request that was sent by
Nginx to NiFi. So I'm going to try and provide you with other information
that might give you some insights into the headers that are being forwarded
to NiFi's embedded web server -
That isn't logback, that lists all jars on your classpath, the first of
which happens to be logback.
If you send a SIGKILL3 (you can send it in HTOP) it will dump the thread
stacks to stdout (probably the bootstrap log)...but that's just for one
instant, and may or may not be helpful.
On Sun, Oct
HI Luis,
It is not likely to be the logging. The area you have highlighted is just
the associated jars included for the classpath.
Profiling could be an option if you are familiar but the community could
also assist effectively if you are able to share a template of your flow (
https://nifi.apac
Luis, please feel free to give us some information on your flow so we can
help you track down problematic areas as well.
On Sun, Oct 13, 2019 at 3:56 PM Jon Logan wrote:
> You should put a profiler on it to be sure.
>
> Just because your processors aren't processing data doesn't mean they are
>
You should put a profiler on it to be sure.
Just because your processors aren't processing data doesn't mean they are
idle though -- many have to poll for new data, especially sources -- ex.
connecting to Kafka, etc, will itself consume some CPU.
But again, you should attach a profiler before par
HI,
I've struggling to reduce my nifi installation CPU consumption. Even in idle
state, all processors running but no data flowing, it is beyond 60% CPU
consumption, with peaks of 200%.
What I've done so far
- Read and followed every instruction/post about tuning NIFI I've found
googling.