SSD Optimierungen - Versionsgeschichte

Revealed: /* Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs. */

2015-09-14T18:17:29Z

‎Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs.

Revealed: /* Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs. */

2015-09-12T22:30:01Z

‎Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs.

Gehrke: Weiterführende Links

2014-03-01T09:23:37Z

Weiterführende Links

TomcatMJ: Änderung 30656 von Gehrke (Diskussion) rückgängig gemacht. Es geht 1. nicht um GrUB Legacy im Artikel und 2. ist im Abschnitt wo sich was auf GrUB 1 bezieht auch GrUB 2 erwähnt->überflüssig

2013-12-09T19:51:31Z

Änderung 30656 von Gehrke (Diskussion) rückgängig gemacht. Es geht 1. nicht um GrUB Legacy im Artikel und 2. ist im Abschnitt wo sich was auf GrUB 1 bezieht auch GrUB 2 erwähnt->überflüssig

Gehrke: Hinweis auf GRUB Legacy

2013-12-09T17:26:12Z

Hinweis auf GRUB Legacy

TomcatMJ: /* MySQL Binary-Logging abschalten */ <- Kategorie hinzugefügt weil es stark Hardwareorientiert ist

2013-11-18T15:19:52Z

‎MySQL Binary-Logging abschalten: <- Kategorie hinzugefügt weil es stark Hardwareorientiert ist

Norritt: /* Scheduling für ssds anpassen: */

2013-08-20T22:31:43Z

‎Scheduling für ssds anpassen:

Robi: Kategorie korrektur, Typo, intern ins Glosar verlinkt

2013-08-16T23:51:44Z

Kategorie korrektur, Typo, intern ins Glosar verlinkt

Norritt am 14. August 2013 um 16:27 Uhr

2013-08-14T16:27:12Z

Norritt: Die Seite wurde neu angelegt: „
==Einleitung== Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei …“

2013-08-14T16:24:05Z

Die Seite wurde neu angelegt: „ ==Einleitung== Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei …“

Neue Seite

==Einleitung==
Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei Einstatz von SSDs im Vergleich zu HDDs eine wesentlich höhere Performance erreicht werden. Flashspeicher unterliegt jedoch stärkeren Alterungsprozessen als mechanische Festplatten, er kann nur begrenzt neu beschrieben werden. Durch ausgeklügelte Algorithmen wie Wear-Leveling haben aktuelle SSDs bereits von Haus aus eine recht hohe Lebenserwartung. Dennoch ist eine Reduktion unnötiger Schreibzugriffe der Lebensdauer von SSDs zuträglich. Nachfolgend werden einige Maßnahmen beschrieben, die die Schreibzugriffe reduzieren und die Performance verbessern können:



==Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs.==

Hierzu muss in der Datei /etc/fstab für alle auf einer SSD gelagerten Partitionen die mountoption "relatime" durch "noatime" ersetzt werden
* '''relatime:''' bei jedem Dateizugriff wird der Zeitpunkt des letzten Zugriffs auf den Datenträger geschrieben
* '''noatime:''' tut dies nicht

Trim aktivieren. Die meisten aktuellen SSDs unterstützen die TRIM Funktion. TRIM ist bei opensuse standardmäßig nicht aktiviert. Es kann durch Hinzufügen der Option "discard" in den Mountoptionen der auf der SSD eingerichteten Partitionen aktiviert werden.

'''Beispiel:'''
<pre>
/dev/disk/by-id/my_shiny_new_ssd-part3 / ext4 discard,acl,user_xattr,noatime 1 1
</pre>

==Scheduling für ssds anpassen:==
Diverse Quellen im Internet berichten, dass der deadline, bzw. noop Scheduler Perfomanceverbesserungen gegenüber dem CFQ (Completely Fair Queuing) Scheduler bei Einsatz von SSD Laufwerken bringen kann. Zwei Möglichkeiten den Scheduler permanent zu ändern sind, entweder über ein Kernelparameter im Bootloader oder via eines Regelsatzes für udev. Letzterer Variante ist der Vorzug zu geben, da sich der Bootparameter auf alle Laufwerke auswirkt und somit, sollte noch zusätzlich zur SSD herkömmliche mechanische Festplatten verbaut sein, diese dann auch das für sie ungünstigere Queing vom Kernel aufdiktiert bekommen. Die udev Variante sollte für jedes Laufwerk automatisch korrekt erkennen, ob es sich um eine (mechanische) HDD oder sine SSD handelt. Der Vollständigkeit halber führe ich hier beide Varianten auf, rate aber dazu Variante 2 zu verwenden

1. Setzen der Bootoption "elevator" für alle Laufwerke (NICHT empfohlen)
::Für GRUB:
::* /boot/grub/menu.lst öffnen
::* In der "kernel" Zeile die Option "elevator=noop" oder elevator="deadline" anfügen (Beispielueile: "kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop"
::Für GRUB2:
::* /etc/grub/default öffnen
::* "GRUB_CMDLINE_LINUX" suchen und die den Wert "elevator=noop" oder "elevator=deadline" anfügen. (Beispielzeile: GRUB_CMDLINE_LINUX_DEFAULT="video=1920x1080 splash=silent quiet showopts elevator=noop")

2. Erstellen eines udev scripts:
::* in das Verzeichnis /etc/udev/rules.d/ wechseln
::* eine neue Datei mit hoher, unbenutzter Prioritätsnummer anlegen:
:::touch 60-disk-scheduling.rules
:::chmod 644 60-disk-scheduling.rules
::* Die Datei "60-disk-scheduling.rules" im editor öffnen und folgenden Inhalt eintragen:

<pre># set deadline scheduler for non-rotating disks (may slightly improve SSD perfomrance)
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

# set cfq scheduler for rotating disks (for rotating HDDs)
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
</pre>

:* Änderungen speichern und Datei schliessen.
:* Beim nächsten Reboot sollten die Änderungen automatisch übernommen werden.

P.S.: In meinem Fall (SanDisk SSD mit SanDisk Controller) konnte ich praktisch keine Unterschiede durch verändertes Scheduling festestellen, d.h. durch Änderung des Schedulers ergaben sich weder Performanceverbesserungen noch -einbußen. Bei anderen SSDs (in der Regel sind Marvel Controller verbaut) kann dies durchaus anders aussehen. Ob diese Maßnahme für eine bestimmte SSD sinvoll ist, läßt sich am einfachsten mit der Durchführung von Benchmarks unter Einsatz der verschiedenen Scheduler belegen.

Um zu überprüfen, welcher Scheduler gerade aktiv ist, kann folgendes Kommando verwendet werden, wobei "sdX" durch den Blockdevicenamen der abzufragenden Platte zu ersetzen ist z.B. "sda":
<pre>cat /sys/block/sdX/queue/scheduler</pre>

Die Ausgabe könnte wie folgt aussehen:
<pre>noop deadline [cfq]</pre>
Der Eintrag in eckigen Klammern ist das aktuell aktive Setting. Dieses kann auch ohne reboot on the fly verändert werden, durch folgendes Kommando (auch hier wieder sdX ersetzen):
<pre>echo deadline > /sys/block/sdX/queue/scheduler</pre>
Erneute Abfrage des Schedulestatus:
<pre>cat /sys/block/sdX/queue/scheduler</pre>
Die Ausgabe zeigt nun das deadline aktiv ist:
<pre>noop [deadline] cfq</pre>

==Datenbankcheckpointingintervall von cyrus imap vergrössern:==
Falls auf dem System ein Cyrus-IMAP-Server betrieben wird, dessen Datenbank auf der SSD liegt, können die Schreibzugriffe durch Vergrößerung des Checkpointingintervals reduziert werden. In der Datei /etc/cyrus.conf den Eintrag "checkpoint" suchen und den Wert der Option "period" verändern, Standard ist 30 Minuten:

<pre>checkpoint cmd="ctl_cyrusdb -c" period=30</pre>

==MySQL Binary-Logging abschalten==
Wird auf dem Rechner ein MySQL Server betrieben, der nicht Teil eines Clusters ist, empfiehlt es sich das Binärlogging abzuschalten. Hierdurch wird Speicherplatz gespart und durch Reduzierung der Schreibzugriffe die Lebensdauer der SSD erhöht. Zur Deaktivierung sind folgende Schritte durchzuführen:
:*Öffnen der /etc/my.cnf
:*auskommentieren der Zeile "log-bin=mysql-bin"
:*Neustart des MySQL Servers via "rcmysql restart"

@@ Zeile 19: / Zeile 19: @@
 '''Weitere umsetzungsmöglichkeiten für Trim:'''
-* [[http://linux-club.de/wiki/opensuse/Systemd#Tipp:_weekly_trim_durch_systemd Tipp: weekly trim durch systemd]]
+* [[Systemd#Tipp:_weekly_trim_durch_systemd|Tipp: weekly trim durch systemd]]
 </p>

@@ Zeile 70: / Zeile 70: @@
 :*auskommentieren der Zeile "log-bin=mysql-bin"
 :*Neustart des MySQL Servers via "rcmysql restart"
 [[Kategorie:Partitionen]]
 [[Kategorie:Hardware]]

← Nächstältere Version		Version vom 9. Dezember 2013, 19:51 Uhr
Zeile 1:		Zeile 1:
−	{{Achtung\|'''Hinweis:''' Dieser Artikel handelt explizit von der Version ''GRUB Legacy''. Das Programm wurde weiterentwickelt. Die Weiterentwicklung wird aufgrund von Inkompatibilitäten auf einer eigenen Seite behandelt: [[GRUB 2]]}}
−
−
	<p>		<p>
	==Einleitung==		==Einleitung==

← Nächstältere Version		Version vom 9. Dezember 2013, 17:26 Uhr
Zeile 1:		Zeile 1:
		+	{{Achtung\|'''Hinweis:''' Dieser Artikel handelt explizit von der Version ''GRUB Legacy''. Das Programm wurde weiterentwickelt. Die Weiterentwicklung wird aufgrund von Inkompatibilitäten auf einer eigenen Seite behandelt: [[GRUB 2]]}}
		+
		+
	<p>		<p>
	==Einleitung==		==Einleitung==

← Nächstältere Version		Version vom 18. November 2013, 15:19 Uhr
Zeile 71:		Zeile 71:
	:*Neustart des MySQL Servers via "rcmysql restart"		:*Neustart des MySQL Servers via "rcmysql restart"
	[[Kategorie:Partitionen]]		[[Kategorie:Partitionen]]
		+	[[Kategorie:Hardware]]

@@ Zeile 17: / Zeile 17: @@
 /dev/disk/by-id/my_shiny_new_ssd-part3       /                    ext4       discard,acl,user_xattr,noatime 1 1
 </pre>
 </p>
 ==Scheduling für ssds anpassen:==
 Diverse Quellen im Internet berichten, dass der deadline, bzw. noop Scheduler Perfomanceverbesserungen gegenüber dem CFQ (Completely Fair Queuing) Scheduler bei Einsatz von SSD Laufwerken bringen kann. Eines sei vorab gesagt: In meinem Fall (SanDisk SSD mit SanDisk Controller) konnte ich praktisch keine Unterschiede durch verändertes Scheduling festestellen, d.h. durch Änderung des Schedulers ergaben sich weder Performanceverbesserungen noch -einbußen. Bei anderen SSDs (in der Regel sind Marvel Controller verbaut) kann dies durchaus anders aussehen. Ob diese Maßnahme für eine bestimmte SSD sinnvoll ist, läßt sich am einfachsten mit der Durchführung von Benchmarks unter Einsatz der verschiedenen Scheduler belegen, und ist vielleicht für die experimentierfreudigen unter euch interessant. Alle anderen sind wahrscheinlich am besten beraten die Schedulingeinstellungen unangetastet zu lassen.

@@ Zeile 19: / Zeile 19: @@
 </p>
 ==Scheduling für ssds anpassen:==
-Diverse Quellen im Internet berichten, dass der deadline, bzw. noop Scheduler Perfomanceverbesserungen gegenüber dem CFQ (Completely Fair Queuing) Scheduler bei Einsatz von SSD Laufwerken bringen kann. Zwei Möglichkeiten den Scheduler permanent zu ändern sind, entweder über ein Kernelparameter im Bootloader oder via eines Regelsatzes für udev. Letzterer Variante ist der Vorzug zu geben, da sich der Bootparameter auf alle Laufwerke auswirkt und somit, sollte noch zusätzlich zur SSD herkömmliche mechanische Festplatten verbaut sein, diese dann auch das für sie ungünstigere Queing vom Kernel aufdiktiert bekommen. Die udev Variante sollte für jedes Laufwerk automatisch korrekt erkennen, ob es sich um eine (mechanische) HDD oder sine SSD handelt. Der Vollständigkeit halber führe ich hier beide Varianten auf, rate aber dazu Variante 2 zu verwenden
+Diverse Quellen im Internet berichten, dass der deadline, bzw. noop Scheduler Perfomanceverbesserungen gegenüber dem CFQ (Completely Fair Queuing) Scheduler bei Einsatz von SSD Laufwerken bringen kann. Eines sei vorab gesagt: In meinem Fall (SanDisk SSD mit SanDisk Controller) konnte ich praktisch keine Unterschiede durch verändertes Scheduling festestellen, d.h. durch Änderung des Schedulers ergaben sich weder Performanceverbesserungen noch -einbußen. Bei anderen SSDs (in der Regel sind Marvel Controller verbaut) kann dies durchaus anders aussehen. Ob diese Maßnahme für eine bestimmte SSD sinnvoll ist, läßt sich am einfachsten mit der Durchführung von Benchmarks unter Einsatz der verschiedenen Scheduler belegen, und ist vielleicht für die experimentierfreudigen unter euch interessant. Alle anderen sind wahrscheinlich am besten beraten die Schedulingeinstellungen unangetastet zu lassen.
 . Setzen der Bootoption "elevator" für alle Laufwerke (NICHT empfohlen)
@@ Zeile 46: / Zeile 48: @@
 :* Beim nächsten Reboot sollten die Änderungen automatisch übernommen werden.
 Um zu überprüfen, welcher Scheduler gerade aktiv ist, kann folgendes Kommando verwendet werden, wobei "sdX" durch den Blockdevicenamen der abzufragenden Platte zu ersetzen ist z.B. "sda":
 <pre>cat /sys/block/sdX/queue/scheduler</pre>

@@ Zeile 1: / Zeile 1: @@
 <p>
 ==Einleitung==
-Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei Einstatz von SSDs im Vergleich zu HDDs eine wesentlich höhere Performance erreicht werden. Flashspeicher unterliegt jedoch stärkeren Alterungsprozessen als mechanische Festplatten, er kann nur begrenzt neu beschrieben werden. Durch ausgeklügelte Algorithmen wie Wear-Leveling haben aktuelle SSDs bereits von Haus aus eine recht hohe Lebenserwartung. Dennoch ist eine Reduktion unnötiger Schreibzugriffe der Lebensdauer von SSDs zuträglich. Nachfolgend werden einige Maßnahmen beschrieben, die die Schreibzugriffe reduzieren und die Performance verbessern können:
+Im Vergleich zu mechanischen [[Hilfe:Glossar#H|HDDs]] arbeiten [[Hilfe:Glossar#S|SSDs]] rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei Einstatz von SSDs im Vergleich zu HDDs eine wesentlich höhere Performance erreicht werden. Flashspeicher unterliegt jedoch stärkeren Alterungsprozessen als mechanische Festplatten, er kann nur begrenzt neu beschrieben werden. Durch ausgeklügelte Algorithmen wie Wear-Leveling haben aktuelle SSDs bereits von Haus aus eine recht hohe Lebenserwartung. Dennoch ist eine Reduktion unnötiger Schreibzugriffe der Lebensdauer von SSDs zuträglich. Nachfolgend werden einige Maßnahmen beschrieben, die die Schreibzugriffe reduzieren und die Performance verbessern können:
 </p>
@@ Zeile 34: / Zeile 34: @@
 :::touch 60-disk-scheduling.rules
 :::chmod 644 60-disk-scheduling.rules
-::* Die Datei "60-disk-scheduling.rules" im editor öffnen und folgenden Inhalt eintragen:
+::* Die Datei "60-disk-scheduling.rules" im Editor öffnen und folgenden Inhalt eintragen:
 <pre># set deadline scheduler for non-rotating disks (may slightly improve SSD perfomrance)
@@ Zeile 46: / Zeile 46: @@
 :* Beim nächsten Reboot sollten die Änderungen automatisch übernommen werden.
-P.S.: In meinem Fall (SanDisk SSD mit SanDisk Controller) konnte ich praktisch keine Unterschiede durch verändertes Scheduling festestellen, d.h. durch Änderung des Schedulers ergaben sich weder Performanceverbesserungen noch -einbußen. Bei anderen SSDs (in der Regel sind Marvel Controller verbaut) kann dies durchaus anders aussehen. Ob diese Maßnahme für eine bestimmte SSD sinvoll ist, läßt sich am einfachsten mit der Durchführung von Benchmarks unter Einsatz der verschiedenen Scheduler belegen.
+P.S.: In meinem Fall (SanDisk SSD mit SanDisk Controller) konnte ich praktisch keine Unterschiede durch verändertes Scheduling festestellen, d.h. durch Änderung des Schedulers ergaben sich weder Performanceverbesserungen noch -einbußen. Bei anderen SSDs (in der Regel sind Marvel Controller verbaut) kann dies durchaus anders aussehen. Ob diese Maßnahme für eine bestimmte SSD sinnvoll ist, läßt sich am einfachsten mit der Durchführung von Benchmarks unter Einsatz der verschiedenen Scheduler belegen.
 Um zu überprüfen, welcher Scheduler gerade aktiv ist, kann folgendes Kommando verwendet werden, wobei "sdX" durch den Blockdevicenamen der abzufragenden Platte zu ersetzen ist z.B. "sda":
@@ Zeile 70: / Zeile 70: @@
 :*auskommentieren der Zeile "log-bin=mysql-bin"
 :*Neustart des MySQL Servers via "rcmysql restart"
-[[Kategorie:Partition]]
+[[Kategorie:Partitionen]]

← Nächstältere Version		Version vom 14. August 2013, 16:27 Uhr
Zeile 70:		Zeile 70:
	:*auskommentieren der Zeile "log-bin=mysql-bin"		:*auskommentieren der Zeile "log-bin=mysql-bin"
	:*Neustart des MySQL Servers via "rcmysql restart"		:*Neustart des MySQL Servers via "rcmysql restart"
		+	[[Kategorie:Partition]]

SSD Optimierungen - Versionsgeschichte

Revealed: /* Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs. */

Revealed: /* Verringern der Schreibzugriffe, durch abschalten der Aktualisierung des Zeitpunkts des letzten Dateizugriffs. */

Gehrke: Weiterführende Links

TomcatMJ: Änderung 30656 von Gehrke (Diskussion) rückgängig gemacht. Es geht 1. nicht um GrUB Legacy im Artikel und 2. ist im Abschnitt wo sich was auf GrUB 1 bezieht auch GrUB 2 erwähnt->überflüssig

Gehrke: Hinweis auf GRUB Legacy

TomcatMJ: /* MySQL Binary-Logging abschalten */ <- Kategorie hinzugefügt weil es stark Hardwareorientiert ist

Norritt: /* Scheduling für ssds anpassen: */

Robi: Kategorie korrektur, Typo, intern ins Glosar verlinkt

Norritt am 14. August 2013 um 16:27 Uhr

Norritt: Die Seite wurde neu angelegt: „ ==Einleitung== Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei …“

Norritt: Die Seite wurde neu angelegt: „
==Einleitung== Im Vergleich zu mechanischen HDDs arbeiten SSDs rein elektronisch, die Datenspeicherung erfolgt auf Flash-Speicherchips. Hierdurch kann bei …“