System-Level Characterization of Datacenter Applications

Abstract

In recent years, a number of benchmark suites have been created for the "Big Data" domain, and a number of such applications fit the client-server paradigm. A large volume of recent literature in characterizing "Big Data" applications have largely focused on two extremes of the characterization spectrum. On one hand, multiple studies have focused on client-side performance. These involve fine-tuning serverside parameters for an application to get the best client-side performance. On the other extreme, characterization focuses on picking one set of client-side parameters and then reporting the server microarchitectural statistics under those assumptions. While the two ends of the spectrum present interesting results, this paper argues that they are not enough, and in some cases, undesirable, to drive system-wide architectural decisions in datacenter design. This paper shows that for the purposes of designing an efficient datacenter, detailed microarchitectural characterization of "Big Data" applications is an overkill. It identifies four main system-level macro-architectural features and shows that these features are more representative of an application's system level behavior. To this end, a number of datacenter applications from a variety of benchmark suites are evaluated and classified into these previously identified macro-architectural features. Based on this analysis, the paper further shows that each application class will benefit from a very different server configuration leading to a highly efficient, cost-effective datacenter.

Rethinking Design Metrics for Datacenter DRAM

“…For achieving low latencies for all users and varying types of request sizes and distributions, one of the most important classes of applications required for reducing service latency belongs in-memory key-value (KV) stores. Primary examples of such applications are Memcached and REDIS [3]. Architecturally, the datacenter tier running the inmemory KV stores typically comprises of a number of servers that form a distributed, shared-nothing, caching tier between the web-service frontend and the server tier that runs the database (or a data store) service.…”

“…Hence, as the number of users increases, the role of the in-memory caching tier becomes increasingly important to meet the service level agreements/requirements (SLAs/SLRs) for the services under consideration. Similar to KV stores, applications at other tiers of the datacenter also require access to DRAM, although, after a certain point, the applications are not sensitive to DRAM [3,4,5]. Some of our previous work in this regard [3] characterized the most popular application for each server tier.…”

“…Similar to KV stores, applications at other tiers of the datacenter also require access to DRAM, although, after a certain point, the applications are not sensitive to DRAM [3,4,5]. Some of our previous work in this regard [3] characterized the most popular application for each server tier. Of all the applications that were considered, the success of in-memory KV caches depends on availability of a large pool of low latency, high density main memory, the role of which has traditionally been fulfilled by DRAM.…”

“…For example, an application might be based primarily on servicing users by querying a NoSQL database, but in order to effectively service all users within reasonable time, the application will require the support of web serving, load balancing and data caching services, among others. In order to display targeted products or advertisements to each user, the services of a (probably Hadoop based) data analytics engine [3] might also be required. Hence, in order to effectively run one fullfledged user facing application, services of four or five distinct ``supporting'' applications might be required.…”

“…Each of these services has distinct requirements in terms of hardware and software support. For example, a typical datacenter that supports web 2.0 style applications might have five to six different tiers of servers [3]. A number of studies have characterized applications running on each of these tiers.…”