Technik-Tipps für Systemadministratoren

    Hallo,


    mit diesem Thema möchte ich eine kleine Sammlung von Technik-Tipps für Systemadministratoren starten.

    Ich bitte darum Antworten - sofern sie keine Tipps sind - kurz und technisch zu halten.



    Dann fange ich mal an...

    Wie wir hoffentlich alle wissen leiden SSDs unter Leistungsverlust, wenn im Dateisystem Dateien verkleinert oder gelöscht werden. Das hat auch negative Auswirkungen auf die Lebensdauer der Flash-Zellen.
    Abhilfe schafft der "neue" ATA-Befehl TRIM, welche das Betriebssystem an den SSD-Controller schickt, um der SSD mitzuteilen, welche Blöcke verworfen (discarded) und für das Neubeschreiben vorbereitet werden können.


    Zuerst schauen wir, ob unsere SSDs TRIM unterstützen. Hier steht DISC für discard und Werte > 0 deuten auf Unterstützung hin:

    Code
    1. $ lsblk --discard
    2. NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
    3. sda 0 4K 1G 0
    4. ├─sda1 0 4K 1G 0
    5. └─sda2 0 4K 1G 0
    6. sr0 0 0B 0B 0


    Moderne Linux-Distributionen bieten einen entsprechenden systemd service und systemd timer oder cron job:

    Code
    1. # systemctl enable fstrim.timer
    3. $ systemctl list-timers
    4. NEXT LEFT LAST PASSED UNIT ACTIVATES
    5. Mon 2019-09-02 00:00:00 CEST 1 day 2h left n/a n/a fstrim.timer fstrim.service



    Man kann den service auch manuell starten:

    Code
    1. # systemctl start fstrim.service

    Status/Ergebnis/Log ein paar Sekunden später:

    Code
    1. # systemctl status fstrim.service
    2. ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
    3. Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
    4. Active: inactive (dead) since Sat 2019-08-31 20:59:57 CEST; 28min ago
    5. Docs: man:fstrim(8)
    6. Main PID: 30948 (code=exited, status=0/SUCCESS)
    8. Aug 28 23:47:09 xserv systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
    9. Aug 28 23:47:10 xserv fstrim[25419]: /: 31.5 GiB (33799159808 bytes) trimmed on /dev/sda2
    10. Aug 28 23:47:10 xserv systemd[1]: fstrim.service: Succeeded.



    Neben diesem periodischen TRIM (auch "batch discard") sei auch noch kontinuierliches TRIM (auch "online discard") erwähnt, was jedoch in den meisten Fällen nicht empfohlen wird.

    Dies wird mit der Option "discard" in /etc/fstab oder direkt im Dateisystem aktiviert.

    Mir reicht dazu mit bash das Paket

    Code
    1. bash-completion

    ... dann einfach TAB spammen. 8o



    Es ergibt auch Sinn in seine ~./bashrc häufig verwendete Befehle samt Optionen als Aliase zu definieren, z.B.:

    Code
    1. alias la='ls -lah --color=yes'

    Aber dazu mehr in einem anderen Beitrag...

    whoami0501 wrote:

    Ich weiß nicht ob Command Line Tipps auch mit hier reinzählen... aber ich hätte thefuck im Angebot. ^^

    Der Vollständigkeit halber: Bei Zsh (https://www.zsh.org/) ist das übrigens eine (optionale) Standardfunktion, welche ohne Fluchen funktioniert (nyae = no/yes/abort/edit); daneben gibt es einen Schutz gegen das Löschen unerwartet vieler Dateien usw.:


    zsh_prompt.png


    Lies: Mit ein wenig Eingewöhnungszeit und Studium der umfangreichen Dokumentation kann man sich hier auf der Kommandozeile viel Arbeit ersparen und sehr produktiv arbeiten... das vorgenannte bash-completion kommt dagegen bei Weitem nicht an. Wer noch mehr will, möge einen Blick auf https://github.com/robbyrussell/oh-my-zsh werfen.

    Git pull/commit/push in allen Repositories in Unterordnern parallel ausführen (ist natürlich nicht auf Git beschränkt, aber gerade zum Pullen benutze ich das gerne ;) )

    Code
    1. ls | sed 's/\/.git//' | xargs -P10 -I{} git -C {} pull
    2. ls | sed 's/\/.git//' | xargs -P10 -I{} git -C {} commit -am "2019-08 blabla"
    3. ls | sed 's/\/.git//' | xargs -P10 -I{} git -C {} push

    Steini Das ergibt für mich keinen Sinn.

    ls gibt nur den Inhalt des aktuellen Ordners aus, und dessen Ausgabe sollte nicht zum Scripten verwendet werden.

    sed sollte unnötig sein, weil wir einfach .. anhängen können.

    Sollte es nicht eher so aussehen?

    Code
    1. find . -type d -name ".git" -print0 -prune | xargs -0 -P10 -I{} git -C "{}/.." pull

    Nächster Tipp: einfache Systemüberwachung mit glances.


    Die meisten Distros bieten ein gleichnamiges Paket an. Also mit Paketmanager installieren und starten:

    Code
    1. $ glances

    So sieht es dann im Terminal aus:

    screenshot-wide2.jpg



    Sieht auf den ersten Blick wie ein htop gekreuzt mit Funktionen aus dstat aus, bietet jedoch auch eine API, Web-UI, sowie Exportmöglichkeiten.


    Dokumentation: https://glances.readthedocs.io/en/latest/

    Nächster zufälliger Tipp bezügl. PHP-Performance: Opcache.

    Zuerst einmal sollte eine aktuelle PHP-Version laufen. 7.1 wird schon nicht mehr aktiv unterstützt und Sicherheitsupdates werden auch mit 1. Dez 2019 eingestellt.


    Siehe: https://www.php.net/supported-versions.php


    Da PHP eine Skriptsprache ist, muss der Quelltext bei jedem Aufruf neu interpretiert/optimiert/übersetzt werden. Genau da hilft der Opcache, indem er das Ergebnis zwischenspeichert und somit beim nächsten Aufruf all die zuvor genannten Schritte entfallen können.


    Dazu kommt in die php.ini:


    Dann php-fpm oder Apache oder was auch immer ihr verwendet neu starten.


    Anschließend kann man sich ein buntes PHP opcache status Skript installieren, wie zB opcache-gui, oder man macht einfach folgendes in eine php Datei:

    PHP
    1. <!DOCTYPE html>
    2. <html lang="en">
    3. <head><meta charset="utf-8" /><title>opcache status</title></head>
    4. <body><pre><?php var_dump(opcache_get_status(true)); ?></pre></body>
    5. </html>


    Dort sieht man dann ob der opcache aktiviert ist (opcache_enabled), Speichernutzung (used_memory), Trefferrate (opcache_hit_rate), sowie eine Liste aller Dateien, die im opcache liegen.