Oversubscribing an Oracle Server Using SolarisTM FSS
Eric Forgette
One of the biggest challenges in consolidating database instances onto a single,
multiprocessor system is the limited control over the priority of processes
running in the time share scheduling class. In this class, each runnable thread
is individually scheduled based on its priority, time spent on CPU, and time
spent waiting for a CPU. Thus, a database instance with many threads can get
more work done than an instance with only a few threads.
Systems in this configuration tend to perform poorly and unpredictably during
periods of peak loads because components of individual instances become starved
for CPU. These performance problems manifest themselves as poor application
response, longer batch run times, and connection timeouts. Using processor sets
and creative prioritization scripts can mitigate these challenges. However,
these techniques create a configuration only marginally better than having a
separate system per instance.
The most successful consolidated database servers are created by strategically
grouping instances with different load signatures. A load signature consists
of the system resources (CPU, memory, and IO) that a database instance consumes
over a specific period of time. While sizing and consolidation strategies are
beyond the scope of this article, an example of a good grouping strategy would
be to combine instances that experience heavy utilization during normal business
hours (online) with instances that experience heavy loads throughout the night
(batch). Overlap of the load signatures, which cause contention for CPU resources,
tend to occur even in well-planned environments.
|
