Kontinuierliches Ansteigen der Speichernutzung

Begonnen von supernova1963, 07 September 2021, 11:39:24

Vorheriges Thema - Nächstes Thema

supernova1963

Hallo zusammen,

wenn ich im Zusammenhang mit FHEMapp ein "fhemweb device" mit dem "Attribut longpoll websocket" anlege und FHEMapp damit verbinde funktioniert FHEMapp wie erwartet.
So weit scheint alles gut, aber, in dieser Konfiguration meine ich festzustellen, dass die Speicherauslastung kontinuierlich bis zum Maximum (inkl. Auslagerungsspeicher) ansteigt.
Nachdem das Maximum erreicht ist, wird scheinbar ein wenig Speicher freigegeben, so dass das System weitgehend unbemerkt weiter läuft.
Selbst, wenn ich den Arbeitsspeicher auf 4GB erhöhe und 4 cores freigebe kann ich diese Entwicklung beobachten.
Ohne FHEMapp in meiner Konfiguration bewegt sich die Speicherauslastung im laufenden Betrieb um die 280 MB und benötigt um die 2% eines cores.

Meine Fragen:
1. Ist das in anderen Konstellationen auch zu beobachten? bzw.: Ist das "normal"?
2. ggf.: Habe ich etwas falsch gemacht?
3. ggf.: Kann ich das irgendwie verhindern?

Vielen Dank,

Gernot

Meine Konfiguration FHEM läuft in einem proxmox Container unter Ubuntu Server 20.04:
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: RAUNETFHEM
memory: 1024
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.100.1.1,hwaddr=FF:FF:FF:FF:FF:FF,ip=10.100.1.5/24,ip6=dhcp,tag=100,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-lvm:vm-105-disk-0,size=32G
swap: 512
unprivileged: 1

FHEM Devices:
defmod fhemapp FHEMWEB 8085 global
attr fhemapp csrfToken none
attr fhemapp longpoll websocket

defmod allowed_fhemapp allowed
attr allowed_fhemapp basicAuth SHA256:xxxx:yyyyy+zzzzzzzzzzzzzzzzzzzzzzzzz
attr allowed_fhemapp validFor fhemapp


FHEMapp config.json:
{
  "connection": {
    "location": "http://10.100.1.5",
    "port": "8085",
    "path": "fhem",
    "type": "websocket"
  }, 
  "options": {
  "mobileHeader": true,
"reloadBtn": true,
"homeBtn": true,
"debugMode": true,
"debugLevel": 5,
"lang": "de",
    "maxChartPoints": 100,
    "logBuffer": 500,
    "ignoreFhemGroup": false,
    "ignoreFhemRoom": false,
    "ignoreFhemSortby": true
  },
  "theme": {
    "dark": true,
    "themes": {
      "light": {
        "primary": "#616161",
        "secondary": "#F5F5F5",
        "accent": "#37474F",
        "error": "#e91e63",
        "warning": "#ffc107",
        "info": "#03a9f4",
        "success": "#4caf50"
      },
      "dark": {
      }
    }
  }
}

jemu75

Zitat von: supernova1963 am 07 September 2021, 11:39:24
Hallo zusammen,

wenn ich im Zusammenhang mit FHEMapp ein "fhemweb device" mit dem "Attribut longpoll websocket" anlege und FHEMapp damit verbinde funktioniert FHEMapp wie erwartet.
So weit scheint alles gut, aber, in dieser Konfiguration meine ich festzustellen, dass die Speicherauslastung kontinuierlich bis zum Maximum (inkl. Auslagerungsspeicher) ansteigt.
Nachdem das Maximum erreicht ist, wird scheinbar ein wenig Speicher freigegeben, so dass das System weitgehend unbemerkt weiter läuft.
Selbst, wenn ich den Arbeitsspeicher auf 4GB erhöhe und 4 cores freigebe kann ich diese Entwicklung beobachten.
Ohne FHEMapp in meiner Konfiguration bewegt sich die Speicherauslastung im laufenden Betrieb um die 280 MB und benötigt um die 2% eines cores.

Meine Fragen:
1. Ist das in anderen Konstellationen auch zu beobachten? bzw.: Ist das "normal"?
2. ggf.: Habe ich etwas falsch gemacht?
3. ggf.: Kann ich das irgendwie verhindern?

Vielen Dank,

Gernot

Meine Konfiguration FHEM läuft in einem proxmox Container unter Ubuntu Server 20.04:
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: RAUNETFHEM
memory: 1024
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.100.1.1,hwaddr=FF:FF:FF:FF:FF:FF,ip=10.100.1.5/24,ip6=dhcp,tag=100,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-lvm:vm-105-disk-0,size=32G
swap: 512
unprivileged: 1

FHEM Devices:
defmod fhemapp FHEMWEB 8085 global
attr fhemapp csrfToken none
attr fhemapp longpoll websocket

defmod allowed_fhemapp allowed
attr allowed_fhemapp basicAuth SHA256:xxxx:yyyyy+zzzzzzzzzzzzzzzzzzzzzzzzz
attr allowed_fhemapp validFor fhemapp


FHEMapp config.json:
{
  "connection": {
    "location": "http://10.100.1.5",
    "port": "8085",
    "path": "fhem",
    "type": "websocket"
  }, 
  "options": {
  "mobileHeader": true,
"reloadBtn": true,
"homeBtn": true,
"debugMode": true,
"debugLevel": 5,
"lang": "de",
    "maxChartPoints": 100,
    "logBuffer": 500,
    "ignoreFhemGroup": false,
    "ignoreFhemRoom": false,
    "ignoreFhemSortby": true
  },
  "theme": {
    "dark": true,
    "themes": {
      "light": {
        "primary": "#616161",
        "secondary": "#F5F5F5",
        "accent": "#37474F",
        "error": "#e91e63",
        "warning": "#ffc107",
        "info": "#03a9f4",
        "success": "#4caf50"
      },
      "dark": {
      }
    }
  }
}


Hallo Gernot,

ich habe das Verhalten bei websocket Verbindungen bisher nicht nachstellen können. Auch bei längerer Laufzeit bleibt der Speicher stabil und läuft nicht voll. Jedoch habe ich im Sourcecode noch etwas festgestellt, was in Verbindung mit longpoll zum Volllaufen des Speichers führen kann. D.h. wenn deine config.json den Parameter "type": "longpoll enthält, könnte das meiner Meinung nach passieren. Bitte beachten, dass diese Einstellung nichts mit dem Attribut "longpoll" in dem FHEM-Device FHEMWEB zu tun hat!


"connection": {
  "location": "http://fhem",
  "port": "8083",
  "path": "fhem",
  "type": "longpoll"
},

supernova1963

Hallo jemu75,

stimmt ich hatte vergessen das fhemweb Attribut longpoll wieder auf "1" zurückzustellen.
Ich hatte extreme Probleme mit den iPad's und iPhones. Irgendwie scheinen die bei attr fhemapp longpoll websocket immer wieder kurzfristig online/offline zu schalten. Damit ist bei diesen Geräten/Browsern (Safari oder Chrome) keine Verbindung herzustellen.
Auch der fhemweb Aufruf http://10.100.1.5:8085/fhem zeigt dann immer wieder "Connection lost, trying a reconnect every 5 seconds."!
Mit attr fhemapp longpoll 1 und
  "connection": {
    "location": "http://10.100.1.5",
    "port": "8085",
    "path": "fhem",
    "type": "longpoll"
  }
funktioniert es jetzt einwandfrei.
Deine Maßnahme in v.3.24.0 hat definitiv etwas gebracht. Mit "type": "longpoll" läuft auch der Speicher nicht mehr voll.

Vielen Dank,

Gernot