| Hootch | mir noch ein whiskey holen oder so :D | 00:00 |
|---|---|---|
| k1l | jo das meinte ich mit "in ruhe". also mit vorbereitung, je nachdem was auf der kiste alles läuft | 00:00 |
| k1l | weil mit knapp 3 jahren seit release werden die baustellen jetzt eher mehr werden von den anforderungen was updates bei den services wollen | 00:01 |
| Hootch | oja, systemupgrade .. immer wieder eine freude | 00:03 |
| === eTeddy1 is now known as eTeddy | ||
| ShiroNeko | morgen. nutzt hier jemand mysql auf einem btrfs? wenn ja was kann ich machen um da eine ordentliche schreibperformance zu bekommen? aktuell schafft der nur ~250inserts/s. | 09:54 |
| ShiroNeko | System ist Ubuntu 20.04. Anderer Server mit xfs macht aktuell 1200inserts/s | 09:54 |
| ShiroNeko | mysql-settings sind dieselben | 09:54 |
| LupusE | das ist etwas speziell fuer diesen channel. | 09:55 |
| ShiroNeko | LupusE: vielleicht reichen ja schon mountoptionen für btrfs | 09:55 |
| LupusE | vielleicht. das wissen aber MqSQL oder btrfs Leute eher als die anwender hier im channel. | 09:57 |
| k1l | gibt ja leute, die hier ubuntu auch im server umfeld einsetzen. aber ob die gerade alle hier reingucken ist die frage. ShiroNeko könntest auch mal in englisch in #ubuntu fragen oder du schreibst einen post ins Forum auf ubuntuusers.de | 09:59 |
| LupusE | oder google. aber wenn ich das fuer dich google, dann hab eich damit natuerlich keine erfahrungen ... https://kudzia.eu/b/2017/12/mysql-on-btrfs/ | 10:01 |
| le_bot | Title: MySQL on BTRFS? – .pQd's log (at kudzia.eu) | 10:01 |
| Heavy91 | ShiroNeko: Für MySQL/MariaDB mit InnoDB gilt generell, dass ext4 und xfs die beste Wahl für hohe Performance sind. Der kritische Punkt bei Schreibtransaktionen sind sequentielle Schreibzugriffe auf die beiden iblogfile* Dateien. BtrFS und ZFS haben ihre Stärken eher bei parallelen Zugriffen. | 10:01 |
| stevieh | wenn ich snapshots von DBs haben will, sollte ich da nicht eher die DB mit "beauftragen" als ein Layer darunter, dass gar nix von weiss? | 10:21 |
| apollo13 | depends :D | 10:21 |
| apollo13 | normalerweise fährt man zweistufig | 10:21 |
| apollo13 | sql dump für disaster recovery | 10:22 |
| apollo13 | fs snapshot (mit support aus der db) für performantes recovery | 10:22 |
| apollo13 | für postgres gilt zum beispiel (und sollte eigentlich für jede db gelten), dass ein snapshot (sofern atomar erfolgt) es der datenbank erlauben sollte zu recovern | 10:23 |
| apollo13 | via write ahead log und freunde | 10:23 |
| Heavy91 | Für das Desaster Recovery würde ich eher xtrabackup / mariabackup einsetzen. Da ist das Recovery viel schneller als bei einem Dump. mysqldump ist gut für logische Backups einzelner Anwendungen. Es erlaubt auch einen Umzug auf eine andere MySQL/MariaDB Version. | 10:24 |
| ShiroNeko | Heavy91: gut, xfs ohne nobarrier performt aber auch eher unterirdisch bei dem ubuntu 20.04 | 10:24 |
| apollo13 | bei desaster recovery geht es nicht mehr um geschwindigkeit | 10:24 |
| ShiroNeko | für backup kommt xtrabackup zum einsatz. also geht hier nicht um backups. ist eher ein performancethema was aktuell mit 20.04 besteht | 10:25 |
| Heavy91 | apollo13: ja, auch bei MySQL kann man konsistente Snapshots erzeugen. Tas Tool mylvmbackup zeigt, wie das geht. | 10:25 |
| apollo13 | Heavy91: das ist mir klar, aber das willst du im desaster nicht. Bzw schon aber dennoch parallel dazu einen normalen SQL dump | 10:26 |
| apollo13 | der Grund ist einfach dass ein binär dump viel frickeliger ist; ein SQL file kannst im notfall noch händisch anpassen | 10:26 |
| Heavy91 | ShiroNeko: Write Barriers sind Pflicht. MySQL stellt ansonsten keine hohen Anforderungen an die Features des Filesystems, aber write barriers und funktionierendes flush sind wichtig. | 10:27 |
| apollo13 | natürlich ist es ideal wenn man ein binäres backup hat für schnelle recovery; aber als einziges backup mittel würde ich es nicht haben wollen | 10:27 |
| ShiroNeko | Heavy91: gut, dann verstehe ich nicht warum ein ubuntu 16.04 mit xfs und nobarrier auf 1200 inserts/s sekunde kommt, ein ubuntu 20.04, egal ob btrfs, ext4 oder xfs ohne nobarrier bei 250 inserts/s rumkrebst | 10:29 |
| ShiroNeko | ist für ein master-master halt schlecht wenn das lag permanent steigt | 10:29 |
| Heavy91 | apollo13: ok, vielleicht habe ich mich missverständlich ausgedrückt. | 10:31 |
| Heavy91 | xtrabackup oder Snapshot sind super, wenn man die komplette MySQL Instanz recovern möchte, aber sehr umständlich, wenn es nur um einzelne Schemata / Anwendungen geht. Also nimmt man sie z.B. nach einem Hardwaredefekt. | 10:31 |
| Heavy91 | Der Dump ist dagegen gut für die einzelnen Anwendungen. Man nimmt sie, bei logischen Fehlern, z.B. wenn der Admin einer Anwendung versehentlich Daten gelöscht hat. Dann recovert man nur das einzelne Schema, nicht die ganze MySQL Instanz. | 10:31 |
| Heavy91 | ShiroNeko: auf der selben Hardware? Und selbe MySQL Version? | 10:31 |
| ShiroNeko | Heavy91: Hardware ist VM, aber specs an sich sind identisch | 10:33 |
| apollo13 | Heavy91: bin ich bei dir, aber als weiteres sicherheitsnetz würde ich dennoch einen vollen sql dump vom cluster auch noch machen | 10:33 |
| Heavy91 | ShiroNeko: VM ist bzgl. Performance leider schwierig zu debuggen. Laufen die VMs auf dem selben Host? Wie stark ist die Hardware überbucht? Was machen andere, gleichzeitig laufende Applikationen? Wo liegt der Storage, über wie viele Spindeln ist er gestriped? Usw. | 10:41 |
| Heavy91 | 250 tx/sec sind für HDDs ein guter Wert, für aktuelle SSDs aber viel zu wenig. | 10:41 |
| ShiroNeko | Heavy91: hardware ist nicht überbucht, host war ein resetup auf derselben hardware mit gleichen specs zu 16.04. darum verstehe ich es ja nicht | 10:43 |
| ShiroNeko | mit 5TB ist die DB auch nicht gerade winzig | 10:43 |
| Heavy91 | ShiroNeko: Wie groß sind deine Inserts? Du solltest erstmal rausfinden, ob es ein IOPS oder Durchsatzproblem ist. | 10:43 |
| ShiroNeko | ich geh aktuell von einem iops-problem aus. wobei nur ext4 und xfs da auf anschlag laufen, btrfs läuft bei ~20% disk utilization | 10:49 |
| tadeus663 | Hallo, ich hab hier UbuntuGnome20.04. Wenn ich die Thumbnailansicht bei Nautilus verwende, ist selbst die größte Einstellung an nem großen Bildschirm noch zu klein. Gibt es evtl. dafür einen funktionieren Tweak damit ich die Thumbnails größer stellen kann? | 12:55 |
| tadeus663 | Ich hab die Antworten hier bei mir versucht, aber leider ohne Erfolg. https://askubuntu.com/questions/539802/nautilus-thumbnails-size-fix | 12:56 |
| le_bot | Title: icons - Nautilus Thumbnails Size Fix - Ask Ubuntu (at askubuntu.com) | 12:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!