DE102016125023A1 - Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben eines Druckservers und sowie einen solchen Druckserver für digitale Hochleistungsdrucksysteme. Das Verfahren umfasst folgende Schritte:- Überwachen von Zustandsparametern, welche Systemzustände, wie z.B. die Belastung einer CPU, eines Arbeitsspeicher, eines Dateisystems, eines Netzwerkes und/oder einer Systemschnittstelle, beschreiben, mittels eines Sammel-Triggers,- Triggern von Filtern zum Lesen weiterer Zustandsparameter, welche Prozesszustände von am Druckserver ausgeführten Anwendungsprozessen umfassen, wobei das Triggern mit einer Triggerlogik ausgeführt wird, in Abhängigkeit davon, ob die mit dem Sammel-Trigger überwachten Systemzustände einen außergewöhnlichen Betriebszustand darstellen.

Description

• Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme sowie einen entsprechenden Druckserver.
• In dem Buch Digital Printing, Technology and Printing Techniques of Oce Digital Printing Presses, 9. Auflage, Februar 2005, ISBN 3-00-001081-5, sind in Kapitel 15 Druckserver für Hochleistungsdrucker beschrieben. Hierin ist schematisch der Ablauf eines in einem Oce PRISMAproduction Document Output Management System verwendeten Verfahrens zur Kommunikation zwischen zwei Prozessen eines Computersystems zum Übertragen von Druckdaten gezeigt.
• Für den Betrieb von Computern sind Betriebssysteme erforderlich. Diese wiederum enthalten in der Regel einen Betriebssystemkern (engl. kernel) als deren zentraler Bestandteil. Im Kernel sind in der Regel Prozess- und Datenorganisationen festgelegt, auf denen weitere Softwarebestandteile des Betriebssystems und ggf. von Anwenderprogrammen aufbauen. Typische Anforderungen an einen Systemkern sind die Parallelverarbeitung verschiedener Aufgaben, sog. Multitasking, die Einhaltung zeitkritischer Grenzen sowie die Transparenz für andere Anwendungen.
• Kernel sind in der Regel in Schichten (engl. layers) aufgebaut, wobei die unteren, maschinennahen Schichten die Basis für die darüberliegenden bilden. Die oberen Schichten können dabei typischerweise Funktionen der unteren Schichten aufrufen, aber nicht umgekehrt.
• Folgende Schichten können insbesondere vorhanden sein, von unten nach oben:
• • Schnittstellen-Schicht zur Hardware, z.B. Ein/Ausgabe-Geräte, Speicher, Prozessoren)
• • Schicht für die Speicherverwaltung, insbesondere einschließlich virtuellem Hauptspeicher
• • Schicht für die Prozessverwaltung (engl. scheduler)
• • Schicht für die Geräteverwaltung (engl. device management)
• • Schicht für die Verwaltung der Dateisysteme.
• Wenn alle diese Funktionen bzw. Schichten im Kernel selbst integriert sind, spricht man von einem monolithischen Kernel. Bei einem sog. Mikrokernel finden Teile davon in getrennten Prozessen statt. Außerhalb des Kernels laufen auch die sog. Anwenderprozesse, die sich der vom Kernel angebotenen Funktionen bedienen, um mit den o.g. Komponenten des Computers zu kommunizieren.
• Aus Betriebssystemen sind auch sog. Kernel Hooks bekannt, die als Schnittstelle dienen um an bestimmten Stellen in einem Kernel den Aufruf einer Routine außerhalb des Kernels zu ermöglichen. Die Verwendung von Kernel Hooks ist bspw. in „Kernel Hook-Prozess-Filter“, Walter Sprenger, IT-security-Secial 3/2003, Seite 39 ff beschrieben. Mit einem Kernel Hook kann ein Programmcode in ein bestehendes Programm eingehängt werden. Ein Kernel Hook hat in der Regel auf das gesamte System uneingeschränkt Zugriff.
• Aus der DE 10 2008 037 651 B4 geht ein Verfahren zur Kommunikation zwischen zwei Anwendungsprogrammen hervor, das in Drucksystemen zum Übermitteln von Druckdaten eingesetzt werden kann.
• Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme zu schaffen, mit welchen ein außergewöhnlicher Betriebszustand, insbesondere ein Zustand mit eingeschränkter Funktionsfähigkeit, zuverlässig und effizient erfasst werden kann.
• Eine weitere Aufgabe liegt darin, einen entsprechenden Druckserver zu schaffen.
• Eine oder mehrere der vorgenannten Aufgaben werden durch die in den unabhängigen Ansprüchen angegebenen Gegenstände gelöst. Vorteilhafte Ausgestaltungen sind in den jeweiligen Unteransprüchen angegeben.
• Nach einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme geschaffen, das folgende Schritte umfasst:
• - Lesen von Zustandsparametern, welche Systemzustände, wie z. B. die Belastung einer CPU, eines Arbeitsspeichers, eines Dateisystems, eines Netzwerks und/oder einer Systemschnittstelle, beschreiben, mittels eines Sammeltriggers,
• - Triggern von Filtern zum Lesen weiterer Zustandsparameter, welche Prozesszustände von am Druckserver ausgeführten Anwendungsprozessen umfassen, wobei das Triggern mit einer Triggerlogik ausgeführt wird, in Abhängigkeit davon, ob die mit dem Sammel-Trigger erfassten Systemzustände einen außergewöhnlichen Betriebszustand darstellen.
• Mit dem erfindungsgemäßen Verfahren werden zunächst Werte von Zustandsparametern, welche Systemzustände beschreiben, gelesen. Wenn diese Werte einen außergewöhnlichen Betriebszustand darstellen, dann werden Filter getriggert, um die Werte von Zustandsparametern, welche Prozesszustände von einem Druckserver ausgeführten Anwendungsprozessen beschreiben, gelesen.
• Diesem Verfahren liegt die Erkenntnis zugrunde, dass die Ursachen für einen Zustand mit eingeschränkter Funktionsfähigkeit sehr unterschiedlich sein können. Sie liegen meistens im Bereich der Anwendungsprozesse. Jedoch wirken sich derartige Ursachen immer auf Zustandsparameter auf Systemebene auf. Meistens ist dann eine Komponente des Systems, wie z. B. die CPU, eine Schnittstelle, eine Datenverbindung oder eine Speichereinrichtung überlastet, sodass die anderen Komponenten verzögert werden, bis die eine überlastete Ressource sich wieder in Normallast befindet, um ihren Betrieb mit normaler Leistung wieder aufnehmen zu können. Daher genügt es in der Regel, einige wenige Statusparameter auf Systemebene zu überwachen, um die Gefahr eines Zustands mit eingeschränkter Funktionsfähigkeit frühzeitig zu erkennen. Die Anzahl der zu überwachenden Zustandsparameter ist vorzugsweise nicht größer als fünfzig, vorzugsweise nicht größer als zwanzig, insbesondere nicht größer als fünfzehn und oftmals genügen sogar nicht mehr als zehn Zustandsparameter. Die Anzahl der überwachten Zustandsparameter entsprechen der Anzahl der Trigger im Sammel-Trigger. Mit einem Trigger kann auch ein Zustandsparameter über mehrere Komponenten hinweg überwacht werden.
• Diese wenigen Zustandsparameter lassen sich mit geringem Aufwand überwachen.
• Wird anhand dieser Werte der systemspezifischen Zustandsparameter die Gefahr eines außergewöhnlichen Zustands erkannt, dann werden Filter getriggert, welche Werte weiterer Zustandsparameter lesen, die Prozesszustände von am Druckserver ausgeführten Prozessen und insbesondere von Anwendungsprozessen umfassen. Hierdurch wird ein umfassendes Bild des jeweiligen Betriebszustands erfasst. Dies wird jedoch nur ausgeführt, wenn anhand der systemspezifischen Zustandsparameter ein derartiger Gefahrenzustand erkannt worden ist. Damit wird das Erfassen von Werten von Zustandsparametern, die Prozesszustände beschreiben, nur auf den Zeitraum, in den die hier interessierenden Situationen stattfinden, und die spezifischen Parameter, die für diese Situation relevant sind, beschränkt.
• Der Sammel-Trigger und die Triggerlogik sind vorzugsweise jeweils als separate Threads ausgebildet. Mit dem Sammel-Trigger werden die Werte der systemspezifischen Zustandsparameter eingelesen. Da diese Threads keine weiteren Aufgaben als das Einlesen dieser Werte hat, kann das Einlesen dieser Werte sehr schnell erfolgen, wodurch ein Betriebszustand sehr realistisch durch die mehreren Werte wiedergegeben wird. Würden diese Threads mehrere Aufgaben umfassen, dann würde das Lesen der Werte der Zustandsparameter langsamer erfolgen. Ein Computersystem kann seinen Zustand innerhalb von kurzer Zeit ändern. Es würde dann die Gefahr bestehen, dass die einzelnen eingelesenen Werte unterschiedliche Betriebszustände beschreiben. Das Trennen in eine Thread, die die Werte ausliest, und eine Thread, die die Auswertung der Werte vornimmt, erhöht die Qualität der ausgelesenen Werte zur Beschreibung eines Betriebszustands.
• Die gelesenen und gegebenenfalls gefilterten Werte können mit einem Daten-Interface einem Leistungsausgleichsmodul zum Steuern von Druckdiensten auf dem Druckserver bereitgestellt werden.
• Es kann auch ein Statistikmodul vorgesehen sein, das die gelesenen und gegebenenfalls gefilterten Werte der Zustandsparameter statistisch auswertet.
• Die gelesenen und gegebenenfalls gefilterten Werte der Zustandsparameter können auch mittels eines Log-Moduls abgespeichert werden.
• Ein Druckserver ist mit einem Computerprogramm versehen, das zum Ausführen des oben erläuterten Verfahrens ausgebildet ist.
• Die vorliegende Erfindung ist besonders zur Anwendung auf einem Druckserver geeignet. Das Überwachen der Betriebszustände kann jedoch auch auf Computersystemen eingesetzt werden, die für andere Anwendungen benutzt werden.
• Die Erfindung wird nachfolgend beispielhaft näher anhand der Zeichnungen erläutert. Die Zeichnungen zeigen in:
• 1 schematisch ein Drucksystem mit einem erfindungsgemäßen Druckserver in einem Blockschaltbild,
• 2 ein schematisches Schichtenmodell des Druckservers aus 1,
• 3a und 3b jeweils eine Speicherstruktur des Druckservers, wobei 3a eine aus dem Stand der Technik bekannte Speicherstruktur und 3b eine erfindungsgemäße Speicherstruktur zeigt,
• 4 den Aufbau des Ressource-Managers in einem Blockschaltbild,
• 5 einen Ausschnitt einer Konfigurationsdatei zum Konfigurieren eines SRM (System Ressource Manager),
• 6 wesentliche Komponenten eines Druckservers zum Steuern von Druckdiensten in einem Blockschaltbild, 7 den Aufbau eines Leistungsausgleichsmoduls in einem Blockschaltbild, und
• 8 schematisch den zeitlichen Ablauf einzelner Prozesse, insbesondere von Druckdiensten am Druckserver.
• Die Erfindung wird nachfolgend anhand eines Drucksystems 1 näher erläutert. Das Drucksystem 1 weist einen Druckserver 2 (1) auf, an dem mehrere Druckgeräte 3 über jeweils eine Datenleitung 4 angeschlossen sind. Die Datenleitung 4 entspricht in der Regel einem Netzwerkstandard, wie z.B. Ethernet.
• Der Druckserver 2 ist mit einem Netzwerk (LAN bzw. WAN)und insbesondere mit dem Internet 5 verbunden, an dem ein oder mehrere Clients 6 angeschlossen sind, an welchen Druckaufträge erzeugt und über das Internet 5 an den Druckserver 2 übermittelt werden.
• Der Druckserver 2 empfängt die Druckaufträge und leitet sie an die jeweiligen Druckgeräte 3 weiter. Die Druckaufträge werden im Druckserver 2 zwischengespeichert, je nach Bedarf bearbeitet, so dass sie vom Druckserver 2 empfangen, am Druckgerät 3 gerastert und ausgedruckt werden können. Am Druckserver hat ein Operator auch die Möglichkeit, die Druckaufträge beispielsweise mit einem sogenannten Preview-Programm einzusehen, wobei er einzelne Seiten überprüfen und Einfluss auf die Weiterleitung und Verarbeitung der Druckaufträge am Druckserver nehmen kann.
• Solche Druckserver, welche Druckdaten zu einem oder mehreren Druckgeräten weiterleiten, werden üblicherweise im Hochleistungsdruck verwendet. Als Hochleistungsdruck im Sinne der vorliegenden Erfindung wird die Verwendung eines Druckgerätes verstanden, das zumindest 5 Seiten der Größe DIN A4 pro Sekunde bedrucken kann. Druckgeräte für den Hochleistungsdruck können jedoch auch für höhere Druckgeschwindigkeiten, wie zum Beispiel zumindest 30 Seiten DIN A4 pro Sekunde und insbesondere zumindest 50 Seiten DIN A4 pro Sekunde und vorzugsweise zumindest 90 Seiten DIN A4 pro Sekunde ausgebildet sein. Die Druckgeräte sind digitale Druckgeräte, d.h., dass ihnen Druckdaten in digitaler Form übermittelt werden, die an einem Druckkopf im Druckgerät 3 in ein Druckbild umgesetzt werden, das mittels einer Druckfarbe auf einen Aufzeichnungsträger, der oftmals Papier ist, aufgetragen wird. Typischerweise ist ein solches Druckgerät als Tintenstrahldruckgerät oder als elektrophotografisches Druckgerät ausgebildet. Es kann auch ein Druckgerät sein, dessen Druckfarbe Flüssigtoner ist.
• Erfahrungsgemäß beträgt die Datenmenge einer Farbseite in der Größe DIN A4 im Format pdf im Durchschnitt etwa 0,5 bis 2 MB. Bei einer Datenmenge von 2 MB pro Seite und einer Druckgeschwindigkeit von 50 Seiten pro Sekunde bedeutet dies, dass dem Druckgerät ein Druckdatenstrom von 100 MB/sec. zugeführt wird. Diese Druckdaten sind noch nicht gerastert. Bei einem hochauflösenden Farbdruck, und insbesondere bei einem Druck, und/oder bei Dokumenten, in welchen mehrere Bilder verankert sind, kann die Datenmenge pro DIN A4-Seite 10 bis 25 MB und im Extremfall bis zu 600 MB betragen.
• Der Druckserver 2 muss daher einen erheblichen Datenstrom empfangen, die darin enthaltenen Daten den einzelnen Druckgeräten 3 zuweisen und gegebenenfalls anpassen. Eine solche Anpassung kann eine Änderung des Formates des Druckdatenstromes (IPDS, PCL, pdf, etc.), eine Skalierung der Druckdaten, eine Änderung der Auflösung der Druckdaten oder eine andere Anpassung der Druckdaten an die Anforderungen des jeweiligen Druckgerätes bzw. an spezielle Anforderungen des Betreibers des Druckgerätes bzw. eines Auftraggebers eines Druckauftrages umfassen.
• Zur Veranschaulichung der vorliegenden Erfindung ist in 2 der Druckserver 2 schematisch in einem Schichtenmodell dargestellt, das jedoch nicht dem standardisierten Schichtenmodell entspricht. Eine unterste Schicht 7 umfasst die Hardware des Druckservers. Diese Hardwareschicht enthält zumindest eine CPU, einen Speicher, Schnittstellen und Peripheriegeräte, insbesondere eine Anzeigeeinrichtung (Bildschirm) und eine oder mehrere Eingabeeinrichtungen (Tastatur, Maus, etc.) Unmittelbar über der Hardwareschicht 7 ist eine Betriebssystemschicht 8 angeordnet, welche die grundlegenden Funktionen der Hardware 7 steuert. Im vorliegenden Ausführungsbeispiel besteht die Betriebssystemschicht 8 aus einem Linux-Kernel. Die Betriebssystemschicht umfasst zumindest ein logisches Dateisystem, ein logisches Speichersystem, eine Speicherseitenverwaltung, einen Bus-Treiber, und weitere Treiber für systemrelevante Komponenten, wie zum Beispiel Schnittstellen, Massenspeicherkomponenten, wie zum Beispiel Festplatten, eine Dateisystemzugriffssteuerung und Schnittstellen zu Prozessen von Anwendungen. Das Betriebssystem regelt den Zugriff zur Hardware mittels entsprechenden Schnittstellen, die Speicherverwaltung, wobei vorzugsweise ein virtueller Hauptspeicher vorgesehen ist, die Prozessverwaltung, wobei die entsprechende Komponente des Betriebssystems in der Regel als Scheduler bezeichnet wird, die Geräteverwaltung, wobei die entsprechende Komponente in der Regel als Device-Management bezeichnet wird, und die Verwaltung der Dateisysteme. In einem monolithischen Kernel sind all diese Funktionen vereint. Außer des Kernels werden nur die Anwenderprozesse ausgeführt, die sich der vom Kernel angebotenen Funktionen bedienen, um mit der Hardware kommunizieren zu können. Es sind jedoch auch Mikro-Kernel bekannt, bei welchen ein Teil dieser Funktionen ausgelagert sind.
• Auf der Betriebssystemschicht 8 ist eine Schicht mit Daemons 9 angeordnet. Die Daemons 9 sind Programme, die im Hintergrund laufen.
• Über der Schicht der Daemons 9 ist eine Schicht mit weiteren Anwendungen 10 vorgesehen, in welcher Prozesse enthalten sind, die Programmabschnitte sind, die die mit dem Druckserver 2 auszuführenden Funktionen steuern.
• Dieser Schichtenaufbau mit einer Hardwareschicht 7, einer Betriebssystemschicht 8, einer Daemonschicht 9 und einer Anwendungsschicht 10 entspricht dem üblichen Aufbau von Computersystemen. Die Daemonschicht 9 enthält Programme, die im Hintergrund laufen, die Daemons. Derartige Daemons können Bestandteil des Betriebssystems als auch des Anwendungsprogramms sein.
• Gemäß einem Aspekt der vorliegenden Erfindung ist in der Daemonschicht 9 ein SRM-Modul(System Ressource Manager) 11 vorgesehen, welches ein Daemon ist, das Bestandteil des Anwendungsprogramms ist und die gleichen Schnittstellen wie die Anwendungsprogramme der Anwendungsschicht 10 zum Kernel benutzt.
• Die Aufgabe des SRM-Modul 11 ist es, den Zustand des Druckservers 2 zu erfassen und insbesondere außergewöhnliche Zustände mit eingeschränkter Funktionsfähigkeit frühzeitig zu erkennen und Zustände mit eingeschränkter Funktionsfähigkeit zu protokollieren. Zustände mit eingeschränkter Funktionsfähigkeit sind beispielsweise Zustände, bei welchen bestimmte Ressourcen oder Systemressourcen, wie zum Beispiel die CPU, Datenverbindungen (Datenbus, Schnittstellen) überlastet sind.
• Das SRM-Modul weist hierzu vier Module, einen Sammel-Trigger 12 (Englisch: Collect-Trigger), eine Triggerlogik 13, einen Sammelfilter 14 und eine Filterlogik 15 auf (4). Der Sammel-Trigger 12, die Triggerlogik 13, der Sammelfilter 14 und die Filterlogik 15 sind jeweils als separate Threads ausgebildet. Das SRM-Modul 11 weist noch eine Haupt-Thread (Englisch: Main; nicht dargestellt in 4) auf, welche die weiteren Threads 12-15 des SRM-Moduls 11 startet und den Austausch der Signale des Betriebssystem und anderer Prozesse handhabt.
• Der Sammel-Trigger 12 ist so ausgebildet, dass er vorbestimmte Zustandsdaten, wie zum Beispiel die Auslastung der CPU, die Auslastung jedes einzelnen CPU-Kerns, den zur Verfügung stehenden Speicherplatz in einem jeden Dateisystem, die verfügbaren Bandbreiten eines jeden Dateisystems, den verfügbaren Arbeitsspeicher, die Größe des benutzten Dateicache-Speichers, die freie Bandbreite von Datenverbindungen und/oder die Beanspruchung von Schnittstellen sammelt. Diese Zustandsparameter sind Zustände, die in der Betriebssystemschicht 8 auftreten und über eine Abfrage des Sammel-Triggers 12 an einer Komponente der Betriebssystemschicht 8 erhalten werden. Der Sammel-Trigger 12 kann zum Abfragen ausschließlich von derartigen betriebssystemspezifischen Zustandsparametern ausgebildet sein. Es können jedoch auch bestimmte Zustandsparameter in der Anwendungsschicht 10 abgefragt werden, jedoch ist dies in der Regel auf bestimmte Prozessgrenzen für Anwendungsprozesse, welche vorab festgelegt worden sind, begrenzt. Die Prozessgrenzen können bspw. den maximal beanspruchbaren Speicherbereich definieren. Der Sammel-Trigger 12 ist somit ein Thread bzw. eine Funktion, die auf Systemniveau Zustandsparameter einliest, welche über die aktuelle Belastung des Druckservers 2 eine Aussage erlauben.
• Der Sammel-Trigger 12 leitet die gesammelten Werte der Zustandsparameter an die Triggerlogik 13 weiter. Vorzugsweise ist der Sammel-Trigger 12 derart ausgebildet, dass jeweils nur die Werte eines Satzes vorbestimmter Zustandsparameter gesammelt werden und die Werte dieses Satzes Zustandsparameter als ein Datensatz der Triggerlogik 13 übergeben werden. Die Triggerlogik kann die Daten auswerten während der Sammel-Trigger erneut Zustandsparameter überwacht und sammelt.
• Die Triggerlogik 13 wertet die Werte der einzelnen Zustandsparameter aus und bei der Detektion eines auffälligen Zustandes startet die Triggerlogik 13 einen aktiven Filter im Sammelfilter 14, um Werte vorbestimmter oder aller Anwendungsprozesse der Daemonschicht 9 und der Anwendungsschicht 10 zu erfassen. Die Anwendungsprozesse können bspw. 1000 bis 2000 Threads umfassen, wobei ein jeder Anwendungsprozess aus einem oder mehreren Threads besteht.
• Von bestimmten Triggern werden bestimmte Sammelfilter 14 ausgelöst. Es gibt einen Trigger, der die CPU-Last überwacht. Wird der entsprechende Schwellenwert des die CPU-Last beschreibenden Zustandsparameters über- oder unterschritten, dann wird dies in der Triggerlogik 13 ausgewertet und ggfs. ein Sammel-Filter 14 aktiviert, der Werte, die mit der CPU-Last in Zusammenhang stehen, einliest. Dies sind insbesondere Parameter von Prozessen die erfahrungsgemäß eine hohe CPU-Belastung verursachen.
• Es ist eine Parametertabelle vorgesehen, in welcher die einzelnen Statusparameter und Werte der Anwendungsprozesse und Systemparameter, welcher überwacht und/oder ausgelesen werden, definiert sind. Die Tabelle kann bspw. den Namen der Parameter, den Ort im Dateisystem des Betriebssystems, den Typ des Parameters (Zahl, String, Formatierung, etc.), Informationen, wie und an wen Parameter weitergegeben wird, enthalten. Mit dieser Tabelle wird sowohl das Einlesen, die Interpretation als auch das Weiterleiten der Werte der Parameter gesteuert. Mit dieser Tabelle wird bspw. die direkte Weiterleitung von Werten bestimmter Parameter von der Triggerlogik 13 an das Statistikmodul 20, das Prozess-Management-Modul 21 und/oder das Daten-Interface 23 gesteuert. Auf diese Tabelle können alle Filter und Trigger zugreifen.
• Weiterhin übermitteln die Triggerlogik 13 und die Filterlogik 15 Werte der Parameter direkt an ein Log-Modul 16, das diese Werte speichert.
• Die mit den aktiven Filtern des Sammelfilters 14 erhaltenen Datensätze der Werte der Zustandsparameter der Anwendungsprozesse werden an die Filterlogik 15 weitergeleitet. Die Filterlogik wertet die vom Sammelfilter 14 erhaltenen Werte der Zustandsparameter aus, wobei die Werte zur Beschreibung des Zustandes des Druckservers 2 neu kombiniert werden können. Die Filterlogik 15 detektiert nach bestimmten vorkonfigurierten Filterregeln außergewöhnliche Zustände und insbesondere Zustände mit eingeschränkter Funktionsfähigkeit und unterrichtet beim Vorliegen eines solchen Zustandes das Log-Modul 16, das diese Zustände abspeichern kann. Mit diesen Filterregeln wird in der Regel geprüft, ob ein oder mehrere Werte von Zustandsparametern vorbestimmte Schwellwerte unter- oder überschreiten.
• Dadurch, dass der Sammel-Trigger 12 als separates Thread zur Triggerlogik 13 ausgebildet ist, kann der Sammel-Trigger 12 mehrere Werte von Zustandsparameter innerhalb eines kurzen Zeitabstandes sammeln. Der Datensatz dieser Werte beschreibt somit einen bestimmten Zustand des Druckservers 2 sehr präzise. Würde die Filterlogik und der Sammel-Trigger in einem einzigen Thread kombiniert sein, dann wären die Zeitabstände zwischen dem Einlesen der einzelnen Werte der Zustandsparameter größer. Da sich in einem Computersystem der Zustand sehr schnell ändern kann, wäre ein Datensatz, dessen Werte über einen größeren Zeitraum eingelesen werden, wesentlich weniger aussagekräftig. Das Gleiche gilt auch für die Trennung des Sammelfilters 14 und der Filterlogik in zwei separate Threads.
• Mit dem Sammel-Trigger 12 werden einige wenige Zustandsparameter in regelmäßigen Abständen von z.B. 0,1 s. bis 10 s. überwacht, um die Gefahr eines Zustandes mit eingeschränkter Funktionsfähigkeit zu erkennen. Die Gefahr eines Zustandes mit eingeschränkter Funktionsfähigkeit kann erkannt werden, indem zumindest ein Wert eines erfassten Zustandsparameters einen vorbestimmten Schwellwert über- oder unterschreitet.
• Die Anzahl der überwachten Zustandsparameter ist vorzugsweise nicht größer als fünfzig oder nicht größer als zwanzig, insbesondere nicht größer als fünfzehn und oftmals genügen sogar weniger als zehn Zustandsparameter. Wird die Gefahr eines Zustandes mit eingeschränkter Funktionsfähigkeit in der Triggerlogik 13 erkannt, so wird eine Filterfunktion im Sammelfilter 14 gestartet. Mit dieser Filterfunktion werden die Werte von Zustandsparametern von Anwendungsprozessen eingelesen, um so eine möglichst spezifische Beschreibung des jeweiligen Zustandes zu erhalten. Anhand dieser spezifischen Beschreibung wird die Ursache der eingeschränkten Funktionsfähigkeit in Log-Dateien und Statistiken dokumentiert und ggfs. eine entsprechende Aktion gestartet. Diese Filterfunktion wird gestartet, wenn die Gefahr eines Zustandes mit eingeschränkter Funktionsfähigkeit erkannt wird und die Filterfunktion wird so lange aufrechterhalten, wie diese Gefahr bzw. der Zustand weiter besteht. Vorzugsweise wird diese Filterfunktion auch noch eine vorbestimmte Zeitdauer aufrechterhalten, nachdem die Gefahr dieses bestimmten Zustandes mit eingeschränkter Funktionsfähigkeit bereits beendet ist. Hierdurch werden auch Zustände des Druckservers unmittelbar nach Erledigung oder Behebung des Problemes erfasst und können von dem Log-Modul 16 aufgezeichnet werden.
• Der Sammelfilter 14 kann mehrere unterschiedliche aktive Filter zur Verfügung stellen, welche unterschiedliche Sätze von Zustandsparameter einlesen, je nachdem welcher außergewöhnliche Zustand bzw. welche Gefahr einer eingeschränkten Funktionsfähigkeit mit der Triggerlogik 13 erkannt wird. Es können mehrere Filter gleichzeitig aktiv sein.
• Dadurch, dass die Filter des Sammelfilters 14 nur aktiv sind, wenn er von der Triggerlogik 13 gestartet wird, werden nur Daten von Zuständen gesammelt, welche im Zusammenhang mit einem außergewöhnlichen Zustand oder einer Gefahrensituation bestehen. Hierdurch werden keine unnötigen Zustandsbeschreibungen gesammelt und die Belastung des SRM-Moduls 11 so gering wie möglich gehalten.
• Die Ursachen für einen Zustand mit eingeschränkter Funktionsfähigkeit können sehr unterschiedlich sein und liegen meistens im Bereich der Anwendungsprozesse. Jedoch wirken sich derartige Ursachen immer auf Zustandsparameter auf Systemeebene aus. Meistens ist dann eine Komponente des Systems, wie zum Beispiel die CPU, eine Schnittstelle, eine Datenverbindung oder eine Speichereinrichtung überlastet, so dass die anderen Komponenten warten müssen, bis die eine überlastete Komponente sich wieder in Normallast befindet, um ihren Betrieb in vollem Umfang wieder aufnehmen zu können. Daher genügt es meistens, einige wenige Statusparameter auf Systemebene zu überwachen, um die Gefahr eines Zustandes mit eingeschränkter Funktionsfähigkeit frühzeitig zu erkennen.
• Hierbei ist zu berücksichtigen, dass das Warten auf überlastete Komponenten zusätzlichen Steuerungsaufwand durch das „Scheduling“ für das Betriebssystem verursacht, so dass hierdurch das Problem weiter verstärkt wird. Findet man auf Systemebene schnell den Engpass und kann man rechtzeitig entgegensteuern, dann können die Ressourcen wesentlich effizienter genutzt werden.
• Die Überwachung der Zustandsparameter auf Systemebene wird vorzugsweise in regelmäßigen Abständen von einigen Zehntelsekunden bis einigen Sekunden durchgeführt. Die Zustandsparameter auf Systemebene können auch in unregelmäßigen Abständen überwacht werden, welche bspw. in Abhängigkeit von einem erfassten Lastzustand abhängen. Je geringer die erfasste Last ist, desto länger können die Abtastintervalle sein.
• Beim vorliegenden Ausführungsbeispiel wird ein mit dem Sammel-Trigger 12 überwachter Zustandswert bezüglich eines Warn-Schwellwertes und bezüglich eines Fehler-Schwellwertes mit der Triggerlogik 13überwacht. Wird der Warn-Schwellwert über- bzw. unterschritten, dann wird ein entsprechender Filter des Sammelfilters 14 gestartet. Werden diese Schwellwerte unter- bzw. überschritten, dann kann jeweils ein Warn- bzw. Fehlermeldung und/oder eine Warn- bzw. Fehleraktion ausgeführt werden. Dies kann individuell vorab konfiguriert werden.
• Hierbei kann auch konfiguriert werden, dass die Ausgabe einer Warn- bzw. Fehlermeldung und/oder das Ausführen einer Warn- bzw. Fehleraktion erst eine vorbestimmte Zeitdauer nach dem Unter- bzw. Überschreiten des entsprechenden Schwellwertes verzögert ausgeführt wird, wobei zum Zeitpunkt der Ausgabe der Meldung bzw. des Ausführens der Aktion der Schwellwert noch unter- bzw. überschritten sein sollte. Hierdurch wird nicht bei einem jeden kurzzeitigen Unter- bzw. Überschreiten des entsprechenden Schwellwertes die Meldung ausgegeben oder die Aktion ausgeführt.
• Wird der Fehler-Schwellwert über- bzw. unterschritten, dann wird der entsprechende Filter weiter aktiv gehalten und/oder ein spezifischer Fehler-Filter aktiv geschaltet, der weitere Zustandsparameter überwacht.
• Es kann auch festgelegt sein, dass wenn der Warn- bzw. Fehler-Schwellwert in schneller Folge über- und unterschritten wird, dass nur einmal die Warn- bzw. Fehleraktion bzw. die Warn- bzw. Fehlermeldung oder jedes n-te-Mal oder immer oder immer nach einem bestimmten Zeitintervall (z.B. all 1 bis 10 sec.) ausgeführt bzw. ausgegeben wird.
• Das SRM-Modul 11 wird bei der Initialisierung des Druckservers 2 mittels einer Konfigurationsdatei konfiguriert, wobei die Trigger und die Filter dahingehend festgelegt werden, welche Zustandsparameter überwacht werden, die Warn-Schwellwerte und die Fehler-Schwellwerte definiert werden und festgelegt wird, welche Filter im Sammelfilter 14 ausgeführt werden und welche Warn- bzw. Fehleraktionen gestartet und/oder welche Warn- bzw. Fehlermeldungen ausgegeben werden. 5 zeigt einen Ausschnitt einer solchen Konfigurationsdatei. Die Trigger und die Filter können alternativ oder ergänzend auch direkt im SRM-Modul 11 fest definiert sein. Das SRM-Modul 11 kann auch über das Daten-Interface 23 Regeln für die Trigger und Filter entgegennehmen, welche zusätzlich oder alternativ zu den in der Konfigurationsdatei angegebenen Regeln angewandt werden.
• In der Konfigurationsdatei werden zunächst einige allgemeine Konfigurationsparameter, wie zum Beispiel die Abtastfrequenz, das Trace-Niveau und weitere Steuerparameter festgelegt.
• Bei diesem Ausführungsbeispiel wird zunächst an dem ersten Abschnitt die Überwachung von Statusparametern konfiguriert, um festzustellen, ob die CPU-Belastung groß ist. Hierzu wird die Leerlaufzeit der CPU in % (=„cpu.%acidle“) überwacht. Weiterhin wird die CPU-Belastung der letzten 15 Minuten (=„cpu.ldav-15“) überwacht.
• Ein Trigger für die Triggerlogik 13 wird derart definiert, dass 40% der CPU-Leerlaufzeit als Warn-Schwellwert festgelegt wird, bei dessen Unterschreitung dies als Gefahr eines Fehlers beurteilt wird. Warten mehr als 30 Prozesse auf den Zugriff auf die CPU in den letzten 15 Minuten, dann ist CPU-Belastung größer als 30. Dies wird als erhöhte CPU-Belastung (>30)bewertet und als Fehlergefahr beurteilt. 30 Prozesse bedeuten hier somit einen entsprechenden Warn-Schwellwert. Der Fehler-Schwellwert für die CPU-Leerlaufzeit beträgt 20% und der Fehler-Schwellwert für die CPU-Belastung beträgt 50 Prozesse.
• Der entsprechende aktive Filter sammelt bei einer Gefahr einer eingeschränkten Funktionsfähigkeit aufgrund der CPU-Belastung alle Prozesse, die mehr als 30% CPU-Belastung verursachen, („Filter=P.%CPU>30“). Diese Prozesse werden in eine Log-Datei 18 geschrieben. Zusätzlich wird der top-Befehl ausgeführt, welcher alle Prozesse des Systems mit Ressourcenverbrauch erfasst und in die Datei CPU.txt schreibt („ErrActionData=‚top-b-m 1‘, , CPU.txt', once“). Eine spezielle Fehleraktion wird hier nicht ausgeführt. Als Fehlermeldung wird der String „70000000, W“ ausgegeben.
• Ein zweiter Trigger wird zur Überwachung der CPU-Belastung vorgesehen, der die Anzahl der geöffneten Dateien und die Anzahl der geöffneten Netzwerkverbindungen überwacht (=handles.%UsedFHd).
• Weiterhin wird mit diesem Ausführungsbeispiel die Benutzung bestimmter Netzwerkanschlüsse bzw. der Schnittstellen überwacht. Hierzu wird der Zustandswert des jeweiligen Netzwerkanschlusses (=network.%totutil) überwacht, wobei der Warn-Schwellwert 70% und der Fehler-Schwellwert 80% beträgt. Mit einem aktiven Filter des Sammelfilters 14 wird der Wert des Zustandparameters der Anzahl der Netzwerkverbindungen. (= P.NoSoc entspricht „No. of Sockets“) eingelesen, und wenn die Anzahl der Netzwerkverbindungen größer als 1 ist, werden alle Prozesse erfasst, die eine CPU-Belastung von mindestens 10% verursachen.
• Das Log-Modul 16 ist so ausgebildet, dass es die mit dem Sammel-Trigger 12 und dem Sammel-Filter 14 eingelesenen Daten in eine System-Log-Datei 17 und eine Prozess-Log-Datei 18 speichert. Die mit dem Sammel-Trigger 12 eingelesenen Werte der Zustandsparameter werden von dem Log-Modul 16 in die System-Log-Datei 17 geschrieben, wenn ein Fehlerzustand und/oder ein Fehlerzustand durch über- oder unterschreiten des Warn-Schwellwertes und/oder des Fehler-Schwellwertes festgestellt wird. Die mit dem Sammel-Filter 14 eingelesenen Werte der Zustandsparameter der Anwendungsprozesse werden in die Prozess-Log-Datei 18 geschrieben, wenn der entsprechende Filter der Filterlogik 15 einen außergewöhnlichen Zustand bzw. eine Gefahr einer eingeschränkten Funktionsfähigkeit erkannt hat. Bei einem unbekannten Fehlerzustand können die Werte aller verfügbaren Zustandsparameter oder zumindest ein Großteil der verfügbaren Zustandsparameter erfasst werden.
• Das Schreiben der entsprechenden Werte in die System-Log-Datei 17 und in die Prozess-Log-Datei 18 wird auch vorzugsweise jeweils eine vorbestimmte Zeitdauer fortgesetzt, nachdem der entsprechende Zustand, mit welchem das Schreiben ausgelöst wird, bereits beendet ist, um einen Vergleich mit einem „Normalzustand“ im Nachhinein zu ermöglichen.
• Das SRM-Modul 11 kann auch ein Aktionsmodul 19 aufweisen, das vorbestimmte Aktionen ausführen kann, welche von der Triggerlogik 13 ausgelöst werden können. Das Aktionsmodul 19 kann ein separates Thread sein. Kurze Aktionen können innerhalb dieser Thread ausgeführt werden. Für längere Aktionen wird eine separate Thread gestartet. Für einen Fehlerzustand und einen Fehlerzustand können unterschiedliche Aktionen ausgelöst werden. Diese werden in der Konfigurationsdatei (5) definiert. Hierbei muss jeweils der Typ der Aktion bei einem Fehlerzustand bzw. bei einem Fehlerzustand angegeben werden. Als Aktionstypen werden zwischen keiner Aktion („none“), einer kurzen Aktion, für die keine separate Thread gestartet wird („ExeStartShort“) sowie einer langen Aktion, für die eine separate Thread gestartet wird („ExeStartLong“), unterschieden. Weiterhin wird die Art der Aktion durch eine vorbestimmte Datenbeschreibung definiert. In 5 ist das folgende Beispiel enthalten: $$\text{ErrActionType}=\text{ExeStartShort}$$

  

  $$\text{ErrActionData}=\text{'}\text{top }-\text{b }-\text{n }1\text{'},\text{'}\text{CPU}\text{.txt}\text{'},60\text{''}$$

  
• Mit diesen Zeilen der Konfigurationsdatei wird eine Fehleraktion definiert, welche eine kurze Dauer aufweist und innerhalb des Aktionsmoduls 19 ohne separater Thread ausgeführt wird. Bei dieser Fehleraktion wird die aktuelle Ausgabe in die Datei CPU.txt geschrieben. Falls der entsprechende Trigger länger aktiv ist, wird das Schreiben der Daten alle 60 Sekunden wiederholt.
• Das SRM-Modul 11 kann ein Statistik-Modul 20 aufweisen, das vorzugsweise die erfassten Daten unmittelbar von der Triggerlogik 13 und von der Filterlogik 15 erhält, ohne dass sie gefiltert werden.
• Mit dem Statistik-Modul 20 können unterschiedliche Statistiken erstellt und in eine oder mehrere Statistikdateien 38 abgespeichert werden. Eine grundlegende Statistik kann für eine jede Minute, einen Tag und/oder langfristig über eine Zeitdauer von mehreren Wochen, Monaten oder Jahren erstellt werden. Die Statistiken können in unterschiedlichen Formaten, wie z.B. einem Zeitstrahl ( 8), einer Tabelle oder in Form von Listen erstellt werden. Die Statistiken enthalten vor allem Minimal-, Maximal- und/oder Mittelwerte. Die einzelnen Werte können mit einem Zeitstempel versehen sein. Hierbei werden vor allem folgende systemspezifischer Zustandsparameter berücksichtigt:
• - Gesamte CPU-Belastung
• - Datendurchsatz für ein jedes Dateisystem sowie für das gesamte Dateisystem
• - Datendurchsatz für jede Netzwerkschnittstelle sowie im Gesamten,
• - die gesamte Verwendung des Anwendungsspeichers durch die Prozesse,
• - die Verwendung des Dateicache-Speichers.
• Weiterhin können Maximal-, Minimal- und/oder Mittelwerte innerhalb einer vorbestimmten Zeitdauer von zum Beispiel 1 Sekunde, 10 Sekunden, einer Minute erfasst und mit Datum und Zeitstempel versehen werden. Typische Zustandsparameter, die derart statistisch erfasst werden können, sind zum Beispiel:
• - Datenrate in MB/s des Schreibens und/oder Lesens, die Anzahl der Lese/Schreibanforderungen (Requests), die Anzahl der Schreibprozesse jeweils für ein jedes Dateisystem und für das gesamte Dateisystem,
• - die Datenrate in MB/s des Empfangens und Übertragens von Daten über eine jede Netzwerkschnittstelle und die Anzahl der empfangenen und übertragenen Datenpakete,
• - die Wartezeiten auf Daten von nicht-flüchtigen Speichermedien, mittlere CPU-Last, Anzahl der CPU-Prozess-Thread-Wechsel (Contex Switches) und die entsprechenden Benutzer und das entsprechende System, um die Belastung der CPU darzustellen,
• - Anzahl der geöffneten Dateien,
• - Größe des benutzten Anwendungsspeichers und des benutzten Dateicache-Speichers,
• - freigegebene Seiten pro Sekunde, eingelesene Seiten pro Sekunde, ausgelesene Seiten pro Sekunde, Anzahl der Seitenfehler und Anzahl von Hauptseitenfehler eines virtuellen Hauptspeichers,
• - Anzahl der Netzwerkverbindungen gemäß vorbestimmten Standards, wie zum Beispiel TCP (v4 & v6), UDP und/oder Unix.
• In der Anwendungsschicht 10 (2) werden auf dem Druckserver 2 Druckdienste 25 (Services) ausgeführt. Dies sind Anwendungsprozesse, die Druckdaten verarbeiten. Mit dem Sammelfilter 14 können auch von solchen Druckdiensten 25 Werte von Statusparametern gesammelt werden, womit auch die Druckdienste 25 einer statistischen Erfassung mittels des Statistikmoduls 20 unterzogen werden können. Für ein jeden Druckdienst werden beispielsweise die Werte zu folgenden Statusparametern gesammelt und statistisch ausgewertet:
• - Dienstname
• - Druckauftragsidentifikationsnummer
• - Datengröße der Eingabedatei (GB)
• - Datengröße der Ausgabedatei (GB)
• - Startzeit (Tag und Uhrzeit)
• - Dauer der Ausführung des Dienstes
• - verwendetes System/Benutzungszeit
• - minimale und/oder maximale CPU-Last, gegebenenfalls aufgeteilt nach CPU-Kerne,
• - minimaler und/oder maximaler Speicherbedarf
• - minimale/maximale und/oder durchschnittliche Werte für die Ein- und Ausgabe von Daten zum jeweiligen Dateisystem und bezüglich des gesamten Dateisystems,
• - minimale und/oder maximale Werte der Netzwerkbenutzung.
• Hierbei werden vor allem Minimal-, Maximal und/oder Mittelwerte für einen jeden Dienst separat statistisch erfasst. Es können statistische Werte von Diensten eines ähnlichen Typs zusammengefasst werden.
• Die für die Druckdienste spezifischen Zustandsparameter, wie zum Beispiel Name, Auftragsidentifikationsnummer, Dateigröße der Eingabedatei und Dateigröße der Ausgabedatei können auch von einem bezüglich des SRM-Moduls 11 externen Modul dem Statistik-Modul 20 zugeführt werden. Die systemspezifischen Statusparameter, wie zum Beispiel Statusparameter, die die CPU-Last, den Speicherbedarf, den Zugriff auf das Dateisystem und/oder auf das Netzwerk beschreiben, werden von den Modulen des SRM-Moduls 11 erfasst und dem Statistik-Modul 20 bereitgestellt.
• Ein Druckdienst kann mittels eines einzigen Prozesses oder mittels mehrerer Prozesse ausgeführt werden, wobei bei mehreren Prozessen in der Regel ein Hauptprozess und mehrere Unterprozesse vorgesehen sind. Für einen jeden Unterprozess werden vorzugsweise die systemspezifischen Statusparameter separat erfasst und statistisch ausgewertet.
• Neben den Druckdiensten werden in der Anwendungsschicht 10 Backendprozesse 26 ausgeführt, welche jeweils einem der Druckgeräte 3 zugeordnet sind und dazu dienen, die Druckdaten an die Druckgeräte 3 zu übermitteln. Diese Backendprozesse werden auch als Druckertreiber bezeichnet. Sie führen die Übermittlung der Druckdaten vom Druckserver 2 zum druckgerät 3 aus. Diese Backendprozesse können in ähnlicher Weise wie die Druckdienste statistisch erfasst werden, wobei einige druckgerätspezifische Daten, wie zum Beispiel der Druckername, der Druckertyp, die Druckgeschwindigkeit, die gesamte Dateigröße der Eingabedatei in GB, die minimale, maximale und/oder durchschnittliche Dateigröße einer jeden Druckseite (z.B. in DIN A4) berücksichtigt werden. Diese Daten werden von einem externen Modul bezüglich des SRM-Moduls 11 an das Statistik-Modul 20 geliefert. Diese Daten können mit den Werten der systemspezifischen Zustandsparameter, die mit dem SRM-Modul 11 erfasst werden, genauso wie bei der statistischen Erfassung der Druckdienste, ergänzt werden. Die statistischen Daten können auch für ein bestimmtes Druckgerät zusammengefasst werden.
• Es kann auch eine Gesamtstatistik für den gesamten Betrieb des Druckservers 2 erstellt werden. Diese Gesamtstatistik umfasst beispielsweise die Werte von folgenden Zustandsparametern:
• - Threadnamen, wird vom Prozess, der den Thread aufruft, vergeben.
• - Zweck des Thread, wird vom Prozess, der den Thread aufruft, vergeben.
• - Name des Hauptprozesses
• - Anzahl der Starts der einzelnen Threads
• - Startzeit der Threads
• - benutzte CPU-Zeit durch diese Threads
• - Betriebsdauer oder Endzeit.
• Diese threadspezifischen Statusparameter können durch folgende prozessspezifischen Statusparameter ergänzt werden:
• - Prozessname
• - gesamte benutzte CPU-Zeit
• - benutzte CPU-Zeit,
• - minimale/maximale und/oder durchschnittliche Speicherbenutzung
• - minimale/maximale Anzahl von geringfügigen Seitenfehlern
• - minimale/maximale Anzahl von Hauptseitenfehlern
• - Parameter, die den Datendurchsatz des gesamten Dateisystems beschreiben
• - Parameter, die den Datendurchsatz des Netzwerkes beschreiben
• - minimale/maximale Anzahl der Threads
• - minimale/maximale benutzte „File Handles“
• - minimale/maximale benutzte CPU-Zeit
• Diese Statistiken können vor allem bei großen Druckservern, bei welchen eine Vielzahl von Threads ausgeführt wird, nach den einzelnen Threads und/oder nach den einzelnen Prozessen unterteilt ausgewertet werden. Normalerweise ist es nicht bekannt, welcher Thread welche Funktion bzw. welchen Zweck erfüllen soll. In dieser Statistik werden die Werte von threadspezifischen Parametern mit den Werten von prozessspezifischen Parametern verknüpft. Hierdurch ist es möglich zu erfassen, welchen Zweck welcher Thread für welchen Prozess hat und welche prozessspezifischen und threadpezifischen Statusparameter dem jeweiligen Thread zugeordnet werden können. Hierdurch werden mit der Statistik prozessspezifische Parameter mit threadspezisfischen Parametern erfasst und abgespeichert, so dass diese verknüpften Daten bei einer späteren Analyse zur Verfügung stehen, wodurch Verursacher eines Zustandes mit eingeschränkter Funktionsfähigkeit einfacher bestimmbar sind. Dadurch, dass damit der Zweck des jeweiligen Threads bekannt ist, kann dieser bei der Steuerung, insbesondere Priorisierung der einzelnen Threads, berücksichtigt werden.
• Mit dem SRM-Modul können somit systemspezifische Statusparameter als auch prozessspezifische Statusparameter einem bestimmten Thread zugeordnet werden. Da Threads bei herkömmlichen Systemen keinen Namen besitzen, werden beim vorliegenden System den Threads von den sie aufrufenden Prozessen Namen zugeordnet, so dass die Threads bei einer späteren Fehleranalyse einfach zuordbar sind.
• Das SRM-Modul 11 kann ein Prozess-Management-Modul 21 aufweisen, mit welchem auf laufende Prozesse auf Systemebene eingewirkt werden kann. Das Prozess-Management-Modul ist ausgebildet, um bspw. bei Bedarf die vom Betriebssystem zugeordnete Priorität der einzelnen Prozesse zu ändern. Hierdurch kann der Zugriff der einzelnen Prozesse auf die CPU verändert werden. Weiterhin kann den einzelnen Prozessen vorbestimmte Bandbreiten des Netzwerkes zugeordnet werden. Hierzu können in dem Betriebssystem entsprechende Tabellen vorgesehen sein, die von dem Prozess-Management-Modul abgeändert werden können. Weiterhin können Prozesse grundsätzlich vorübergehend angehalten werden, wobei hierbei vorzugsweise ein Netzwerk-Time-Out dahingehend berücksichtigt wird, dass dieses möglichst nicht überschritten wird, damit das Netzwerk nicht durch nicht-notwendige Wiederholungen von Übermittlungen von Datenpaketen blockiert wird. Weiterhin kann die Anzahl der Datenübertragungen der zuzuführenden Druckaufträge gesteuert werden, so dass die zur Verfügung stehenden Bandbreiten nicht überbelastet werden.
• Vor Ausführung einer dieser Aktionen durch das Prozess-Management-Modul 21 werden vorzugsweise einer oder mehrerer der folgenden Statusparameter überprüft:
• - Leerlaufzeit der CPU
• - Leerlaufzeit der CPU für einen jeden Kernel
• - freie Zeit/Lesezeiten für ein jedes Dateisystem
• - freier Speicherbereich eines jeden Dateisystems
• - verfügbarer Arbeitsspeicher
• - Benutzung des Dateicache-Speichers
• - verfügbare Netzwerkbandbreiten (MB/s) für eine jede Schnittstelle.
• Diese Überprüfung wird insbesondere dann ausgeführt, wenn ein Backendprozess gestartet werden soll. Ein Backendprozess darf keinesfalls unterbrochen werden, weshalb durch Überprüfung bspw. dieser Statusparameter vor dem Start eines Backendprozesses sichergestellt wird, dass ausreichend Ressourcen vorhanden sind. Die Backendprozesse haben eine höhere Priorität als die Dienstprozesse.
• Weiterhin besitzt das Prozess-Management-Modul 21 eine Cache-Kontrollfunktion, mit welcher aktuelle Informationen zum Dateicache-Speicher abgerufen werden können. Diese Informationen sind vor allem der Name der im Dateicache-Speicher gespeicherten Datei bzw. der im Dateicache-Speicher gespeicherten Dateien und der verfügbare Dateicache-Speicher. Diese Informationen können vom Prozess-Management-Modul 21 weitergegeben werden, so dass sie für die weitere Steuerung des Betriebes des Druckservers 2 zu Verfügung stehen. Hierdurch können übergeordnete Programm-Module, wie z.B. ein unten näher erläutertes Leistungsausgleichsmodul 24, die die Bedeutung der einzelnen Dateien kennen, gezielt den Betrieb des Druckservers 2 beeinflussen und Prozesse starten, die eine im Dateicache-Speicher befindliche Datei weiter bearbeiten oder wenn die Datei oder Teile davon nicht mehr benötigt werden, unverzüglich aus dem Dateicache-Speicher zu löschen. Dies wird unten näher erläutert.
• Das Prozess-Management-Modul 21 weist eine Prozessorkonfigurationsfunktion auf, mit welcher den einzelnen Prozessen ein oder mehrere Kerne der CPU und/oder einem entsprechenden Arbeitsspeicherbereich, ein Speicherbereich eines Massenspeichers (Festplatte, SSD, etc.) zugeordnet werden kann.
• Durch diese Zuordnung ist es beispielsweise möglich, einzelne Prozesse zunächst auf einzelne CPU-Kerne zu verteilen und erst wenn alle CPU-Kern benutzt werden, mehrere Prozesse einem CPU-Kerne zuzuordnen, welche dann beispielsweise quasiparallel mittels Hyper-Threading ausgeführt werden. Hierdurch können die Kerne optimal ausgelastet werden.
• Diese Konfiguration kann mittels einer CPU-Kern-Tabelle ausgeführt werden, in welcher alle auf der CPU auszuführenden Prozesse registriert sind. In dieser Tabelle sind der Prozessname, die Prozess-Identifikationsnummer, die Prozesspriorität, die angefallene Anzahl von Kernen, die angeforderte Menge an Speicher, die aktuelle CPU-Kern-Maske, der aktuelle CPU-Bedarf und der aktuelle Speicherbedarf hinterlegt.
• Ein GUI-Schnittstellenmodul 22 ist vorgesehen, um dem Benutzer des Druckservers 2 Warn- und Fehlernachrichten sowie vorbestimmte Zustandsbeschreibungen zukommen zu lassen. Dieses GUI-Schnittstellenmodul 22 sendet alle Warn- und Fehlernachrichten zu einem GUI-Modul des Druckservers 2, um sie an einer entsprechenden Anzeigeeinrichtung darzustellen. Die vorbestimmten Zustandsbeschreibungen umfassen beispielsweise die gesamte CPU-Belastung, die Belastung eines jeden Dateisystems, die Belastung einer jeden Netzwerkschnittstelle, die Größe des benutzten Arbeitsspeichers, die Größe des Dateicache-Speichers. Diese Statusbeschreibung kann vom Benutzer an der Anzeigeeinrichtung beispielsweise durch Anklicken eines vorbestimmten Icons aufgerufen werden.
• Ein Daten-Interface 23 ist im SRM-Modul 11 vorgesehen, um die im SRM-Modul 11 gesammelten Daten und Statistiken anderen Modulen, insbesondere dem unten näher erläuterten Leistungsausgleichmodul 24 zu Verfügung zu stellen.
• Das SRM-Modul 11 erfasst in regelmäßigen Abständen mittels des Sammel-Triggers 12 Werte systemspezifischer Statusparameter. Hierauf werden die Daten der System-Log-Datei 17, der Prozess-Log-Datei 18 und der Statistiken je nach Bedarf aktualisiert. Das Daten-Interface 23 erzeugt hierbei jedes Mal eine SRS-Nachricht (System Ressource Status Notification), um die zuletzt ausgeführte Aktualisierung der Daten anzuzeigen. Üblicherweise findet sie eine jede Sekunde einmal statt.
• Das Daten-Interface 23 kann auch Nachrichten beim Vorliegen eines Engpasses einer bestimmten Systemressource erzeugen (System Ressource Shortage Modification), welche vor allem bei einem Warn-Zustand oder Fehler-Zustand ausgelöst werden.
• Weiterhin kann das Daten-Interface 23 eine Anfrage (Process-Core-Map-Request) entgegennehmen, welcher Kern bzw. welche Kerne einen vorbestimmten Prozess, insbesondere einem Druckdienst, der CPU zugeordnet werden sollen.
• Das Daten-Interface 23 kann auf eine vorbestimmte Anfrage zum Überwachen der Benutzung der Ressourcen durch einen vorbestimmten Prozess die entsprechenden Werte der Statusparameter dieser Ressourcen sammeln und nach Beendigung des Prozesses mit einer entsprechenden Nachricht (Process Ressource Usage Notification) zurücksenden.
• Weiterhin kann das Daten-Interface 23 eine Anfrage nach dem verfügbaren Speicherplatz einer bestimmten Speichereinrichtung (RAM-Disk, SSD, HD) entgegennehmen und entsprechend beantworten.
• Neben diesen speziellen Anfragen und Nachrichten kann das Daten-Interface 23 insbesondere dem Leistungsausgleichsmodul 24 Zugriff auf einzelne Datenwerte, beliebigen Sätzen von Datenwerten, insbesondere jeweils bestimmte Zustände beschreibende Datensätze und allen Daten, die in der System-Log-Datei, in der Prozess-Log-Datei und in den Statistiken vorliegen, gewähren.
• Zusammenfassend kann somit festgehalten werden, dass mit dem oben erläuterten SRM-Modul 11 Daten von Statusparametern auf Systemebene erfasst, gefiltert durch Daten von Statusparametern auf Prozessebene ergänzt und bei Bedarf archiviert werden können. Eine Besonderheit dieses SRM-Moduls liegt darin, dass Statusparameter auf Systemebene überwacht werden, um einen Zustand mit eingeschränkter Funktionsfähigkeit, insbesondere eine Überlast des Systems festzustellen. Weiterhin können die erfassten Daten statistisch ausgewertet werden und weiteren Modulen, wie zum Beispiel einem GUI-Modul oder einem Leistungsausgleichsmodul zu Verfügung gestellt werden. Darüber hinaus erlaubt das SRM-Modul 11 einen direkten Eingriff auf die Prozesssteuerung auf Systemebene mittels des Programm-Management-Moduls. Das SRM-Modul 11 ist somit ein unmittelbar an das Betriebssystem 8 bzw. an den Kernel eines Betriebssystems gekoppeltes Modul in der Daemonschicht 9 (2).
• Das Leistungsausgleichsmodul 24 ist in dem in 2 dargestellten Schichtmodell zwischen dem SRM-Modul 11 und mehreren Anwendungsprozessen der Anwendungsschicht 10 zwischengeordnet. Diese Anwendungsprozesse umfassen vor allem die oben angesprochenen Druckdienste 25 und die Backendprozesse 26.
• Im Folgenden wird das Leistungsausgleichsmodul (Englisch: Performance Balancer Module) 24 näher erläutert:
• Mit dem Leistungsausgleichsmodul 24 werden am Druckserver Prozesse, insbesondere die Druckdienste 25 und die Backendprozesse 26 gesteuert und so optimiert, dass sowohl der Druckserver 2 als auch die Druckgeräte 3 möglichst optimal ausgelastet sind. Um eine maximale Leistung zu erreichen sind die Ressourcen möglichst optimal auszulasten. Die Anzahl der aktiven Prozesse ist so einzustellen, dass einerseits möglichst wenig Ressourcen unbenutzt sind und andererseits keine Engpässe auftreten, welche für das Scheduling bzw. Arbitrieren der Prozesse/Threads zusätzliche Rechenleistung binden.
• Am Druckserver 2 sind neben dem Leistungsausgleichsmodul 24 noch ein Arbeitsablaufmodul 27 (Englisch: work flow module), ein Lizenz-Management-Modul 28, ein Spooler-Modul 29 (Englisch: printer spool module), ein Druckdienst-Interface 30, ein Prozess-Metadaten-Modul 31 sowie das oben erläuterte SRM-Modul 11 vorgesehen (6). Grundsätzlich ist es möglich, dass zwei Druckserver 2 miteinander gekoppelt sind, wobei die Leistungsnachweismodule 24 der beiden Druckserver 2 Daten über die Druckdienste 25 und die Backendprozesse 26 teilen bzw. austauschen, welche je nach Kapazität über einen der beiden Druckserver 2 abgewickelt werden können. Grundsätzlich werden beiden Druckservern die jeweiligen Druckaufträge übermittelt, welche dann von dem Druckserver bearbeitet werden, der zuerst die benötigten Ressourcen zur Verfügung stellen kann. Vor dem Starten der Abarbeitung eines Druckauftrages prüft der jeweilige Druckserver, ob dieser Druckauftrag nicht vom anderen Druckserver bereits bearbeitet wird. Nur wenn er noch nicht bearbeitet wird, wird die Abarbeitung dieses Druckauftrages gestartet.
• Das Arbeitsablauf-Modul 27 legt die Bearbeitung eines jeden Druckauftrages fest, wobei vor allem die Abfolge der Druckdienste 25 festgelegt wird, mit welchen die im Druckauftrag enthaltenen Druckdaten verarbeitet werden. Die Reihenfolge der Druckdienste 25 ist in 6 symbolisch in dem das Arbeitsablauf-Modul 27 darstellenden Block gezeigt.
• Das Lizenz-Management-Modul 28 enthält die Lizenzinformationen zu den einzelnen Modulen des Druckservers 2. Diese umfassen auch die Lizenzinformationen zu den Druckdiensten 25, wodurch vorgegeben ist, welcher Druckdienst 25 ausgeführt werden kann und wie viel Instanzen (Laufzeitversionen) des jeweiligen Druckdienstes am Druckserver 2 ausgeführt werden dürfen.
• Das Spooler-Modul 29 hält für ein jedes Druckgerät 3 die jeweiligen Druckdaten vor.
• Mit dem Druckdienst-Interface 30 wird die entsprechende Software für die zur Ausführung der Druckdienste 25 zur Verfügung gestellt.
• Das Prozess-Metadaten-Modul 31 sammelt von den gestarteten Druckdiensten 25 Daten und erstellt eine oder mehrere Log-Dateien für die Druckdienste 25.
• Das Arbeitsablaufmodul 27 erstellt aus bestimmten Daten der Druckaufträge, insbesondere aus in den Druckaufträgen enthaltenen Job-Tickets eine Beschreibung der Reihenfolge der einzelnen Schritte, die am Druckserver 2 mit den Druckdaten auszuführen sind. 8 zeigt schematisch den Ablauf der einzelnen Schritte für drei Druckaufträge. Zunächst werden die Druckdaten mittels eines Input-Moduls (IM) 32 eingelesen und dann bei Bedarf mit einem oder mehreren Druckdiensten (S1-S6) 25 verarbeitet. Sind die Druckdaten am Druckserver 2 vollständig verarbeitet, werden sie ausgedruckt (P1: am Druckgerät 1; P2: am Druckgerät 2). Das Prozess-Metadaten-Modul 31 erfasst die Abarbeitung der einzelnen Schritte und erzeugt dann einen Datensatz mit jeweils dem Zeitpunkt des Beginnes und des Endes des jeweiligen Schrittes für einen jeden Druckauftrag.
• Diese Metadaten können einem Benutzer auf einer grafischen Benutzeroberfläche in einer Grafik, ähnlich der aus 8, dargestellt werden.
• Das Arbeitsablaufmodul 27 steuert den Ablauf der einzelnen Arbeitsschritte und insbesondere der Druckdienste 25 und der Backendprozesse 26. Ist ein Druckdienst 25 oder ein Backendprozess 26 zu starten, dann sendet das Arbeitsablaufmodul 27 einen Prozessstartanfrage 39 (Service Start Request) an das Leistungsausgleichsmodul 24.
• Im Leistungsausgleichsmodul 24 ist für jeden Druckdienst 25 eine separate Dienstliste (Englisch: Service Queue) 33 vorgesehen (7). In den einzelnen Dienstlisten 33 sind die entsprechenden Prozessstartanfragen 39 aufgereiht, wobei jede Dienstliste Druckdienstinformationen 40, welche den jeweiligen Druckdienst beschreiben, umfasst. Diese Druckdienstinformationen enthalten bspw. den Namen des jeweiligen Druckdienstes bzw. Backendprozesses, Informationen, ob die entsprechende Lizenz verfügbar ist, Informationen zur Priorität des Druckdienstes bzw. des Backendprozesses und unten näher erläuterte Prozess-Beanspruchungsfaktoren enthalten. Die Prozessstartanfragen 39 enthalten Prozessstartinformationen 41, die die jeweilige Prozessstartanfrage näher präzisieren, wie z.B. den Namen des jeweiligen Druckdienstes bzw. Backendprozesses, Angaben zum Druckgerät, zur Dateigröße, Prioritätsfaktoren und Angaben zum Ressourcenbedarf, wie z.B. weitere Prozess-Beanspruchungsfaktoren.
• Vom Spooler-Modul 29 erhält das Leistungsausgleichsmodul 24 Zustandsinformationen zu den einzelnen Druckgeräten, insbesondere ob sie aktiv sind, die Druckzeit der verfügbaren Druckaufträge, etc. Anhand dieser Statusinformationen des Spooler-Moduls kann das Leistungsausgleichsmodul 24 erkennen, wann welches Druckgerät neue Druckaufträge benötigt, d.h., dass die in einer Druckschlange (=Spool) im Spooler-Modul 29 für ein bestimmtes Druckgerät 3 vorhandenen Druckaufträge eine Bearbeitungszeitdauerschwelle unterschreiten. Ein solches Unterschreiten der Bearbeitungszeitdauerschwelle bedeutet, dass wenn keine neuen Druckaufträge der Druckschlange zugeführt werden, das Druckgerät angehalten werden muss, wenn alle Druckaufträge abgearbeitet worden sind. Dies will man vermeiden. Deshalb setzt das Leistungsausgleichsmodul die Prioritäten von für dieses Druckgerät geeigneten Druckaufträgen hoch.
• Vom SRM-Modul 11 erhält das Leistungsausgleichsmodul 24 die Werte der Zustandsparameter, die die Belastung des Druckservers beschreiben. Dies sind insbesondere die Leerlaufzeit der CPU für die gesamte CPU und jeden einzelnen Kern, der freie Speicherbereich eines jeden Dateisystems sowie die verfügbare Datendurchsatz der Dateisysteme, der verfügbare Arbeitsspeicher, die verfügbare Netzwerkbandbreite für eine jede Schnittstelle zum Netzwerk sowie Informationen zum verwendeten Dateicache-Speicher, welche ungefiltert von der Triggerlogik 13 über das Daten-Interface 23 an das Leistungsausgleichs- Modul 24 übermittelt werden.
• Das Leistungsausgleichsmodul 24 prüft für die einzelnen Prozessstartanfragen die verfügbaren Systemressourcen, berechnet mit unten näher erläuterten Ressourcen-Beanspruchungsfaktoren die zu erwartende Ressourcen-beanspruchung und entscheidet dann anhand der verfügbaren Systemressourcen, ob ein bestimmter Druckdienst bzw. Backendprozess gestartet werden kann. Hierdurch wird vermieden, dass gleichzeitig zu viele Prozesse gestartet sind, und sich bei dem Zugriff auf die Systemressourcen gegenseitig behindern. Hierdurch wird sichergestellt, dass jeder Druckdienst 25 und vor allem jeder Backendprozess 26 ordnungsgemäß ohne Verzögerung am Druckserver 2 ausgeführt werden kann.
• Die hierbei berücksichtigten Systemressourcen sind vor allem eine oder mehrere der folgenden Ressourcen:
• - Lizenzen
• - Leerlaufzeit der CPU
• - Leerlaufzeit der einzelnen Clients der CPU
• - ausreichende Speicherkapazität des bzw. der benötigten Dateisysteme
• - ausreichend Ein- und Ausgabebandbreite zu den benötigten Dateisystemen
• - ausreichender Arbeitsspeicher
• - verfügbare Lizenz
• - verfügbares Druckgerät.
• Grundsätzlich können noch weitere Faktoren berücksichtigt werden, wie z.B.
• - Die Priorität eines jeden Druckdienstes,
• - falls die Eingabe- oder Ausgabedatei nicht auf einem lokalen Dateisystem vorhanden ist, dann ist die freie Bandbreite des Netzwerkes zu berücksichtigen.
• Die Priorität kann aus folgenden Komponenten zusammengesetzt sein (mit absteigender Bedeutung aufgeführt):
1. 1) Druckaufträge für bestimmten Drucker umfassen weniger als n Minuten Druckzeit
2. 2) Vom Nutzer festgelegte Priorität der Druckaufträge
3. 3) Eingabedatei ist im Dateicache-Speicher
4. 4) Anzahl der abgearbeiteten Prozessschritte bzw. Druckdienste (je mehr Druckdienste abgearbeitet sind, desto höher ist die Priorität)
5. 5) Anzahl der Prozessschritte, welche noch auszuführen sind (je mehr Prozessschritte auszuführen sind, desto höher ist die Priorität)
6. 6) Wartezeit für die Druckdienste (Priorität nimmt mit zunehmender Wartezeit zu).
• Wenn für ein Druckgerät Druckaufträge für eine Druckzeit von weniger als n Minuten zur Verfügung stehen, dann führt die Erhöhung der Priorität zu einer Bevorzugung eines geeigneten Druckauftrages, womit für dieses Druckgerät wieder ausreichend Druckaufträge bereit gestellt werden.
• Wenn sich die Eingabedatei im Dateicache-Speicher befindet, dann kann sie schnell, d.h. ohne einem langsamen Zugriff auf die Festplatte, weiter bearbeitet werden, weshalb es sinnvoll ist, in diesem Fall die Priorität hoch zu setzen. Jedem Druckdienst sind die Ressourcen-Beanspruchungsfaktoren (Englisch: Ressource Usage Factors) zugeordnet. Die Ressourcen-Beanspruchungsfaktoren sind für die unterschiedlichen Ressourcen des Druckservers 2 und insbesondere für die unterschiedlichen Systemressourcen vorgesehen. Die Ressourcen-Beanspruchungsfaktoren beschreiben, wie stark der jeweilige Druckdienst bzw. Backendprozess die entsprechende Ressource in Anspruch nimmt. Die meisten Ressourcen-Beanspruchungsfaktoren sind mit der Dateigröße der zu verarbeitenden Datei zu multiplizieren, um die Beanspruchung bzw. die Last, die durch die Verarbeitung dieser Datei mittels dieses Druckdienstes verursacht wird, zu bestimmen. Um die zu erwartende Beanspruchung zu berechnen, können die Ressourcen-Beanspruchungsfaktoren an Stelle einer Multiplikation auch auf andere Weise mit vorbestimmten Werten, wie z.B. der Dateigröße, Datendurchsätze, Speicherbereiche, Steuerparameter, welche angeben, wie die einzelnen Dienste ausgeführt werden, etc. verknüpft werden. Diese Steuerparameter fordern bspw. bestimmte Schreib- oder Lesevorgänge, indem sie definieren, dass ein Datei vervielfältigt, geändert (insbesondere konvertiert) oder gelöscht werden soll.
• Diese Ressourcen-Beanspruchungsfaktoren erlauben dem Leistungsausgleichsmodul 24 somit eine Vorhersage, wie lang die Ausführung des jeweiligen Druckdienstes zur Bearbeitung einer bestimmten Datei dauert und welche Ressourcen hierbei in Anspruch genommen werden. Mit der oben erläuterten Prozess-Ressource-Beanspruchungsnachricht (Process Ressource Usage Modification), die vom Daten-Interface 23 erzeugt wird, kann das Leistungsausgleichsmodul 24 aktuelle Informationen über die Ressourcen-Beanspruchung eines bestimmten Dienstes zum Verarbeiten eines bestimmten Druckauftrages bzw. einer bestimmten Druckdatei erhalten. Mit diesen Daten können die Prozess-Beanspruchungsfaktoren an die aktuellen Werte angepasst und aktualisiert werden. Hierdurch wird die statistische Basis der Ressourcen-Beanspruchungsfaktoren mit der Zeit immer breiter und die Zuverlässigkeit der Vorhersage entsprechend besser.
• Diese Ressource-Beanspruchungsfaktoren können neben dem Leistungsausgleichsmodul 24 auch vom Arbeitsablaufmodul 27 zur Bestimmung der Ausführungszeit der einzelnen Druckdienste verwendet werden.
• Für das Leistungsausgleichsmodul 24 ist nicht nur die Abschätzung der Zeitdauer der Ausführung eines Druckdienstes 25, sondern auch die Abschätzung der Beanspruchung der einzelnen Ressourcen wichtig, um zu entscheiden, ob ein Druckdienst 25 gestartet werden kann. Da mit dem SRM-Modul 11 eine große Datenbasis für den aktuellen Ressourcen-Verbrauch vorhanden ist, ohne dass die Erzeugung dieser Datenbasis viel Rechenzeit des Druckservers 2 in Anspruch nimmt, kann das Leistungsausgleichsmodul 24 sehr präzise die Ressourcen-Beanspruchung durch die einzelnen Druckdienste und Backendprozesse abschätzen und sicherstellen, dass am Druckserver 2 nicht zu viele Druckdienste 25 und Backendprozesse 26 parallel gestartet werden, wodurch eine Überlastsituation eintreten würde, welche ein unbeabsichtigtes Anhalten eines der Druckgeräte verursachen könnte. Andererseits können auch bestimmte Druckdienste 25, die mehr Ressourcen beanspruchten als zur Verfügung stehen, zurückgestellt werden und andere Druckdienste gestartet werden, die weniger Ressourcen beanspruchen und vor allem diese Ressourcen beanspruchen, die frei sind. Hierdurch wird die Auslastung des Druckservers 2 optimiert, so dass bei gleicher Computerkapazität ein größerer Durchsatz an Druckaufträgen möglich ist.
• Das Leistungsausgleichsmodul 24 kann auch Einfluss auf die abzuarbeitenden Druckdienste 25 bzw. Backendprozesse 26 dahingehend nehmen, dass sich die Schreib- und Lesebelastung der Speichereinrichtungen des Druckservers 2 verringert und so die Bearbeitung der Druckaufträge beschleunigt wird.
• 3a zeigt ein herkömmliches Speichersystem für einen Druckserver. Dieses Speichersystem weist eine erste logische Festplatte 34 und eine zweite logische Festplatte 35 auf. Ein drittes Massenspeichermedium 36 ist vorgesehen, das zur Aufnahme vom Betriebssystem, von Anwendungsprogrammen, von Steuerdaten und Trace-Daten dient. Die erste Festplatte 34 dient zur Aufnahme der Druckdaten (PD: Print Data) und die zweite Festplatte 35 zur Aufnahme der zum Drucken bereits vorbereiteten Druckdaten (R2P: Ready to Print). Mit dem Inputmodul 32 werden eingehende Druckaufträge (PD) auf die erste Festplatte geschrieben. Beim Durchführen eines der Druckdienste 25 werden die Druckdaten jeweils von der ersten Festplatte 34 in den Arbeitsspeicher gelesen, bearbeitet und wieder auf die erste Festplatte 34 geschrieben. Dies wird für jeden Druckdienst wiederholt. Nach dem letzten Druckdienst Sn werden die Druckdaten von der ersten Festplatte 34 auf die zweite Festplatte 35 (R2P) kopiert. Von der zweiten Festplatte 35 werden sie mit einem Backendprozess 26 zu dem entsprechenden Druckgerät 3 übermittelt. Jeder Schreib- und Lesevorgang benötigt entsprechende Rechenzeit zum Schreiben und zum Lesen der Daten von und zur Festplatte.
• Eine erste Möglichkeit zur Beschleunigung des Verfahrens besteht darin, die Priorität eines Druckdienstes 25 durch das Leistungsausgleichsmodul 24 hoch zu setzen, wenn sich die entsprechenden Daten im Dateicache-Speicher befinden. Sie können dann aus dem Dateicache-Speicher gelesen und dort wieder abgelegt werden. Hierdurch wird zumindest ein Lese- oder ein Schreibvorgang auf der ersten Festplatte 34 vermieden.
• Die Kombination aus der Verwendung des Dateicache-Speichers und der nicht flüchtigen Speicher 34, 35 zur Speicherung der mittels des Input-Moduls erhaltenen Version der Druckdaten und der vollständig für den Druckvorgang aufbereiteten Druckdaten bewirkt eine hohe Betriebssicherheit und trotzdem eine im Vergleich zu herkömmlichen Verfahren erhebliche Durchsatzsteigerung.
• Das Leistungsausgleichsmodul 24 kann steuern, dass sich nur bestimmte Dateien im Dateicache befinden.
• Das Leistungsausgleichsmodul 24 kann folgendermaßen auf den Dateicache Einfluss nehmen:
• - Das Leistungsausgleichmodul 24 kann Dateien bzw. eine bestimmte Datei im Dateicache löschen, indem es einen entsprechenden Löschauftrag an das SRM-Modul 11 abgibt, das den Löschvorgang ausführt.
• - Das Leistungsausgleichsmodul 24 kann bspw. aus den Prozessstartanfragen die Information erhalten, welcher Prozess (Druckdienst oder Backendprozess) den Dateicache benutzt. So kann das Leistungsausgleichsmodul gezielt einen oder mehrere Prozesse starten, die den Dateicache benutzen.
• - Das Leistungsausgleichsmodul 24 kann Prozesse so starten, dass sie die von ihnen bearbeiteten Dateien sofort aus dem Dateicache löschen, wenn sie nicht mehr benötigt werden.
• Da das Leistungsausgleichsmodul sowohl systemspezifische Informationen, welche bspw. vom Sammel-Trigger eingelesen werden, als auch prozessspezifischen Informationen auswerten kann, welche bspw. vom Sammel-Filter eingelesen oder in der Dienstliste 33 oder den Prozessstartanfragen enthalten sind, kann das Leistungsausgleichsmodul 24 auf das System Einfluss nehmen, wobei bei dieser Einflussnahme Informationen auf Prozessebene berücksichtigt werden. Die Steuerung der Dateien im Dateicache ist hierfür ein typisches Beispiel.
• Eine zweite Möglichkeit, die alternativ oder in Kombination mit der ersten Möglichkeit angewendet werden kann, um die Verarbeitung der Druckdaten zu beschleunigen, liegt darin, zusätzlich eine RAM-Disk 37 oder eine SSD (Raid 0) vorzusehen (3b). Eine RAM-Disk ist ein virtueller und temporärer Datenträger im Arbeitsspeicher (RAM) eines Computers. Ein gewisser Anteil des Arbeitsspeichers wird statisch oder auch dynamisch für die RAM-Disk reserviert und dabei wie eine Festplatte oder wie ein Extra-Laufwerk angesprochen. Eine RAM-Disk ist in der Größe begrenzt, aber extrem schnell. Zudem wird die RAM-Disk vom Betriebssystem wie eine Festplatte verwaltet, so dass die in der RAM-Disk gespeicherten Daten nicht auf die Festplatte geschrieben werden. Bei Verwendung einer RAM-Disk ist die mit den Druckdiensten 25 zu bearbeitende Datei so zu wählen oder gegebenenfalls zu teilen, dass die vollständige Datei in der RAM-Disk gespeichert werden kann, so dass alle Druckdienste 25 an dieser Datei ausgeführt werden können, ohne dass eine Rückspeicherung auf eine Festplatte notwendig ist. Das Leistungsausgleichsmodul 24 kann bei einer vorgegebenen RAM-Disk beurteilen, ob die zu bearbeitende Druckdatei während der Bearbeitung durch die Druckdienste auf der RAM-Disk verbleiben kann. Wenn dies der Fall ist, dann ist es vorteilhaft, wenn das Leistungsausgleichsmodul 24 die entsprechenden Druckdienste 25 zum Bearbeiten der Druckdaten auf der RAM-Disk startet. Wenn die zu verarbeitende Druckdatei zu groß ist, dann ist zu prüfen, ob die Druckdatei geteilt werden kann, so dass die einzelnen Teile der Druckdatei unabhängig voneinander auf einem Druckgerät ausgedruckt werden. Wenn dies möglich ist, dann wird die Druckdatei entsprechend unterteilt, so dass die geteilten Abschnitte der Druckdatei auf der RAM-Disk mittels der Druckdienste 25 bearbeitet und dann die zum Drucken vorbereiteten Druckdaten auf der ersten logischen Festplatte 34 gespeichert. Von dort werden die Druckdaten auf die zweite logische Festplatte 35 kopiert, um mittels des Backendprozesses 26 zum Druckgerät übermittelt zu werden. Die in der RAM-Disk zu speichernden Druckdateien können vom SRM-Modul verwaltet werden.
• Diesem Verfahren liegt die Erkenntnis zugrunde, dass für die Ausführung des Verfahrens nur die erste Version der Druckdatendatei, die vom Inputmodul 32 auf die erste Festplatte 34 geschrieben wird, und die letzte vollständig für den Druckvorgang vorbereitete Version der Druckdatendatei, die auf die zweite Festplatte 35 kopiert wird, von Bedeutung sind. Wenn durch einen Systemfehler das Verfahren unterbrochen wird und die dazwischen erzeugten Versionen verlorengehen, dann kann das Bearbeitungsverfahren wieder schnell aufgenommen werden, wenn diese beiden Versionen vorhanden sind, da aus der ersten Version mit den Druckdatendiensten 25 die Zwischenversionen wieder herstellbar sind und wenn die letzte Version vorhanden ist, das Übermitteln der Daten zum Druckgerät fortgesetzt werden kann, ohne dass das Druckgerät warten muss, bis die Daten wieder vollständig aufbereitet sind.
• Ein weiterer Vorteil der Verwendung einer RAM-Disk liegt darin, dass bei Drucksystemen oftmals die auf einer Festplatte gespeicherten Daten zu verschlüsseln sind. Ist die RAM-Disk ein flüchtiger Datenspeicher, was die Regel ist, dann ist keine Verschlüsselung notwendig. Das bedeutet, dass zwischen den einzelnen Druckdiensten 25 keine Ver- und Entschlüsselung durchzuführen ist, was die Bearbeitungsgeschwindigkeit weiter steigert und die Systemressourcen schont, da eine Ver- oder Entschlüsselung erheblich die CPU in Anspruch nimmt.
• Die Kombination aus der Verwendung einer RAM-Disk 37 in Verbindung mit dem Leistungsausgleichsmodul 24, das vorab überprüft, ob die Verarbeitung der Druckdaten auf der RAM-Disk möglich ist, erlaubt eine erhebliche Beschleunigung des Verfahrens.
• Die erste Festplatte 34 kann hierbei mit einer großen Speicherkapazität und geringer Bearbeitungsgeschwindigkeit ausgebildet sein. Derartige Festplatten sind kostengünstig und erlauben die Zwischenspeicherung mehrerer Druckaufträge. Bei einer solchen Ausführungsform können die Kosten im Vergleich zu einer herkömmlichen Speicherstruktur erheblich gesenkt werden, da es bisher üblich war, die erste und zweite Festplatte 34, 35 mit großer Speicherkapazität und hohem Durchsatz vorzusehen, was entsprechend teuer ist.
• Anstelle einer RAM-Disk kann auch eine SSD verwendet werden. Eine SSD kann mit größerer Speicherkapazität vorgesehen werden, weshalb die bei einer RAM-Disk auftretenden Beschränkungen hier nicht vorliegen. Jedoch ist eine SSD wesentlich langsamer als eine RAM-Disk jedoch schneller als eine herkömmliche Festplatte. Zusätzlich wird eine SSD wie eine Festplatte vom Betriebssystem angesteuert und die Daten können automatisch entsprechend verschlüsselt werden, was die Bearbeitungsgeschwindigkeit weiter einschränkt. Daher wird grundsätzlich eine RAM-Disk gegenüber einer SSD bevorzugt.
• Das Leistungsausgleichsmodul kann vorzugsweise so ausgebildet sein, dass bei Verwendung einer RAM-Disk oder einer SSD die RAM-Disk oder die SSD zum Speichern von Druckdaten durch vorbestimmte Prozesse verwendet wird, ohne dass hierfür der Dateicache benutzt wird, der dann einem oder mehreren anderen Prozessen ausschließlich zur Verfügung gestellt wird.
• Gleichermaßen, ob eine RAM-Disk verwendet wird oder gemäß der ersten Möglichkeit die Prioritäten so gesteuert werden, dass die Dateien beim Bearbeiten durch die Druckdienste im Dateicache-Speicher verbleiben, wird der Durchsatz erheblich beschleunigt. Dies bedeutet, dass entweder weniger Hardware-Ressourcen notwendig sind, um den gleichen Durchsatz zu erzielen oder dass ein höherer Durchsatz bei ähnlichen Hardwarekapazitäten erzielt wird.
• Grundsätzlich ist es auch möglich, das Drucksystem gemäß 3b mit einer zweiten Festplatte 35 und einer RAM-Disk 37 auszubilden und je nach Größe der Druckdateien die Verarbeitung der jeweiligen Druckdatei auf der RAM-Disk 37 oder der zweiten Festplatte 35 durchzuführen.
• Oben wurde bereits erläutert, dass mittels des Prozess-Manager-Moduls 21 die Prozesse zunächst jeweils einem Kern der CPU zugeordnet werden und erst wenn allen Kernen ein Prozess zugeordnet ist, dann wird einem der Kerne ein weiterer Prozess zugeordnet und dieser Kern im Hyper-Thread-Modus betrieben, wobei sich zwei Prozesse einen Kern teilen. Diese Zuordnung kann vom Leistungsausgleichsmodul 24 gesteuert werden, das die einzelnen Druckdienste 25 startet und ihnen hierbei einen entsprechenden Kern zuordnet.
• Das Leistungsausgleichsmodul 24 kann auch dazu eingesetzt werden, die Benutzung der Dateicache-Speichers zu optimieren. Mittels des Prozess-Management-Moduls 21 kennt das Leistungsausgleichsmodul 24 den verfügbaren Speicherplatz des Dateicache-Speichers und welche Dateien sich darin befinden.
• Das Leistungsausgleichsmodul 24 prüft vorzugsweise, ob die im Dateicache-Speicher befindlichen Dateien durch weitere Druckdienste 25 zu bearbeiten sind und/oder mittels der Backendprozesse 26 aus dem Dateicache-Speicher ohne Unterbrechung direkt an das Druckgerät 3 übermittelt werden können. Ist dies der Fall, dann werden die Prioritäten der entsprechenden Druckdienste 25 hoch gesetzt, so dass die im Dateicache-Speicher befindlichen Druckdaten, ohne auf einer Festplatte zwischengespeichert zu werden, weiter verarbeitet werden.
• Weiterhin kann das Leistungsausgleichsmodul 24 prüfen, ob die im Dateicache-Speicher enthaltenen Dateien noch weiter von einem anderen Prozess zu bearbeiten sind. Durch ein aufeinanderfolgendes Bearbeiten der im Dateicache-Speicher enthaltenen Dateien ist es nicht notwendig diese mehrfach in den Dateicache-Speicher von der Festplatte zu lesen. Bei einem aufeinanderfolgenden Bearbeiten einer sich im Dateicache-Speicher befindlichen Datei kann eine Übertragung der Datei aus dem Dateicache-Speicher auf eine Festplatte zwischen den einzelnen Bearbeitungen der unterschiedlichen Prozesse unterdrückt werden. Bei einem Dateicache-Speicher kann ein Schreiben der Daten nur mittelbar unterdrückt werden, indem die einzelnen Schritte ohne Unterbrechung ausgeführt werden, dass das Betriebssystem die automatische und grundsätzlich nicht unterdrückbare Sicherung auf die Festplatte nicht ausführt. Das Sichern der Daten aus dem Dateicache-Speicher kann nur sicher vermieden werden, wenn die entsprechenden Daten im Dateicache-Speicher oder die entsprechende Datei generell gelöscht werden.
• Bei Verwendung einer RAM-Disk kann hingegen das Verfahren so gesteuert werden, dass ein Zwischenspeicher der zu bearbeitenden Dateien bzw. Druckdaten grundsätzlich nicht ausgeführt wird und die Dateien bzw. Druckdaten nur an bestimmten Verarbeitungsschritten, insbesondere erst nach der vollständigen Ausführung aller Druckdienste auf die Festplatte gespeichert werden.
• Bei diesen beiden Verfahren werden einerseits Informationen, die auf Systemebene gewonnen werden (Name der Datei im Dateicache-Speicher bzw. freie Speicherkapazität des Dateicache-Speichers), und Informationen auf Prozessebene (die im Dateicache-Speicher enthaltene Datei kann weiter bearbeitet werden oder nicht) berücksichtigt, um zu entscheiden, wie die Prioritäten der Druckdienste bzw. Backendprozesse gesetzt werden, um den weiteren Verarbeitungsablauf dementsprechend zu steuern. Die Verknüpfung von systemspezifischen als auch prozessspezifischen Informationen erlaubt eine erhebliche Effizienzsteigerung.
• Ein weiteres Verfahren zur Beschleunigung der Bearbeitung der Druckdaten liegt in der dynamischen Steuerung der Benutzung der System-Ressourcen durch das Leistungsausgleichsmodul 24.
• Da das SRM-Modul 11 auf Systemebene Statusparameter regelmäßig abfragt und die entsprechenden Werte entweder unmittelbar oder mittelbar in Form von einer statistischen Auswertung oder in Form von einem aus mehreren einzelnen Werten kombinierten Wert mittels des Daten-Interfaces 23 dem Leistungsausgleichsmodul 24 zur Verfügung stellt, kann dieses die Prozesse während der Ausführung der Prozesse so steuern, dass die Ressourcen-Ausnutzung bzgl. des gesamten Systems optimiert ist.
• Beispielsweise kann es zweckmäßig sein, bestimmte Prozesse nur auf einem CPU-Chip auszuführen. Dies kann vom Leistungsausgleichsmodul bspw. durch Zuordnen eines CPU-Chips zu einem Prozess mittels einer CPU-Kernmaske beim Start des jeweiligen Prozesses gesteuert werden. Hierdurch wird vermieden, dass die Daten, die bei diesem Prozess bearbeitet werden, nicht auf unterschiedliche Arbeitsspeicher aufgeteilt werden , was zusätzlich Rechenleistung beansprucht, weil der Zugriff auf Daten, die im Arbeitsspeicher eines anderen CPU-Chips gespeichert sind, langsam ist.
• Die einzelnen Prozesse können vom Leistungsausgleichsmodul auch bestimmten Kernen der CPU-Chips zugeordnet werden, wie oben bei der Erläuterung des Prozess-Management-Moduls 21 bereits kurz beschrieben ist. Bei einer Prozesstartanfrage durch das Arbeitsablaufmodul 27 wird diese zunächst durch das Leistungsausgleichsmodul geprüft. Hierbei kann das Leistungsausgleichsmodul vom SRM-Modul, insbesondere dem Prozess-Management-Modul 21 eine aktuelle CPU-Kernmaske abfragen, in welcher angegeben ist, welcher Prozess auf welchem Kern ausgeführt werden darf. Das Leistungsausgleichsmodul kann dann dem neuen Prozess einen oder mehrere Kerne zuordnen und dies in der Kernmaske notieren. Diese Kernmaske wird dann beim Start eines Prozesses an das Betriebssystem, insbesondere dem Kernel übergeben. Der Prozess wird dann so gestartet, dass er nur auf den zugewiesenen Kernen ausgeführt wird. Hierdurch kann ein der Einsatz von Hyper-Threading gering gehalten und die Kerne optimal ausgelastet werden.
• Weiterhin kann das Leistungsausgleichsmodul anhand der vom SRM-Modul zur Verfügung gestellten Informationen nichtbenötigte Speicherkapazität, die für einen bestimmten Prozess reserviert ist, erkennen und freigeben. Hierzu sind in der Software der Druckdienste Programmabschnitte enthalten, mit welchen das Leistungsausgleichsmodul direkt kommunizieren kann, so dass die Druckdienste bzw. deren Laufzeitinstanzen mit dem Leistungsausgleichsmodul sich austauschen, um verfügbaren Speicherbereich festzustellen und bei Bedarf zu löschen. Hierdurch kann die Speicherkapazität insgesamt besser ausgelastet werden.
• Wenn innerhalb eines vorbestimmten Abtastintervalles, von zum Beispiel einer Sekunde, festgestellt wird, dass bestimmte Systemkapazitäten ausgeschöpft sind oder ausgeschöpft werden, insbesondere die Ein- und Ausgabebandbreiten eines Dateisystemes, einer Speichereinrichtung und/oder eines Netzwerkes, dann können bestimmte Druckdienste bzw. deren Laufzeitinstanzen vom Leistungsausgleichsmodul 24 für eine vorbestimmte Dauer und insbesondere die restliche Dauer des Abtastintervals schlafen gelegt werden, so dass andere Prozesse die anderen Ressourcen ungehindert nutzen können. Auch hierzu sind in der Software der Druckdienste Programmabschnitte enthalten, mit welchen das Leistungsausgleichsmodul direkt kommunizieren kann, wobei die Software einen Verzögerungsabschnitt enthält, so dass das Leistungsausgleichsmodul die Druckdienste bzw. deren Laufzeitinstanzen direkt ansteuern kann, um sie zu verzögern. Eine solche Verzögerung ist vor allem dann zweckmäßig, wenn ein Backendprozess die Ressourcen benötigt, die von dem verzögerbaren Druckdienst beansprucht werden.
• Die Druckdienste können somit Programmabschnitte aufweisen, welche zu Steuerungszwecke mit dem Leistungsausgleichsmodul direkt kommunizieren und/oder direkt vom Leistungsausgleichsmodul ansteuerbar sind, um während ihrer Laufzeit in der Ausführung verändert zu werden.
• Oben sind unterschiedlichste Verfahren aufgeführt, um Einfluss auf die Auslastung des Druckservers zu nehmen. Grundsätzlich werden bei diesen Verfahren somit Systemzustände, die mittels der überwachten Systemparameter erfasst werden, vom Leistungsausgleichsmodul 24 genutzt, um in den Ablauf bestehender Prozesse einzugreifen. Dies zeigt ein grundsätzliches Prinzip der vorliegenden Erfindung, dass eine Überwachung von Systemparametern genutzt wird, um in Kenntnis der Prozesse diese mittels des Leistungsausgleichsmoduls 24 auf Prozessebene intelligent zu steuern, so dass der gesamte Durchsatz optimiert wird. Das SRM-Modul stellt somit auf intelligente Art und Weise Informationen über den Zustand des Systems auf Betriebssystem- als auch Prozessebene zur Verfügung, welche von dem Leistungsausgleichsmodul zur Steuerung des gesamten Systems genutzt werden, wobei auf Betriebssystemebene eingegriffen werden kann, indem den einzelnen Prozessen bestimmte Ressourcen zugeordnet werden oder für diese Prozesse freigegeben werden, wie bspw. die Benutzung bestimmter Speicherbereiche bzw. Speichertypen durch bestimmte Prozesse, insbesondere des Dateicache-Speichers, und/oder die Verteilung von Prozessen auf CPU-Chips und/oder Kernels, oder die Prioritäten der einzelnen Prozesse gesteuert werden.
• Bezugszeichenliste

1

Drucksystem

2

Druckserver

3

Druckgerät

4

Datenleitung

5

Internet

6

Client

7

Hardwareschicht

8

Betriebssystemschicht

9

Systemdienstschicht

10

Anwendungsschicht

11

SRM-Modul

12

Sammel-Trigger

13

Triggerlogik

14

Sammel-Filter

15

Filterlogik

16

Log-Modul

17

System-Log-Datei

18

Prozess-Log-Datei

19

Aktionsmodul

20

Statistikmodul

21

Prozess-Management-Modul

22

GUI-Schnittstellenmodul

23

Daten-Interface

24

Leistungsausgleichsmodul

25

Druckdienst

26

Backendprozess

27

Arbeitsablaufmodul

28

Lizenz-Management-Modul

29

Spooler-Modul

30

Druckdienst-Interface

31

Prozess-Metadaten-Modul

32

Input-Modul

33

Dienstliste

34

erste Festplatte

35

zweite Festplatte

36

Massenspeicher

37

RAM-Disk

38

Statistikdatei

39

Prozessstartanfrage

40

Druckdienstinformationen

41

Prozessstartinformationen

• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• DE 102008037651 B4 [0008]

Claims (18)

1. Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme umfassend folgende Schritte: - Überwachen von Zustandsparametern, welche Systemzustände, wie z.B. die Belastung einer CPU, eines Arbeitsspeicher, eines Dateisystems, eines Netzwerkes und/oder einer Systemschnittstelle, beschreiben, mittels eines Sammel-Triggers (12), - Triggern von Filtern zum Lesen weiterer Zustandsparameter, welche Prozesszustände von am Druckserver (2) ausgeführten Anwendungsprozessen umfassen, wobei das Triggern mit einer Triggerlogik (13) ausgeführt wird, in Abhängigkeit davon, ob die mit dem Sammel-Trigger (12) überwachten Systemzustände einen außergewöhnlichen Betriebszustand darstellen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Sammel-Trigger (12) und die Triggerlogik (13) jeweils mit separaten Threads ausgeführt werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Triggerlogik (13) einen außergewöhnlichen Betriebszustand dadurch bestimmt, dass zumindest ein Wert eines überwachten Zustandsparameters einen vorbestimmten Schwellwert über- oder unterschreitet.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, das die Anzahl der mit dem Sammel-Trigger (12) überwachten Zustandsparameter nicht größer als fünfzig und vorzugsweise nicht größer als zwanzig ist.
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass die Zustandswert bezüglich eines Warn-Schwellwertes und bezüglich eines sich vom Warn-schwellwert unterscheidenden Fehler-Schwellwertes überwacht werden, wobei beim Über- oder Unterschreiten eine Warn- bzw. Fehlermeldung und/oder eine Warn- bzw. Fehleraktion ausgeführt werden können, welche individuell vorab konfigurierbar sind.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Filter zum Lesen der Prozesszustände in einem Sammel-Filter (14) zusammengefasst sind und eine Filterlogik (15) vorgesehen ist, wobei mit der Filterlogik Werte von vorbestimmten Zustandsparametern von Prozesszuständen gefiltert werden.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Sammel-Filter (14) und die Filterlogik (15) in separaten Threads ausgeführt werden.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass mit Filterregeln der Filterlogik (15) geprüft wird, ob ein oder mehrere Werte von Zustandsparametern vorbestimmte Schwellwerte unter- oder überschreiten, um einen außergewöhnlichen Betriebszustand festzustellen.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass ein oder mehrere getriggerte Filter eine vorbestimmte Zeitdauer weiter aktiv sind, nachdem der erfasste außergewöhnliche Betriebszustand zu Ende ist.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass mittels eines Daten-Interfaces (23) die beim Überwachen erfassten und ggfs. gefilterten Werte der Zustandsparameter einem Leistungsausgleichsmodul (24) zum Steuern von Druckdiensten (25) bereit gestellt werden.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass mittels eines Statistik-Moduls (20) die beim Überwachen erfassten und ggfs. gefilterten Werte der Zustandsparameter statistisch ausgewertet werden.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass das Statistik-Modul (20) Werte von prozessspezifischen Parametern mit den Werten von systemspezifischen Parametern statistisch verknüpft.
13. Verfahren nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass das Statistik-Modul (20) Werte von prozessspezifischen Parametern mit Werten von threadspezifischen Parametern statistisch verknüpft.
14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass mittels eines Log-Moduls (16) die gelesenen und ggfs. gefilterten Werte der Zustandsparameter in zumindest eine Log-Datei (17, 18) abgespeichert wird.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass das Überwachen von Zustandsparametern mittels des Sammel-Triggers (12) entweder in regelmäßigen Zeitabständen, von bspw. 0,1 sec. bis 60 sec., oder in Abhängigkeit eines erfassten Lastzustandes in variablen Zeitabständen ausgeführt wird, wobei die variablen Zeitabstände umso länger sind je geringer der erfasste Lastzustand ist.
16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass auf laufende Prozesse eingewirkt wird entweder mittels eines Prozess-Management-Moduls (21), das vorbestimmte Systemparameter verändern kann, oder mittels eines Leistungsausgleichsmoduls (24), das auf vorbestimmte Prozesse direkt während der Laufzeit einwirken kann.
17. Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass vorbestimmte Parameter eines Dateicache-Speichers eingelesen und für die weitere Steuerung des Betriebes des Druckservers (2) zur Verfügung gestellt werden, wobei diese vorbestimmten Parameter insbesondere den bzw. die Dateinamen der im Dateicache-Speicher gespeicherten Dateien, die Größe der im Dateicache-Speicher gespeicherten Dateien und/oder den freien Speicherbereich des Dateicache-Speichers umfassen.
18. Druckserver für digitale Hochleistungsdrucksysteme mit dem Druckaufträge empfangen, mit vorbestimmten Anwendungsprozessen verarbeitet und an ein oder mehrere Druckgeräte weiter geleitet werden, umfassend eine CPU, eine Speichereinrichtung, wobei der Druckserver (2) mit einem Computerprogramm versehen ist, das zum Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 17 ausgebildet ist.

Images