GELÖST: Load immer 1.x obwohl sie nix zu tun hat?

tpf

Niemand ne Idee?

btw: irgendwie vermisse ich ja das pfSense-Layout im Forum :(

JeGr

Hast du mal mit top/ps nachgesehen, wo die load herkommt?

Bzgl. Forum: Lese ich immer wieder vereinzelt. Ich frage mich, was genau denn am alten Layout so viel besser war? Ich finde es gerade so viel angenehmer, was das Antworten, durchscrollen und auch mal mobil ansehen angeht, dass ich das alte Layout so überhaupt nicht vermisse...

tpf

Ich fands wesentlich übersichtlicher. Ich hatte an meinen Post übrigens ein Bild angehängt. Wurde wohl nicht mit übernommen.

JeGr

Da müsste man jetzt mit Dstat oder was ähnlichem ran, um noch zusätzliche Wait states zu sehen, ich mutmaße mal, dass die Load von 1 von irgendwas mit wait ausgehen würde. Ist aber schwer zu sagen.

Was gibt denn ps auxwww aus? Müsste eigentlich Idle mit annähernd CPU Kernen * 100% laufen? Wie schauts bei vmstat 1 aus?

Also an der Übersichtlichkeit des Forums kann ich nicht meckern. Gerade der jüngste Feinschliff war doch sehr schick. Sind ein paar Kleinigkeiten noch, aber alles andere gefällt mir persönlich toll. Kein altes Boxen/Tabellen Layout mehr, dass man nicht Mobil anschauen konnte, ordentliche Editierbox wo man schnell schreiben kann - ich finds toll ;)

tpf

@jegr said in Load immer 1.x obwohl sie nix zu tun hat?:

auxwww

Vielleicht bin ich es einfach nach knapp 12 Jahren so gewohnt ;-)

ps auxwww zeigt komplett:

USER PID %CPU %MEM root 11 399.2 0.0 root 0 0.0 0.0 root 1 0.0 0.0 root 2 0.0 0.0 root 3 0.0 0.0 root 4 0.0 0.0 root 5 0.0 0.0 root 6 0.0 0.0 root 7 0.0 0.0 root 8 0.0 0.0 root 9 0.0 0.0 root 10 0.0 0.0 root 12 0.0 0.0 root 13 0.0 0.0 root 14 0.0 0.0 root 15 0.0 0.0 root 16 0.0 0.0 root 17 0.0 0.0 root 18 0.0 0.0 root 19 0.0 0.0 root 20 0.0 0.0 root 21 0.0 0.0 root 22 0.0 0.0 root 23 0.0 0.0 root 24 0.0 0.0 root 25 0.0 0.0 root 26 0.0 0.0 root 27 0.0 0.0 root 28 0.0 0.0 root 29 0.0 0.0 ... VSZ RSS TT STAT STARTED TIME COMMAND
0 64 - RL 23May18 49824:12.77 [idle]
0 304 - DLs 23May18 0:03.00 [kernel]
5028 908 - ILs 23May18 0:00.04 /sbin/init --
0 16 - DL 23May18 0:00.00 [crypto]
0 16 - DL 23May18 0:00.00 [crypto returns 0]
0 16 - DL 23May18 0:00.00 [crypto returns 1]
0 16 - DL 23May18 0:00.00 [crypto returns 2]
0 16 - DL 23May18 0:00.00 [crypto returns 3]
0 32 - DL 23May18 0:00.00 [cam]
0 16 - DL 23May18 0:00.23 [soaiod1]
0 16 - DL 23May18 0:00.23 [soaiod2]
0 16 - DL 23May18 0:00.00 [audit]
0 368 - WL 23May18 27:06.68 [intr]
0 64 - DL 23May18 0:00.00 [ng_queue]
0 48 - DL 23May18 0:00.02 [geom]
0 80 - DL 23May18 0:27.41 [usb]
0 16 - DL 23May18 0:00.23 [soaiod3]
0 16 - DL 23May18 0:00.22 [soaiod4]
0 16 - DL 23May18 0:00.00 [sctp_iterator]
0 16 - DL 23May18 3:36.39 [pf purge]
0 16 - DL 23May18 0:10.24 [acpi_thermal]
0 16 - DL 23May18 0:05.91 [acpi_cooling0]
0 16 - DL 23May18 6:27.92 [rand_harvestq]
0 48 - DL 23May18 0:14.50 [pagedaemon]
0 16 - DL 23May18 0:00.00 [vmdaemon]
0 16 - DL 23May18 0:00.02 [pagezero]
0 16 - DL 23May18 0:06.15 [bufspacedaemon]
0 32 - DL 23May18 0:19.84 [bufdaemon]
0 16 - DL 23May18 0:06.55 [vnlru]
0 16 - DL 23May18 0:29.01 [syncer]

vmstat 1
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr md0 md1 in sy cs us sy id
0 0 0 1.1G 3.3G 397 0 0 0 465 6 0 0 180 324 477 0 0 100
0 0 0 1.1G 3.3G 2 0 0 0 0 4 0 0 144 156 404 0 0 100
0 0 0 1.1G 3.3G 1 0 0 0 0 4 0 0 139 159 400 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 87 138 304 0 0 100
0 0 0 1.1G 3.3G 5 0 0 0 0 5 0 0 61 185 238 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 97 138 293 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 140 138 383 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 82 138 288 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 85 146 274 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 2 4 2 2 60 138 226 0 0 100
0 0 0 1.1G 3.3G 6 0 0 0 0 4 0 0 79 181 293 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 2 14 98 156 303 0 0 100
1 0 0 1.1G 3.3G 0 0 0 0 0 5 0 2 90 137 284 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 10 103 138 318 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 78 159 303 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 96 138 306 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 283 138 696 0 0 100
0 0 0 1.1G 3.3G 5 0 0 0 0 4 0 0 136 199 415 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 124 159 376 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 6 0 0 137 159 376 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 87 138 281 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 104 137 313 0 0 100
1 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 112 138 350 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 6 0 0 111 139 317 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 131 138 360 0 0 100
1 0 0 1.1G 3.3G 5 0 0 0 0 5 0 0 82 159 270 0 1 99
1 0 0 1.1G 3.3G 0 0 0 0 0 4 0 0 151 142 435 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 4 0 2 110 155 337 0 0 100
0 0 0 1.1G 3.3G 0 0 0 0 0 5 0 0 93 162 292 0 0 100

JeGr

@tpf OK, sieht also danach aus, als wäre es auf jeden Fall nichts CPU-lastiges oder DiskI/O. Zumindest wenn ich den cruden output von vnstat richtig sehe ;)

Leider gibt es jetzt aus dem Stehgreif kein "Ersatz" für linux' dstat command, aber vielleicht weiß da jemand was Ähnliches. Hat die Möhre denn viel Netzwerk I/O? Auch der geht bei BSD ja m.W. in die Load Kalkulation ein (die von der Berechnung her eh anders zusammengesetzt ist, wie bspw. unter Linux). Daher immer ein wenig schwierig.

Solang sich das System aber nicht komisch/langsam/laggy anfühlt und die Netzwerk Interfaces ordentlich mitspielen würde ich da jetzt keinen Alarm machen, wunderlich ist es schon.

tpf

Der Interface Load ist quasi nicht vorhanden. 10GB in 8 Tagen. Die kiste langweilt sich. Mir scheint, aus der 0 wurde einfach eine 1, und die Nachkommastellen spiegeln den tatsächlichen Load wieder

JeGr

@tpf in der Tat merkwürdig aber ich halte es mal im Hinterkopf, vielleicht springt mich an anderer Stelle mal was an, was das erklären könnte. Tatsächlich hab ich zwar nach Umstellung verschiedener Systeme auf 2.4.x höhere Load wahrgenommen, aber teils durch ZFS, teils durch das neue OS drunter erklärbar und nicht einfach mal 100% von irgendeinem I/O Part mehr. Eine exakte Steigerung um 1.0 gabs tatsächlich nirgends. Seltsam.

tpf

Merci ;-) Lohnt der Umstieg auf ZFS ohne RAID?

JeGr

@tpf Da gibt es sicher solche und solche Meinungen. IMHO ist ZFS kein RAID-only Filesystem und nur weil es durch SAN/NAS Einsatz und seine RAID- und Pool-Levels berühmt/berüchtigt worden ist, waren die Infos, die man auch in der Beta und den RCs von 2.4 damals bekam schon sehr aussagekräftig, dass UFS eben sehr leicht mal kaputt geht bei Power-loss oder abruptem Reboot, ZFS ist da eben für Robustheit ausgelegt.

Ich sehe den Vergleich ein wenig wie bei MySQL/Maria/Percona DBs und MyISAM vs InnoDB. Es hat heute schon seinen Grund, warum InnoDB die Standard Engine geworden ist und auch wenn es viele Nein-Sager gibt, selbst Anwendungen die es früher explizit nicht genutzt haben (weil Overhead, langsamer, bliblablubb) setzen es heute ein weil Geschwindigkeit jetzt ~on par ist und Robustheit und Optimierungspotential viel größer sind.

Dazu kommt, dass es schonmal angedeutet wurde, dass - sobald ZFS mal breit ausgerollt ist - man sich u.a. solche Dinge wie Backup und Recovery anschauen will und diese ggf. mit ZFS Snapshots, Rollbacks etc. wieder zurückbringen möchte. Also quasi vor dem Update auf die nächste Firmware automatischen ZFS Snapshot machen, installieren, testen -> wenns nicht gescheit läuft, auf alten Stand zurückrollen (oder bei Panic/Faults beim Booten automatischer Reboot und Fallback auf letzte Version).

Daher habe ich schonmal vorsorglich alles, was ich ordentlich neu machen konnte ohne Probleme, mit ZFS auf 2.4 neu installiert :)

tpf

Servus,
hat wohl mit dem HPET-Problem auf dem J3455 zu tun. In 2.4.4 Dev ist es mit machdep.disable_msix_migration=1 in der /boot/loader.conf.local behoben. Mit 2.3.5 tritt es ebenfalls nicht auf. Fix wirkt unter 2.3.4 leider nicht.

Naja...

tpf

Problem ist in pfS 2.4.4 gelöst. Alles gut :)