Adguard crashes all the time: out of memory

these functions are one of the main ones

What does that mean?

Fact: interception could be left off all the time unless a VPN is active.

One of the main reasons to get an GL router: Using VPN.
Could intercepting be turned off? Yeah, but why should it? It does the job and isn't problematic in any way, lol.

I just explained why it would be a good thing; save resources on devices that are limited in them. Saving resources has many advantages as you surely know.

Also I am very curious to the data as to what percentage of users actually has a VPN enabled. I would be very surprised if that number is over 50% and that number will even be lower for those who run ad guard + VPN at the same time. Who are the only group to "benefit" from having interception always being enabled.

Everybody else benefits from having it disabled as it frees up resources. Like memory and cpu cycles. Plus using less power. But you made it clear being frugal with limited resources is a non-issue for you, lol.

1 Like

Why should intercepting save any amount of useful resources? That does not make any sense. The only way to save resources is by disabling AGH.

The ā€œinterceptā€ using iptables is so easy, you won't recognize any difference.

Thats why intercepting DNS traffic is a great thing IMO, it blocks devices with hardcoded dns servers our users with their own settings from circumventing our settings.

1 Like

And it works for plain DNS (UDP/53) only. And this one is slowly dying anyway.

Why should intercepting save any amount of useful resources?

Turning any additional filtering off like packet interception when not needed will 100% save resources. Unless next you'll argue that filtering and firewalling does not cost any resources to begin with.

You seem to be pretty clueless and needlessly argumentative for a moderator. And you don't work for Gli-Inet, you just wear the company clothes and interact with their customers. Kind of weird.

Also you saying to turn aguard off to save resources in a topic that is about running it is kind of weird.

The DNS redirection occurs within the kernel and does not cause any performance degradation. This is a routine process, and the OS is designed to handle it efficiently. It’s not comparable to TLS interception or other resource-intensive operations.

Sure, some resources are saved—but the impact is negligible and not measurable. It’s like saying that ā€œhaving no SSH sessionsā€ will save resources. Sure, it technically will… but it’s completely pointless.

You're posting in a topic about running adguard when resources are limited. I post a possible solution here to try and help out. I also make a point that any resources saved will help when running out of resources. Makes sense right? All you seem to do is to argue for the sake of arguing. I don't see you share any solutions. You just want to argue.

Some resources are saved—but the impact is negligible and not measurable

Since you seem to know, care to share your measurements? Or are you just making things up? It is a well known fact having any kind of filtering causes more system load. Things like iptables/iftables can be very memory and cpu intensive. But I await your data showing its not measurable.

I won't discuss this with you any further, I am sorry.

Being scared about performance loss while using nftables / iptables for redirecting DNS traffic ... is just insane.

I won't discuss this with you any further, I am sorry.

That's for the best. You didn't discuss anything to begin with. You butted in and argued for the sake of arguing.

Being scared about performance loss while using nftables / iptables for redirecting DNS traffic ... is just insane.

Thanks for calling me insane. You're doing a great job representing Gl-Inet.

My point stands: optimizing every little thing will help when resources are limited. All I did was try to help out. If you know it all so well why don't you contribute solutions instead?

I'm sorry if you feel attacked. This is not about you personally, but about the ā€œfearā€ that this DNS redirect could have a negative impact on performance. This is not the case - just accept it.

The entire functionality is kernel-based. If this were to cause performance problems, you could throw the router on the scrap heap - because it would fail at its main task.

AdGuard Home is much worse in terms of performance, which is why you should switch to DNS filters such as AdGuard DNS on weak devices.

This is not true though, see my previous posts where I gave more than enough arguments as to why it matters to optimise everything. Every little bit helps.

There is no need to intercept all dns traffic when not using a vpn and will needlessly use resources. That is just a fact. I don't understand why you want to keep arguing about this fact. If you honestly believe additional packet filtering does not increase system loads there is nothing that will convince you.

Maybe you don't see any value in freeing up 10-25mb of ram on a 128mb device or reduce cpu load but me and many others that does matter. Heck, OpenWrt is minimal and highly optimised so it can do a lot with few resources. You seem to not subscribe to that design philosophy.

Once again you tell people to not use adguard in a topic about using adguard, the logic behind such statements escapes me. You might as well tell people to buy a fanless mini pc with 5 network ports and dual or triple m.2 slots for wireless cards and use that as router and ad blocker.

Since you couldn't keep your word and not respond any more I will just mute this topic and end my post with a slightly modified quote from you:

Claiming no performance loss while using nftables / iptables for redirecting DNS traffic ... is just insane.

We are talking about bytes here, not MB. Perhaps kilobytes. The DNS server needs to run anyway. You will just skip the interception which is like nothing.

If "intercepting" is a problem can you just posting the rules?

Better not arguing fundamentals than detailed questions.

I use this Settings and Lists from an Github User on my Brume 2 MT2500, also after some hours freeze and i had to delete with SCP the Lists. Than it works again some hours with luck.

The Tip from @SourMilk with Zram seems that the Problem gone now :slight_smile:
With all my lists from The Github User, since 2 days no Problem. So i hope it will stay :slight_smile: Thanks so much for this Greet Workaround. I have with Zram on MT2500 till now no Problems detected. I use VPN too and also as PPOE and also Tailscale. No Performance Problem.

Will it stay after i update the Firmware? Or have to do it each time after Update again?

Just an observation from an Openwrt noobie - OSS and Openwrt were the primary reasons I bought my Flint 2. But I knew going into this world that the learning curve would have some steep spots and that any 'support' was going to end up on my shoulders more than what you'd expect from a generic consumer product. There's good and bad with open source.

Coincidentally, this spur has also lead me towards experimenting with Opnsense, which also allows AGH. It was there that I learned how memory intensive AGH could be when you loaded up filter lists. And that lead to checking my AGH setup on my Flint 2.

It's possible the GL could provide some warning in the gui when enabling AGH about memory limitations, but I suspect that would be lost on many users accustomed with proprietary routers 'just working'. And because AGH is it's own project, you can't very easily just insert memory checks (though AGH should perhaps consider that themselves).

2 Likes

I whould also appeal for it....

1 Like

It's not a bad idea, but you have to consider the experience level of the target user base... Because there's many variables involved, the best you could do would be to warn users that applying large filter lists consumes additional ram and there are limits to what can be implemented in your device. Also, I'd guess that various models have differing amounts of ram installed, so you can add more filtering to some models vs others. And of course the amount of available ram is also dependent on what other features may have been enabled on the device.

So you are basically left with providing a simple warning that users need to be mindful of the size of filter lists they add. The documentation should also include this information and inform the user how to monitor ram usage to determine what the limits might be on their specific device. Of course, this can really only be done in the GL menu for AGH where you enable it because the actual AGH interface is an independent project (which is kind of the whole problem) - the AGH menu for adding + managing filter lists is outside GL's control.

EDIT - as an Openwrt newbie, I fell into this as well. My first instinct was to add a ton of filter lists until I realized the memory implications.

1 Like

Yes, a simple pop-up warning when adding lists would be better than nothing. Then the newbie is forewarned and has to expect problems if he adds more and larger lists. I only discovered the problem after a lot of googling and reading the log. And only then did I realize that I couldn't get any further and that the router in the AGH was stuck in a freeze. It is therefore essential to clean up the memory in the AGH folder with SCP so that you can get rid of the lists that have been imported too much and AGH can function properly. For my part, I am now satisfied with the Zram solution. It accelerates AGH satisfactorily, and all my required lists have been working perfectly for days now. No more messages in the log. So I get 99% in the Ad Block Test!