owdir /uncached @100% CPU

[makki]

Haben sich bei einem der Beteiligten schon neue Erkenntnisse zur Systemlast hinsichtlich owdir bzw. monit ergeben?

Ähm, darf ich fragen ob man jetzt vom WG oder dem anderen Teil spricht ?

Vorab aber schonmal: aufm WG ist das eher unwahrscheinlich: die permanente Abfrage des 1-Wire treibt die loadavg in die Höhe, die CPU aber eher nicht >40% .. hab da gerade nen Testaufbau für PL38 mit 250 Sensoren aufm Tisch

Makki

[mfd]

Ähm, darf ich fragen ob man jetzt vom WG oder dem anderen Teil spricht ?

Ich spreche in meinem Fall von einem CG.
Dass "nur" die loadavg steigt ist mir soweit schon klar, eigentlich wollte ich diese aber ja niedrig halten. Das dürfte ja WG-Besitzer gleichermaßen betreffen...
Hat sich außer der weiter oben genannten Änderung bzgl. iButton-Abfrage in den letzten Patchleveln noch etwas in der Abfrage geändert?
Wie kann ich die iButton-Geschichte (vorübergehend) deaktivieren?

[makki]

Nun wenn man sich (die aufm WG Serienmässigen) collectd-Grafiken ansieht ist die loadavg mit den letzten zwei Updates (vor ca. 2J!) zwar krass angestiegen, kommt im Kern aber von "Wait-IO".
Was IMHO Ok ist, wir versuchen halt den 1w so schnell wie möglich abzufragen, weil das ist nunmal dessen primäre Aufgabe.

Wie man das aufm CG mit unbekannter HW ändern kann=?, Sorry, ich gebe gerne Tipps - aber das ist eher Suchen der Nadel im Heuhaufen, bevor man damit überhaupt im Nebel stochern kann..

Makki

[heckmannju]

Da ich keine IOs verwende, habe ich das Polling in wiregated-ow.pl deaktiviert. Seit dem läuft alles wieder etwas runder (load < 1.0, i.d.R. 0.7).

Wie kann man diese Polling den abschalten?

[XueSheng]

Wie kann man diese Polling den abschalten?

Ohne das weiter zu hinterfragen, habe ich einfach folgende Anpassung an /usr/sbin/wiregated-ow.pl vorgenommen (man könnte auch die gesamte while Schleife auskommentieren). In der While Schleife werden offensichtlich die Sensoren zusammengetragen, die gepollt werden sollen. Wie gesagt, ist mehr "quick and dirty".

        while( my ($k, $v) = each(%wg_config) ) {
            LOGGER('DEBUG',"CONFIG: Sensor $k Type $wg_config{$k}{'type'} !");
#            if ($wg_config{$k}{'type'} eq "DS1990" ) {  # ROM iButton
#                push(@a_owdev_buttons, $k);
#            }
#            if ($wg_config{$k}{'type'} eq "DS2406" or $wg_config{$k}{'type'} eq "DS2408") {  # PIO
#                push(@a_owdev_pio, $k);
#            }
#            if ($wg_config{$k}{'type'} eq "DS2413" or $wg_config{$k}{'type'} eq "DS2406") {  # PIO without latch - poll
#                #FIXME: also polling DS2406 for now as we disabled alarm-search !
#                push(@a_owdev_pio_poll, $k) unless ($wg_config{$k}{'type_ch0'} and $wg_config{$k}{'type_ch1'}) # 0 = input, 1=output
#            }
#            $wg_config{$k}{'offset'} = 0 unless $wg_config{$k}{'offset'};
        }

[mfd]

@makki
Wie wäre die Vorgehensweise für das Original WG?
Wenn du das verraten magst hilft es den WG-Besitzern die die loadavg senken wollen und anderen (mit WG-ähnlicher Hardware*) vielleicht ja auch.

*bei mir CPU Geode LX800@500MHz, 256MB RAM, 4GB CF Industrial, VGA CS5536A, LAN Realtek RTL8110, 3x USB 2.0, 2xPS/2, Realtek AC97 Audio, RS232.

[heckmannju]

Naja solange die loadavg <2 bleibt ist ja noch alles OK. Wenn dadurch die IOs schnell zum Zuge kommen wurde ich nix daran drehen.

Gesendet von meinem LIFETAB_E10316 mit Tapatalk