Jemand eine Idee wie ich es debugge, dass ein #zfs Pool irgendwie extrem langsam ist in #freenas ?
dedup ist an, aber cpu und ram auslastung geht laut top 🤷‍♂️ selbst das löschen einer datei dauerte grad ewig und die hatte 0 byte...
in dmesg hab ich meldungen wie diese:
(0:8:0/6): WRITE(10). CDB: 2a 00 64 92 9f 50 00 0a 00 00
(0:8:0/6): Tag: 0xfe380d75, type 1
(0:8:0/6): ctl_process_done: 635 seconds

das ist das einzig auffällige grade.
vllt dedup schuld?
#hilfe #serveradmin #sysadmin

@alex Ich würde 3 Dinge prüfen. Wie voll ist das zfs? Den langen SMART Test auf allen Geräten des zpool laufen lassen. Lesegeschwindigkeit der Blockgeräte des zpool.

@txt_file
@tokudan
pool ist leer und relativ frisch.
die Festplatten sind auch recht neu und haben grade einen langen SMART lauf hinter sich.
das system war unnutzbar ich konnte den server nach stunden mal neustarten.

so wie es aussieht verträgt sich vermutlich dedup und iscsi nicht. jetzt läuft es zumindest erst mal ohne dedup.

ist echt super wenn die erste erfahrung mit dedup direkt so kacke ist, jetzt werde ich das sicher nicht mehr irgendwo einschalten wollen :D

@alex @txt_file dedup ist sowieso ein ZFS feature das man nur sehr selektiv aktivieren sollte. Das ist für server gedacht mit vielen GB RAM und entsprechendem ZFS arc.

@tokudan
Das stimmt. Hatte es auch nur selektiv bei dem pool und dem Server aktiviert. Dachte eigentlich 32gb könnte reichen bei 2Stk. 14TB platten im RAID 1. hab nicht mit so katastrophalen Nebenwirkungen gerechnet.
Komisch war auch, dass es erst mal lief bis ich so 170Gb per iscsi über tragen habe, danach kam der so massiv ins stocken und auch ein Neustart half da nicht so richtig.
Eventuell erklärt das auch die Probleme mit den RaspberryPis die per iscsi ihre platte hatten.
@txt_file

@alex @txt_file ZFS dedup hat für jeden block eine checksum im arc. Wenn die nicht im ram sind, werden sie mühsam von der Platte geladen. Wenn die Platten dann hohe Latenz haben ist das fatal. Mach mal

# zpool iostat -w 5

Und achte mal was da für Werte auftauchen.

@alex @txt_file ein reboot ist aus der Sicht dann sogar ein Nachteil, weil dadurch der arc geleert wird und erst wieder neu aufgebaut werden muss.

@alex @txt_file ZFS checksums für ca. 170 GB an Daten sind übrigens etwa 5 GB RAM, wenn ich die Zahlen noch richtig im Kopf hab. Kann also sein, dass du da grade über die Größe deines arcs rüber bist. Kannst du mit arcstat.pl mal prüfen.

@tokudan also falls arcstat das gleiche ist wie arcstat.ph, dann wäre die ausgabe aktuell auf dem nas server:

@alex size und c sind die interessanten Werte. Dein arc ist 24GB groß.

Follow

@alex kann sein, dass meine Rechnung mit dem 5gb arc pro 170gb Daten blödsinn war.

@tokudan möglich. ist aber auch nicht so wichtig xD

@alex aber die compression hast du aktiviert, denke ich mal? :)

@tokudan haste auch tiefgreifende ahnung von nginx? xD ich versuche grade schlechteres ssl zu erlauben und der vhost will patu lieber nut tls 1.3 mit 4 ciphern anbieten.

Sign in to participate in the conversation
chaos.social

chaos.social – a Fediverse instance for & by the Chaos community