Tailscale using 130% of memory

Installing and Using OpenWrt
1

image
image1045×453 25.3 KB

ive tried to update it
tailscale update

and of course reboot a few times, but its pegged at this 130%

ive also tried
tailscale down
and it replies: Tailscale was already stopped.
but that process stays (even if i kill/terminate it)

my internet and samba was slow loading today so i investigated and found this. however im not sure how long its been going on. after a few reboots the process is still at 130% but things are loading and normal speeds

2

Please show

ubus call system board

from your device

3 

root@skittles:~# ubus call system board
{
        "kernel": "6.6.86",
        "hostname": "skittles",
        "system": "ARMv8 Processor rev 4",
        "model": "GL.iNet GL-MT6000",
        "board_name": "glinet,gl-mt6000",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.1",
                "revision": "r28597-0425664679",
                "target": "mediatek/filogic",
                "description": "OpenWrt 24.10.1 r28597-0425664679",
                "builddate": "1744562312"
        }
}
4

That is memory overcommitment at its finest, chexk pa aww in ssh for "res"ident memory usage, if that seems excessive add zram-swap to compress out-of-memory imminent soon?

5

what package/software is "pa"

root@skittles:~# pa
-ash: pa: not found

i looked in the Software section too but nothing just "pa"

6

ps axww
sorry big fingers small mobile kbrd

7

BusyBox' built-in ps doesn't support these options.

I'd try htop.
In most cases, htop isn't installed. You'd have to do this first.

2 Likes
8

image
image1601×911 87.2 KB

i guess though ps or htop are really just showcasing the issue, not resolving it. kinda sucks because tailscale doesnt have a forum for q/a. likely for paid version it has support

9

found this in the logs

Wed Jun 4 15:08:01 2025 daemon.err tailscaled[2449]: 2025/06/04
15:08:01 health(warnable=no-derp-connection): error: Tailscale could
not connect to the 'Seattle' relay server. Your Internet connection
might be down, or the server might be temporarily unavailable.

Wed Jun 4 15:08:51 2025 daemon.err tailscaled[2449]: 2025/06/04
15:08:51 health(warnable=no-derp-connection): ok

10

such bs tailscales site says to post on stackoverflow and tag them but my question was closed there
submitted a ticket to tailscale; we'll see how that goes
from the error, the problem seems straight forward but idk where to configure the DERP server or what to replace it with (seems like its all handled internally by their client)

11

Screen Shot USG-3P Tailscale memory
Screen Shot USG-3P Tailscale memory1932×674 64.3 KB

I also see an unusually high Memory usage number for Tailscale, but
I don't experience any issues....could this be a bug?

12

It uses 10x(60-20) mb just that vm.overcommit_memory pre-reserves some backing for virtual mappings.

Add zram-swap, if it swaps nothing then nothing needs to be done to fix it.

13

Noted, but it says 323% which looks like a wrong number being reported. I don't understand how that number can be above 100%?

Note: USG-3P has 512 MB RAM and 4 GB Flash.

14

I installed zram-swap which automatically installed kmod-zram and they did nothing to reduce the reported 323% memory usage shown on the LuCI Processes page.

I also installed HTOP and it reported approx 90 MB memory usage, while the LuCI Processes page continued to report 323% memory usage.

15

You need to check on first status page whether swap is ever used which would be real sign of danger.

16

Just tested again and "Swap free" sat at 100% and was never used.

17

Leave as it is check in a week and month again. That is the way linux accounts un-accesses but allocated memory.

18

if you look at syslog do you see the error "Tailscale could
not connect to the 'Seattle' relay server."? (or whatever derp server your client uses)

19

Not seeing that error currently, however I did have serious issues when IPv6 was enabled but the ISP did not support IPv6. So if your ISP does not support IPv6 then disable it.

20

This is mainly caused by Go programs. I have experienced this for ages with dnsproxy (which is also Go), currently reporting 515% on a 256 MB device.

I don't use Go myself, but as far as I know, it overcommits address space on purpose as an optimization to its GC.
Not sure what the appropriate fix for this (if any) would be. Overcommiting address space is by all means fine and shouldn't cause any problems, other than programs that report memory usage by committed address space reporting a wrong estimate.

EDIT: Some discussion by people who actually use the language

1 Like