Zur Zeit so:uwe111 hat geschrieben: Wie sehen die Werte für den freien Speicher und die CCU-Auslastung auf der CUxD-Statusseite aus?
Es gibt mittlerweile auch schon die CUxD Version 0.58e zum Update.
Code: Alles auswählen
CUxD-Uptime(0.58a): 0 Tag(e) 18:31:18, 22032 Bytes belegt, Compiled Jun 10 2013 21:38:30
CCU-Uptime(1.508): 10 Tag(e) 22:32:20, load-average: 0.71 0.77 0.88, 10s-cpu-load: 37.7%
Speicher: Total 62372k Used 42076k Free 20296k (Cached 9524k)
OK.Hab ich geändert. Waren Infrarotbefehle an eine LED Leiste zum Alarm geben (aus ein aus ein ..) wenn es in's Dach regnet.uwe111 hat geschrieben: 1. Du rufst (wahrscheinlich aus einem Script heraus) innerhalb von 3s etwa 37x wget auf.
Ich würde die wget-Aufrufe in ein Shell-Script auslagern und dann dieses Script mit nur einem CMD_EXEC aufrufen. Dann müssen nicht mehr parallel 37 Prozesse auf der CCU erzeugt werden.
Wo liegt denn das? Das ist aber nicht das Log das ich in der CCU unter "Systemprotokoll" finde, oder?uwe111 hat geschrieben:
2. Dein CCU-Syslog wird ziemlich schnell vollgeschrieben.
Hier solltest Du kontrollieren, ob es sich um Fehlermeldungen handelt und ggf. versuchen, die Ursache zu finden.
Mal sehen. Vieleicht ist jetzt ja Ruhe. Die wget Schleife hab ich erst mal ausgebaut.
Warum werden eigentlich 37 Prozesse parallel gestartet? Die wget Aufrufe mache ich in einer Schleife sequentiell. Die kann man nacheinander abarbeiten.
Wenn die als Threads quasi asynchron gestartet werden funktioniert das was ich will eh nicht.
Wie kann ich denn dafür sorgen, dass sequentiell gestartete System.execs auch nacheinander abgearbeitet werden?
Gruss Ralf