WO2015010891A1 - Verfahren zur ermittlung des ressourcenverbrauchs einer software-komponente - Google Patents

Verfahren zur ermittlung des ressourcenverbrauchs einer software-komponente Download PDF

Info

Publication number
WO2015010891A1
WO2015010891A1 PCT/EP2014/064585 EP2014064585W WO2015010891A1 WO 2015010891 A1 WO2015010891 A1 WO 2015010891A1 EP 2014064585 W EP2014064585 W EP 2014064585W WO 2015010891 A1 WO2015010891 A1 WO 2015010891A1
Authority
WO
WIPO (PCT)
Prior art keywords
load
software component
computer system
determining
total load
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2014/064585
Other languages
English (en)
French (fr)
Inventor
Marc Heinlein
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aumovio Germany GmbH
Original Assignee
Continental Automotive Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of WO2015010891A1 publication Critical patent/WO2015010891A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Definitions

  • the invention relates to a method, a computer program and a computer readable medium for determining resource consumption of a software component and a Rechnersys ⁇ tem.
  • the individual computation time consumptions of all parallel runtime contexts (such as processes, threads or tasks) present in a computer system have hitherto been measured and assigned to the individual software components.
  • a software component may include many (approximately more than 100) runtime contexts. To determine the computing time consumption, therefore, normally all runtime contexts belonging to the respective software component must be known and clearly identifiable.
  • One aspect of the invention relates to a method for determining the resource consumption of a software component in a computer system.
  • a computer system can also be called computer or computer system.
  • a computer system may include a processor, memory, and peripherals.
  • a software component can be and a lot of runtime contexts and processes that are activated or loaded simultaneously (independent) Com ⁇ puter program.
  • a resource can be, for example, computing time, memory and / or a network bandwidth. That is, the consumption Res ⁇ source may include a computing time a memory consumption and / or network usage.
  • the method comprises the steps of:
  • runtime contexts are taken into account, the other software components are associated, but because of the activity of the software component consume resources (such as computing times, such as those incurred by con ⁇ peting accesses).
  • Under load or computational load can be understood how much computing time per unit time or CPU budget of a software component, a runtime context or the
  • the load can be specified in percent.
  • the load may be an average over a given period of time over the current utilization of the computer system or its processor (or its processors).
  • the total load of the system can be determined in such a way that the load of an idling process or idle runtime context is subtracted from a maximum total load (approximately 100%).
  • Activating a software component can be understood as starting the software component.
  • the software component can be loaded into a main memory of the computer system and then executed.
  • a software component can be as active until it is no longer running, for example by all their running time ⁇ contexts are stopped.
  • the method measures the resource consumption of the overall system before, during and / or after the activity of the software component. Before the activity, this resource consumption thus corresponds to the base load of the entire system without the load of the activated software component.
  • this resource consumption less the base load is equal to the resource consumption caused by the activated software component (regardless of the runtime context it consumes).
  • this resource consumption minus the base load corresponds to the increase in the base load caused by the activated software component (irrespective of the runtime context in which it is created).
  • the software component is activated when only system components contributing to the general base load are active.
  • the system components contributing to the general base load may include, for example, an operating system and / or drivers. In this way it can be determined which computer times are only caused by the software component. For example, only individual software components can be put into activity to measure their resource consumption.
  • the software component can be activated if one or more other software components are already active in order to determine their interaction with the software component activated during the method.
  • the base load of the computer system can be defined by the Systemkompo ⁇ component, such as the operating system or the drivers.
  • the base load may be the load yours, which is present if only these components are active.
  • the method further comprises the steps of:
  • the method further comprises the steps of:
  • this initial load includes the load of the runtime contexts of the software component during initialization and a load of other components of the computer system generated by the initialization.
  • one end of the initialization phase is determined by the fact that the Ge ⁇ total load has set value to a time not more variable Intellast-. After the software component has completed its initialization phase, the total load on the computer system will stabilize at a (reasonably) constant value. Another possibility is that to send vermes ⁇ software component sends a signal that the end of the initialization signal.
  • the method further comprises the steps of:
  • the method can further determine a base load for the software component. It should be understood that these base load comprises the base load runtime contexts of Soft ⁇ ware component and a software component by the basic ⁇ load of other components of the computer system.
  • a further aspect of the invention relates to a computer program which, when executed on a processor of a computer system, instructs the processor to perform the steps of the method, as above, and un ⁇ teniedd described.
  • the results of the measurements (initial load, the initialization phase, base load) for a plurality of software components can be determined automatically with the program and, for example, automatically stored in a table. This table can then for example, may be used by a scheduler to determine optimal utilization of the computer system by the plurality of software components.
  • a computer readable medium may be a non ⁇ volatile medium such as a floppy disk, a hard disk, a USB memory device, RAM, ROM, EPROM.
  • a computer-readable medium may also be a volatile medium, such as a data communication network, such as the Internet, that enables the download of program code.
  • Another aspect of the invention relates to a computer system, which is executed to perform the steps of the method fürzu ⁇ , as it is described above and below.
  • parts or steps of the method can also be implemented by means of hardware.
  • Fig. 1 shows schematically a computer system according to an embodiment of the invention.
  • FIG. 2 is a flowchart for a method for determining the consumption of resources according to one embodiment of the invention ⁇ .
  • Figures 3, 4, 5 and 6 are diagrams of loads on a computer system over time.
  • FIG. 1 shows a computer system 10 that includes a processor 12, a main memory 14, and peripheral devices such as a hard disk 16.
  • main memory 14 to software components, such as an operating system 18, driver 20, to be measured software component 22 and a software component 24 can be located, which, as described below, can carry out the procedural ⁇ ren.
  • Other (non-active) software components 26 may be stored on the hard disk.
  • FIG. 2 shows a method for determining the resource consumption of the software component 22, which will be described with reference to the diagrams of FIGS. 3 to 6.
  • the computing time consumption of the software component is used as resource consumption.
  • the base load 50 has been substantially constant for some time (for example, a predefined time), which need not be the case, for example, shortly after starting the computer system 10, as indicated in the diagrams.
  • the computer system 10 can actively wait for the base load to change significantly.
  • the software component 24, which executes the method can still be active, but does not or only insignificantly contributes to the base load 50.
  • a general base load of Rechnersys ⁇ tems 10 is determined.
  • the software compo ⁇ nent can detect 24 before or at the time ti a value for the basic ⁇ load, for example, using a function of the operating system.
  • step 32 the software component 22 to be measured is then activated.
  • the software component 24 may instruct the operating system 18 to load the software component 22 from the hard disk 16 into the memory 14 and then execute it.
  • the total load 52 increases to the computer system 10. Normally, the total load in an initialization phase 54 will rise to ⁇ closest to a peak 56 and then again from ⁇ fall until the software component is ready 22nd Thereafter, the total load 52 will typically settle to a value 58 that is above the value of the base load 50.
  • step 34 a total load 52 of the computer system 10 is determined while the software component 22 is active.
  • the load 60, 62 associated with the software component 22 is determined based on subtracting the common base load 50 from the total load 52, or based on determining the wrapped area between the two curves. In particular, this load will be before and after End of the initialization phase 54 of the software component 22 determines.
  • an end t2 of the initialization phase 54 is determined by the fact that the total load 58 has adjusted to a temporally no longer variable total load value.
  • the software component 22 Comp ⁇ turn signals the end of the initialization phase.
  • an initial total load of 56 Rechnersys ⁇ tems during the initialization phase 54 is determined, and an initial load of 60 software component 22 determined by subtracting the general base load 50 from the initial total load 56th
  • the CPU-time of the entire accounting nersystems 10 during initialization of the software component 22 are gemes ⁇ sen. Of this, the CPU time that corresponds to the previous base-load 50 of the total system, subtracting the ⁇ .
  • a total load 58 of the computer system 10 is determined after the initialization phase and a base load 62 of the software component 22 is determined by subtracting the general base load 50 from the total load 58.
  • the CPU can (processor) time of the overall system 10 are measured by the initialization of the software component 22 and the CPU time which corresponds to the preceding base load of Ge ⁇ entire system 10, can be subtracted.
  • different patterns for the computing time consumptions or the loads can result from different circumstances (for example, displacement by priorities of the individual runtime contexts).
  • the base load 50 is not caused by the activation of the software component 22. is pressing, but remains at the same value as before the Akti ⁇ crossing at time ti.
  • the computer system 10 has a base load 50 that is not affected by the activation of the software component 22.
  • FIG. 4 shows that the base load 50 increases due to the activation of the software component 22.
  • additional computing times are incurred by the activation in runtime contexts outside the software component 22 (for example in drivers 20).
  • the value 64 of the base load 50 is increased in the initialization phase 54 by activating the software component 22 and remains at a higher value 66, after the software component has left 22, the initialization phase ⁇ approximately 54th
  • the increase of the base load 64, 66 is assigned to the load 60, 62 of the software component (in particular its initial load 60 and its base load 62). This is correct because he ⁇ heightening the base load is comparable ursacht by the software component 22 50th
  • FIGS. 5 and 6 show how the base load 50 is reduced by displacement. This can be the case whenever the total load reaches 100%.
  • the general base load is displaced by Initia ⁇ capitalization of the software component 22 50th This may result in that the value 68 of the base load is lower during the Initiali ⁇ s istsphase 54 as the value of the basic load prior to activation of the component. It may also be that the displaced base load increases at a later date, the base load at a later date (in the 70) and thus gives the impression that the initialization phase 54 County ⁇ ger takes, than it really is.
  • the computer system is busy 10 after activating the software component 22 (the total load 52 is 100%), it is therefore deactivated at step 36, it ⁇ neut waited until again constant basic load is present 50, and the software Component 22 is reactivated, limiting its computational time consumption.
  • the use of the CPU 12 may be limited by the software component 22 (only during the measurement of its CPU budget). In this way it can be achieved that the computing time ⁇ consumption does not reach 100% in order to prevent displacement.
  • the result is a load, as shown in Figs. 3 and 4.
  • step 34 the las ⁇ th 60, 62 are then calculated correctly.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ein Verfahren zur Ermittlung des Ressourcenverbrauchs einer Software-Komponente (22) in einem Rechnersystem (10) umfasst die Schritte von: - Ermitteln einer allgemeinen Grundlast (50) des Rechnersys tems (10); - Aktivieren der Software-Komponente (22); - Ermitteln einer Gesamtlast (56, 58) des Rechnersystems (10), während die Software-Komponente (22) aktiv ist und - Bestimmen einer Last (60, 62) der Software-Komponente (22) durch Subtrahieren der allgemeinen Grundlast (50) von der Gesamtlast (60, 62).

Description

Beschreibung
Verfahren zur Ermittlung des Ressourcenverbrauchs einer Soft¬ ware-Komponente
Die Erfindung betrifft ein Verfahren, ein Computerprogramm und ein computerlesbares Medium zur Ermittlung des Ressourcenverbrauchs einer Software-Komponente sowie ein Rechnersys¬ tem.
Im Bereich der Performancevorhersagen und -analysen von Rechnersystemen kann es notwendig sein, den Ressourcenverbrauch wie etwa das CPU-Budget einzelner Software-Komponenten zu ermitteln.
Beispielsweise zur Ermittlung der Rechenzeitverbräuche der verschiedenen Software-Komponenten wurden bisher die einzelnen Rechenzeitverbräuche aller in einem Rechnersystem vorhandenen parallelen Laufzeitkontexte (wie etwa Prozesse, Threads oder Tasks) gemessen und den einzelnen Software-Komponenten zugeordnet .
Eine Software-Komponente kann jedoch viele (etwa mehr als 100) Laufzeitkontexte umfassen. Zur Ermittlung des Rechen- zeitverbrauchs müssen daher normalerweise alle zur jeweiligen Software-Komponente gehörenden Laufzeitkontexte bekannt und eindeutig identifizierbar sein.
In einem Rechnersystem gibt es in der Regel immer Laufzeit- kontexte, die Aufgaben verschiedener Software-Komponenten bearbeiten (beispielsweise ein Betriebssystem oder Treiber) . Diese Laufzeitkontexte (und damit die dort angefallenen Re¬ chenzeitverbräuche) lassen sich daher nur schwer einer einzelnen Software-Komponente korrekt zuordnen.
Es ist Aufgabe der Erfindung, den Ressourcenverbrauch einer Software-Komponente genau und einfach zu bestimmen. Diese Aufgabe wird durch den Gegenstand der unabhängigen An¬ sprüche gelöst. Weitere Ausführungsformen der Erfindung ergeben sich aus den abhängigen Ansprüchen und aus der folgenden Beschreibung.
Ein Aspekt der Erfindung betrifft ein Verfahren zur Ermittlung des Ressourcenverbrauchs einer Software-Komponente in einem Rechnersystem. Ein Rechnersystem kann auch Computer bzw. Computersystem genannt werden. Ein Rechnersystem kann einen Prozessor, einen Speicher und Peripheriegeräte umfassen. Eine Software-Komponente kann ein (eigenständiges) Com¬ puterprogramm sein bzw. eine Menge an Laufzeitkontexten bzw. Prozessen, die gleichzeitig aktiviert bzw. geladen werden. Eine Ressource kann dabei beispielsweise Rechenzeit, Speicher und/oder eine Netzwerkbandbreite sein. Das heißt, der Res¬ sourcenverbrauch kann einen Rechenzeitverbrauch, einen Speicherverbrauch und/oder einen Netzwerkverbrauch umfassen. Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren die Schritte von:
- Ermitteln einer allgemeinen Grundlast des RechnerSystems (bevor die Software-Komponente aktiviert wurde) ;
- Aktivieren (bzw. Starten) der Software-Komponente;
- Ermitteln einer Gesamtlast des Rechnersystems, während die Software-Komponente aktiv ist und
- Bestimmen einer Last der Software-Komponente durch Subtra¬ hieren der allgemeinen Grundlast von der Gesamtlast. Durch die Betrachtung des gesamten Rechnersystems und die Be¬ rücksichtigung der allgemeinen Grundlast können alle Ressourcen automatisch korrekt berücksichtigt werden. Es werden automatisch alle zur Software-Komponente zugeordneten Laufzeit¬ kontexte berücksichtigt. Diese Laufzeitkontexte müssen nun nicht mehr bekannt und eindeutig identifizierbar sein. Weiter werden alle anderen nicht eindeutig zuordenbaren Laufzeitkontexte berücksichtigt. Hier werden nun auch alle Res¬ sourcen berücksichtigt, die durch die Aktivität der Software- Komponente in anderen Software-Komponenten bzw. Systemkompo- nenten entstehen (beispielsweise in Treibern) .
Insbesondere werden auch Laufzeitkontexte berücksichtigt, die anderen Software-Komponenten zugeordnet sind, aber wegen der Aktivität der Software-Komponente Ressourcen verbrauchen (beispielsweise Rechenzeiten, die beispielsweise durch kon¬ kurrierende Zugriffe entstehen) .
Unter Last bzw. Rechenlast kann dabei verstanden werden, wie viel Rechenzeit pro Zeiteinheit bzw. CPU-Budget von einer Software-Komponente, einem Laufzeitkontext oder auch dem
Rechnersystem verbraucht wird. Die Last kann beispielsweise in Prozent angegeben werden. Die Last kann ein Mittelwert über einen vorgegebenen Zeitraum über die aktuelle Auslastung des Rechnersystems bzw. dessen Prozessors (oder dessen Pro- zessoren) sein.
Die Gesamtlast des Systems kann dabei derart bestimmt werden, dass die Last eines Leerlaufprozesses bzw. Leerlauf-Laufzeit- kontexts von einer maximalen Gesamtlast (etwa 100 %) abgezo- gen wird.
Unter dem Aktivieren einer Software-Komponente kann das Starten der Software-Komponente verstanden werden. Beispielsweise kann die Software-Komponente in einen Hauptspeicher des Rech- nersystems geladen und anschließend ausgeführt werden. Eine Software-Komponente kann so lange aktiv sein, bis sie nicht mehr ausgeführt wird, indem beispielsweise alle ihre Lauf¬ zeitkontexte gestoppt werden. Mit dem Verfahren wird der Ressourcenverbrauch des Gesamtsystems vor, während und/oder nach der Aktivität der Software- Komponente gemessen. Vor der Aktivität entspricht dieser Ressourcenverbrauch somit der Grundlast des Gesamtsystems ohne die Last der aktivierten Software-Komponente .
Während der Aktivität entspricht dieser Ressourcenverbrauch abzüglich der Grundlast dem durch die aktivierte Software- Komponente verursachten Ressourcenverbrauch (unbeachtlich in welchem Laufzeitkontext er anfällt).
Nach der Aktivität entspricht dieser Ressourcenverbrauch abzüglich der Grundlast der durch die aktivierte Software- Komponente verursachten Erhöhung der Grundlast (unbeachtlich in welchem Laufzeitkontext er anfällt).
Gemäß einer Ausführungsform der Erfindung wird die Software- Komponente aktiviert, wenn lediglich zur allgemeinen Grundlast beitragende Systemkomponenten aktiv sind. Darunter kann verstanden werden, dass wenigstens alles was zur Ausführung der Software-Komponente notwendig ist, aktiviert wird. Die zur allgemeinen Grundlast beitragenden Systemkomponenten können beispielsweise ein Betriebssystem und/oder Treiber umfassen. Auf diese Weise kann bestimmt werden, welche Rechnerzei¬ ten lediglich durch die Software-Komponente verursacht wer- den. Beispielsweise können nur einzelne Software-Komponenten in Aktivität versetzt werden, um deren Ressourcenverbrauch zu messen .
Es ist aber auch möglich, dass die Software-Komponente akti- viert wird, wenn bereits eine oder mehrere andere Software- Komponenten aktiv sind, um deren Wechselwirkung mit der während des Verfahrens aktivierten Software-Komponente zu bestimmen . Die Grundlast des Rechnersystems kann über die Systemkompo¬ nente, wie etwa dem Betriebssystem oder den Treibern, definiert werden. Bei der Grundlast kann es sich um die Last han- dein, die vorhanden ist, wenn lediglich diese Komponenten aktiv sind.
Gemäß einer Ausführungsform der Erfindung umfasst das Verfah- ren weiter die Schritte von:
- erneutes Aktivieren der Software-Komponente, wobei deren Ressourcenverbrauch begrenzt wird, falls das Rechnersystem nach dem erstmaligen Aktivieren der Software-Komponente ausgelastet ist (d. h. die Gesamtlast bei 100 % liegt) und - Bestimmen einer weiteren Gesamtlast, während die Software- Komponente aktiv ist, wobei die Last der Software-Kompo¬ nente durch Subtrahieren der allgemeinen Grundlast von der weiteren Gesamtlast bestimmt wird. Wenn das Rechnersystem bzw. die CPU vollständig ausgelastet ist, kann nicht sichergestellt werden, dass die von der Soft¬ ware-Komponente verursachte Last nicht Teile der Grundlast verdrängt und dann Laufzeitkontexte beispielsweise verzögert oder gar nicht ausgeführt werden. In diesem Fall kann die Software-Komponente deaktiviert und erneut aktiviert werden, wobei ihre Ressourcen aktiv reduziert bzw. begrenzt wird. Beispielsweise kann die Priorität der Laufzeitkontexte der Software-Komponente reduziert werden. Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren weiter die Schritte von:
- Ermitteln einer Initial-Gesamtlast des Rechnersystems wäh¬ rend der Initialisierungsphase (zwischen dem Aktivieren der Software-Komponente und dem Ende der Initialisierungsphase) und
- Bestimmen einer Initial-Last der Software-Komponente durch Subtrahieren der allgemeinen Grundlast von der Initial- Gesamtlast .
Kurz nach dem Aktivieren der Software-Komponente wird diese eine verstärkte Aktivität aufweisen, die sich in einem zeit¬ weisen Anstieg der Last bemerkbar machen kann. Diese erhöhte Initial-Last (und auch die Zeitdauer dieser erhöhten Last) kann mit dem Verfahren genau vermessen werden. Es ist zu verstehen, dass diese Initial-Last die Last der Laufzeitkontexte der Software-Komponente während der Initialisierung und eine durch die Initialisierung erzeugte Last anderer Komponenten des Rechnersystems umfasst.
Gemäß einer Ausführungsform der Erfindung wird ein Ende der Initialisierungsphase dadurch ermittelt, dass sich die Ge¬ samtlast auf einen zeitlich nicht mehr variablen Gesamtlast- wert eingestellt hat. Nachdem die Software-Komponente ihre Initialisierungsphase beendet hat, wird sich die Gesamtlast auf dem Rechnersystem auf einem (halbwegs) konstanten Wert einpendeln. Eine weitere Möglichkeit ist, dass die zu vermes¬ sende Software-Komponente ein Signal aussendet, dass das Ende der Initialisierungsphase signalisiert.
Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren weiter die Schritte von:
- Ermitteln einer Gesamtlast des Rechnersystems nach der Ini- tialisierungsphase und
- Bestimmen einer Grundlast der Software-Komponente durch
Subtrahieren der allgemeinen Grundlast von der Gesamtlast.
Mit dem Verfahren kann weiter eine Grundlast für die Software-Komponente ermittelt werden. Es ist zu verstehen, dass diese Grundlast die Grundlast der Laufzeitkontexte der Soft¬ ware-Komponente und eine durch die Software-Komponente Grund¬ last anderer Komponenten des Rechnersystems umfasst.
Ein weiterer Aspekt der Erfindung betrifft ein Computerpro- gramm, das, wenn es auf einem Prozessor eines Rechnersystems ausgeführt wird, den Prozessor dazu anleitet, die Schritte des Verfahrens durchzuführen, so wie es obenstehend und un¬ tenstehend beschrieben ist. Die Ergebnisse der Messungen (Initial-Last, der der Initialisierungsphase, Grundlast) für eine Mehrzahl von Software-Komponenten können mit dem Programm automatisch bestimmt und beispielsweise automatisch in einer Tabelle gespeichert werden. Diese Tabelle kann dann beispielsweise von einem Scheduler verwendet werden, um eine optimale Ausnutzung des Rechnersystems durch die Mehrzahl von Software-Komponente zu bestimmen.
Ein weiterer Aspekt der Erfindung betrifft ein computerlesba¬ res Medium, auf dem ein derartiges Computerprogramm gespeichert ist. Ein computerlesbares Medium kann dabei ein nicht¬ flüchtiges Medium wie eine Diskette, eine Harddisk, ein USB- Speichergerät, ein RAM, ein ROM, ein EPROM sein. Ein computerlesbares Medium kann auch ein flüchtiges Medium wie etwa ein Datenkommunikationsnetzwerk, wie beispielsweise das Internet, das den Download eines Programmcodes ermöglicht, sein .
Ein weiterer Aspekt der Erfindung betrifft ein Rechnersystem, das dazu ausgeführt ist, die Schritte des Verfahrens durchzu¬ führen, so wie es obenstehend und untenstehend beschrieben ist. Beispielsweise können Teile bzw. Schritte des Verfahrens auch mittels Hardware umgesetzt sein.
Es ist zu verstehen, dass Merkmale des Verfahrens, so wie obenstehend und untenstehend beschrieben, auch Merkmale des Computerprogramms, des Computerlesbaren Mediums und des Rech¬ nersystems sein können und umgekehrt.
Im Folgenden werden Ausführungsbeispiele der Erfindung mit Bezug auf die beiliegenden Figuren detailliert beschrieben. Es zeigen:
Fig. 1 schematisch ein Rechnersystem gemäß einer Ausführungsform der Erfindung.
Fig. 2 ein Flussdiagramm für ein Verfahren zur Ermittlung des Ressourcenverbrauchs gemäß einer Ausführungs¬ form der Erfindung. Fig. 3, 4, 5 und 6 Diagramme mit Lasten auf einem Rechnersystem über die Zeit.
Grundsätzlich sind identische oder ähnliche Teile mit den gleichen Bezugszeichen versehen.
Fig. 1 zeigt ein Rechner- bzw. Computersystem 10, das einen Prozessor 12, einen Hauptspeicher 14 und Peripheriegeräte, wie etwa eine Festplatte 16, umfasst. Im Hauptspeicher 14 können sich Software-Komponenten, wie etwa ein Betriebssystem 18, Treiber 20, eine zu vermessende Software-Komponente 22 sowie eine Software-Komponente 24 befinden, die das Verfah¬ ren, so wie es im Folgenden beschrieben ist, ausführen kann. Auf der Festplatte können weitere (nicht-aktive) Software- Komponenten 26 gespeichert sein.
Die Fig. 2 zeigt ein Verfahren zur Ermittlung des Ressourcenverbrauchs der Software-Komponente 22, das in Bezug auf die Diagramme der Fig. 3 bis 6 beschrieben wird. Im Folgenden wird beispielhaft der Rechenzeitverbrauch der Software-Komponente als Ressourcenverbrauchs verwendet.
In den Diagrammen, in denen nach rechts die Zeit und nach oben der Rechenzeitverbrauch bzw. die Last dargestellt ist, ist (unter anderem) der Ausgangszustand zu einem Zeitpunkt ti des Rechnersystems 10 gezeigt, zu dem das Verfahren gestartet wird. Zum Zeitpunkt ti sind lediglich zu einer allgemeinen Grundlast 50 beitragende Systemkomponenten 18, 20 aktiv. Au¬ ßerdem sind alle Software-Komponenten aktiv, die zur Ausfüh- rung der Software-Komponente 22 benötigt werden.
Weiter ist die Grundlast 50 seit einiger Zeit (beispielsweise einer vordefinierten Zeit) im Wesentlichen konstant, was beispielsweise kurz nach dem Starten des Rechnersystems 10, wie in den Diagrammen angedeutet ist, nicht der Fall sein muss.
Beispielsweise kann das Rechnersystem 10 aktiv darauf warten, dass sich die Grundlast nicht mehr wesentlich ändert. Außerdem kann noch die Software-Komponente 24, die das Ver¬ fahren ausführt, aktiv sein, die aber nicht oder nur unwesentlich zur Grundlast 50 beiträgt.
Im Schritt 30 wird eine allgemeine Grundlast des Rechnersys¬ tems 10 ermittelt. Beispielsweise kann die Software-Kompo¬ nente 24 vor oder zum Zeitpunkt ti einen Wert für die Grund¬ last ermitteln, beispielsweise mithilfe einer Funktion des Betriebssystems.
Im Schritt 32 wird die zu vermessende Software-Komponente 22 dann aktiviert. Beispielsweise kann die Software-Komponente 24 das Betriebssystem 18 anweisen, die Software-Komponente 22 von der Festplatte 16 in den Speicher 14 zu laden und sie dann auszuführen.
Aufgrund der Aktivierung der Software-Komponente 22 steigt die Gesamtlast 52 auf das Rechnersystem 10 an. Normalerweise wird die Gesamtlast in einer Initialisierungsphase 54 zu¬ nächst zu einem Spitzenwert 56 ansteigen und dann wieder ab¬ fallen, bis die Software-Komponente 22 bereit ist. Danach wird sich die Gesamtlast 52 in der Regel auf einem Wert 58 einpendeln, der über dem Wert der Grundlast 50 liegt.
Im Schritt 34 wird eine Gesamtlast 52 des Rechnersystems 10 ermittelt, während die Software-Komponente 22 aktiv ist.
Falls das Rechnersystem 10 nach dem Aktivieren der Software- Komponente 22 nicht ausgelastet ist, d. h. der Wert der Ge¬ samtlast 52 nicht auf 100 % steigt, so wie es in den Fig. 3 und 4 gezeigt ist, wird mit den Schritten 38 bis 42 fortge¬ setzt. In diesen Schritten wird die der Software-Komponente 22 zugeordnete Last 60, 62 basierend auf Subtrahieren der allgemeinen Grundlast 50 von der Gesamtlast 52 bestimmt bzw. basierend auf Bestimmen der eingehüllten Fläche zwischen den beiden Kurven. Insbesondere wird diese Last vor und nach dem Ende der Initialisierungsphase 54 der Software-Komponente 22 bestimmt .
Im Schritt 38 wird dazu ein Ende t2 der Initialisierungsphase 54 dadurch ermittelt, dass sich die Gesamtlast 58 auf einen zeitlich nicht mehr variablen Gesamtlastwert eingestellt hat. Alternativ oder zusätzlich signalisiert die Software-Kompo¬ nente 22 ihrerseits das Ende der Initialisierungsphase. Im Schritt 40 wird eine Initial-Gesamtlast 56 des Rechnersys¬ tems während der Initialisierungsphase 54 ermittelt und eine Initial-Last 60 der Software-Komponente 22 durch Subtrahieren der allgemeinen Grundlast 50 von der Initial-Gesamtlast 56 bestimmt. Beispielsweise kann die CPU-Zeit des gesamten Rech- nersystems 10 während der Initialisierung der Software-Komponente 22 (die der Initial-Gesamtlast 56 entspricht) gemes¬ sen werden. Davon kann die CPU-Zeit, die der vorhergehenden Grundlast 50 des Gesamtsystems entspricht, subtrahiert wer¬ den .
Im Schritt 42 wird eine Gesamtlast 58 des Rechnersystems 10 nach der Initialisierungsphase ermittelt und eine Grundlast 62 der Software-Komponente 22 durch Subtrahieren der allgemeinen Grundlast 50 von der Gesamtlast 58 bestimmt. Hierzu kann die CPU- (Prozessor ) -Zeit des Gesamtsystems 10 nach der Initialisierung der Software-Komponente 22 gemessen werden und die CPU-Zeit, die der vorhergehenden Grundlast des Ge¬ samtsystems 10 entspricht, davon subtrahiert werden. Während der Aktivität der vermessenen Software-Komponente 22 und des restlichen Rechnersystems 10 können sich durch verschiedene Gegebenheiten (beispielsweise Verdrängung durch Prioritäten der einzelnen Laufzeitkontexte ) unterschiedliche Muster für die Rechenzeitverbräuche bzw. die Lasten ergeben.
Beispielsweise ist in Fig. 3 gezeigt, dass die Grundlast 50 nicht durch die Aktivierung der Software-Komponente 22 ver- drängt wird, sondern auf dem gleichen Wert wie vor der Akti¬ vierung zum Zeitpunkt ti bleibt. Das Rechnersystem 10 weist eine Grundlast 50 auf, die nicht durch die Aktivierung der Software-Komponente 22 beeinflusst wird.
In der Fig. 4 ist gezeigt, dass sich die Grundlast 50 durch die Aktivierung der Software-Komponente 22 erhöht. Es fallen beispielsweise durch die Aktivierung weitere Rechenzeiten in Laufzeitkontexten außerhalb der Software-Komponente 22 an (beispielsweise in Treibern 20) . Der Wert 64 der Grundlast 50 ist in der Initialisierungsphase 54 durch Aktivieren der Software-Komponente 22 erhöht und bleibt auf einem höheren Wert 66, nachdem die Software-Komponente 22 die Initialisie¬ rungsphase 54 verlassen hat.
Die Erhöhung der Grundlast 64, 66 wird der Last 60, 62 der Software-Komponente zugeordnet (insbesondere deren Initial- Last 60 und deren Grundlast 62) . Dies ist korrekt, da die Er¬ höhung der Grundlast 50 durch die Software-Komponente 22 ver- ursacht wird.
In den Fig. 5 und 6 ist gezeigt, wie die Grundlast 50 durch Verdrängung verringert. Dies kann immer dann der Fall sein, wenn die Gesamtlast 100 % erreicht.
Beispielsweise wird die allgemeine Grundlast 50 durch Initia¬ lisierung der Software-Komponente 22 verdrängt. Das kann dazu führen, dass der Wert 68 der Grundlast während der Initiali¬ sierungsphase 54 niedriger ist als der Wert der Grundlast vor Aktivierung der Komponente. Auch kann es sein, dass die verdrängte Grundlast zu einem späteren Zeitpunkt die Grundlast zu einem späteren Zeitpunkt (im Bereich 70) erhöht und damit den Anschein erweckt, dass die Initialisierungsphase 54 län¬ ger dauert, als sie wirklich ist.
Da es hier zu falschen Messergebnissen kommen würde, kann dies durch Limitierung der Aktivität der Software-Komponente 22 (nur während der Messung) beispielsweise durch Betriebs¬ system-Mechanismen verhindert werden.
Falls das Rechnersystem 10 nach dem Aktivieren der Software- Komponente 22 ausgelastet ist (die Gesamtlast 52 bei 100 % liegt), wird sie im Schritt 36 daher wieder deaktiviert, er¬ neut gewartet, bis wieder konstante Grundlast 50 vorhanden ist, und die Software-Komponente 22 erneut aktiviert, wobei deren Rechenzeitverbrauch begrenzt wird. Beispielsweise kann die Verwendung der CPU 12 durch die Software-Komponente 22 begrenzt werden (nur während der Messung deren CPU-Budgets) . Auf diese Weise kann erreicht werden, dass der Rechenzeit¬ verbrauch nicht 100 % erreicht, um ein Verdrängen zu verhindern. Das Ergebnis ist ein Lastaufkommen, wie es in den Fig. 3 und 4 gezeigt ist.
Anschließend wird im Schritt 34 fortgesetzt, wodurch die Las¬ ten 60, 62 dann korrekt berechnet werden.
Ergänzend ist darauf hinzuweisen, dass „umfassend" keine an¬ deren Elemente oder Schritte ausschließt und „eine" oder „ein" keine Vielzahl ausschließt. Ferner sei darauf hingewie¬ sen, dass Merkmale oder Schritte, die mit Verweis auf eines der obigen Ausführungsbeispiele beschrieben worden sind, auch in Kombination mit anderen Merkmalen oder Schritten anderer oben beschriebener Ausführungsbeispiele verwendet werden kön¬ nen. Bezugszeichen in den Ansprüchen sind nicht als Einschränkung anzusehen.

Claims

Verfahren zur Ermittlung des Ressourcenverbrauchs einer Software-Komponente (22) in einem Rechnersystem (10), das Verfahren umfassend die Schritte:
- Ermitteln einer allgemeinen Grundlast (50) des Rechnersystems (10) ;
- Aktivieren der Software-Komponente (22);
- Ermitteln einer Gesamtlast (56, 58) des Rechnersystems (10), während die Software-Komponente (22) aktiv ist;
- Bestimmen einer Last (60, 62) der Software-Komponente (22) durch Subtrahieren der allgemeinen Grundlast (50) von der Gesamtlast (60, 62) .
Verfahren nach Anspruch 1, wobei die Software-Komponente (22) aktiviert wird, wenn lediglich zur allgemeinen Grundlast (50) beitragende Systemkomponenten (18, 20) aktiv sind.
Verfahren nach Anspruch 1 oder 2, wobei die zur allgemeinen Grundlast (50) beitragenden Systemkomponenten ein Betriebssystem (18) und/oder Treiber (20) umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend die Schritte:
- falls das Rechnersystem (10) nach dem Aktivieren der Software-Komponente (22) ausgelastet ist, erneutes Ak¬ tivieren der Software-Komponente (22), wobei deren Ressourcenverbrauch begrenzt wird;
- Bestimmen einer weiteren Gesamtlast (56, 58), während die Software-Komponente (22) aktiv ist;
- wobei die Last (60, 62) der Software-Komponente durch Subtrahieren der allgemeinen Grundlast von der weiteren Gesamtlast bestimmt wird. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend die Schritte:
- Ermitteln einer Initial-Gesamtlast (56) des Rechner¬ systems während der Initialisierungsphase (54);
- Bestimmen einer Initial-Last (60) der Software-Kompo¬ nente durch Subtrahieren der allgemeinen Grundlast (50) von der Initial-Gesamtlast (56).
Verfahren nach Anspruch 5, wobei ein Ende der Initialisierungsphase (54) dadurch ermittelt wird, dass sich die Gesamtlast auf einen zeitlich nicht mehr variablen Gesamtlastwert (58) eingestellt hat.
Verfahren nach Anspruch 5 oder 6, weiter umfassend die Schritte :
- Ermitteln einer Gesamtlast (58) des Rechnersystems nach der Initialisierungsphase (54);
- Bestimmen einer Grundlast (62) der Software-Komponente durch Subtrahieren der allgemeinen Grundlast (50) von der Gesamtlast (58).
Computerprogramm (24), das, wenn es auf einem Prozessor (12) eines Rechnersystems (10) ausgeführt wird, den Pro¬ zessor dazu anleitet, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen.
Computerlesbares Medium (16), auf dem ein Computerpro gramm (24) nach Anspruch 8 gespeichert ist. 10. Rechnersystem (10), das dazu ausgeführt ist, die Schrit¬ te des Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen .
PCT/EP2014/064585 2013-07-25 2014-07-08 Verfahren zur ermittlung des ressourcenverbrauchs einer software-komponente Ceased WO2015010891A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE201310214565 DE102013214565A1 (de) 2013-07-25 2013-07-25 Verfahren zur Ermittlung des Ressourcenverbrauchs einer Software-Komponente
DE102013214565.9 2013-07-25

Publications (1)

Publication Number Publication Date
WO2015010891A1 true WO2015010891A1 (de) 2015-01-29

Family

ID=51136492

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/064585 Ceased WO2015010891A1 (de) 2013-07-25 2014-07-08 Verfahren zur ermittlung des ressourcenverbrauchs einer software-komponente

Country Status (2)

Country Link
DE (1) DE102013214565A1 (de)
WO (1) WO2015010891A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040267548A1 (en) * 2003-06-25 2004-12-30 Jones James O. Workload profiling in computers
US20050120341A1 (en) * 2003-09-03 2005-06-02 Andreas Blumenthal Measuring software system performance using benchmarks
DE102005045904A1 (de) * 2005-09-26 2007-04-05 Siemens Ag Datenverarbeitungseinrichtung mit Performance-Steuerung
WO2012089564A1 (en) * 2010-12-30 2012-07-05 St-Ericsson Sa Load determination method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040267548A1 (en) * 2003-06-25 2004-12-30 Jones James O. Workload profiling in computers
US20050120341A1 (en) * 2003-09-03 2005-06-02 Andreas Blumenthal Measuring software system performance using benchmarks
DE102005045904A1 (de) * 2005-09-26 2007-04-05 Siemens Ag Datenverarbeitungseinrichtung mit Performance-Steuerung
WO2012089564A1 (en) * 2010-12-30 2012-07-05 St-Ericsson Sa Load determination method

Also Published As

Publication number Publication date
DE102013214565A1 (de) 2015-01-29

Similar Documents

Publication Publication Date Title
DE3031852C2 (de) Verfahren zum Ermitteln des Ladezustandes einer Akkumulatorenbatterie
DE60226176T2 (de) Verfahren und programme zur einstellung von prioritätsstufen in einem datenverarbeitungssystem mit multiprogrammierung und priorisierte warteschlangenbildung
DE112012002545B4 (de) Verwalten von Arbeitslasten in einem Mehrprozessor-Computersystem
DE102013015172A1 (de) Challenge-and-response-Verfahren für Sicherheitssystem unter Verwendung eines modifizierten Watchdog-Zeitgebers
EP1831786B1 (de) Verfahren zur verteilung von rechenzeit in einem rechnersystem
DE102011005382A1 (de) Aufgabenausführungs-Steuereinheit und Aufzeichnungsmedium, auf dem ein Aufgabenausführungs-Steuerprogramm aufgezeichnet ist
DE102021131356A1 (de) System und verfahren zum beurteilen des zustands von bremsscheiben
DE112011103194T5 (de) Koordinieren von Gerät- und Anwendungsunterbrechungsereignissen zum Plattformenergiesparen
DE102020214951A1 (de) Verfahren zum dynamischen Zuweisen von Speicherbandbreite
DE112010002980T5 (de) Verwalten der Verteilung elektrischer Energie auf mehrere Lasten unter Verwendung einer selektiven Begrenzung
DE112016005597B4 (de) Objekterfassungsvorrichtung und Objekterfassungssystem
WO2015010891A1 (de) Verfahren zur ermittlung des ressourcenverbrauchs einer software-komponente
DE102008022302A1 (de) Elektronische Rechenvorrichtung zur Bestimmung einer Ausführzeit einer Aufgabe und Programm
DE102018209187A1 (de) Technologien zur Bereitstellung von adaptiver Plattform-Dienstqualität
DE102007031529B4 (de) Elektronisches Gerät und Verfahren zum Umschalten einer CPU von einer ersten in eine zweite Betriebsart
DE112017005778B4 (de) Mikrocontroller-energie-profiler und verfahren zu seiner anwendung
DE102013022564B4 (de) Aufrechterhalten der Bandbreiten-Servicequalität einer Hardware-Ressource über einen Hardware-Zähler
DE112016006060T5 (de) Technologien zum Aufruf von nativem Code unter Verwendung binärer Analyse
EP1502189B1 (de) Verfahren zur ermittlung der prioritätsabhangigen rechenzeitverteilung in einem priorit tsgesteuerten mehrprozess-rechenysystem
DE112010005672B4 (de) Systeme und Verfahren zum Bestimmen einer elektrischen Konnektivität
DE102016206490A1 (de) Elektronische steuereinheit
DE102020130611B4 (de) Vorrichtung und verfahren zur analog -digital -umwandlung
DE102012219917A1 (de) Verfahren zur Verwaltung eines Steuergerätenetzwerks in einem Fahrzeug und Steuergerätenetzwerk
DE102015221892A1 (de) Bestimmung einer maximalen Latenzzeit
DE102017211564A1 (de) Elektronische steuereinheit

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14736403

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14736403

Country of ref document: EP

Kind code of ref document: A1