Bug Memory Leak? Auslastung auf einer Instanz steigt permanent, andere bleibt niedrig

Thumper_ · Jan 3, 2017

Betriebssystem: Linux ubuntu 16.10
SinusBot Version: 0.9.15-b20cc30
TS3 Version: 3.0.19.4

Problembeschreibung
Ich nutze aktuell 2 Instanzen, beide Streamen lediglich Webradio. Innerhalb von ~1-2 Wochen steigt die RAM Nutzung einer Instanz auf über 2-3GB an. Die andere Instanz bliebt davon unberührt. Witzigerweise steigt die RAM Nutzung immer von der gleichen Instanz an, nämlich jener, die laut.fm/harpermusic streamt. Liegt es vielleicht daran? Wie kann ich das eingrenzen ohne das unsere User andere Musik hören?

Der Sinusbot läuft als Service, bringt das Problem allerdings auch wenn ich ihn händisch in einer Screen Session starte.

Code:

● sinusbot.service - LSB: Sinusbot
   Loaded: loaded (/etc/init.d/sinusbot; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2016-12-30 12:52:18 CET; 4 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1291 ExecStart=/etc/init.d/sinusbot start (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
      CPU: 0
   CGroup: /system.slice/sinusbot.service

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Code:

==========================================================
SINUSBOT RELATED
SYSTEM INFORMATION
 - Operating System: Ubuntu 16.10
 - OS x64 check: OK
 - Kernel: Linux 4.8.0-30-generic x86_64
 - Load Average: 0.41 0.95 0.73
 - Uptime: 20 days, 1 hours, 57 minutes, 6 seconds
 - OS Updates: 0 (well done!)
 - OS Missing Packages: None (v1)
 - OS APT Last Update: 03.01.2017 13:00:03 CET +01:00:00
 - Bot Start Script: found at /etc/init.d/sinusbot [perms: 755]
 - DNS resolution check: google.com -> OK
 - CPU:
  Architecture:  x86_64
  CPU(s):  2
  Thread(s) per core:  1
  Core(s) per socket:  1
  Socket(s):  2
  Model name:  Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
  CPU MHz:  2297.336
  Hypervisor vendor:  KVM
  Virtualization type:  full
 - RAM: 2.48 GB/5.82 GB in use (42%)
 - SWAP: 168.70 MB/3.99 GB in use (4%)
 - DISK: 8.31 GB/97.12 GB in use (8%)
 - Package versions:
  > libglib: 2.50.0-1

BOT INFORMATION
 - Status: running (PIDs: 10455 10454, User: sinusbot)
 - Webinterface: port locally reachable (Port: 8089)
 - Binary: /opt/sinusbot/sinusbot (MD5 Hash: ca497448f617fc17a5bb579980a8572e)
 - Version: 0.9.15-b20cc30
 - TS3 Plugin: installed (md5 hash match)
  - Bot Plugin: 0b71cb8de70ec252d6f339b26c3a0e82
  - TS3 Client: 0b71cb8de70ec252d6f339b26c3a0e82
 - Config:
  - LogLevel = 3
  - TS3Path = /opt/sinusbot/teamspeak3-client/ts3client_linux_amd64 (Version 3.0.19.4)
  - YoutubeDLPath = not set (does exist anyway, version: 2016.12.18)
 - Installed scripts: advertising.js; aloneMode.js; badchan.js; bookmark.js; covatar.js; dev.js; followme.js; idle.js; metadata.js; norecording.js; rememberChannel.js; showcase.js; sound.js; welcometext.js

OTHER INFORMATION
 - Report date: 03.01.2017 13:36:09 CET +01:00:00 (timezone: Europe/Berlin)
 - TeamSpeak 3 Version: 3.0.19.4
 - youtube-dl Version: 2016.12.18
 - DiagScript version: 0.4.6
==========================================================

Xuxe · Jan 3, 2017

Hi,

Update bitte mal auf die 0.9.16 die mittlerweile erschienen ist. Deine Screenshots sagen leider nicht wirklich viel aus ^^
Die erste Spalte "VIRT" in Htop ist nicht der wirklich genutzte RAM, jediglich das was der Client sich vom Kernel "erst einmal" gewünscht hat. Und solang der Client dort nichts drin allocated ist der Kernel Herr über diesen RAM und nutzt diesen z.B für Cache.

Was sagt:

Code:

free -m

PS: Der Client teilt sich einen RAM Pool unter allen Instanzen weitest gehend.

Thumper_ · Jan 3, 2017

Xuxe said:
Hi,

Update bitte mal auf die 0.9.16 die mittlerweile erschienen ist. Deine Screenshots sagen leider nicht wirklich viel aus ^^
Die erste Spalte "VIRT" in Htop ist nicht der wirklich genutzte RAM, jediglich das was der Client sich vom Kernel "erst einmal" gewünscht hat. Und solang der Client dort nichts drin allocated ist der Kernel Herr über diesen RAM und nutzt diesen z.B für Cache.

Was sagt:

Code:

free -m

PS: Der Client teilt sich einen RAM Pool unter allen Instanzen weitest gehend.

free -m gibt aus:

Code:

              total        used        free      shared  buff/cache   available
Mem:           5967        2178        1592          88        2196        3407
Swap:          4092         168        3924

Update habe ich soeben durchgeführt, im Anschluss free -m:

Code:

              total        used        free      shared  buff/cache   available
Mem:           5967        1742        1977          88        2247        3843
Swap:          4092          97        3995

Wohlgemerkt war der Sinusbot davor zuletzt vor ein paar Tagen neugestartet worden.

Zudem läuft nach dem Update der "service sinusbot start" Befehl nicht mehr durch. "service sinusbot status" gibt folgendes aus, allerdings ist der Sinusbot nicht gestartet:

Code:

● sinusbot.service - LSB: Sinusbot
   Loaded: loaded (/etc/init.d/sinusbot; generated; vendor preset: enabled)
   Active: active (exited) since Tue 2017-01-03 15:17:13 CET; 3min 14s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 26851 ExecStop=/etc/init.d/sinusbot stop (code=exited, status=1/FAILURE)
  Process: 27114 ExecStart=/etc/init.d/sinusbot start (code=exited, status=0/SUCCESS)

Jan 03 15:17:11 server su[27137]: Successful su for root by root
Jan 03 15:17:11 server su[27137]: + ??? root:root
Jan 03 15:17:11 server su[27137]: pam_unix(su:session): session opened for user root by (uid=0)
Jan 03 15:17:11 server sinusbot[27114]: mesg: ttyname failed: Inappropriate ioctl for device
Jan 03 15:17:11 server su[27170]: Successful su for root by root
Jan 03 15:17:11 server su[27170]: + ??? root:root
Jan 03 15:17:11 server su[27170]: pam_unix(su:session): session opened for user root by (uid=0)
Jan 03 15:17:11 server sinusbot[27114]: mesg: ttyname failed: Inappropriate ioctl for device
Jan 03 15:17:13 server sinusbot[27114]: sinusbot started successfully
Jan 03 15:17:13 server systemd[1]: Started LSB: Sinusbot.

edit: über screen läuft es allerdings!

Xuxe · Jan 3, 2017

Thumper_ said:
Zudem läuft nach dem Update der "service sinusbot start" Befehl nicht mehr durch. "service sinusbot status" gibt folgendes aus, allerdings ist der Sinusbot nicht gestartet:

Thumper_ said:
edit: über screen läuft es allerdings!

Das Service Script startet auch nur einen Screen, muss ich mir mal angucken das sollte eh langsam mal alles auf Systemd umgestellt werden.
RAM sieht aber Okay aus, wie du siehst nutzt er viel RAM als Cache ich vermute so kommst du auf 3 GB?

Thumper_ · Jan 3, 2017

Xuxe said:
RAM sieht aber Okay aus, wie du siehst nutzt er viel RAM als Cache ich vermute so kommst du auf 3 GB?

Soll er denn überhaupt Webradio Cachen? Das wundert mich jetzt doch etwas...

Falls du beim Script einen Freiwilligen Tester brauchst, hau mich an

Thumper_ · Jan 10, 2017

Heute liegt die RAM Auslastung wieder bei ~78%.

free -m
total used free shared buff/cache available
Mem: 5967 4109 227 59 1629 1504
Swap: 4092 304 3788

Leider fällt davon wieder 25%auf die gleiche Instanz zurück, wohingegen die andere Instanz bei unter 3% arbeitet. Kann es sein, dass bestimmte Einstellungen miteinander nicht arbeiten und daher den Leak erzeugen?

Xuxe · Jan 10, 2017

Hi,

Thumper_ said:
Soll er denn überhaupt Webradio Cachen? Das wundert mich jetzt doch etwas...

Das ist nicht der Bot der cached, sondern Linux selber. Linux nutzt idle RAM für Disk Cache und parkt da z.B Files die häufig genutzt werden.

Thumper_ said:
Leider fällt davon wieder 25%auf die gleiche Instanz zurück, wohingegen die andere Instanz bei unter 3% arbeitet. Kann es sein, dass bestimmte Einstellungen miteinander nicht arbeiten und daher den Leak erzeugen?

Das kann schon sein, die letzten Änderungen waren ja an der Engine hauptsächlich. - Welches Scripts nutzt du den so?
Du verwendest übrigens auch kein Docker oder LXC? Nur KVM?

Thumper_ · Jan 10, 2017

Xuxe said:
Hi,

Das ist nicht der Bot der cached, sondern Linux selber. Linux nutzt idle RAM für Disk Cache und parkt da z.B Files die häufig genutzt werden.

Das kann schon sein, die letzten Änderungen waren ja an der Engine hauptsächlich. - Welches Scripts nutzt du den so?
Du verwendest übrigens auch kein Docker oder LXC? Nur KVM?

Kein Docker, kein LXC. Lediglich mein VPS ist per KVM virtualisiert.

Habe grade eben mal das update auf die 8. Jan Version gemacht, mal schauen wie es jetzt läuft.
Scripts aktiv nutze ich keine - jedenfalls habe ich keine wissentlich aktiviert.

PaInKiLLeR · Jan 11, 2017

Moin,

habe das gleiche Problem nachdem ich heute Morgen Debian 8 geupdatet habe

Code:

2017-01-11T13:50:37+01:00 TSClient quit. LogLevel has been increased, please try to connect again to see more details.
2017-01-11T13:50:37+01:00 Closed.
2017-01-11T13:50:37+01:00 TS>terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >: boost::thread_resource_error: Resource temporarily unavailable
2017-01-11T13:50:37+01:00 TS>fork(): Cannot allocate memory
2017-01-11T13:50:37+01:00 TS |INFO | | |Loading plugin: libtest_plugin
2017-01-11T13:50:37+01:00 TS |INFO | | |Loading plugin: libsoundbot_plugin
2017-01-11T13:50:37+01:00 TS |INFO | | |Loading plugin: liblua_plugin
2017-01-11T13:50:37+01:00 TS |INFO | | |Loading plugin: libclientquery_plugin
2017-01-11T13:50:37+01:00 TS |WARNING |SoundDevManager| |Did not load any sound backends. No (usable) dynamic libraries found.
2017-01-11T13:50:37+01:00 TS |ERROR |SoundBckndIntf| |/home/musicbot/TeamSpeak3-Client-linux_amd64/soundbackends/libpulseaudio_linux_amd64.so error: INIT_PA_IMPL
2017-01-11T13:50:37+01:00 TS |ERROR |PulseAudio | |pa_context_connect failed
2017-01-11T13:50:37+01:00 TS |ERROR |PulseAudio | |failed to connect to pulse audio server
2017-01-11T13:50:37+01:00 TS |ERROR |SoundBckndIntf| |libasound.so.2: cannot open shared object file: No such file or directory
2017-01-11T13:50:37+01:00 TS |INFO | | |SystemInformation: Linux 3.16.7-042stab117.16 #1 SMP Fri Sep 9 21:57:19 MSK 2016 x86_64 Binary: 64bit"]

Ich habe 4GB RAM und vorher nie Probleme gehabt oder zumindest nicht gemerkt bis auf Sound Aussetzer!

Es scheint wohl an Debian selbst zu liegen da er mir seit dem Update meldet ich hätte zuwenig RAM!

Ich kann nicht mehr wie 3 Bots starten wo bei jeder laut Webmin auf einmal 1.2 GB nutzt

System:

vCore: 4x2,3 GHz
RAM: 4 GB DDR3
SSD: 125 GB
Swap: 500 MB
TS-Client: 3.0.19.4
OS: Debian 8.6 minimal 64bit

SinusBot: 0.9.16-10f0fa

Stand: 11.Jan 2017

PaInKiLLeR · Jan 12, 2017

So hier noch ein paar Screens

Sehr komisch ist das unter SSH alles in Ordnung scheint aber unter Webmin werden extreme Werte angezeigt

Selbst Teamspeak frisst über 1GB

Starte ich alle 8 Bots gleichzeitig geht einer nach dem anderen Offline (inkl. Webmin) bis nur noch 3 Online sind da die 4GB dann grad noch so ausreichen!

Ist das ein Bug vom SinusBot oder liegt das an Debian?

Webmin:

SSH:

Xuxe · Jan 12, 2017

PaInKiLLeR said:
Selbst Teamspeak frisst über 1GB

Was sagt free - m? Das sieht eher nach Buggy Webinferface Anzeige aus bzw virtueller RAM was ich oben erklärte.
Dein Top Screenshot sagt ja das du noch gut 3 gig frei hast...

irgendwr · Jan 12, 2017

PaInKiLLeR said:
Ist das ein Bug vom SinusBot oder liegt das an Debian?

Webmin:

Ein Bug in Webmin würde ich sagen ^^

PaInKiLLeR · Jan 12, 2017

Eher nicht, Webmin scheint eher anzuzeigen was Wirklich los ist,sobald ich mehr als 3 Bots am laufen habe kommt diese Meldung:

Code:

2017-01-11T13:50:37+01:00 TS>fork(): Cannot allocate memory

Xuxe · Jan 12, 2017

PaInKiLLeR said:
017-01-11T13:50:37+01:00 TS>terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >: boost::thread_resource_error: Resource temporarily unavailable

PaInKiLLeR said:
Eher nicht, Webmin scheint eher anzuzeigen was Wirklich los ist,sobald ich mehr als 3 Bots am laufen habe kommt diese Meldung:

Ich kann dir versichern das du dem Output von Top mehr glauben kannst als Webmin. - Könnte auch nen Overloaded Host sein fehlt mir die Info zu mit was das ding Virtualisiert ist. ^ Oben genannte Meldung kam u.a auf OpenVZ bereits vor da die kisten zu stark limitiert waren.
Ohne viel Info's kann man hier leider wieder nicht viel sagen, ich schließe aber mal aus das es direkt was mit Debian und oder dem Bot zutun hat.

PaInKiLLeR · Jan 12, 2017

Das mag ja sein aber warum macht der Bot dann Dicht und meldet der Speicher reicht nicht mehr aus
wo ich vorher ohne Probleme 8 Bots am laufen hatte wo jeder im Schnitt nur um die 250kb verbraucht hat!

Und jetzt verbraucht einer alleine auf einmal über 1GB an Speicher,das bei 4GB dann nur noch 3 laufen is
mir dann auch klar nur liegt das nicht am Server sonst hätte ich das Problem ja schon immer gehabt

Da stimmt doch was nicht

mxschmitt · Jan 12, 2017

PaInKiLLeR said:
2017-01-11T13:50:37+01:00 TS>fork(): Cannot allocate memory

Diese Meldung hat als Präfix "TS" somit kommt diese nicht vom Sinusbot. Der Sinusbot gibt diese Fehlermeldung nur aus da er diese vom TS3 Client bekommt.

PaInKiLLeR · Jan 13, 2017

maxibanki said:
Diese Meldung hat als Präfix "TS" somit kommt diese nicht vom Sinusbot. Der Sinusbot gibt diese Fehlermeldung nur aus da er diese vom TS3 Client bekommt.

Habe 3 verschiedene Clienten probiert,immer das gleiche Ergebnis und der
SinusBot[siehe Log oben] nutzt ja selbst fast 2GB was ja nicht normal sein kann oder?

Xuxe · Jan 13, 2017

Liest du eigentlich was hier geschrieben wird? Ich habe dir gestern bereits gesagt das es im Webmin nen Anzeige Bug sein muss, das gibt Mathematisch keinen sinn was da steht! Ich kann keine ca 10 GB Ram verbrauchen wenn mein Server nur 4 hat ^^
Dein 2. Screenshot sagt ja auch das du 3 GB frei hast und 1GB etwa belegt ist also wie kann das sein?^^

flyth · Jan 13, 2017

PaInKiLLeR said:
und der
SinusBot[siehe Log oben] nutzt ja selbst fast 2GB

Was sagt der bot denn im webinterface über seinen Speicherverbrauch?

Thumper_ · Jan 13, 2017

Da ich vorgestern erst neu gestartet habe liegt er noch bei 2% RAM Nutzung. Laut Webinterface siehe Anhang.

Bug Memory Leak? Auslastung auf einer Instanz steigt permanent, andere bleibt niedrig

Donor

Attachments

Containerholic

Donor

Containerholic

Donor

Donor

Containerholic

Donor

Helping Hand

Helping Hand

Containerholic

no longer active, "retired" staff member

Helping Hand

Containerholic

Helping Hand

Moderator

Helping Hand

Containerholic

is reticulating splines

Donor

Attachments