After a few days of running, I can see in the stats window, that my cpu usage is 15%, compared to the normal 4-5% constantly (if nothing else is running, on a daily, weekly stats chart)

 

If I restart docker, it doesn't solve it (In settings, docker enable No, than back to yes)

If I restart the server, I think it solves it sometimes, for a few days, than it starts again.

 

I think it started around the time, when I changed some docker log settings or after i switch my cache to encrypted xfs

It starts to bother me now, cos if this writes to SSD so much log constantly, that it takes up 10% CPU, it will just kill my SSD in a few months (Or var/run/ is all in RAM?)

 

my docker.img is less than 50%, log is 1% in the dashboard.

 

If I run a htop, I get the following results:

My cache drive is now XFS encrypted for a few months, i though it would solve this occasional btrfs csum error. I was wrong, as the docker img is still btrfs...

Any ideas?

Thank you!

So am I the only one with this issue, and noone has any idea.

This is not github on an open source free loveproject.

 

This is a paid software, right?

On 5/26/2020 at 4:08 AM, LSL1337 said:

This is a paid software, right?

Yes, but by and large the community of volunteers is who does the support

 

And without diagnostics being posted, no one is going to be able to help.  But, your first course of diagnosis is to start shutting down your containers one at a time and then see when that disappears.  Personally though, I don't particularly worry about CPU % being utilized.  If the CPU has something to do, then it has something to do.

 

And the stats window isn't particularly the best place to guage what the server is actually doing because both it (and the dashboard) do consume CPU cycles.  

 

Your load average over the last 15 minutes of the screen shot is 0.68 which is basically nothing on an 8 core system.

 

Now, if your writes to the SSD are increasing exponentially, then that is a different story.

1 hour ago, Squid said:

Yes, but by and large the community of volunteers is who does the support

 

And without diagnostics being posted, no one is going to be able to help.  But, your first course of diagnosis is to start shutting down your containers one at a time and then see when that disappears.  Personally though, I don't particularly worry about CPU % being utilized.  If the CPU has something to do, then it has something to do.

 

And the stats window isn't particularly the best place to guage what the server is actually doing because both it (and the dashboard) do consume CPU cycles.  

 

Your load average over the last 15 minutes of the screen shot is 0.68 which is basically nothing on an 8 core system.

 

Now, if your writes to the SSD are increasing exponentially, then that is a different story.

first of all, thanks for the reply.

second: if the baseline would be 15%, i wouldn't care about it, but it is less than 5% (has been for years, without plex transcoding), so the system is doing something, which it shouldn't/ didn't before.

based on htop, it might have something to do with containered.toml, which could indicate possible  drive usage. this is a 1 line txt file. if it has 10% cpu usage, that would mean something is very wrong...

 

i stopped my containers one by one, and the cpu usage decreased proportionally, which means it's not a single docker which causes the issue, it could be with the docker engine itself.

 

Diagnostics attached

lsl-nas-diagnostics-20200527-1300.zip

I changed back my cache drive from encrypted xfs back to xfs, but the issue still persist.

 

I can't be the only one with this issue...

I have the same... Did you figure out what it was?

Noone? Nothing? I tryed updating to Version: 6.9.0-beta29, same thing happening.

still nothing, I've given up.

What dockers do you run, what motherboard do you have, cpu etc.

maybe we can pinpoint something

@LSL1337 & @INTEL

What kind of Unraid installation are you on?

Have you a Nvidia build running?

6.8.3 normal. i have a 7700T, no dGPU @ich777

Edited October 13, 20205 yr by LSL1337

@LSL1337 & @INTEL

Try to disable 'Advanced View' on the docker page and report back, I bet it will be the solution.

are you f'in kidding me? @ich777

it works

why does it have any impact even, and why is it ok for a few days after boot?

is this a bug, or a feature?

and it has impact, when the ui is not even open

 

I can't even find the words...

how many people does this impact btw?

 

@INTEL check the previous post

Edited October 13, 20205 yr by LSL1337

I'm still speechless. Thanks very much.

Is there a way to get advanced view without this extra side effect? whatever, i can always toggle it off.

Just now, LSL1337 said:

are you f'in kidding me? @ich777

it works

I know

 

1 minute ago, LSL1337 said:

why does it have any impact even, and why is it ok for a few days after boot?

is this a bug, or a feature?

Both, I will report that directly to @limetech it's more kind of a bug but not sure if it's easily fixable...

 

1 minute ago, LSL1337 said:

and it has impact, when the ui is not even open

Yep, I won't get to technical.

 

I know what it is and I will report back about my findings.

 

23 minutes ago, ich777 said:

I know

 

Both, I will report that directly to @limetech it's more kind of a bug but not sure if it's easily fixable...

 

Yep, I won't get to technical.

 

I know what it is and I will report back about my findings.

 

GOD TIER

Can't belive this works! Just disabled advenced view and cpu dropped. 

No more .toml in htop

 

 

Guess when i clicked the button

On 10/13/2020 at 2:00 PM, ich777 said:

@LSL1337 & @INTEL

Try to disable 'Advanced View' on the docker page and report back, I bet it will be the solution.

 

Found a few of these listed when running an htop:
 

containerd --config /var/run/docker/container/containerd.toml --log-level error unraid

 

Not sure if it was of any concern but it did cost about 4% of my CPU. Switching to basic view immediately remedied this. Thanks for that.

 

But is that "error" process an issue?

 

 

 

Just now, adminmat said:

But is that "error" process an issue?

That is not an error...

 

These are just the commands that the process was started with.

This process starts if you turn on the Advanced View (to show the CPU und RAM usage from your containers) on the Docker page and won't go away if you switch back to the Basic View (even if you logout or close the WebGUI).

6 minutes ago, ich777 said:

This process starts if you turn on the Advanced View (to show the CPU und RAM usage from your containers) on the Docker page and won't go away if you switch back to the Basic View (even if you logout or close the WebGUI).

 

ok. So those process are still running but just not consuming as much resources when showing the basic view. So I guess nothing to be concerned about. I probably check my logs for errors a little too much. This was actually the first time I've run an htop... when I was troubleshooting the wsdd network today issue that had one CPU core at 100%.

Edited February 21, 20215 yr by adminmat

3 minutes ago, adminmat said:

So those process are still running but just not consuming as much resources when showing the basic view.

No, in basic view the process isn't running only if you turn on advanced view the process is started and ended if you turn on basic view again, that's because I keep the advanced view turned off...

What is the reason for this process? After starting the docker service without starting a container it's already present:

 

This means it is something related to docker service itself. I found this documentation. It mentions the log-driver, which should be "json-file" as it is the default if no /etc/docker/daemon.js exists. So it would write logs to a json file, but is there really a log file for the docker service itself? EDIT: Yes there is a daemon log file under /var/log/docker.log, but this file is tiny and its last entries are several minutes old as well.

 

And it looks like the process does not even access the log file:

# ps -aef | grep containerd
root      7815  7791  0 10:40 ?        00:00:03 containerd --config /var/run/docker/containerd/containerd.toml --log-level error
root     29548 11758  0 10:55 pts/1    00:00:00 grep containerd

 

Or is this something which can't be further influenced?

36 minutes ago, mgutt said:

What is the reason for this process? After starting the docker service without starting a container it's already present

Because this process is the backend for docker, it manages the pulls, networking, storage,... it also supervises the running containers and this is one reason why it's creating more load when you turn on the "Advanced View".

 

The "docker" command is only the command line tool, if you issue a command with for example "docker run WHATEVER" it will actually invoke "containerd" to pull the image itself if they are not available locally and assign it to the specified network, hand it over to runc to actually run the container.

If you install Docker on a Linux machine, or even Windows machine, it will also install containerd with docker and runc.

 

It's not only the log driver it's more than that... see the creation/start process from a container like this:

 

docker -> containerd -> runc -> actually run the container

Interesting. I've never turned on advanced view under docker before, but I'm still getting a huge number of these commands running at random points on my server. Is there anything else that can be causing it? Of course I don't really mind since the usage isn't over 5-10%, but I'd like to figure out what the actual issue is!

On 10/13/2020 at 2:05 PM, LSL1337 said:

are you f'in kidding me? @ich777

it works

why does it have any impact even, and why is it ok for a few days after boot?

is this a bug, or a feature?

and it has impact, when the ui is not even open

 

I can't even find the words...

how many people does this impact btw?

 

@INTEL check the previous post

Wow... just effin wow. 

Seems that fixed my problem too...