80% CPU usage always, - Raspberry Pi 1, WEB UI Stuck, Never Ending loading.

lutfor-diu commented 1 year ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARMv6

Installation

GitHub releases or script from README

Setup

On a router, DHCP is handled by AdGuard Home

AdGuard Home version

v0.107.40

Action

nslookup -debug -type=a 'www.example.com' '$YOUR_AGH_ADDRESS'

Adguard Stuck at never ending WEB loading page. Also 80-100% CPU usage until restart the adguard service manually. But after few mins same condition.

please have a look at this serious problem. I install adguard on raspberry pi 1 running DietPi lightweight Linux OS

Expected result

WEB UI should work smoothly and flawlessly

Actual result

Stuck on WEB UI, never ending loading page. Also 100% CPU usage

Additional information and/or screenshots

OS; DietPi

talonric332 commented 1 year ago

It may be due the hardware and only having 512MB of RAM. I am using it on an Orangepi zero 2 with no issues mine has 1GB of RAM

lutfor-diu commented 1 year ago

It may be due the hardware and only having 512MB of RAM. I am using it on an Orangepi zero 2 with no issues mine has 1GB of RAM

Ram usage is very low, and free ram is above 350mb. Still facing this wired problem. I think it's a bug

lutfor-diu commented 1 year ago

anyone help?

heloproc commented 1 year ago

If the web UI is stuck, try clearing your browser cache and cookies. This can help eliminate any temporary data that might be causing the issue.

Also, verify that there are no other software or services running on your Raspberry Pi that could be conflicting with Adguard. Some applications or processes might consume excessive resources or interfere with Adguard's functionality.

Any specific error message?

lutfor-diu commented 1 year ago

If the web UI is stuck, try clearing your browser cache and cookies. This can help eliminate any temporary data that might be causing the issue.

Also, verify that there are no other software or services running on your Raspberry Pi that could be conflicting with Adguard. Some applications or processes might consume excessive resources or interfere with Adguard's functionality.

Any specific error message?

i only have few software running which i think not conflict with adguard. Only adguard services shows 90+ CPU usage percentage.as a result i can't access web ui, which is stuck and dns query process also stops.

heloproc commented 1 year ago

It seems like AdGuard Services is consuming a high amount of CPU usage, causing issues with accessing the web UI and DNS query processes. You can try restarting the AdGuard Services to see if it resolves the problem. If the issue persists, you may want to consider reaching out to AdGuard support for further assistance.

On Mon, 6 Nov, 2023, 7:26 pm Md. Lutfor Rahman, @.***> wrote:

If the web UI is stuck, try clearing your browser cache and cookies. This can help eliminate any temporary data that might be causing the issue.

Also, verify that there are no other software or services running on your Raspberry Pi that could be conflicting with Adguard. Some applications or processes might consume excessive resources or interfere with Adguard's functionality.

Any specific error message?

i only have few software running which i think not conflict with adguard. Only adguard services shows 90+ CPU usage percentage.as a result i can't access web ui, which is stuck and dns query process also stops.

— Reply to this email directly, view it on GitHub https://github.com/AdguardTeam/AdGuardHome/issues/6389#issuecomment-1794880466, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASSX3GHLXBF5QEGBQL72ZFLYDDUBBAVCNFSM6AAAAAA66LHC2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJUHA4DANBWGY . You are receiving this because you commented.Message ID: @.***>

ainar-g commented 1 year ago

Raspberry Pi 1 is a rather old machine, so it could be that. Please enable verbose logs and collect them following a start of AGH and until the CPU issue begins. You can then send them to devteam@adguard.com with subject “AdGuard Home Issue 6389”.

lutfor-diu commented 1 year ago

Raspberry Pi 1 is a rather old machine, so it could be that. Please enable verbose logs and collect them following a start of AGH and until the CPU issue begins. You can then send them to devteam@adguard.com with subject “AdGuard Home Issue 6389”.

already collecting data, what i observe that adgurads runs okey whole day but problem starts after evening. 95% CPU usage after evening.

lutfor-diu commented 1 year ago

Raspberry Pi 1 is a rather old machine, so it could be that. Please enable verbose logs and collect them following a start of AGH and until the CPU issue begins. You can then send them to devteam@adguard.com with subject “AdGuard Home Issue 6389”.

send the log file. please check

duckxx commented 1 year ago

类似 #5998 ，因为启用adguardhome后默认进行更新规则列表，分批次自动更新不会造成高负荷，一次性全更新规则列表就会造成高负荷。一个小bug就是手动更新一个规则列表会导致全列表也跟着触发自动更新。

duckxx commented 1 year ago

也有一种情况是，adguardhome的容器软件缓存cache处理不到位，执行 ./AdGuardHome -s stop 出现卡死或需要等待长时间。

ainar-g commented 1 year ago

@lutfor-diu, thanks for the logs. There isn't anything too much out of the ordinary except that:

AdGuard DNS servers, required for both Safe Browsing and Parental Control features, seem to occasionally be unavailable from your network. That can slow down queries.
Your filters seem to be over 4 MiB, which is probably way too much for a Raspberry Pi 1 CPU. Please consider using smaller filtering-rule lists.

lutfor-diu commented 1 year ago

@lutfor-diu, thanks for the logs. There isn't anything too much out of the ordinary except that:

AdGuard DNS servers, required for both Safe Browsing and Parental Control features, seem to occasionally be unavailable from your network. That can slow down queries.

Your filters seem to be over 4 MiB, which is probably way too much for a Raspberry Pi 1 CPU. Please consider using smaller filtering-rule lists.

Thank you for your time for going through the log file. I used Adguard with same config before in raspberry pi 1 without any problem or high CPU usage for last 1 year. Didn't faced any major issue, but last 3 - 5 months I'm facing similar type of problem. Like high CPU usage, sudden web ui hang, not processing DNS quarry.

lutfor-diu commented 1 year ago

@lutfor-diu, thanks for the logs. There isn't anything too much out of the ordinary except that:

AdGuard DNS servers, required for both Safe Browsing and Parental Control features, seem to occasionally be unavailable from your network. That can slow down queries.

Your filters seem to be over 4 MiB, which is probably way too much for a Raspberry Pi 1 CPU. Please consider using smaller filtering-rule lists.

Another finding,

it only happens when filter database update at night.

Sakura-Luna commented 1 year ago

Maybe you can check whether the connection to the lists source website is good. If the connection speed is too slow or lost, the entire service may be stuck.

lutfor-diu commented 1 year ago

Maybe you can check whether the connection to the lists source website is good. If the connection speed is too slow or lost, the entire service may be stuck.

connection to filter list is good. But assumption is that there is a problem in adgurad itself. Maybe a BUG

ainar-g commented 1 year ago

it only happens when filter database update at night.

Rebuilding the filtering engine is a CPU-intensive task, so this is to be expected. Especially with large filtering-rule lists.

Didn't faced any major issue, but last 3 - 5 months I'm facing similar type of problem. Like high CPU usage, sudden web ui hang, not processing DNS quarry.

Are you entirely sure that the lists themselves haven't changed during that time? If not, what is the last version where you can update the lists without these issues?

Sakura-Luna commented 1 year ago

it only happens when filter database update at night.

Rebuilding the filtering engine is a CPU-intensive task, so this is to be expected. Especially with large filtering-rule lists.

I often encounter list updates stuck. Judging from the logs, rebuilding the filter list seems to be done at the same time. Why not design a sequential update to enhance stability?

lutfor-diu commented 1 year ago

it only happens when filter database update at night.

Rebuilding the filtering engine is a CPU-intensive task, so this is to be expected. Especially with large filtering-rule lists.

I often encounter list updates stuck. Judging from the logs, rebuilding the filter list seems to be done at the same time. Why not design a sequential update to enhance stability?

Good idea! I think they should make the filter update sequential, not at once.

lutfor-diu commented 1 year ago

it only happens when filter database update at night.

Rebuilding the filtering engine is a CPU-intensive task, so this is to be expected. Especially with large filtering-rule lists.

Didn't faced any major issue, but last 3 - 5 months I'm facing similar type of problem. Like high CPU usage, sudden web ui hang, not processing DNS quarry.

Are you entirely sure that the lists themselves haven't changed during that time? If not, what is the last version where you can update the lists without these issues?

I can't remember which version but I had no problem back 3-4 months

ainar-g commented 1 year ago

@Sakura-Luna, updates of filtering-rule lists are done sequentially.

@lutfor-diu, there haven't been any major changes to the logic of how AGH updates filtering-rule lists, so without a more precise range we cannot really tell if anything is wrong.

Sakura-Luna commented 1 year ago

@ainar-g Whenever I check the file path after a freeze, I always find the old list being replaced like this, so if the problem isn't updating the list, is it when reloading the list. This makes sense, because there is also a chance that it will get stuck when saving custom rules. I had to reboot the entire system, lacking some way to detect the problem.

Sakura-Luna commented 11 months ago

@ainar-g Whenever the service runs for a day, updating the list or custom rules will most likely cause the entire virtual environment to freeze and have to be restarted. There was no problem with the update when the service was first started. Can an experimental feature be provided to restart the process before automatic updates so that the service is not interrupted?

icedan commented 11 months ago

I had similar problems. I have RPI 02W and 4B 2GB. The same card between devices causes incredible lag and practically no response from RPI0 2W, but when inserted into RPI 4B it works without any problems. I noticed that at the beginning there is a high RAM usage + the entire SWAP on RPI 0 2W is full, and e.g. 4B plus starts, uses a lot of RAM at the start, then returns to normal and uses 350MB in idl.

ainar-g commented 11 months ago

@Sakura-Luna, I'm not sure I understand, sorry. Can you provide the exact steps, including the filtering-rule lists in question, to reproduce that?

Sakura-Luna commented 11 months ago

@ainar-g I created a single-core 512MB Docker environment. Once the service has been running for a day, updating the list will cause the entire virtual environment to become unresponsive. In contrast, there will be no problem in updating the list of newly started service.

Troubleshooting operational issues is complicated, so I recommend providing a feature to restart itself before updating the list to circumvent this issue.

List: HaGeZi Multi NORMAL and Default

duckxx commented 11 months ago

@ainar-g I created a single-core 512MB Docker environment. Once the service has been running for a day, updating the list will cause the entire virtual environment to become unresponsive. In contrast, there will be no problem in updating the list of newly started service.

Troubleshooting operational issues is complicated, so I recommend providing a feature to restart itself before updating the list to circumvent this issue.

List: HaGeZi Multi NORMAL and Default

我不赞同，因为更新列表前执行重启会导致业务中断，DNS解析停止，并且重启后会占用大部分CPU和内存，如果重启后立即执行更新一样会导致服务器崩溃，特别是将自动更新调整为1小时。

Sakura-Luna commented 11 months ago

我不赞同，因为更新列表前执行重启会导致业务中断，DNS解析停止，并且重启后会占用大部分CPU和内存，如果重启后立即执行更新一样会导致服务器崩溃，特别是将自动更新调整为1小时。

It's just speculation on your part that the update will have issues after a reboot. Also, the server never crashed, it was just unresponsive. In rare cases, the service might resume after a long wait. If you experience a crash, you should create a new issue.

duckxx commented 11 months ago

我不赞同，因为更新列表前执行重启会导致业务中断，DNS解析停止，并且重启后会占用大部分CPU和内存，如果重启后立即执行更新一样会导致服务器崩溃，特别是将自动更新调整为1小时。

It's just speculation on your part that the update will have issues after a reboot. Also, the server never crashed, it was just unresponsive. In rare cases, the service might resume after a long wait. If you experience a crash, you should create a new issue.

不不不，自动更新不是固定几点更新，是每几个小时更新一次，如果我在浏览网页或视频，处理重要的事情，突然DNS停止解析，那得多扫兴，如果每次自动更新都重启adguardhome，那高配置服务器怎么办？

Sakura-Luna commented 11 months ago

@ainar-g I also recommend changing the automatic update of the list from an interval to a fixed time. Based on actual experience, each update will delay the time for some time, which may cause new problems after multiple accumulations.

Sakura-Luna commented 11 months ago

不不不，自动更新不是固定几点更新，是每几个小时更新一次，如果我在浏览网页或视频，处理重要的事情，突然DNS停止解析，那得多扫兴，如果每次自动更新都重启adguardhome，那高配置服务器怎么办？

You can choose not to enable or reduce the frequency of updates to accommodate automatic restarts.

geeheim commented 11 months ago

Hi, I am facing the same issue on a raspberry 2b. It was working fine for almost 1 month. CPU load is now always close to 100% after start. Webinterface is not usable and clients also do run into timeouts.

Tested with version version v0.107.41 and one previous version (don't know the version)

I ran AdGuardHome with log.debug=true and saw lots of these messages:

2023/12/06 19:57:21.542019 1010#11629 [debug] bootstrap: connection to 94.140.14.15:443 succeeded in 1.841797687s 2023/12/06 19:57:23.490551 1010#11627 [debug] dnsproxy: https://family.adguard-dns.com:443/dns-query: response received over tcp: "requesting https://family.adguard-dns.com:443/dns-query: Get \"https://family.adguard-dns.com:443/dns-query?dns=AAABAAABAAAAAAAABDNhNjIENDgxYwQyMjY1AnNiA2RucwdhZGd1YXJkA2NvbQAAEAAB\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" 2023/12/06 19:57:23.492175 1010#11627 [debug] re-creating the http client due to requesting https://family.adguard-dns.com:443/dns-query: Get "https://family.adguard-dns.com:443/dns-query?dns=AAABAAABAAAAAAAABDNhNjIENDgxYwQyMjY1AnNiA2RucwdhZGd1YXJkA2NvbQAAEAAB": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 2023/12/06 19:57:23.493403 1010#11627 [debug] using HTTP/2 for this upstream: HTTP3 support is not enabled 2023/12/06 19:57:23.494566 1010#11627 [debug] dnsproxy: https://family.adguard-dns.com:443/dns-query: sending request over tcp: TXT 3a62.481c.2265.sb.dns.adguard.com. 2023/12/06 19:57:23.496241 1010#11635 [debug] bootstrap: dialing 94.140.14.15:443 (1/4) 2023/12/06 19:57:24.162982 1010#11635 [debug] bootstrap: connection to 94.140.14.15:443 succeeded in 665.721827ms 2023/12/06 19:57:26.995960 1010#11627 [debug] dnsproxy: https://family.adguard-dns.com:443/dns-query: response received over tcp: "requesting https://family.adguard-dns.com:443/dns-query: Get \"https://family.adguard-dns.com:443/dns-query?dns=AAABAAABAAAAAAAABDNhNjIENDgxYwQyMjY1AnNiA2RucwdhZGd1YXJkA2NvbQAAEAAB\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" 2023/12/06 19:57:26.997198 1010#11627 [debug] re-creating the http client due to requesting https://family.adguard-dns.com:443/dns-query: Get "https://family.adguard-dns.com:443/dns-query?dns=AAABAAABAAAAAAAABDNhNjIENDgxYwQyMjY1AnNiA2RucwdhZGd1YXJkA2NvbQAAEAAB": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 2023/12/06 19:57:26.998442 1010#11627 [debug] using HTTP/2 for this upstream: HTTP3 support is not enabled 2023/12/06 19:57:26.999607 1010#11627 [debug] dnsproxy: https://family.adguard-dns.com:443/dns-query: sending request over tcp: TXT 3a62.481c.2265.sb.dns.adguard.com. 2023/12/06 19:57:27.001498 1010#11641 [debug] bootstrap: dialing 94.140.14.15:443 (1/4) 2023/12/06 19:57:27.708436 1010#11641 [debug] bootstrap: connection to 94.140.14.15:443 succeeded in 706.014514ms

Not sure wether this is helpful. Regards, Geert

AdguardTeam / AdGuardHome