Hohe Load mit gluon testing (1.3~20181118) - Mehrfachaufrufe von dhcpv6.script br-client ra-updated

Technik
3

Hallo hexa,

das sieht schonmal viel besser aus, und reicht erstmal als vorläufiger Fix:

Version                    avg	   max        von - bis
1.2.6 (beta)               0.29    1.08       23.-26.11.
1.3.1 (testing)            0.74    2.58       26.-27.11.
1.3.1, ra_holdoff=30       0.26    1.25       27.-29.11.

loadgraph-tuccity_20181123-29
loadgraph-tuccity_20181123-291000×500 97.9 KB

Link zum Graphen

Die Mehrfachaufrufe sind immer noch da (aber die gab’s auch schon bei 1.2.6):

-----------------------------------------------------
OpenWrt 18.06-SNAPSHOT, r7391+11-0d549271d3
-----------------------------------------------------
root@64287-tuccity:~# while [ 1 ]; do l=`ps|grep "br-client ra-updated" |grep -v grep`; [ -n "$l" ] && (date; echo "$l") ; sleep 1 ;done > /tmp/ps_raupdated.log
^C
root@64287-tuccity:~# cat /tmp/ps_raupdated.log 
Fri Nov 30 01:36:14 CET 2018
25973 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
25974 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
25975 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
25977 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
25978 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
Fri Nov 30 01:36:15 CET 2018
25977 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
25978 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
Fri Nov 30 01:36:51 CET 2018
26213 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26214 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26215 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26216 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26217 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
Fri Nov 30 01:36:52 CET 2018
26211 root      1340 R    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26213 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26214 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26215 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26216 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
26217 root      1340 S    /bin/sh /lib/netifd/dhcpv6.script br-client ra-updated
Fri Nov 30 01:37:27 CET 2018
[5 Zeilen]
Fri Nov 30 01:37:28 CET 2018
[6 Zeilen]
Fri Nov 30 01:38:08 CET 2018
[6 Zeilen]
Fri Nov 30 01:38:09 CET 2018
[7 Zeilen]
...usw.

In script_call() ist wohl der Wurm drin…

  1. Zeile 400:
    - if (diff > delay)
    + if (diff < delay)
    , sonst ist delay immer <= 0, und der Child-Prozess rennt durch, ohne zu warten.

  2. Zeile 398, kill() fork() usw.
    Das laufende Skript zu killen und neu zu forken verbrennt IMHO unnötig Rechenzeit. Das Problem ist wohl, dass die DHCP-Einträge nur im Parent-Prozess aktualisiert werden, und die Einträge des Childs während des sleep(delay) veralten.
    Evtl. könnte man auf sleep() verzichten, und statt dessen z.B. mit waitpid(.. WNOHANG ..) testen, ob das Skript noch läuft. Falls nein && (now - last_update >= delay): neu forken.
    Trade-off: ein Update während des Delays wird nicht (gleich) umgesetzt.

  3. Anscheinend will man für RA-Updates ein delay von mind. 1 Sekunde (script_accu_delay = 1). Das kann aber schiefgehen, weil mit ganzen Sekunden gerechnet wird.

(4.) 1.-3. erklären wahrscheinlich noch nicht, warum es überhaupt zu mehreren gleichzeitigen(?) Updates kommt. (Soll/muss das so sein?)

Edit: Mein Vorschlag zu 2. taugt nichts. Bin davon ausgegangen, dass nach ein paar Sekunden sowieso das nächste Update kommt, aber es gibt ja auch andere Setups.
Wenn eine hohe Update-Frequenz die Regel und nicht die Ausnahme ist, ist die jetzige Methode sehr ineffizient.