NEWS
Gelöst: Multihost, Slave geht ständig down
-
@michihorn cpu am Master ist verdächtig hoch und der verbrauchte Ram am Slave liegt auch bei knapp 800 MB. Was läuft denn auf dem Slave so alles ?
-
@homoran Hallöchen
die beiden Hosts haben einen eigenen Namen.
Der neue Slave hat die Speicherkarte vom alten Slave erhalten
Im Slave ist in der Datei iobroker.json die IP des Master vorhanden.
Im Master ist Multihost auf enable
Anbei die iobroker.json vom Master:
{ "system": { "memoryLimitMB": 0, "hostname": "", "statisticsInterval": 15000, "// statisticsInterval": "Interval how often the counters for input/output in adapters and controller will be updated", "checkDiskInterval": 300000, "// checkDiskInterval": "Interval how often the disk size will be checked", "instanceStartInterval": 2000, "// noChmod": "Flag to test new feature with no chmod call. Must be deleted later and noChmod must be mainline (2018.06.04)", "compact": false, "// compact": "Controller will try to start the instances as a part of the same process. No spawn will be done. Only by adapters that support it and have flag compact flag in io-package.json", "allowShellCommands": false, "// allowShellCommands": "Allow execution of \"shell\" sendToHost commands", "memLimitWarn": 100, "// memLimitWarn": "If the available RAM is below this threshold on adapter start, a warning will be logged.", "memLimitError": 50, "// memLimitError": "If the available RAM is below this threshold on adapter start, an error will be logged." }, "multihostService": { "enabled": true, "secure": false, "password": "$/aes-192-cbc:1139b4570fcc6f8b285ef7bd2b8cde18:d59d0233246bb259a62b00c19b93cd88" }, "objects": { "type": "jsonl", "// type": "Possible values: 'file' - [port 9001], 'jsonl' - [port 9001], 'redis' - [port 6379 or 26379 for sentinel].", "host": "0.0.0.0", "port": 9001, "noFileCache": false, "maxQueue": 1000, "connectTimeout": 5000, "writeFileInterval": 5000, "dataDir": "", "options": { "auth_pass": null, "retry_max_count": 19, "db": 0, "family": 0, "enableReadyCheck": true, "host": "0.0.0.0", "port": 9001, "password": null, "autoResubscribe": false, "connectionName": "host.master", "retry_max_delay": 5000 }, "backup": { "disabled": false, "files": 24, "// files": "Minimal number of backup files, after the deletion will be executed according to backupTime settings", "hours": 48, "// hours": "All backups older than 48 hours will be deleted. But only if the number of files is greater than of backupNumber", "period": 120, "// period": "by default backup every 2 hours. Time is in minutes. To disable backup set the value to 0", "path": "", "// path": "Absolute path to backup directory or empty to backup in data directory" }, "jsonlOptions": { "// autoCompress (1)": "The JSONL DB is append-only and will contain unnecessary entries after a while.", "// autoCompress (2)": "It will be compressed when the uncompressed size is >= size * sizeFactor AND >= sizeFactorMinimumSize", "// autoCompress (3)": "Note that too low values here will cause the DB to be rewritten often.", "autoCompress": { "sizeFactor": 2, "sizeFactorMinimumSize": 25000 }, "// ignoreReadErrors": "If single lines in the DB are corrupted, they can be ignored without losing the whole DB.", "ignoreReadErrors": true, "// throttleFS (1)": "By default, the database immediately writes to the database file. Write accesses can be reduced using the throttleFS option.", "// throttleFS (2)": "Be aware that buffered changes will be lost in case the process crashes.", "throttleFS": { "// intervalMs": "Write to the database file no more than every intervalMs milliseconds.", "intervalMs": 60000, "// maxBufferedCommands": "Force writing after this many changes have been buffered. This reduces memory consumption and data loss in case of a crash.", "maxBufferedCommands": 100 } } }, "states": { "type": "jsonl", "// type": "Possible values: 'file' - [port 9000], 'redis' - [port 6379].", "host": "0.0.0.0", "port": 9000, "connectTimeout": 5000, "writeFileInterval": 30000, "dataDir": "", "options": { "auth_pass": null, "retry_max_count": 19, "db": 0, "family": 0, "enableReadyCheck": true, "host": "0.0.0.0", "port": 9000, "password": null, "autoResubscribe": false, "connectionName": "host.master", "retry_max_delay": 5000 }, "backup": { "disabled": false, "files": 24, "// files": "Minimal number of backup files, after the deletion will be executed according to backupTime settings", "hours": 48, "// hoursC": "All backups older than 48 hours will be deleted. But only if the number of files is greater than of backupNumber", "period": 120, "// period": "by default backup every 2 hours. Time is in minutes. To disable backup set the value to 0", "path": "", "// path": "Absolute path to backup directory or empty to backup in data directory" }, "jsonlOptions": { "// autoCompress (1)": "The JSONL DB is append-only and will contain unnecessary entries after a while.", "// autoCompress (2)": "It will be compressed when the uncompressed size is >= size * sizeFactor AND >= sizeFactorMinimumSize", "// autoCompress (3)": "Note that too low values here will cause the DB to be rewritten often.", "autoCompress": { "sizeFactor": 10, "sizeFactorMinimumSize": 50000 }, "// ignoreReadErrors": "If single lines in the DB are corrupted, they can be ignored without losing the whole DB.", "ignoreReadErrors": true, "// throttleFS (1)": "By default, the database immediately writes to the database file. Write accesses can be reduced using the throttleFS option.", "// throttleFS (2)": "Be aware that buffered changes will be lost in case the process crashes.", "throttleFS": { "// intervalMs": "Write to the database file no more than every intervalMs milliseconds.", "intervalMs": 60000, "// maxBufferedCommands": "Force writing after this many changes have been buffered. This reduces memory consumption and data loss in case of a crash.", "maxBufferedCommands": 2000 } }, "maxQueue": 1000 }, "log": { "level": "info", "maxDays": 7, "noStdout": true, "transport": { "file1": { "type": "file", "enabled": true, "filename": "log/iobroker", "fileext": ".log", "maxSize": null, "maxFiles": null }, "syslog1": { "type": "syslog", "enabled": false, "host": "localhost", "// host": "The host running syslogd, defaults to localhost.", "// port": "The port on the host that syslog is running on, defaults to syslogd's default port(514/UDP).", "protocol": "udp4", "// protocolC": "The network protocol to log over (e.g. tcp4, udp4, unix, unix-connect, etc).", "// path": "The path to the syslog dgram socket (i.e. /dev/log or /var/run/syslog for OS X).", "// facility": "Syslog facility to use (Default: local0).", "localhost": "iobroker", "// localhost": "Host to indicate that log messages are coming from (Default: localhost).", "// sysLogType": "The type of the syslog protocol to use (Default: BSD).", "// app_name": "The name of the application (Default: process.title).", "// eol": "The end of line character to be added to the end of the message (Default: Message without modifications)." }, "seq1": { "type": "seq", "enabled": false, "serverUrl": "http://IP:PORT", "// serverUrl": "The http(s) URL including port of the seq server. If you use HTTPS a real certificate is needed; self signed certs are ot accepted.", "apiKey": "", "// apiKey": "The apiKey of the seq system" } } }, "// dataDir": "Always relative to iobroker.js-controller/", "plugins": {}, "dataDir": "../../iobroker-data/" }@michihorn sagte in Multihost, Slave geht ständig down:
die beiden Hosts haben einen eigenen Namen.
auch die beiden getauschten PIs?
@michihorn sagte in Multihost, Slave geht ständig down:
Der neue Slave hat die Speicherkarte vom alten Slave erhalten
und hat vom Router die selbe IP erhalten, wie der alte?
Zwei verschiedene Boards haben unterschiedliche MAC-Adressen gemäß derer ein Router die IP zuweist.
Also hat der Router jetzt 2 verschiedene MAC-Adressen im Speicher, die dem selben Hostnamen zugeordnet werden!?? -
@michihorn cpu am Master ist verdächtig hoch und der verbrauchte Ram am Slave liegt auch bei knapp 800 MB. Was läuft denn auf dem Slave so alles ?
-
@michihorn sagte in Multihost, Slave geht ständig down:
die beiden Hosts haben einen eigenen Namen.
auch die beiden getauschten PIs?
@michihorn sagte in Multihost, Slave geht ständig down:
Der neue Slave hat die Speicherkarte vom alten Slave erhalten
und hat vom Router die selbe IP erhalten, wie der alte?
Zwei verschiedene Boards haben unterschiedliche MAC-Adressen gemäß derer ein Router die IP zuweist.
Also hat der Router jetzt 2 verschiedene MAC-Adressen im Speicher, die dem selben Hostnamen zugeordnet werden!??@homoran sagte in Multihost, Slave geht ständig down:
und hat vom Router die selbe IP erhalten, wie der alte?
Zwei verschiedene Boards haben unterschiedliche MAC-Adressen gemäß derer ein Router die IP zuweist.
Also hat der Router jetzt 2 verschiedene MAC-Adressen im Speicher, die dem selben Hostnamen zugeordnet werden!??Der neue Slave hat natürlich eine neue IP erhalten. In der Iobroker.json des Master wird aber nach keiner speziellen IP des Slave gefragt. Nur im Slave wird expiliziet die IP des Master angegeben.
-
@homoran sagte in Multihost, Slave geht ständig down:
und hat vom Router die selbe IP erhalten, wie der alte?
Zwei verschiedene Boards haben unterschiedliche MAC-Adressen gemäß derer ein Router die IP zuweist.
Also hat der Router jetzt 2 verschiedene MAC-Adressen im Speicher, die dem selben Hostnamen zugeordnet werden!??Der neue Slave hat natürlich eine neue IP erhalten. In der Iobroker.json des Master wird aber nach keiner speziellen IP des Slave gefragt. Nur im Slave wird expiliziet die IP des Master angegeben.
@michihorn sagte in Multihost, Slave geht ständig down:
In der Iobroker.json des Master wird aber nach keiner speziellen IP des Slave gefragt.
aber bei putty
-
@michihorn sagte in Multihost, Slave geht ständig down:
In der Iobroker.json des Master wird aber nach keiner speziellen IP des Slave gefragt.
aber bei putty
-
@homoran Ja klar in Putty habe ich um drauf zu kommen natürlich die neue IP angegeben. Mit dem neuen Slave läuft es zur Zeit seit 1 Stunde ohne probleme, aber gut, der alte Slave hat i.R auch 3 Stunden gemacht
@michihorn sagte in Multihost, Slave geht ständig down:
läuft es zur Zeit seit 1 Stunde ohne probleme
Möglicherweise bis der Router über die neue MAC Bindung an den selben Hostnamen stolpert
-
@djmarc75 Folgendes läuft auf dem Slave:
Der Adapter Smartthings für Samung ist der einzige sehr hungrige Adapter auf dem Slave
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
-
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
Außerdem wird bei richtiger Einrichtung ja alles auf dem Master verwaltet, was ggf. der Grund für die hohe Last dort sein könnte.
Näheres dazu würde man mit
topauf dem Master sehen.
Möglicherweise bremst da auch die (S)SD -
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
Möglich wenn Smartthing mal wieder richtig Daten schiebt,
aber aktuell, schau mal auf die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
-
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
Möglich wenn Smartthing mal wieder richtig Daten schiebt,
aber aktuell, schau mal auf die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
@michihorn sagte in Multihost, Slave geht ständig down:
die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
beim MASTER!
-
@michihorn sagte in Multihost, Slave geht ständig down:
die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
beim MASTER!
@homoran sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
beim MASTER!
DJMarc75 und ich schrieben gerade über den Slave.
Natürlich ist der Master zu sehr Busy. Das sehe ich auch so.
-
@homoran sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
beim MASTER!
DJMarc75 und ich schrieben gerade über den Slave.
Natürlich ist der Master zu sehr Busy. Das sehe ich auch so.
@michihorn sagte in Multihost, Slave geht ständig down:
DJMarc75 und ich schrieben gerade über den Slave.
liest du nicht alles?
@homoran sagte in Multihost, Slave geht ständig down:
Außerdem wird bei richtiger Einrichtung ja alles auf dem Master verwaltet, was ggf. der Grund für die hohe Last dort sein könnte.
-
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
Folgendes läuft auf dem Slave
bei einem RPI3 mit 1GB RAM wundert mich das nicht wenn sich der bei solch vielen Adaptern mal verabschiedet.
Möglich wenn Smartthing mal wieder richtig Daten schiebt,
aber aktuell, schau mal auf die Auslastung, die geht sowohl bei CPU als auch bei RAM niemals über 30-40%
@michihorn sagte in Multihost, Slave geht ständig down:
bei RAM niemals über 30-40%
das siehst Du falsch. Bei RAM wird hier der verfügbare angezeigt. 22,6% sind also verfügbar.
-
@michihorn sagte in Multihost, Slave geht ständig down:
DJMarc75 und ich schrieben gerade über den Slave.
liest du nicht alles?
@homoran sagte in Multihost, Slave geht ständig down:
Außerdem wird bei richtiger Einrichtung ja alles auf dem Master verwaltet, was ggf. der Grund für die hohe Last dort sein könnte.
@homoran Doch ich habe das gelesen, aber Du schreibst ja selbst bei richtiger Einrichtung wird alles über den Master verwaltet. Wo ist also mein Fehler?
Ich werde mir am Wochenende mal meine bei Javascript Instancen anschauen, die haben jede Menge traffic verursacht. -
@homoran Doch ich habe das gelesen, aber Du schreibst ja selbst bei richtiger Einrichtung wird alles über den Master verwaltet. Wo ist also mein Fehler?
Ich werde mir am Wochenende mal meine bei Javascript Instancen anschauen, die haben jede Menge traffic verursacht.@michihorn sagte in Multihost, Slave geht ständig down:
wird alles über den Master verwaltet. Wo ist also mein Fehler?
dass ggf. durch den vielen Traffic der zu verwaltenden Daten des Slaves der Master in die Knie geht.
@michihorn sagte in Multihost, Slave geht ständig down:
Ich werde mir am Wochenende mal meine bei Javascript Instancen anschauen, die haben jede Menge traffic verursacht.
@homoran sagte in Multihost, Slave geht ständig down:
Näheres dazu würde man mit
topauf dem Master sehen.
Möglicherweise bremst da auch die (S)SD -
@michihorn sagte in Multihost, Slave geht ständig down:
bei RAM niemals über 30-40%
das siehst Du falsch. Bei RAM wird hier der verfügbare angezeigt. 22,6% sind also verfügbar.
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
bei RAM niemals über 30-40%
das siehst Du falsch. Bei RAM wird hier der verfügbare angezeigt. 22,6% sind also verfügbar.
Okay???
Bei der Angabe CPU wird die Auslastung angegeben?
Und bei RAM nur noch der verfügbare Speicher?
Das ist ist mir neu und klingt von der Logik irgendwie widersinnig. -
@michihorn sagte in Multihost, Slave geht ständig down:
wird alles über den Master verwaltet. Wo ist also mein Fehler?
dass ggf. durch den vielen Traffic der zu verwaltenden Daten des Slaves der Master in die Knie geht.
@michihorn sagte in Multihost, Slave geht ständig down:
Ich werde mir am Wochenende mal meine bei Javascript Instancen anschauen, die haben jede Menge traffic verursacht.
@homoran sagte in Multihost, Slave geht ständig down:
Näheres dazu würde man mit
topauf dem Master sehen.
Möglicherweise bremst da auch die (S)SD -
@djmarc75 sagte in Multihost, Slave geht ständig down:
@michihorn sagte in Multihost, Slave geht ständig down:
bei RAM niemals über 30-40%
das siehst Du falsch. Bei RAM wird hier der verfügbare angezeigt. 22,6% sind also verfügbar.
Okay???
Bei der Angabe CPU wird die Auslastung angegeben?
Und bei RAM nur noch der verfügbare Speicher?
Das ist ist mir neu und klingt von der Logik irgendwie widersinnig.@michihorn sagte in Multihost, Slave geht ständig down:
Bei der Angabe CPU wird die Auslastung angegeben?
Und bei RAM nur noch der verfügbare Speicher?
Das ist ist mir neu und klingt von der Logik irgendwie widersinnig.korrekt in allen Punkten ;)
-
@michihorn sagte in Multihost, Slave geht ständig down:
wird alles über den Master verwaltet. Wo ist also mein Fehler?
dass ggf. durch den vielen Traffic der zu verwaltenden Daten des Slaves der Master in die Knie geht.
@michihorn sagte in Multihost, Slave geht ständig down:
Ich werde mir am Wochenende mal meine bei Javascript Instancen anschauen, die haben jede Menge traffic verursacht.
@homoran sagte in Multihost, Slave geht ständig down:
Näheres dazu würde man mit
topauf dem Master sehen.
Möglicherweise bremst da auch die (S)SD@homoran sagte in Multihost, Slave geht ständig down:
@homoran sagte in Multihost, Slave geht ständig down:
Näheres dazu würde man mit top auf dem Master sehen.
Möglicherweise bremst da auch die (S)SDHier ist eine Scandisk Ultra A1 installiert
457
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge