Browse Prior Art Database

Method to optimize resource requirement for OSGi application in cloud

IP.com Disclosure Number: IPCOM000226038D
Publication Date: 2013-Mar-21
Document File: 3 page(s) / 47K

Publishing Venue

The IP.com Prior Art Database

Abstract

Execution environment resource (CPU / Memory / Disk / Network IO) over commit is normally employed for the most optimal use of the cloud environment. Over-commit allows having a higher VM ratio per host in the infrastructure however it has a negative impact on the performance and responsiveness of the hosted applications during resource contention or peak load. Presented is an approach to avoid negative performance impact for OSGi applications in a cloud environment with over-committed resources.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 3

method to optimize resource requirement for OSGi application in cloud

One of the enablers for cloud computing is virtualization of computing environment. In a typical cloud computing based virtualized setup, there are multiple physical hosts on which Virtual Machines (VMs) or guest OS gets created, run, migrated and destroyed.

Execution environment resource (CPU / Memory / Disk / Network IO) over commit is normally employed for the most optimal use of the cloud environment. Over-commit allows having a higher VM ratio per host in the infrastructure however it has a negative impact on the

performance and responsiveness of the hosted applications during resource contention or peak

load.

This disclosure provides a novel method to avoid negative performance impact for OSGi applications in a cloud environment with over-committed resources.

The Open Services Gateway initiative framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model ( http://en.wikipedia.org/wiki/OSGi).

According to this disclosure it is proposed that physical host will expose certain resource characteristics like overcommit info (cpu/memory/disk) to hosted VMs which will be then subsequently used by OSGi runtime of the applications running on the VMs.

The physical host will appropriately set the value of the overcommit property which can be read by the OSGi runtime on the VM to optimise itself. The host can also send an event notification to all the VMs that is currently running on the host.

Note that the host can change the value of the overcommit variable dynamically based on changing scenarios for eg starts with no_memory_overcommit and changes to memory_overcommit later on. It could also be threshold based like when reaching a specific threshold for memory or cpu or storage commit the host can send a notification to the VMs. The change notification can be either event based or poll based ( OSGi runtime on the VM polling the host variable at regular intervals).

The OSGi application will adapt its behaviour based on the host info like if the even received indicates that the system is running under memory overcommit, the OSGi application will refrain from starting certain functionality (read services and modules) which are resource intensive in such VM. Another possibility is that the OSGi application scheduling multiple resource intensive functions (read services and modules) sequentially (once one operation is finished, stop it and start other and so on) or put and reduce the max limit of parallel threads it spawns. It can also defer some of the non-critical house-keeping tasks (such as logging, periodic clean-ups etc) to non-peak time slots.

This dynamically adaptive behaviour of application as per the resource constraints in the execution environment will help application maintain the overall performance to acceptable limits hence helping meet availability and response SLAs (Service...