Useful Oracle Queries

The following query shows the last sql text from an inactive session

select sess.sid,
       sess.serial#,
       sess.username,
       sql_text
 from v$sqlarea sqlarea, v$session sess
 where sess.prev_hash_value = sqlarea.hash_value
   and sess.prev_sql_addr  = sqlarea.address
   and sess.username is not null
   and sess.status='INACTIVE';   

The following query shows which session (id) is blocking which session (id)

select blocking_session, sid, serial#, wait_class, seconds_in_wait
from v$session where blocking_session is not NULL order by blocking_session;
And this is a very relevant post to the topic

Icebergs in the Clouds: The Other Risks of Cloud Computing

This is an interesting series of problems by Bryan Ford from Yale university.

In the paper he counts some of the interesting problems with Cloud Computing in general:

He summarized some of the issues as follows:

• Side channels
• Stability Risks from Interactive Services
• Risks of hidden failure correlation (cross-layer robustness)
• The always-connected assumption
• Digital Preservation Risks

The assumption is making the cloud more reliable.

Here is the link to the paper: https://www.usenix.org/system/files/conference/hotcloud12/hotcloud12-final54.pdf

The seven deadly sins of cloud computing research

The paper is presented in HotCloud2012 by

Steven Hand and Derek Murray as co-authors and Malte Schwarzkopf as the main author who is a PhD student at Cambridge.

The paper is on seven mistakes that researchers commit when dealing with Cloud and data processing in the cloud. The list is the following

• Unnecessary distributed parallelism 
• Assuming performance homogeneity
• Picking the low hanging fruit
• Forcing the abstraction
• Unrepresentative workload
• Assuming perfect elasticity
• Ignoring fault tolerance

what seems to be the case with all seven arguments is that it particularly focuses on parallel algorithms applicable to the cloud, mostly by benefiting from Map / Reduce.

The paper is heavily performance oriented and at least the first 3 points also represented by the author in the talk have performance comparisons. Those are the ones that provided nice graphs for the slides to the author. Some of the points that are interesting are the fact that machines may get overloaded and that the data needs to be more representative. But I think there is nothing very new about the paper and these are the already known facts re-iterated in the paper. Yet it is good that he highlighted some issues with the papers already being published. Maybe others will try to avoid the mistakes mentioned in the paper.

You can tell it is a work at the early years of this guy's PhD.

Link to the paper: https://www.usenix.org/system/files/conference/hotcloud12/hotcloud12-final70.pdf

Parallel Symbolic Execution for Automated Real-World Software Testing

http://eurosys2011.cs.uni-salzburg.at/pdf/eurosys2011-bucur.pdf

This paper introduces Cloud9, a platform for automated testing of real-world software. Our main contribution is the scalable parallelization of symbolic execution on clusters of commodity hardware, to help cope with path explosion. Cloud9 provides a systematic interface for writing “symbolic tests” that concisely specify entire families of inputs and behaviors to be tested, thus improving testing productivity. Cloud9 can handle not only single-threaded programs but also multi-threaded and distributed systems. It includes a

new symbolic environment model that is the first to support all major aspects of the POSIX interface, such as processes, threads, synchronization, networking, IPC, and file I/O. We show that Cloud9 can automatically test real systems, like memcached, Apache httpd, lighttpd, the Python interpreter, rsync, and curl. We show how Cloud9 can use existing test suites to generate new test cases that capture untested corner cases (e.g., network stream fragmentation). Cloud9 can also diagnose incomplete bug fixes by analyzing the difference between buggy paths before and after a patch.

Designing Distributed Database Systems for Efficient Operation

Designing Distributed Database Systems for Efficient Operation

Sangkyu Rho, Salvatore March

http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1065&context=icis1995

Distributed database systems can yield significant cost and performance advantages over centralized systems for geographically distributed organizations. The efficiency o f a distributed database depends primarily on the data allocation (data replication and placement) and the operating strategies (where and h ow retrieval and update query processing operations are performed). W e develop a distributed database design approach that comprehensively treats data allocation and operating strategies, explicitly modeling their interdependencies for both retrieval and update processing. W e demonstrate that data replication, join node selection, and data reduction b y semijoin are important design and operating decisions that have significant impact on both the cost and response time of a distributed database system.

On the impact of network latency on distributed systems design

link: http://www.springerlink.com/content/v8x37536u2343u86/fulltext.pdf

Research in distributed database systems to date has assumed a “variable cost” model of network response time. However, network response time has two components: transmission time (variable with message size) and latency (fixed). This research improves on existing models by incorporating a “fixed plus variable cost” model of the network response time. In this research, we: (1) develop a distributed database design approach that incorporates a “fixed plus variable cost”, network response time function; (2) run a set of experiments to create designs using this model, and (3) evaluate the impact the new model had on the design in various types of networks.

This is a followup paper by the same author:

Modeling Network Latency and Parallel Processing in Distributed Database Design

http://onlinelibrary.wiley.com/doi/10.1111/j.1540-5414.2003.02409.x/pdf

Thialfi: A Client Notification Service for Internet-Scale Applications

http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/10-adya.pdf

Abstract. Ensuring the freshness of client data is a fundamental problem for
applications that rely on cloud infrastructure to store data and mediate sharing. Thialfi is a notification service developed at Google to simplify this task. Thialfi supports applications written in multiple programming languages and running on multiple platforms, e.g., browsers, phones, and desktops. Applications register their interest in a set of shared objects and receive notifications when those objects change. Thialfi servers run in multiple Google data centers for availability and replicate their state asynchronously. Thialfi’s approach to recovery emphasizes simplicity: all server state is soft, and clients drive recovery and assist in replication. A principal goal of our design is to provide a straightforward API and good semantics despite a variety of failures, including server crashes, communication failures, storage unavailability, and data center failures.

Some notes: Version updates come from the application server and as a result the application server should maintain the new version number for the objects it shares with the clients. This implies that Thialfi imposes a requirement for versioning objects whereas in many cases versioning may not be even needed.

They consider only 10% of the clients to be online most of the time and measurements are taken for cases where the number of clients is not really high, an increase in the number of clients would change the metrics (drastically?).

Some interesting graph cut papers

Notes on graph cuts with submodular edge weights
http://users.cms.caltech.edu/~krausea/discml/papers/jegelka09subcuts.pdf

Optimization on Graphs with Variable
http://www.springerlink.com/content/g457x624814gm812/fulltext.pdf

Labelings of Graphs with Fixed and Variable Edge-Weights
http://epubs.siam.org/sidma/resource/1/sjdmec/v21/i3/p688_s1

Dynamic Graph Cuts for Efficient Inference in Markov Random Fields
http://research.microsoft.com/en-us/um/people/pkohli/papers/pami07.pdf

Some thoughts on Replicability

Replicability

• Horizontal Partitioning is where cloud is more significantly helpful so if you manage to determine stateless components or come up with recommendations for stateless components, it is easier to identify whether or not we can do any horizontal partitioning without significant effects and modifications to the application.
• Data is an issue, so let's collocated code and data

Graph Partitioning with Natural Cuts

link: http://research.microsoft.com/pubs/142349/punchtr.pdf

Daniel Delling, Andrew GOldberg, Ilya Razenshteyn, Renato F. Weneck

Abstract. We present a novel approach to graph partitioning based on the notion of natural

cuts. Our algorithm, called PUNCH, has two phases. The rst phase performs a

series of minimum-cut computations to identify and contract dense regions of the

graph. This reduces the graph size signi cantly, but preserves its general structure.

The second phase uses a combination of greedy and local search heuristics to assemble

the nal partition. The algorithm performs especially well on road networks, which

have an abundance of natural cuts (such as bridges, mountain passes, and ferries).

In a few minutes, it obtains the best known partitions for continental-sized networks,

signi cantly improving on previous results.

A New Approach to the Minimum Cut Problem

http://www.columbia.edu/~cs2035/courses/ieor6614.S09/Contrac

tion.pdf

An Evaluation of Alternative Architectures for Transaction Processing in the Cloud

Donald Kossmann, Tim Kraska, Simon Loesing SIGMOD2010

http://www.cs.berkeley.edu/~kraska/pub/sigmod10-cloudbench.pdf

Cloud computing promises a number of advantages for the deployment
of data-intensive applications. One important promise
is reduced cost with a pay-as-you-go business model. Another
promise is (virtually) unlimited throughput by adding servers if
the workload increases. This paper lists alternative architectures
to effect cloud computing for database applications and reports on
the results of a comprehensive evaluation of existing commercial
cloud services that have adopted these architectures. The focus of
this work is on transaction processing (i.e., read and update workloads),
rather than analytics or OLAP workloads, which have recently
gained a great deal of attention. The results are surprising
in several ways. Most importantly, it seems that all major vendors
have adopted a different architecture for their cloud services. As a
result, the cost and performance of the services vary significantly
depending on the workload.

To Move or Not to Move: the economics of Cloud Computing

To Move or Not to Move: The Economics of Cloud Computing
Byung Chul Tak, Bhuvan Urgaonkar, and Anand Sivasubramaniam, The Pennsylvania State University

HotCloud 2011

http://www.usenix.org/events/hotcloud11/tech/final_files/Tak.pdf

Cloud-based hosting promises cost advantages over conventional in-house (on-premise) application deployment. One important question when considering a move to the cloud is whether it makes sense for 'my' application to migrate to the cloud. This question is challenging to answer due to following reasons. Although many potential benefits of migrating to the cloud can be enumerated, some benefits may not apply to 'my' application. Also, there can be multiple ways in which an application might make use of the facilities offered by cloud providers. Answering these questions requires an in-depth understanding of the cost implications of all the possible choices specific to 'my' circumstances. In this study We identify an initial set of key factors affecting the costs of a deployement choice. Using benchmarks representing two different applications (TPC-W and TPC-E) we investigate the evolution of costs for different deployment choices. We show that application characteristics such as workload intensity, growth rate, storage capacity and software licensing costs produce complex combined effect on overall costs. We also discuss issues regarding workload variance and horizontal partitioning.

Applying graph partitioning methods in measurement-based dynamic load balancing [PPL Technical Report 2012]

Applying graph partitioning methods in measurement-based dynamic load balancing

[PPL Technical Report 2012]

Here is the link to the paper: http://charm.cs.illinois.edu/newPapers/12-03/paper.pdf

As noted it is a technical report by people from University of illinois.

[SUMMARY]

Wishbone: Profile-based Partitioning for Sensornet Applications

Two major problems with application partitioning:

• Heterogeneity
• Decomposition

The requirements for wishbone applications

1. Streaming dataflow model: the model should be a dataflow graph
   
2. Predictable input rates and patterns: because they use profiling they need to set this constraint

The front-end creates a dataflow graph. The backend performs graph optimization and reduces work functions to an intermediate language that can be fed to a number of code generators.

namespace is used to logically define the distribution of the code, i.e., the code that can be distributed, not the code that necessarily needs to be distributed.

if the code to be placed (logically) in a node is stateful, the state of the stateful operators should be replicated on the node too.

Stateful server oprators can not be moved to the network, however, stateful node operators can be brought to the server.

The system considers two modes of conservative and permissive where in the conservative mode the stateful nodes are not pushed to the server but in the permissive mode, the stateful operators can be pushed to the server, in case the application is capable of dealing with data loss.

For dataflow, the Scheme compiler executes the code during the compilation to measure the data flow, producing platform independent data rates.

Once partitoned, the partition is executed within simulated or real hardware to measure the cpu foot print for the partition. Timing statements are placed at the beginning and end of each operation. The timestamp can help with extracting the memory footprint for each piece of the code.

Cost is measured using Cost = aC + bNet

The ILP algorithm used is minimum cost cut for partitioning the graph

Dynamic Function Placement for Data-intensive Cluster Computing

Application partitioning is difficult because of :

• variation in application behavior
• variability in resource availability
• availability in workload mixes

Effective use of cluster resources require

1. load balancing
2. proper partitioning of functionality among producers and consumers

Function placement is done in abacus only based on black box monitoring removing the burden from the programmers to worry about function placement.

Abacus consists of a programming model and a runtime system. In the abacus programming model, the programmers need to define their components as explicitly migratable functionally independent components or objects.

Anchored elements need to be explicitly defined in the graph of the application. I think this is required because when it comes to modeling the grapho for the application, these components should be makred properly.

Abacus components:

1. Migration and Location Transparent Invocation Component (Binding Manager)
   
2. Resource Monitoring and Management Component (Resource Manager)

Resource Manager uses notifications to collect monitoring information (mointoring and profiling happens during runtime).

The best net benefit is calculated by the server in order to determine whether it is worth doing the migration (minimum requirements for doing the migration). Code Mobility and Dynamic Linking are sidestep in this model.

Mobile Objects are defined by the programmer.

Cluster characteristics critical for function placement:

• Communication bandwidth between nodes
• Relative processor speed among nodes
• Workload characteristics (e.g., bytes moved among functions, instructions executed by each function)

-> Data Intensive Applications: those that selectively filter, mine, sort, or otherwise manipulate large data sets. Spread the parallel computations across the source/sink servers.

Programmable Storage Services. is what they consider as a potential alternative to Cloud when it comes to naming.

Difference between Coign and Abacus is that Coign relies on the profiling history of functions / components to make decisions, while Abacus tries to do it at runtime.

Equanimity dynamically balances the load between a single client and its servers. Abacus extends it to real world clusters, i.e., resource contention, resource heterogeneity, workload variation.

Dynamic adaptation of resource placement based on resource usage and availability.

The two applications used in Abacus:

1. The file system
2. The search application
   

Goals for Abacus:

1. improve overall performance

Parameters measured:

• Data Flow Graph
• Memory Consumption
• Instructions Executed per Byte
• Stall Time

The Coign Automatic Distributed Partitioning System

The problem:

The need to partition and place pieces of applications on different nodes. Considering the effort, repartitioning is not done frequently because of the required effort even though repartitioning may buy a lot of efficiency for the application.

Application reprofiling is supported based on the periodical profiling of the application and calculating the optimal solution.

The architecture for Coign:

• The application is augmented with instrumentations for Coign using the binary re-writer.
• The instrumented binary is run through a set of profiling scenarios (degrading application performance. inter-component communications are summarized)
  
• The profile analysis engine combines component communication profiles and component location constraints to create an abstract inter-component communication graph (ICC).
• Location constraints are obtained from the programmer, from analysis of component communication records, and from application binaries.
  
• The ICC graph is combined with a network profile to create a graph of potential communication time on the network
• The graph cutting algorithm: lift-to-front minimum cut

The set of components for Coign Runtime:


Instance Classifier is probably the most important part of Coign Runtime. This is probably the most important part of the profiler as it tries to identify similarities between instances and extracted profiles. They have listed the following classifiers which need to be further investigated:

1. incremental classifier (Straw man classifier)
   
2. Procedure Called-By Classifier (PCB)
3. Static Type Classifier (ST)
   
4. Static Type Called-By Classifier (STCB)
5. Internal-function Called-By Classifier (IFCB)
6. Entry Point Called-By Classifier (EPCB)
7. Instantiated-By Classifier (IB)

The next step is correlating the profile of one instance with another instance based on similar resource usage and communication behavior. They have used instance communication vector.

The algorithm that it uses is the lift-to-front minimum cut graph cutting algorithm

Capacity Leasing in Cloud Systems using the OpenNebula Engine

Borja Sotomayor, Rubeen Santiago Montero, Ignacio Martero Llorente, and Ian Foster
http://www.cca08.org/papers/Paper20-Sotomayor.pdf

The problem: is advanced leasing.

• In the current models resources are allocated at the time of request.
• resource requests subject to notrivial policies are not supported
• capacity specification in advance is not supported
• no support for variable resource usage
• dynamic renegotiation of resource allocation is not possible
• small cloud systems can benefit from queuing, priorities and advanced reservation

Approach: OpenNebula + Haiza

OpenNebula:

1. Core: Manages the lifecycle of a VM + management and monitoring of the physical host
   
2. Capacity Manager: Adjusts placement of VMs
   
3. pluggable Virtualizer Access Driver: expose the basic functionality of the hypervisor

Hiza is a lease manager:

1. leases in Haiza, hardware resource, software environment, and availability
2. Supports
3. advance reservation lease: request for resource at a specific time
   
4. best effort leases: resources are assigned as soon as possible, queuing resources if necessary
   
5. immediate leases: provisioned when requested or not at all
   

Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities

Comparing some cloud services:

QCon SF 2009: Simon Guest, Patterns of Cloud Computing

QCon SF 2009: Simon Guest, Patterns of Cloud Computing
By Stefan Tilkov on November 19, 2009 2:38 PM | Permalink | Comments (0)

Similar Post: http://horicky.blogspot.com/2009/11/cloud-computing-patterns.html

These are my unedited notes from Simon Guest's talk about Patterns for Cloud Computing at QCon SF 2009.

* "This talk is about Jim, he has many questions about cloud computing…"
* 5 pattern of cloud-based applications
* Definition of cloud computing
* Different models:
o Applications must run on-premises – complete control, upfront capital costs
o Application runs at a hoster – lower capital costs, but pay for fixed capacity even if idle
o Shared, multi-tenant, pay as you go – pay someone for a pool of computing resources that can be applied to a set of applications
* Public Cloud vs. Private Cloud – private cloud useful e.g. for telcos offering this to their customers
* Windows Azure – compute, storage, management, based on 64bit Windows images
* SQL Azure - RDBMS
* .NET Service - service bus and access control
* [ed.: Who thinks of these names, and even more importantly, why doesn't Microsoft fire them?]
* Different models infrastructure (IaaS) vs. Platform as a Service (PaaS) as main paths
* Slide shows that MS offers a higher-level stack than Amazon - EC2 provides instance, Windows Azure model is a platform as a service model
* [Seems to me this is one of the major problems of Azure – it seems neither one or the other, as I would define PaaS as what GAE does, which is much higher-level than simply a Windows Server]

Pattern #1: Using the Cloud for Scale

* Shows how to scale up a Web app using more machines, load balancer, database partitioning
* A lot of work - a lot of money
* Designed for peak capacity, idle for a lot of time
* Much easier to let cloud vendor handle this dynamically
* Prerequisite for successful scaling in the cloud: having a queue to decouple web tier and backend
* Starbucks [of all possible examples! ;-)] as an example for queueing
* Demo: "PrimeSolvr" (Web 2.0 because it's missing the last "e")
* 3 takeaways: 1) core tenet of cloud computing: ability to scale up/down 2) understand how to communicate between roles and nodes 3) strategy for when to scale up and down

Pattern #2: Using the cloud for multi tenancy

* Simply approach internally: one application per customer - works only for small numbers
* Implications: Schema customizations, UI customizations
* 3 options for data in a multi-tenant environment: 1) share DB between customers 2) each customer gets a separate DB - hard to do on-premise, much easier in the cloud 3) fixed DB schema with customizations on a tenant-by-tenant basis
* Demo: ASP.NET MVC app using the HTTP host name to switch UI and DB Schema
* Takeaways: 1) Consider multi-tenancy first, hard to retrofit 2) Design considerations must include both data and UI specifics 3) Identity as a very important consideration, see MS Patterns and Practices paper on multi-tenancy ID

Pattern #3: Using the cloud for compute

* Popularized by MapReduce
* Apache Hadoop, Cloudera, Amazon Elastic MapReduce, Hadoop implementation
* Typical on-premise solution: very infrastructure-heavy, complex, expensive
* No explicit framework implementation on Azure
* Demo (inspired my MapReduce): Development Fabric (local execution environment), not using virtualization [similar to GAE environment]; next step is upload to Azure staging area, next level production
* Takeaways: MapReduce very visible, although can be hard to initally grasp, learn about existing implementations; MS academic effort: Dryad

Pattern #4: Using the cloud for (infinite) storage

* Problem: Affinity between hardware and data
* how does the cloud help? breaks the affinity
* virtualized layer between the data you store and the hardware underneath
* Three ways: blobs, tables, relational
* MS: Azure Blog Storage – REST API (using GET (even range requests) and PUT); PutBlock API to move blocks - transaction build up [must look this up]
* Azure Table Storage (Key/Value pairs)
* Initial relational effort: SQL Server Data Services (MIX 08) - REST API on top of SQL
* Customer reaction: We want to do TDS (MS native DB protocol)
* SQL Data Services (MIX 09), late SQL Azure: TDS (SQL Server) in the Cloud
* Similarity between internal and cloud architecture makes it easier for customers [agreed, even though this might me more of a problem]
* Demo: SQL Azure (http://sql.azure.com); Codeplex sqlazuremw (migration wizard) - migration from local SQL Server DB to the cloud (subset of SQL Server functionality, e.g. restrictions on certain value types, clustered indexes)
* Takeaways: 1) Storage in the cloud may look the same, but breaks the affinity problem 2) Pricing is relevant 3) SQL Azure factor for moving to cloud in the first place=
*

Pattern #5: Using the cloud for communications

* Classic approach: VAN, now replace by Internet direct file transfers
* Cloud approach: REST-based queues could be used for communication - not commonly used, problem: need to pass tokens around
* Putting a web facade in front of the queue doesn't work too well either due to firewall problems. HTTP polling is bad [why?]
* MS Solution: .NET Service Bus
* TCP Relay: outbound bi-directional socket, tunneled through the bus and kept alive on both sides. Enables routing of arbitrary protocols across company boundaries
* Alternative: Message Buffer, exposed using AtomPub, support retrieve, peek, lock
* Takeaways: Be careful consuming REST-based queues because of shared secret
* additional trouble because of REST
* service bus as potential solution

Last question: How can patterns be integrated?

* 1) Sample PHP (!) application running on Windows Azure, ported to GAE and EC2 (as ASP.NET)
* 2) Map reduce spreads load across Amazon, Google, MS
* 3) Store results in SQL Azure database
*

4) Coordinate communication using .NET Service Bus
*

How many prime numbers between 1 and 10,000,000? 40 jobs of 250,000 numbers
* WPF client app sends off job
* "I'm gonna submnit the job and pray"
*

Spontaneous applause as the demo actually worked
*

make sure you have a clear definition of cloud computing
* explore the 5 usage patterns
* think about the next steps for implementation and migration