Wine: Die SSD schonen

Ihr wollt mit Wine Spiele spielen, aber Eure SSD nicht unnötig belasten? Da könnte man was machen.

Wine: Die SSD schonen

Wer auf Linux Windows Spiele zocken möchte, der kommt um Wine nicht herum. Egal in welcher Form, es ist immer irgendwie beteiligt. Leider bedeutet das auch, daß Eure SSD alleine durchs Loggen von Debuginfos belastet wird. So eine Runde WOW kann da die Lebenszeit der SSD richtig dezimieren:

# grep fixme /var/log/messages |grep „Jun 28“ | grep -c fixme
711541

meint, am 28.Juni wurden ins Logfile 711.541 Zeilen von Wine geschrieben, fast alle mit dem gleichen, leeren Inhalt:

Jun 28 10:08:21 xxx /usr/libexec/gdm-x-session[2227]: 009e:fixme:rawinput:GetRawInputBuffer data (nil), data_size 0x22f7b0, header_size 24 stub!

Von den 711k Logzeilen macht die obige Zeile 708k aus, ohne Mehrwert für den User. Rechnet Euch mal aus, wieviele das übers Jahr sind!

Wie bekommt man das jetzt weg?

Zum Glück ist das einfach in der .desktop Datei vom jeweiligen Wine-Spiel zu lösen(hier WOW):

Ändert die Exec Zeile von so:

Exec=env WINEPREFIX=“/home/<username>/.wine“ /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

in so um:

Exec=env WINEPREFIX=“/home/<username>/.wine“ WINEDEBUG=-all /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

Danach ist Ruhe im Logfile und rsyslogd bzw. journald werden Euch danken, denn:

Jun 28 16:38:51 XXXXXXX rsyslogd[1506]: imjournal: 180769 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:48:52 XXXXXXX rsyslogd[1506]: imjournal: 180635 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:58:58 XXXXXXX rsyslogd[1506]: imjournal: 103949 messages lost due to rate-limiting (20000 allowed within 600 seconds)

das, was grep da gezählt hat, ist nur das, was im Logfile auch angekommen ist. In Wirklichkeit sind da tonnenweise Logzeilen weg gefiltert worden und trotz dessen waren es am Ende noch 711k ! Das müssen mehrere Millionen Zeilen gewesen sein, an nur einem einzigen Tag!

„Warum ist das nicht die Defaulteinstellung?“ würde man zurecht fragen, aber solange nur beim Start mal kurz was wichtiges geloggt wird, ok, aber 708.010x das eine 3D-Routine gefixt werde müßte?? Also da könnte man auch mal über sinnvolleres Loggen nachdenken, oder?

Tip des Tages: Öfters mal Logfiles rotieren

Tomcat Logfiles können lang werden, daher sollte man diese desöftern rotieren.

Ganz unproblematisch ist das beim Tomcat aber nicht, denn im Gegensatz zu PHP Webanwendungen, stehen hier die Sessioninfos im RAM und nicht auf der Platte. Das hat beim Tomcat einen enormen Vorteil, weil der Server deutlich schneller an Infos kommt, als es z.B. PHP kann.

Der Nachteil liegt auf der Hand:  ein Neustart zerstört auch immer die Sessioninformationen. Gerade bei Shops ist das ein Problem. Hier muß die Sessionverwaltung dann auf Datenbanken ausgelagert werden, was bei verteilten Webanwendungen ohnehin gemacht werden muß.

Wo würde man daher das Logrotate ansetzen ?

Wer Serverdienste einsetzt, der braucht auch immer ein Startscript. Tomcat kommt zwar mit seinem eigenen startup.sh daher, aber auf ein klassisches Startscript ala init.d kann man eigentlich nicht verzichten. Hier ein Ausschnitt:

export CATALINA_HOME=/java/tomcat

ulimit -v unlimited -d unlimited -s unlimited -n 20000

PATH=$PATH:/usr/local/bin/

# See how we were called.
case "$1" in
 start)
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;
 stop)
 echo -n "Stopping tomcat : "
 killtomcat
 RETVAL=$?
 echo
 ;;
 status)
 status tomcat
 RETVAL=$?
 ;;
 restart)
 $0 stop
 $0 start
 RETVAL=$?
 ;;
 *)
 echo "Usage: tomcat {start|stop|status|restart}"
 exit 1
esac

exit $RETVAL

und genau hier setzen wir an :

# See how we were called.
case "$1" in
 start)
 echo -n "Rotating Logs : "
 cd /usr/java/apache-tomcat/logs/
 echo "Deleting old files : "
 find . -ctime +100 -name "catalina.out*" -exec rm -fv {} \;
 COUNTER=0
 while [ $COUNTER -lt 99 ]; do
       echo The counter is $COUNTER
       let COUNTER=COUNTER+1
       if [ ! -f "catalina.out.$COUNTER" ]; then
           FILENAME="catalina.out.$COUNTER";
           break;
       fi
 done
 echo "Benutze $FILENAME";
 mv catalina.out $FILENAME
 echo "Compressing Logfile : $FILENAME"
 bzip2 -9 $FILENAME
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;

Dieses Script ist natürlich nur ein Beispiel. Ihr müßt es noch anpassen an Eure Pfade und Präferenzen. Es wird Logfiles löschen, die älter als 100 Tage sind und maximal bis .99 zählen. Das kann je nach Häufigkeit des Starts Eures Tomcats dann eventuell nicht passen. Da müßt Ihr jetzt Eure Erfahrungen für Eurer System berücksichtigen.

Bitte beachtet, daß BZIP2 ein echter Zeitfresser ist, besonders in der Kombination mit 8 GB Logfile und -9 Option. Das packt hier auf einem nicht langsamen Server bereits seit 50 MInuten 😉 Das Ergebnis ist allerdings genial:

catalina.out.5: 53.987:1, 0.148 bits/byte, 98.15% saved, 8.250.838.531 in, 152.828.685 out.

Unter 2 % sind vom Logfile übrig geblieben 🙂

Wer jetzt meint, daß dieser Beitrag den 50 Minuten geschuldet ist, hat recht 😀 War leider ein echter Blocker.