SD Karte Schreibprozesse reduzieren

  • Raspberry 2
    Raspbian-Lite
    Kiosk Modus von Maigrafd https://forum-raspberrypi.de/(http%3A//www.…highlight=kiosk (da wir eine PHP-Slideshow angezeit)
    SD 32GB SanDisk ultra

    Mein Pi soll 24/7/365 laufen. Ob ich ein automatisiertes Ausschalten über Nacht per Zeitschaltuhr einrichte soll/will, weiss ich noch nicht.)
    Nun müssen ja die Schreibvorgänge möglichst reduziert werden, um die Lebensdauer der SD hoch zu halten.

    Ich hab mit iotop nun folgende Auswertungen (01 wenige Minuten / 02 ca. 45 Minuten) erhalten.


    iotop-test-01.jpg

    iotop-test-02.jpg

    Ich bitte um Interpretation der beiden Bilddateien und um Hinweise oder Tipps, wie ich nun die Schreibprozesse verringern kann, damit sich die Chance für ein langes Leben meiner SD erhöht.

  • wend: apt-cache search iotop

    Ceronimo: So wie es aussieht verursachen deine PHP Scripts die meiste Schreiblast. Ohne die Scripts zu kennen/sehen kann man dazu aber keine Verbesserung vorschlagen.


    PS: FAQ => Nützliche Links / Linksammlung => varlog

  • ich nutzte den Befehl: sudo iotop -a

    Dieses leicht angepasste Script läuft auf meiner Webseite: PHP-Slideshow

    Momentan werden ca. 10 Dateien (jpg, gif) angezeigt, insgesamt ca. 2,6MB gross, welche alle 8 Sekunden gewechselt werden.

    Einmal editiert, zuletzt von Ceronimo (15. Januar 2017 um 20:15)

  • Schlanke Lösung wäre folgende:

    Aus einer RamDisk laufen lassen.

    /etc/fstab

    Code
    tmpfs   /tmp    tmpfs   defaults,size=100M   0   0

    Wie oft ändern sich die Bilddateien? (Wo kommen die dann her?)

    Also Pseudocode:

    • @reboot Kopiere den Document Root z.B. nach /tmp/html
    • Ändere in der Webserver-Config den Pfad entsprechend


    Falls die Bilder von extern zugeliefert werden, entweder direkt nach /tmp schreiben lassen oder einen SymLink vom org. Verzeichnis nach /tmp/...

    Mache ich mit Logger-Scripten so, die teilweise mehrmals pro Minute laufen und auf eine API pushen, kein SD-Card Zugriff mehr :bravo2:

    Knut

  • tmpfs ist nicht ramfs , insofern wäre ich vorsichtig tmpfs als ramdisk zu betiteln. tmpfs nutzt in erster linie ram, ja, aber wenn kein ram mehr frei ist wird swap genutzt und wo liegt der swap? genau, auf der sd. ramfs nutzt ausschließlich ram.
    tmpfs für /tmp/ aktiviert man zudem eigentlich über /etc/default/tmpfs


    Ich würde auch erst mal __deets__ Vermutung verfolgen und sofern thumbnails erzeugt werden thumbnails_dir auf ein tmpfs Verzeichnis setzen wie zB /dev/shm/
    Auch könnte php-apc Verbesserung bewirken.

    Allerdings bleibt die Frage offen wie das PHP Script bei ihm aussieht. Ebenso fehlen Infos von wo die Bilder geladen werden, da das phpslideshow.php vorsieht die Dateien über FTP zu laden könnte das auch der Grund für die Schreiblast sein...
    Ggf. ist das PHP Script auch fehlerhaft und verursacht viele "warnings" die alle von apache2 in ein Logfile geschrieben werden...

  • Die Bilddateien werden vom php-script aus einem Unterordner des FTP-Server geladen. (Die Bilder werden teilweise täglich bis wöchentlich von mir manuell geändert.)

    Momentan werden ca. 10 Dateien (jpg, gif) angezeigt, insgesamt ca. 2,6MB gross.
    Die Dateien werden alle 8 Sekunden gewechselt.

    Dieses leicht angepasste Script läuft auf meiner Webseite: PHP-Slideshow

    Thumbnails könnten mit dem Sript zwar erzeugt werden, doch habe ich dies auf OFF gestellt.

    Bezüglich php session werde ich mich später schlau machen und mich wieder melden... --> session.save_path /users/_temp/"mein Name"
    Local und Master sind identisch.
    Linux, php version 5.5.21

    Einmal editiert, zuletzt von Ceronimo (16. Januar 2017 um 08:43)


  • ..., aber mir iotop kann man nix aufrufen (command not found),


    Versuch mal mit:

    Code
    which iotop
    sudo iotop -oPak

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • Wenn "iotop" in /usr/sbin/ liegt, dann ist es nicht im Pfad eines normalen Benutzers.

    Dann hast Du am "PATH" des normalen Benutzers etwas geändert, denn:

    Code
    pi@raspberrypi:~ $ which iotop
    /usr/sbin/iotop

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Danke, es geht nun (aber nur mit sudo) Unter normalem Nutzer Pi kommt command not found. Aber das ist recht so. Jetzt weiss ich ja, wie es geht. War nur verwirrt.
    Automatisch zusammengefügt:
    Bei mir sieht es nun so aus:

    Code
    Total DISK READ:       0.00 B/s | Total DISK WRITE:      22.79 K/s
      TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                    
       40 be/3 root          0.00 B    212.00 K  0.00 %  0.54 % [jbd2/mmcblk0p6-]
    17045 be/4 root          4.00 K      0.00 B  0.00 %  0.00 % python /usr/sbin/iotop -a
     2057 be/4 root          0.00 B    104.00 K  0.00 %  0.00 % rsyslogd -c5
    11678 be/4 pi            0.00 B      8.00 K  0.00 %  0.00 % xbasic test.bas
        1 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % init [2]
        2 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [kthreadd]
        3 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [ksoftirqd/0]


    Automatisch zusammengefügt:
    Das meiste Schreiben kommt wohl vom syslog daemon. Vielleicht kann man den abstellen. (test.bas ist meine Datennahme, das ist soweit OK.)

    Einmal editiert, zuletzt von wend (16. Januar 2017 um 11:29)

  • Man kann den rsyslogd zwar mit pkill -f killen, aber der startet dann wieder via syslog.socket
    Bei mir kommt das meiste geschreibe von [jbd2/mmcblk0p2-] und ich weiss nicht woher, ich habe zum testen schon dhcpd, rsyslogd und syslog.socket ausgeschaltet, trotzdem bin ich jetzt schon bei 6.01 M laut iotop -a
    iotop.jpg


  • Bei mir kommt das meiste geschreibe von [jbd2/mmcblk0p2-] und ich weiss nicht woher, ...


    Das ist das Journaling vom ext4-Dateisystem.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Man könnte ein anderes Filesystem verwenden, aber lohnt das? Dann muss öfters fsck drueberlaufen und das belastet die Karte ja auch. Wenn ich 22kB pro Sekunde habe, dann braucht das 400 Stunden, um einmal die ganze Karte (32GB) zu beschreiben, also 16 Tage. Die SDKarte kann aber 10000 Schreibzyklen, also macht das 168000 Tage oder 400 Jahre, bis die Karte kaputtgeschriben ist. Da sich die Karte ja vielleicht halb füllt kann man das ganze noch durch 2 Teilen, also 200 Jahre Betrieb möglich. Ich sehe da kein Problem.


  • Man könnte ein anderes Filesystem verwenden, ...


    Nicht zwingend, denn man könnte das Journaling für ext4 auch deaktivieren (... wenn man das nicht haben will).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das journaling sollte aber auch nur stattfinden bei schreibzugriffen. Es ist Konsequenz, nicht Ursache.

  • Ein paar Dosierte Schreibzugriffe muss man wohl zulassen, für Datennahme z.B. Man kann auch einen USB-Stick mit den Daten beschreiben, aber der hat dasselbe Problem. Wenn man regelmäßig sehr viele Daten speichert, dann ist eine externe USB Festplatte besser. Aber das kommt bei mir gar nicht vor.
    Den Syslogdaemon könnte man aud /dev/shm umleiten, aber dann macht er auch keinen Sinn mehr.

  • Danke für die Hinweise.

    Zurück zum im Post 1 beschriebenen Problem...

    Mein Problem besteht (Oder irre ich mich diesbezüglich?) darin, dass die Bilddateien aus meiner PHP-Slideshow auf die SD heruntergeladen werden. Da diese Dateien alle 8 Sekunden aktualisiert werden und die ca. 10 Bilder insgesamt 2,5MB gross sind verursacht dies die vielen und grossen Schreibprozesse.

    Bringt varlog von maigrafd in meinem Fall Linderung? (Datenverlust würde keine Rolle spielen, da ich sowieso nur Infos aus dem Web anzeigen möchte.)
    Ich müsste also sie Daten (das wären ja nicht die Log-Dateien), welche aus dem Web geholt werden in den Ram schreiben lassen, funktioniert das?

    Im Kiosk-Modus wird der Cache des Browsers nicht gespeichert. Würde die Aktivierung das Problem entschärfen?

    ((Oder vielleicht (möchte dies aber eigentlich nicht) muss ich das Ganze anders angehen: Pi holt sich Bilder aus dem Internet, prüft ca. alle 5 Minuten und akutalisiert wenn Änderungen vorhanden (neue Datei/gelöschte Datei) die Dateien auf dem Pi und zeigt diese als Lokale Diashow an. Aber würde dies die Schreibprozesse verringern?))

    Bin wirklich froh um Tipps oder Workarounds, da ich befürchte, dass meine SD-Karte so nicht lange halten wird.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!