Ressourcenbedarf von ROSI-SQL
Inhaltsübersicht
ROSI-SQL benötigt ab der Version 3.0 für den Betrieb verschiedene Ressourcen der Inter-Prozeß-Kommunikation im Kernel.
Die Anzahl der notwendigen Semaphoren und Shared-Memory Segmente wird im Referenzhandbuch im Kapitel 5 "Windowmanager" auf der ersten Seite beschrieben. Dort wird auch die Einstellung der Kernel-Parameter erläutert.
In den Releasenotes zu ROSI-SQL 3.1 wird bei den Bemerkungen zum Nutzungsrechtkontrollmechanismus auch die Behandlung der benötigten Messagequeue erläutert. Beide Abschnitte sind recht kurz gehalten und zur Einstellung der entsprechenden Kernel-Parameter wird stets auch auf die UNIX-Dokumentation verwiesen. Diese ist jedoch in vielen Fällen wenig hilfreich.
Dieser Text faßt unsere Erfahrungen und die Erfahrungen der ROSI-SQL Anwender in Bezug auf "Kernel-Konfiguration beim Einsatz von ROSI-SQL" zusammen. Er enthält zudem weitere Informationen zur Kernel-Konfiguration, die bisher noch nicht im ROSI-SQL Referenzhandbuch abgedruckt waren.
Der multitaskingfähige Windowmanager von ROSI-SQL benötigt für die Synchronisation der laufenden Programme Semaphore und Shared-Memory Segmente.
Für das Multitasking verwendet er für jede virtuelle (pty o.ä.) wie physische Terminalsitzung folgende Ressourcen:
- 1 Shared-Memory Segment mit bis zu 64KB Größe.
- 3 bzw. 4 Semaphore je nach Hardware-Plattform.
Für die Shared-Memory Segmente sowie für die Semaphoren verwendet ROSI-SQL die Identifier-Nummern im Bereich 0x52530000 bis 0x5253FFFF.
Für die Benutzerlimitkontrolle wird pro System eine Messagequeue benötigt. Diese wird mit der Identifier-Nummer 0x52530000 angelegt.
Für eine einwandfreie Funktion von ROSI-SQL darf keine andere Software Identifier innerhalb dieser Nummernkreise verwenden!
Finden an einem Rechner viele ROSI-SQL Sitzungen parallel statt (etwa mehr als drei), ist ein Hochsetzen der Kernelparameter in den meisten Fällen notwendig. Dazu sind im Kernel die entsprechenden Parameter zu verändern. Die für ROSI-SQL sinnvollen Einstellungen werden im nächsten Kapitel beschrieben.
3. Einstellung der Kernel-Parameter
3.1 Semaphoren Parameter
SEMMNI
Definiert die maximale Anzahl von Semaphor-Identifiers im System.
ROSI-SQL benötigt pro Terminalsitzung ein Semaphor-Identifier, unter dem jeweils ein Satz mit 3 bzw. 4 Semaphoren verwaltet wird.
Empfehlenswerte Einstellung:
SEMMNI >= maximale Anzahl Terminalsitzungen gleichzeitig.
SEMMNS
Definiert die maximale Anzahl der Semaphoren im System.
Empfehlenswerte Einstellung:
SEMMNS >= SEMMNI * 4
SEMMNU
Definiert die Anzahl der UNDO-Strukturen im System.
ROSI-SQL belegt pro Prozeß eine UNDO-Struktur, unter der jeweils ein Satz mit 3 bzw. 4 Semaphoren verwaltet wird.
Empfehlenswerte Einstellung:
SEMMNU >= SEMMNI * maximale Anzahl ROSI-SQL Prozesse (nur rsrun und/oder rssdb Prozesse), die gleichzeitig innerhalb einer Sitzung ablaufen.
SEMMAP
Definiert die maximale Anzahl Semaphor-Sets, die gleichzeitig verwaltet werden können.
Empfehlenswerte Einstellung:
SEMMAP >= SEMMNI
SEMMSL
Definiert die maximale Anzahl Semaphoren pro Semaphor-Identifier.
Empfehlenswerte Einstellung:
SEMMSL >= 4
SEMOPM
Definiert die maximale Anzahl Semaphoren, die innerhalb eines Betriebsystem-Funktionsaufruf an "semop" bearbeitet werden können.
Empfehlenswerte Einstellung:
SEMOPM >= 4
SEMUME
Definiert die Maximale Anzahl von UNDO-Einträgen pro UNDO-Struktur.
Empfehlenswerte Einstellung:
SEMUME >= 4
3.2 Shared-Memory Parameter
SHMMNI
Definiert die maximale Anzahl Shared-Memory Identifier im System.
Empfehlenswerte Einstellung:
SHMMNI >= maximale Anzahl Terminal-Sitzungen gleichzeitig.
SHMMAX
Definiert die maximale Segmentgröße in Bytes eines Shared-Memory Segments.
Empfehlenswerte Einstellung:
SHMMAX >= 65536
SHMSEG
Definiert die Anzahl Shared-Memory Segmente, auf die ein Prozeß gleichzeitig zugreifen kann.
Empfehlenswerte Einstellung:
SHMSEG >= 1
SHMALL
Definiert die maximale Anzahl Shared-Memory Pages, die gleichzeitig im System verwendet werden können.
Die Größe in Bytes einer Page ist systemabhängig. Auf den meisten Systemen ist diese 4KB.
Empfehlenswerte Einstellung:
SHMALL >= SHMMNI * (65536 / Page-Size)
3.3 Message-Queue Parameter
MSGMNI
Definiert die maximale Anzahl der Queue-Identifier im System.
ROSI-SQL benötigt auf einem System einen Identifier.
Empfehlenswerte Einstellung:
MSGMNI >= 1
MSGMAX
Definiert die maximale Größe in Bytes einer Message-Queue.
Empfehlenswerte Einstellung:
MSGMAX >= 8 + (8 * maximale Anzahl Terminalsitzungen + 1)
MSGMNB
Definiert die maximale Anzahl Bytes, die unter einer Queue gleichzeitig gespeichert werden können.
Empfehlenswerte Einstellung:
MSGMNB >= 2052 + MSGMAX * (maximale Anzahl-Projekte + maximale Anzahl ROSI-SQL Runtime-Versionen + 1)
MSGTQL
Definiert die maximale Anzahl Message-Header im System.
Empfehlenswerte Einstellung:
MSGTQL >= 2 + maximale Anzahl Projekte + maximale Anzahl ROSI-SQL Runtime-Versionen
MSGSEG
Definiert die maximale Anzahl Message-Segmente.
Empfehlenswerte Einstellung:
MSGSEG >= MSGMNB / MSGSSZ
MSGSSZ
Definiert die Größe in Bytes eines Message-Segments.
Hier ist der Default-Wert zu ermitteln und in die Formel für MSGSEG einzusetzen.
MSGPOOL (BSD)
Definiert die maximale Größe des Speichers für alle Messages im System.
Empfehlenswerte Einstellung:
MSGPOOL >= MSGMNB
MSGMAP
Definiert die maximale Anzahl Message-Segmente, die gleichzeitig verwaltet werden können.
Empfehlenswerte Einstellung:
MSGMAP >= MSGMNB / MSGSSZ
Die maximale Anzahl der ROSI-SQL Runtime-Versionen ist die Anzahl der verschiedenen ROSI-SQL Runtimes, die auf demselben System mit unterschiedlicher Seriennummer installiert sind und gleichzeitig betrieben werden. Normalerweise ist ein Runtime auf einem System installiert. In besonderen Fällen, wenn z.B. mehrere Applikationen von verschiedenen Herstellern mit jeweils eigenem ROSI-SQL Runtime installiert sind, kann sich diese Zahl entsprechend erhöhen.
Die maximale Anzahl Projekte ergibt sich aus der Anzahl Applikationen, die gleichzeitig mit unterschiedlicher Projekt-Nummer mittels dem Programm "rsbrand" gebrannt wurden. Sind alle Applikationen nicht gebrannt, laufen diese unter Projekt-Nummer 0 und die Anzahl Projekte ist damit 1.
ROSI-SQL Prozesse mit abgeschaltetem Windowmanager (mittels -w Option) belegen keine Semaphore bzw. Shared-Memory Segmente.
ROSI-SQL Prozesse, die keinem tty zugeordnet sind (typischerweise Hintergrundprozesse), werden für die Berechnung der Message-Queue wie eine Terminalsitzung behandelt.
Alle Werte beziehen sich nur auf die von den ROSI-SQL Runtime-Prozessen benötigten Ressourcen. Um die realen Werte der Parameter zu berechnen, müssen die Ressourcen, die andere Applikationen wie das Betriebssystem, die Datenbank usw. belegen, hinzuaddiert werden. Je nach Portierung kann sogar ein ROSI-SQL Runtime-Prozeß mehr Ressourcen benötigen wie oben angegeben wurde. Dies hängt von der verwendeten Methode der Client/Server-Kommunikation innerhalb des Datenbank-Interfaces ab. In 99% der Portierungen werden hier jedoch Pipes oder Sockets verwendet. Nähere Auskunft dazu kann der ESQL/C- (Informix), OCI- (Oracle) oder Call-Schnittstellen-Dokumentation (ADABAS D) entnommen werden.
Die hier aufgeführten Formeln ergeben die Werte für den "worst-case", also den maximalen Ressourcenbedarf, der auf einem System theoretisch auftreten kann. In der Praxis wird sich der Wert des einen oder anderen Parameters noch reduzieren lassen, womit weniger Hauptspeicher im Betriebsystemkern benötigt wird. Dieser kommt dann den Applikationen zugute.
Weitere Parameter wie z.B. die Anzahl benötigter Filedeskriptoren oder die Anzahl benötigter Prozesse sind extrem applikationsabhängig und lassen sich nicht ohne weiteres in einem einfachen Formelschema ausdrücken.