WR1043ND Arbeitsspeicherauslastung

JoBu · 16. Juli 2015 um 10:16

Hallo zusammen,

ich weiß nicht in welchen Bereich dies am besten gehört. Wenn sich im Laufe des Themas herausstellt, dass es ein allgemeines Gluon-Thema ist, kann das hier gerne verschoben werden.

Setup ist ein TL-WR1043ND v2 an einem Telekom Hybrid Anschluss.

Ich habe in den letzten Tagen im Meshviewer eine ungewöhnlich hohe Arbeitsspeicherauslastung (>90%) gesehen.

Mangels Zeit, Energie und IPv6 konnte ich aber nicht auf den Knoten zugreifen. Gestern Abend war ich dann wieder zu Hause.

Im Log fand sich folgendes, ansonsten keine Auffälligkeiten:

Wed Jul 15 17:05:00 2015 kern.info kernel: [262107.090000] IPv6: udp checksum is 0
Wed Jul 15 17:10:20 2015 kern.info kernel: [262427.110000] IPv6: udp checksum is 0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.710000] alfred: page allocation failure: order:6, mode:0x1040d0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.710000] CPU: 0 PID: 1639 Comm: alfred Not tainted 3.10.49 #1
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000] Stack : 00000000 00000000 00000000 00000000 803bce56 00000034 82994a08 00000000
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000]        802f2bcc 8033b97b 00000667 803b39e0 82994a08 00000000 0000003d 00000000
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000]        0000003d 8028d478 00000000 801f00ac 00000006 00000000 802f425c 82993d64
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000]        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000]        00000000 00000000 00000000 00000000 00000000 00000000 00000000 82993cf0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.720000]        ...
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.760000] Call Trace:
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.760000] [<80232134>] show_stack+0x48/0x70
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.760000] [<8029cd84>] warn_alloc_failed+0x108/0x12c
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.770000] [<80081e48>] __alloc_pages_nodemask+0x3a0/0x634
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.780000] [<8008fd40>] __get_free_pages+0x18/0x4c
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.780000] [<802209b0>] seq_read+0x270/0x48c
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.790000] [<802931dc>] vfs_read+0xa4/0x164
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.790000] [<80078198>] SyS_read+0x58/0xa4
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.790000] [<800625b0>] stack_done+0x20/0x44
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.800000]
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.800000] Mem-Info:
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.800000] Normal per-cpu:
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000] CPU    0: hi:   18, btch:   3 usd:   0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000] active_anon:6439 inactive_anon:15 isolated_anon:0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000]  active_file:983 inactive_file:977 isolated_file:31
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000]  unevictable:0 dirty:0 writeback:0 unstable:0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000]  free:1398 slab_reclaimable:357 slab_unreclaimable:2376
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000]  mapped:448 shmem:40 pagetables:698 bounce:0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.810000]  free_cma:0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.840000] Normal free:5592kB min:988kB low:1232kB high:1480kB active_anon:25756kB inactive_anon:60kB active_file:3932kB inactive_file:3908kB unevictable:0kB isolated(anon):0kB isolated(file):124kB present:65536kB managed:61080kB mlocked:0kB dirty:0kB writeback:0kB mapped:1792kB shmem:160kB slab_reclaimable:1428kB slab_unreclaimable:9504kB kernel_stack:1616kB pagetables:2792kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaiWed Jul 15 17:14:29 2015 kern.warn kernel: [262675.890000] lowmem_reserve[]: 0 0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.890000] Normal: 102*4kB (UM) 94*8kB (UEM) 23*16kB (UEM) 26*32kB (UM) 16*64kB (UM) 15*128kB (UEM) 1*256kB (E) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5560kB
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.900000] 2031 total pagecache pages
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.910000] 0 pages in swap cache
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.910000] Swap cache stats: add 0, delete 0, find 0/0
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.920000] Free swap  = 0kB
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.920000] Total swap = 0kB
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.930000] 16384 pages RAM
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.930000] 1043 pages reserved
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.930000] 280131 pages shared
Wed Jul 15 17:14:29 2015 kern.warn kernel: [262675.940000] 12522 pages non-shared
Wed Jul 15 17:27:13 2015 kern.info kernel: [263440.680000] IPv6: udp checksum is 0
Wed Jul 15 17:32:01 2015 kern.info kernel: [263728.530000] IPv6: udp checksum is 0

Interessant war die Ausgabe von top:

Mem: 56580K used, 4784K free, 0K shrd, 936K buff, 3104K cached
CPU:   0% usr  16% sys   0% nic  75% idle   0% io   0% irq   8% sirq
Load average: 0.08 0.18 0.24 2/232 17738
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
17738 17659 root     R     1404   2%  17% top
 1499     1 root     R     3352   5%   8% /usr/bin/fastd --config - --daemon --
 2115     1 root     S     2324   4%   0% /usr/bin/respondd -g ff02::2:1001 -p
17086 17081 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
31669 31664 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
 4578  4576 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
 8701  8696 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
17277 17274 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
29321 29316 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
  655   653 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
26893 26888 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
 5122  5117 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
26956 26954 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
14374 14369 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
27360 27358 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
12197 12195 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
31527 31525 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
16456 16454 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
 5872  5870 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/
18693 18691 root     S     2072   3%   0% {autoupdater} /usr/bin/lua /usr/sbin/

Ich wollte das zum weiteren debuggen so bestehen lassen, allerdings hat sich der Knoten kurz nach meiner Abmeldung neugestartet. Arbeitsspeicherauslastung liegt jetzt wieder bei um die 50%, was für den WR1043ND v2 deutlich normaler ist.

Vielleicht kann jemand etwas mit den Daten anfangen

Viele Grüße
JoBu

MPW · 16. Juli 2015 um 11:23

Erstmal abwarten, ob es sich wiederholt. Kann immer Mal eine Anwendung hängen.

JoBu · 16. Juli 2015 um 16:00

Es lies sich in soweit rekonstruieren, dass autoupdater -f auch zu keinem Ergebnis geführt hat. Ich musste es dann abbrechen.

Jetzt nach einem manuellen Reboot funktioniert autoupdater -f weider. Vielleicht liegt es am Zusammenspiel von Telekom Hybrid und Friefunkknoten (instabile Verbindung oder ähnliches). Ich behalte das auf jeden Fall im Auge.

JoBu · 17. Juli 2015 um 14:00

Heute war das Netz wieder nicht nutzbar und der Autoupdater brachte wieder kein Ergebnis (weder Abbruch noch Resultat).
Ich vermute ins Blaue hinein, dass der Fehler mit dem IP-Wechsel zusammenhängt. Aktuell schreibe ich über den Knoten, aber nach einer Nacht, funktioniert nichts mehr. Berichte weiter, wenn es neue Erkenntnisse gibt.

limlug · 17. Juli 2015 um 16:07

Hmm kannst du mal versuchen im Router an dem der Node hängt dem Node nur die normale Internetleitung zuzuweisen und ihn vom Hybrid abzuklemmen?

JoBu · 17. Juli 2015 um 16:09

Kann ich tun, aber dann ist Freifunk aufgrund der Internetleitung sicher nicht nutzbar

Ich habe mal IPv6 auf der WAN-Seite ausgestellt. Morgen kann ich bestimmt mehr sagen.

MPW · 17. Juli 2015 um 23:13

Ich dachte das tolle an diesem Hybrid-Zeugs wäre gerade, dass die Telekom das Routing macht und man eine globale IP hat? Oder sind die noch nicht so weit?

JoBu · 17. Juli 2015 um 23:17

Es wird alle 24 Stunden ein Teil der IPv6-Adresse ausgewechselt ohne die Internetverbindung zu trennen (laut Anleitung). Das ganze hat angeblich Datenschutzgründe.

JoBu · 18. Juli 2015 um 09:29

Heureka! Es ist wieder eine Nacht vergangen und ausnahmsweise läuft Freifunk noch so wie es soll. Ich lag mit der Vermutung anscheinend richtig und es hilft IPv6 auf der WAN-Seite abzuschalten.