Enterprise Linux 7 und Oracle-relevante Kernel-Parameter
Für den Betrieb von Oracle Datenbanken unter Linux gilt es einige Kernel-Parameter zu setzen. Oracle listet diese in der jeweiligen Dokumentation pro Version detailliert auf - beispielsweise für die aktuelle Version 12c: [klick mich!]
Speziell für Enterprise Linux 7 gibt es ein entsprechendes Profil für den tuned
-Dienst (RPM-Paket tuned-profiles-oracle
). Dieser übernimmt die Konfiguration einiger Systemeinstellungen, unter anderem auch Kernel-Parameter. Die meisten Oracle-relevanten Einstellungen stimmen mit den Angaben aus der Dokumentation überein. Bei einer Installation kürzlich mussten jedoch nachträglich zwei Kernel-Parameter geändert werden:
Parameter | Erklärung |
---|---|
kernel.shmall |
Anzahl der Memory Pages, die systemweit genutzt werden können |
kernel.shmmax |
Maximale Größe in Bytes eines einzelnen Shared Memory Page Segments, die von einem Linux-Prozess verwendet werden kann |
Oracle kommentiert diese beiden Einstellungen in der Dokumentation wie folgt:
Parameter | Erklärung |
---|---|
kernel.shmall |
40 percent of the size of physical memory in pages |
kernel.shmmax |
Half the size of physical memory in bytes |
Also Einstellungen, die in jedem Fall je nach Größe des Arbeitsspeichers kalkuliert werden müssen. Das im RPM-Paket definierte Profil enthält aber feste Werte - somit ist die Einstellung für die meisten Systeme nicht korrekt.
In einem solchen Fall funktioniert das Definieren alternativer Werte in einer sysctl
-Konfigurationsdatei, beispielsweise unterhalb /etc/sysctl.d
(oder eben in der systemweiten Datei /etc/sysctl.conf
), jedoch nicht. Ich habe viel Zeit mit Troubleshooting, vor allem bezüglich Zugriffsrechte und SELinux verbracht - doch das Problem liegt an einer anderen Stelle.
Vorab noch ein Tipp: das Definieren von Kernel-Parametern in einer eigenen Datei unterhalb /etc/sysctl.d
funktioniert nur, wenn:
- die Datei die Endung
.conf
enthält - der SELinux-Kontext
system_conf_t
vergeben wurde (sofern SELinux aktiviert ist) - die Nummerierung der Datei sinnvoll gewählt wurde (z. B.
99-oracle.conf
). Eine höhere Zahl sorgt für das spätere Laden der Datei - ggf. vorher gesetzte Werte werden so überschrieben.
Da ich die Konfiguration von zentraler Stelle erstellen und verteilen wollte, war das Manipulieren von Konfigurationsdateien, die zu einem RPM-Paket gehören, keine Option. Ein späteres Update des Betriebssystems könnte so die Anpassungen verwerfen, wenn man unachtsam neue Konfigurationsdateien installiert.
Beim näheren Beobachten des tuned-Profiles für Oracle fiel mir auf, dass das Profil auf einem weiteren basiert - Vererbungen innerhalb von tuned
-Profilen sind also möglich:
1$ cat /usr/lib/tuned/oracle/tuned.conf
2#
3# tuned configuration
4#
5
6[main]
7include=throughput-performance
8...
Also entschied ich mich einfach dazu, ein eigenes tuned-Profil, welches auf dem Oracle-Profil basiert, zu erstellen:
1# mkdir /usr/lib/tuned/oracle-custom
2# vi /usr/lib/tuned/oracle-custom/tuned.conf
3#
4# tuned configuration
5#
6
7[main]
8include=oracle
9
10[sysctl]
11
12kernel.shmall = ...
13kernel.shmmax = ...
14
15ESC ZZ
16
17# restorecon /usr/lib/tuned/oracle-custom/tuned.con
Das erstellte Profil lässt sich wie folgt mittels tuned-adm
setzen und verifizieren:
1# tuned-adm profile oracle-custom
2# tuned-adm active
3Current active profile: oracle-custom
Idealerweise verpackt man dieses Profil noch in ein RPM-Paket und referenziert als Abhängigkeit tuned-profiles-oracle
- somit steht einer standardisierten Verteilung nichts mehr im Weg. Sofern das benötigte Oracle-Profil noch nicht vorhanden ist, wird es nachinstalliert. 🙂