Netzteil defekt oder unterdimensioniert?

Ok, oder auch nicht. ;)

Jedenfalls sehr gut nachvollziehbar, danke für die ausführliche Erklärung!


Und ja, ich habe ECC-Ram. Hardware im Eimer wäre mir sehr lieb...wenn ich die genaue Komponente wüsste.

Das Ding ist, ich habe das Mainboard 3x und die RAM-Riegel 6x. Dass da alles kaputt ist (aus unterschiedliche Quellen gekauft), kann ich mir eigentlich nicht vorstellen und es sollte da doch möglich sein, mindestens eine funktionierende Kombi hinzubekommen. :)
Vllt. eher in der Richtung, dass im BIOS ne Einstellung mit dem RAM nicht harmoniert? Die Riegel sind so gesteckt, wie in der Anleitung, anderenfalls piepst das Board und es kommt kein Bild, logisch.
memtest lief ja durch, umgesteckt und getauscht hab ich ja schon alles untereinander.

Fürs Erste habe ich den ECC Mode auf 'basic' gestellt, dann werde ich alle durchtesten.

Fällt wem noch was ein?

Ich hab jetzt auf die Schnelle mal 2x2 GB andere Riegel bestellt, bevor ich noch mehr Geld aus dem Fenster werfe. :ugly:
 

Anhänge

  • bios1.png
    bios1.png
    94,8 KB · Aufrufe: 405
  • bios2.png
    bios2.png
    126,3 KB · Aufrufe: 431
  • IMG_20180725_115902.jpg
    IMG_20180725_115902.jpg
    241,2 KB · Aufrufe: 345
  • IMG_20180725_120829.jpg
    IMG_20180725_120829.jpg
    205 KB · Aufrufe: 361
  • IMG_20180725_120835.jpg
    IMG_20180725_120835.jpg
    145,8 KB · Aufrufe: 389
  • IMG_20180725_120849.jpg
    IMG_20180725_120849.jpg
    184 KB · Aufrufe: 382
  • IMG_20180725_120926.jpg
    IMG_20180725_120926.jpg
    220,1 KB · Aufrufe: 399
  • ramtabelle.png
    ramtabelle.png
    102,3 KB · Aufrufe: 402
  • Screenshot_2018-07-25 TYAN® Computer - Motherboards S8010 S8010GM2NR - Support Lists.png
    Screenshot_2018-07-25 TYAN® Computer - Motherboards S8010 S8010GM2NR - Support Lists.png
    13,3 KB · Aufrufe: 390
Wenn du es noch nicht hast: Baue das System mal aus seinem Gehäuse raus, lege die Komponenten schön auf ein Holzbrett (oder etwas anderes Nichtleitendes) und schaue mal ob es so stabil läuft. Dabei natürlich die Kühlung nicht vergessen, zum Beispiel durch einen direkt darauf gerichteten Ventilator. Ich weiß, es ist schon recht weit hergeholt, aber da du praktisch alles durch hast, bleiben eigentlich nur noch ein sporadischer Kurzschluss durch's Gehäuse oder vielleicht die Backplane.
 
Zur Auswahl stehen auch noch die PCI-Express Steckkarten und die CPU
Nö, der HBA wurde vorgestern getauscht und die Netzwerkkarte war schon mal testweise ausgebaut, trotzdem Absturz. :ugly:
Und ich hab auch insgesamt drei verschiedene Opterons hier auf Halde....ich kenn defekte CPUs nur, wenn erst gar kein Bild mehr kommt. Aber ja...die CPU werde ich auch nochmal tauschen...so verzweifelt wie ich bin, würd ich sogar fast beten. :rolleyes:

Baue das System mal aus seinem Gehäuse raus, lege die Komponenten schön auf ein Holzbrett (oder etwas anderes Nichtleitendes) und schaue mal ob es so stabil läuft.

Das werde ich und es bleibt spannend.

to be continued :D
 
In der Zwischenzeit habe ich aus der Grabbelkiste noch ein Intel-Board 'D525MW' gezogen, welches nun mich und meinen Nachbarn mit Internet versorgt, damit ich ungestört am dicken Server rumpfuschen kann.
Zu meinem Erstaunen gibts keine Engpässe, sogar ein jailed Asterisk läuft noch darauf problemlos und das trotz nur 4Gb max. möglichem RAM, software-crypto mit geli und ausgeschaltetem zfs-prefetch:
Code:
ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present;
to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
....und als Bonbon obendrauf ist der Atom D525 nicht anfällig für spectre und meltdown. Lediglich genervt hat mich, dass nur efiboot geht (bootpool+zroot) und naja das Kernelbauen war schnarchig.

Kleine Verständnisfrage, konnte mir keinen Reim darauf machen:
Code:
real memory  = 4294967296 (4096 MB)
avail memory = 4072845312 (3884 MB)
Ist das der RAM, den die onboard-gpu abzwackt?

Anyway,
was ich bis jetzt noch am Problemkind gemacht habe:
2 andere RAM-Riegel gekauft. 2x2Gb NANYA, einfach zum Testen. memtest86 und memtest86+ liefen sauber durch. Im Standardmodus und im Modus 'alle CPU-Kerne nutzen'. Mit den 'nur' 4GB RAM läuft er nun.

Die beiden Backplanes (Teilenummer chenbro 80h10321516a1) nochmal ausgebaut, ausgepustet. Die IDs sind korrekt gejumpert, anhand vom Manual überprüft.

Den SAS-2008 auf Firmware: 20.00.07.00 gehoben.
Code:
mps0: <Avago Technologies (LSI) SAS2008> port 0xe000-0xe0ff mem 0xfeab0000-0xfeabffff,0xfeac0000-0xfeafffff irq 28 at device 0.0 on pci1
mps0: Firmware: 20.00.07.00, Driver: 21.02.00.00-fbsd
mps0: IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>

Interessant ist jetzt, dass ich im dmesg wieder die folgenden Fehlermeldungen bekomme (die kamen beim SAS2308 mit Firmware 20.00.07.00 auch so!):
Code:
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=384244731904, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=402184826880, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=410942025728, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=679182319616, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=683924090880, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=447638908928, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=448859918336, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=449236664320, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da1.eli[READ(offset=450967576576, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=453330710528, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=453889454080, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da1.eli[READ(offset=457379528704, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=460329091072, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=460694712320, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=464785575936, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=466604044288, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=474814738432, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da0.eli[READ(offset=721985679360, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=740210827264, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da4.eli[READ(offset=763615617024, length=28672)]
GEOM_ELI: Crypto READ request failed (error=22). da5.eli[READ(offset=764348452864, length=28672)]

Und noch interessanter ist, dass es nur da0, da1, da4 und da5 sind, die geli-errors (mit P19 auf dem SAS2008 gab es die nicht) spucken. Die devices mit error habe ich mit x markiert, wie sie an den Backplanes hängen:

x|o|o|x
x|o|o|x

Welches Teufelswerk ist das?

Abgestürzt ist er jedenfalls nicht mehr, auch nicht nachts zu den periodic-jobs.

@Yamagi
Aus dem dump und backtrace konnte man rauslesen, dass auf eine Adresse zugegriffen werden sollte, die aber nicht existiert, daher die Kernelpanic.
Kann es sein, dass die Ram-Riegel (2x 16GB quadranked) irgendein Mainboardlimit aushebeln und das daher kommt? Obwohl sie offiziell fürs Board unterstützt werden mit den 8 lanes? FreeBSD zeigt halt Speicherbereich A-Z, das Board kann aber nur bis Bereich Y?
Oder ist das Käse und das Board würde einfach nicht starten und kein Bild bringen?
 
Noch was gefunden:
http://freebsd.1045724.x6.nabble.co...-1-STABLE-to-LSI-2008-firmware-td6253259.html

Ich habe den HP H220 / SAS9207-8i (crossflashed auf LSISAS2308) jetzt wieder drin, weil er schneller ist. Folgende Erkenntnisse zur Firmware:
20.00.07.00 -> viele errors -> GEOM_ELI: Crypto READ request failed (error=22) und zu 100% garantierter Absturz nachts um 3 zu den periodic jobs
Weitere Anmerkung zu error 22, der sich auch bei anderen folgendermaßen zeigt:
Code:
(da0:mps0:0:15:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command
operation code)
(da0:mps0:0:15:0): Error 22, Unretryable error
(da0:mps0:0:15:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00
(da0:mps0:0:15:0): CAM status: SCSI Status Error
(da0:mps0:0:15:0): SCSI status: Check Condition
(da0:mps0:0:15:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command
operation code)
(da0:mps0:0:15:0): Error 22, Unretryable error
Und den Fehler hatte ich bereits gaaaanz am Anfang, aber nicht 100% richtig interpretiert, als ich den Controller kaufte und auf SAS umstieg. -> https://www.bsdforen.de/threads/problem-mit-sas-platten.34138/

20.00.06.00 -> kein error 22 mehr, kein Absturz um 3 bei periodic jobs aber dafür fiept (Spulenfiepen?) der Controller unter Last (z.B. beim scrub) ganz erbärmlich. Stoppt man den scrub, hörts kurz danach auf und geht reproduzierbar wieder los bei nem erneuten scrub.

20.00.04.00 -> gibts nicht auf der Broadcom-Seite, habe die Version auch sonst nicht im Netz gefunden.

19.00.00.00 -> Die teste ich gerade langfristig aus, bisher kein error 22 und kein Fiepen beim scrub.

Mit dem PERC H310 (sas2008) werde ich dann ebenfalls so verfahren und schrittweise die Firmware von neu nach alt durchtesten.
 
So, nachdem auch die P19 beim SAS2308 error 22 spuckte und im dmesg stand, dass fast alle Dienste aufgrund mangelndem swap wegbrechen (hatte ich schonmal, kann bei 96GB swap nicht sein), hab ich das Teil erstmal auf die Seite gekloppt.

Neuer Testaufbau:

1x Chenbro Rackgehäuse (gebraucht, Ursprungsgerät), 1x Chenbro Towerserver (nagelneu, mit 12Gb/s mini-SAS HD Backplane, war teuer und ja, ich weiß....Frevelei weil kein 12G-Controller zur Hand;'()

Jeweils gleiches Mainboard, jeweils der Ursprungsram 2x16GB-Module, jeweils ein Dell PERC H310 mit IT-Firmware 20.00.06.00 crossflashed, nachdem das die höchste, problemlos laufende, FW unter 11.2-Release ist (zumindest bei mir). 20.00.07.00 wirft mit error 22 irgendwann um sich.

Code:
dmesg | grep mps0
mps0: <Avago Technologies (LSI) SAS2008> port 0xe000-0xe0ff mem 0xfeab0000-0xfeabffff,0xfeac0000-0xfeafffff irq 28 at device 0.0 on pci1
mps0: Firmware: 20.00.06.00, Driver: 21.02.00.00-fbsd
mps0: IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>
mpsutil show adapter
mps0 Adapter:
       Board Name: SAS9211-8i
   Board Assembly:
        Chip Name: LSISAS2008
    Chip Revision: ALL
    BIOS Revision: 0.00.00.00
Firmware Revision: 20.00.06.00
  Integrated RAID: no

PhyNum  CtlrHandle  DevHandle  Disabled  Speed   Min    Max    Device
0       0001        0009       N         6.0     1.5    6.0    SAS Initiator
1       0007        000f       N         6.0     1.5    6.0    SAS Initiator
2       0008        0010       N         6.0     1.5    6.0    SAS Initiator
3       0006        000e       N         6.0     1.5    6.0    SAS Initiator
4       0002        000a       N         6.0     1.5    6.0    SAS Initiator
5       0003        000b       N         6.0     1.5    6.0    SAS Initiator
6       0004        000c       N         6.0     1.5    6.0    SAS Initiator
7       0005        000d       N         6.0     1.5    6.0    SAS Initiator

Ergebnis: keine panics nachts um 3, überhaupt keine panics bisher, kein error 22, gar keine errors auf der Konsole und sysutils/spindown grätscht auch nicht doof dazwischen, funkt wie es soll. Ich schiebe seit gestern Abend mit voller 1gbit-Netzauslastung meinen pool auf die andere Maschine. Die Gehäuse sind hinten warm bis heiß, wie ich es noch nie erlebt habe. Das spricht für sich! :D

Meine TV-Maschine habe ich von debian befreit und stumpf das aktuelle libreELEC stable draufgepackt, seitdem ist auch das 3-Minutenvideoanlaufproblem verschwunden, es klappt sofort, auch nach standby. Erfreulich war auch, dass die GPU-Beschleunigung sofort funktionierte. ;)

Was ich jetzt mit meinem SAS2308 mache, weiß ich noch nicht. Ich könnte ihn nochmal an die neue Backplane vom Tower anschließen und alle Firmwares durchtesten. Zumindest hätte ich dann den Gegenbeweis, dass es der HBA ist und nicht die Backplanes.

Aber wenn ich das so lese, was ich noch gefunden habe :ugly: :

The problem could also be isolated by breaking to the debugger on the console and see where the system is really hanging (presumably in the LSI driver, but where in that driver?). A verbose boot (from the boot menu) might reveal something, but probably not. Sometimes the problem is that an earlier kernel operation (possibly not even for the device last reported) has set up a "time bomb" that goes off a random time later, leading to a hang or panic. That is probably a lot less work than a hardware bus analyzer and may point to the problem. But there is probably an even easier solution - see below.
https://forums.freebsd.org/threads/hang-during-boot-when-poking-disks.62015/

SAS controller (LSI 2308) , since I recieved it always does this one thing : Drops all HDDs connected to it
https://bbs.archlinux.org/viewtopic.php?id=167366

https://www.illumos.org/issues/5698
https://bugzilla.redhat.com/show_bug.cgi?id=1099254

pci_access_mutex: Mutex to synchronize ioctl,sysfs show path and
*pci resource handling. PCI resource freeing will lead to free
*vital hardware/memory resource, which might be in use by cli/sysfs
*path functions resulting in Null pointer reference followed by kernel
*crash. To avoid the above race condition we use mutex syncrhonization
*which ensures the syncrhonization between cli/sysfs_show path.
https://github.com/sprdlinux/kernel/blob/master/drivers/scsi/mpt3sas/mpt3sas_base.h

Könnte das nicht genau das sein, was der backtrace mitteilen wollte?
 
Ok, wieder ein OOM. Jetzt auf dem Zielrechner, wo ich noch immer Daten hinschiebe:
Code:
pid 817 (ntpd), uid 0, was killed: out of swap space

Code:
root@dserver:/ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p2      33554432     7188 33547244     0%
/dev/ada1p2      33554432     6400 33548032     0%
/dev/ada2p2      33554432     5900 33548532     0%
Total           100663296    19488 100643808     0%

Es wurde kein ZFS- oder mem-Tuning unternommen.
 
Quellrechner wieder abgestürzt um ca 1:15, kein kernel dump, aber eins vom 27.7.

Code:
(kgdb) backtrace
#0  0xffffffff80b25ebd in sched_switch ()
#1  0xffffffff80b00cf6 in mi_switch ()
#2  0xffffffff80b4a50c in sleepq_wait ()
#3  0xffffffff80b0072e in _sleep ()
#4  0xffffffff80b4ff31 in taskqueue_thread_loop ()
#5  0xffffffff80aba083 in fork_exit ()
#6  <signal handler called>
 
Der Fehler zieht sich seit Januar/Februar. Da hatte ich die 11.1 erstmalig frisch installiert.

Ich müsste wenn dann, auf ne noch ältere gehen, gesehen hat der Server nur 11.1 und 11.2. Aber ich hab den pool jetzt schon upgegraded auf die Features von 11.2 und unter ner alten Version kann ich die microcode-updates nicht fahren.

Bin mir auch nicht sicher, wo Driver: 21.01.00.00-fbsd vorkommt. 10.3? 10.2? Oder ob es überhaupt am Driver liegt.

Mir würde es glaube ich, schon helfen, wenn mir einer ne funktionierende Treiber/FW-Kombo (entweder SAS2008 oder SAS2308) von sich aus nennen kann UND dann auf seinem pool sysutils/spindown und 'sharenfs on' für mich ausprobiert.

Irgendwo auf den mailing-listen fand ich den ebenfalls passenden bug und dass man die kernel panic auslösen kann, wenn man die doppelte Menge an physikalischem RAM auf den pool schreibt, während die Platten runtergefahren sind. Wäre in meinem Fall dann so:
dd if=/dev/zero of=testfile count=64 bs=1G

Das klappt problemlos mehrfach auf beiden eingerichteten Maschinen. Die Platten fahren hoch, das file wird geschrieben und gut is, keine Meldung irgendwo.

Mehrfach versucht hatte ich jetzt noch mit ausgeschalteten Platten per kodi videos zu starten. Klappt auch problemlos, Platten fahren hoch und gut is, video startet.
 
Ich trau mich gar nicht es endgültig aufzulösen (weil ich noch nicht genug Uptime habe, um 1000% sicher zu sein :D) ...es war doch ein Hitzeproblem. Darauf gekommen bin ich, weil ich hier in meiner Wohnung seit letzter Woche dahinschmelze und ich die zweite Maschine im großen Servertower nicht gecrasht bekam, weder idle noch unter Last. (später fiel mir noch auf, dass die Threads in anderen Foren mit meinen ähnlichen Problemen und Kernelpanics oft in den Monaten Juni/Juli herum waren :eek: )
Das Sorgenkind 2HE Rack crashte allerdings in letzter Zeit nur noch idle.
Da ich ganz am Anfang schon bemerkte, dass die Kühlkörper brutal heiß werden und geraten wird, die Kühlkörper von den Stockwärmeleitpads zu befreien, mit neuer Paste zu beschmieren und noch einen Lüfter draufzuschnallen, hab ich das mal befolgt. Ich habe dazu einen Noctua NF-A4x20 bestellt und noch ein paar NF-A4x10 (zum Experimentieren), falls ersterer doch zu dick sein sollte und ich mir den benachbarten PCI-E Steckplatz zubauen sollte. Jedenfalls passte der dickere problemlos drauf und den habe ich jeweils immer auf die jeweilige Karte montiert, wenn ich im 2HE ebensolche zum Testen ausgewechselt hatte, weil 2HE einfach nicht viel Luft zum Atmen bietet. Das Kabel war exakt lang genug für den "REAR_FAN2" Anschluss vom Board. Jetzt der Clou: der NF-A4x20 hat 4pins zur dynamischen Lüftersteuerung, die kleineren NF-A4x10 nur 3pins. Im Eifer des Gefechts hab ich damals beim Bestellen nicht darauf geachtet, Noctua hat bei den Modellbezeichnungen die Zusätze 'PWM' für 4pins und 'FLX' für 3. Ein aktiviertes 'Auto Fan Control' mit Duty-Cycle 30% im BIOS trat dann immer die Fehlerkette in Gang. Ich dachte, dass das nur für den CPU-Fan gilt, aber nein, ist auch im Handbuch so nicht beschrieben. Alle Fananschlüsse orientieren sich anscheinend an der CPU-Temperatur (oder vllt. noch CPU0 MOS Area oder SR5670 Temp, konnte ich nicht rausfinden). Dh. unter Last ging die CPU-Temperatur (schnell genug) hoch und der CPU-Lüfter bis 7000rpm, das hat dann auch den Noctua auf seine maximalen 5000rpms hochgezogen.
Dadurch erklären sich auch alle meine Fehler...CPU ist idle, hat 26°, der Lüfter am Controller dreht deswegen nur mit 2000rpms und da kocht der Chip wahrscheinlich bereits an seiner Grenze (in Datenblättern fand ich 55° und auch 110°, was jetzt für den jeweiligen Chip stimmt oder ob Celsius oder Fahrenheit, weiß ich nicht. Jedenfalls habe ich im Netz keine Angabe gefunden, wie man die Temperatur auslesen könnte. Bilde mir aber ein, dass ich bei den ganzen DOS-Tools megarec, sas2flsh zum Flashen mal 'ROC Temperature' über den Screen huschen sah. Weiß da wer genaueres?).
So...und kommt dann nachts mal ein 'periodic daily' daher oder streame ich ein video, langweilt sich die CPU so gähnig, dass beide Lüfter nicht hochgezogen werden, aber der HBA steigt dann irgendwann aus. Dh. es war immer pures Glück, dass während meiner Woche Urlaub oder den Wochenenden die Temperatur gerade so unter Limit beim periodic daily blieb.
Ich hab den 4pin Noctua jetzt stumpf an die Backplane angeschlossen, da gibts nur 3pins, der CPU-Fan soll ja weiterhin dynamisch laufen. Im Tower-Server hab ich den kleinen NF-A4x10 auf dem SAS2008 am 'REAR_FAN2', das klappt, weil der eh nur 3pins hat und stiefelt fest mit 4800rpms, was ich per IPMI auslesen kann.

Heureka! :D

Da das nun geschafft war, hab ich auch die Firmware 20.00.07.00 nochmal ausprobiert und mittels mpsutil im live-Betrieb geflasht. Ich hab mir nichtmal die Mühe gemacht, den pool auszuhängen. Wenn man sich routiniert fühlt und Backups hat, wird man mutig. :)
Sofern der Controller bereits crossflashed ist, also LSI Firmware und die SAS-Adresse hat, stiefelt das einwandfrei durch mit ein paar Sekunden. Zum Reinitialisieren hab ich die ganze Kiste dann neu gestartet, hat geklappt. Also Firmware 20.00.07.00 mit Driver: 21.02.00.00-fbsd stiefelt jetzt einwandfrei auf dem SAS2308 und beiden SAS2008.

Für google, falls wer darüber kommt. Da würde ich dann sagen, dass die allgemeine Meinung zutrifft, die man in den Foren zu den Firmwares liest:
-19.00.00.00 funktioniert
-20.00.00.00 - ??? -> murksig, soll wohl auch von LSI bestätigt sein
-20.00.04.00, 20.00.06.00, 20.00.07.00 funktioniert

Noch ne Frage an die Experten:
Da ich am ZFS bisher nichts rumgetunt hatte und erneut durch meine zfs send/receive Experimente, diese Kills (pid 817 (ntpd), uid 0, was killed: out of swap space) mit sshd, ntpd und div. anderen wichtigen Diensten hatte. Wie regelt man das und wieso ist das so? Da waren auf einen Schlag 10 Dienste gekillt worden. Per ssh kam ich dann wieder rein, flog aber dann gleich wieder nach ein paar Sekunden raus. Nur reboot half.

Wieso ist der Back-Pressure/ARC so träge? Ich mein, das ist ein 11.2-Release und frisch installiert, nichts verbastelt, nichts damit vorher gemacht. Mir ist klar, dass sich das einpendelt (steckt da sowas wie eine Lernroutine dahinter oder wird stumpf %-x vom RAM genommen?) und ein System, welches z.B. 60 Tage rumidlete dann unter ZFS-Last plötzlich umdenken muß. Nix gegen Verzögerungen, aber dass das System dann unbenutzbar wird, wenn der Fall eintritt, stell ich mir unschön vor, wenn die Maschine 500km entfernt stehen sollte.
Und überhaupt....wieso wird dann der swap nicht genutzt, damit das nicht passiert? Sollte in der Prioliste nicht zuerst swap kommen, bevor der oom-Killer zulangt?
Ich hab auf jeder Platte meine RAM-Größe als swap. Ist eigentlich Platzverschwendung, ich weiß...aber wieso wird der nicht zuerst verbraten?


Jetzt die allerwichtigste Frage:
ich hab in der loader.conf jetzt mal
Code:
vfs.zfs.arc_max="8G"
reingeschrieben, neu gestartet, mit top und zfs-stats überprüft. Macht man das so oder ist das Pfusch mit dem Holzhammer oder fummelt man noch an den vm.kmem-Variablen rum?

Jedenfalls wurde bisher auf keiner der beiden Maschinen danach mehr ein Dienst beendet. :p
 
Also ist die Lösung jetzt, dass der LSI-Controller überhitzte? Das würde aber bedeuten, dass zumindest in dem 2HE Gehäuse etwas mit dem Luftstrom nicht stimmt. Denn eigentlich haben die ja vorne ihre 4 bis 6 Gewalt-Lüfter, die stumpf Luft ohne Ende durch das Gehäuse pumpen. Wenn es trotzdem zu Überhitzungen kommt, liegt die jeweilige Komponente nicht im Luftstrom. Zum Beispiel da die Luftführung (dieses Plastikdings, was über dem Mainboard liegt) nicht richtig eingesetzt ist. Wenn es sowas in dem Gehäuse überhaupt gibt...

Zum ZFS: ZFS Cache ist sehr gierig, er nimmt sich an RAM was er kriegen kann. Wenn nun plötzlich etwas anderes viel Speicher braucht, kann ZFS seinen Cache oft nicht schnell genug abbauen und dem System geht der Speicher aus. Daher sollte man auf allem, was kein reiner Fileserver ist, ZFS immer begrenzen. Deine 8GB sind eine gute Wahl, genau der Wert, den ich meistens nehme. Wenn die Kiste viel I/O macht, kann man auch über Zweidrittel des RAMs nachdenken. Darüber sollte man aber nicht gehen.
 
vfs.zfs.arc_max="8G"
Da kann man doch mal sehen. Ich hatte geglaubt, ZFS geht heute automatisch gut mit Speicher um. Tatsächlich sehe ich auch auf meinem Desktop bislang nie einen ARC > 8G.
Trotzdem leuchtet mir die Begrenzung an der Stelle durchaus ein.

Funktioniert das auch in 11.1 so?
Wenn ich den Wert mit sysctl setzen möchte, akzeptiert dies nicht "8G" und ich muss einen Bit-Wert setzen.
 
Also ist die Lösung jetzt, dass der LSI-Controller überhitzte?

Ja, ja und nochmals JA! :D:):D Egal, welchen Controller ich reingesteckt hab, ob mit oder ohne Noctua...der überhitzte, weil der Lüfter einfach auf die niedrigste Stufe abhängig der CPU-Temperatur geregelt wurde. Egal...hat ja nur ein halbes Jahr gedauert.... :rolleyes:
Das AST2050-IPMI dazu ist aber auch arg beschissen beschnitten, sodass mans nicht manuell geregelt bekommt. Werde dazu denke ich mal noch einen anderen Thread öffnen.

Er hat leider keine Luftführung, aber vier Gewaltlüfter (jeweils 3pin an der BP) und der Steckplatz ist genau mittig zum linken Lüfter. Liegt also genau im Strom. Hab zwar nochmal versucht, die Kabel für den flow etwas zurechtzustrapsen und mit zurechtgeschnittenem Karton einen Kanal gebaut, aber es half alles nix. Diese Kühllösung ist aber auch ein Witz, denn als ich die Paste neu auftrug, konnte man sehen, dass der Chip nur 1/4 der Kühlerunterseitenfläche belegt.
Mit dem Noctua auf 3pin gesteckt und daher Vollgas funktionierts jedenfalls. Ich kann nun Steaks und Eier auf dem Blechbereich braten bei nem scrub. Das ist noch nicht optimal und generell kochts im Gehäuse beim stresstest. Gut, im Moment haben wir generell Hitze und ich keinen gekühlten Serverschrank. Zu der Kühllösung werd ich auch noch nen Thread öffnen, da gibts ja diese u-förmigen Luftnachhintenrausbläser oder ich mach kurzen Prozess, säge ein Stück raus und schraube den dicksten Noctua drauf, den es gibt.

So far läufts und das war erstmal die Hauptsache! :)

Wenn die Kiste viel I/O macht, kann man auch über Zweidrittel des RAMs nachdenken. Darüber sollte man aber nicht gehen.
Yeah, danke! Dann lass ich das mal auf 8G und guck mal wie sichs bewährt. :)

Funktioniert das auch in 11.1 so?
Mit Sicherheit, ABER:

Wenn ich den Wert mit sysctl setzen möchte, akzeptiert dies nicht "8G" und ich muss einen Bit-Wert setzen.
Du musst die Kiste dazu neu starten, live mit sysctl setzen ist nicht möglich. ;)
 
Du musst die Kiste dazu neu starten, live mit sysctl setzen ist nicht möglich.
ja klar, er übernimmt den sysctl Wert nicht. Aber ich hatte halt Bedenken, dass er die Syntax grundsätzlich ablehnt.
Ist in der loader.conf drin und wenn/wann ich mal wieder neu starte, sollte das auch wirken.

Danke nochmal für den Hinweis.
 
Ja, ja und nochmals JA! :D:):D Egal, welchen Controller ich reingesteckt hab, ob mit oder ohne Noctua...der überhitzte, weil der Lüfter einfach auf die niedrigste Stufe abhängig der CPU-Temperatur geregelt wurde. Egal...hat ja nur ein halbes Jahr gedauert.... :rolleyes:
Das ist aber auch mal ein richtig schön eklig-widerliches Problem. LSI / Avago / Broadcom könnte da aber auch gerne vernünftige Temperatursensoren verbauen, die einen schön eindeutigen Alarm geben...
 
Find ich auch bzw. sofern überhaupt welche enthalten sind...man findet dazu nichts im Netz. Er hat zwar eine grüne heartbeat-LED, die blinkte aber munter weiter.

Die 2Cent für ne rote schnell blinkende LED an einen Sensor gekoppelt wäre wirklich wünschenswert oder eben ein Piepser.
 
Ich hatte das hier gestern übersehen:
Code:
real memory  = 4294967296 (4096 MB)
avail memory = 4072845312 (3884 MB)
Das wird nun etwas stark vereinfacht, auch auf die Gefahr hin in ##bsdforen.de wieder geschlagen zu werden: Simpel gesagt liegt physischer Speicher von Speicheradresse 0 an aufwärts. Die kleinste Adresse ist also 0, die höchste Adresse ergibt sich aus der Menge des RAMs. Nun gibt es Dinge wie Direct Memory Access (DMA), bei dem Hardwarekomponenten die Adressen, über die man mit ihr kommunziert, auf Speicheradressen mappen. Anstatt umständlich durch das Bussystem zu fummeln, muss die Software nur noch Daten auf diese gemappten Speicheradressen schreiben und sie landen magisch auf den Hardwarekomponenten, wo sie hin sollen. Außerdem gibt es Hardware wie IGPs oder auch das UEFI selbst, die sich RAM für ihre eigenen Zwecke klauen. Das ist "Stolen Memory".

Bei DMA kommt es nun drauf an. Ein 32 Bit System kann erstmal nur 2^32 Speicheradressen - also 4 Gigabyte RAM - ansprechen. Wenn man die 4 Gigabyte voll belegt hat, müssen diese DMA-Bereiche über den RAM gemappt werden. Es gibt halt nicht mehr Speicheradressen. In diesem Fall wird RAM verdeckt, er ist verloren. "avail memory" sinkt dadurch. Ein 64 Bit System hat 2^64 Speicheradressen, man kann die DMA-Bereiche also einfach abseits des normalen RAMs mappen. Dadurch entstehen weitere Speicheradressen, "real memory" steigt. Allerdings gibt es dort draußen immer noch jede Menge Hardware-Komponenten, die ihre DMA-Bereiche innerhalb der ersten 2^32 Speicheradressen haben müssen. In diesem Fall bringt das 64 Bit System gar nichts, es wird wieder RAM überdeckt und "avail memory" sinkt. Stolen Memory senkt "avail memory" immer.

In der Praxis ist daher "avail memory" immer kleiner als "real memory" und "real memory" liegt in etwa in den Dimensionen des physischen RAMs. Wenn man Systeme mit sehr großen DMA-Bereichen hat, kann sich schon mal "real memory" um Gigabytes größer als der physische RAM ergeben. Mein unvergessener und nun als TV-Bank missbrauchter Dual-Socket Opteron 265 hatte das zum Beispiel extrem. Und ich glaube, dass FreeBSD bei einem Verbose Boot die genaue Speicherbelegung mit allen Mappings anzeigt.

EDIT: Ich war mit "avail memory" und "real memory" durcheinandergekommen. Es ist warm.
 
Wie immer sehr ausführliche Erklärung von dir, vielen Dank!

Schadet auch gar nicht, wenn man mal sein altes Schulwissen nochmal aufgefrischt bekommt und das dann auch mal in der Praxis erneut vor den Füßen hat. :)
 
ein wenig detaillierter kannst du dir deinen Speicher mit dem angehängten Script ansehen, das ich mal irgendwo runter geladen hatte und immer noch recht interessant finde.
Und weil ich das neulich erst gebraucht hatte, nenne ich gerade auch dmidecode, das ganz gute Information über die HW liefert. Manchmal nützlich, diese Dinge im Hinterkopf zu haben.
 

Anhänge

  • freebsd-memory.txt
    5,3 KB · Aufrufe: 336
Danke dir! Werds mir aber vorher im Editor mal ansehen, blind starten werde ich das nicht. :)
Sieht ganz gut aus, werds mal als Befehlssammlung wegsichern, ist ja schnieke dokumentiert.

Ansonsten: Ich hab mir den dicksten Noctua bestellt. 20x20cm und somit werd ich ein Loch in das Gehäuse sägen. Bilder folgen, sobald es vollbracht ist. :)
 
Danke dir! Werds mir aber vorher im Editor mal ansehen, blind starten werde ich das nicht. :)
Sieht ganz gut aus, werds mal als Befehlssammlung wegsichern, ist ja schnieke dokumentiert.

Ja klar. Und eigentlich ist es auch nur eine Sammlung der passenden sysctl-Aufrufe, die man genauso gut auch manuell eingeben kann.
 
Wie angedroht, die Bilder vom Ergebnis ;). Mein Kumpel hat das Loch rund geschnitten, er meinte damit sei der Sog besser.

Ich hab ihn sorum montiert, dass er rausbläst, also nach oben. Der CPU-Lüfter bläst weiterhin nach unten. Ist nicht so pralle, wenn die sich gegenseitig die Luft wegziehen oder?

Bei nem scrub ist die max. CPU-Temperatur jetzt immerhin nur noch 62° statts 69° wie vorher.
Was meint ihr...soll ich den Noctua reinpusten lassen oder nur den CPU-Lüfter umdrehen, damit beide nach oben pusten?

idle hab ich jedenfalls das (FRONT_FAN3 ist der dicke Noctua):

Code:
ipmitool sensor
P_VDD            | 0.920      | Volts      | ok    | na        | 0.752     | na        | na        | 1.440     | na        
P_VDDNB          | 1.208      | Volts      | ok    | na        | 1.056     | na        | na        | 1.344     | na        
P_VDDIO          | 1.528      | Volts      | ok    | na        | 1.320     | na        | na        | 1.680     | na        
VDD_RD890_1_1.1V | 1.104      | Volts      | ok    | na        | 0.968     | na        | na        | 1.232     | na        
VDD_RD890_1.8V   | 1.824      | Volts      | ok    | na        | 1.584     | na        | na        | 2.016     | na        
P12V             | 12.192     | Volts      | ok    | na        | 10.560    | na        | na        | 13.440    | na        
VCC5V            | 5.088      | Volts      | ok    | na        | 4.392     | na        | na        | 5.592     | na        
CPU_VLDT         | 1.184      | Volts      | ok    | na        | 1.056     | na        | na        | 1.344     | na        
VDD_3.3V         | 3.312      | Volts      | ok    | na        | 2.904     | na        | na        | 3.696     | na        
VDD_3.3_DUAL     | 3.288      | Volts      | ok    | na        | 2.904     | na        | na        | 3.696     | na        
VBAT             | 3.264      | Volts      | ok    | na        | 2.808     | na        | na        | 3.576     | na        
CPU0 MOS Area    | 48.000     | degrees C  | ok    | na        | na        | na        | na        | 105.000   | na        
Ambient          | na         |            | na    | na        | na        | na        | na        | 46.000    | na        
SR5670 Temp      | 56.000     | degrees C  | ok    | na        | na        | na        | na        | 100.000   | na        
SAS Temp         | na         |            | na    | na        | na        | na        | na        | 110.000   | na        
PCIE Air Inlet   | 43.000     | degrees C  | ok    | na        | na        | na        | na        | 60.000    | na        
CPU Temp         | 30.000     | degrees C  | ok    | na        | na        | na        | na        | 70.000    | na        
CPU FAN          | 4200.000   | RPM        | ok    | na        | 1080.000  | na        | na        | na        | na        
FRONT_FAN1       | 2040.000   | RPM        | ok    | na        | 1800.000  | na        | na        | na        | na        
FRONT_FAN2       | 2040.000   | RPM        | ok    | na        | 1800.000  | na        | na        | na        | na        
FRONT_FAN3       | 360.000    | RPM        | ok    | na        | 240.000   | na        | na        | na        | na        
FRONT_FAN4       | 2040.000   | RPM        | ok    | na        | 1800.000  | na        | na        | na        | na        
REAR_FAN1        | 3240.000   | RPM        | ok    | na        | 3000.000  | na        | na        | na        | na        
REAR_FAN2        | 5040.000   | RPM        | ok    | na        | 4560.000  | na        | na        | na        | na
 

Anhänge

  • 1.jpg
    1.jpg
    81,2 KB · Aufrufe: 361
  • 2.jpg
    2.jpg
    80 KB · Aufrufe: 369
  • 3.jpg
    3.jpg
    86,8 KB · Aufrufe: 380
Zurück
Oben