Slide 1: Cover

In this paper we present an alternative to deal with the traces scalability problem, from the point of view of performance analysis tools. Nowadays, it is not surprising to have applications running in real production systems for hours and using thousands of processes. This keeps on increasing everyday, bringing us closer to the Petascale. It is clear that, blind tracing in such scenarios produces huge volumes of data that, at best, are difficult to handle. And this problem is not exclusive to tracing tools anymore, because profilers also start to present issues at such scale. Despite the drawbacks, our interest stays in traces because they provide far much information for a very detailed analysis. However, the very first handicap these tools face is actually to store the data. Even if you can, the amount of time required to process it can be very high. So if the tool is not responsive enough… How much time will the user wait for results before he looses all interest? Slide 3: Work with large traces So far, the way we've dealt with such big traces has typically consisted in filtering the information. Generally, we would: 1. Generate the full trace 2. Summarize it to get general understanding of the application behavior. 3. Focus on a small, interesting region with all details. 4. Iterate if necessary. And this process was manually driven by the expert and done post-mortem. So, what comes next is to automatize this process to be done on-line, so that you directly get the most interesting parts of the trace, getting rid of the tedious task of handling large files. Our objective is to produce traces of 100 Mb. And the number here is not important. What this really means is that we want to balance the trade-off between relevant information and raw data. Or in other words, we want the minimum amount of data that best describes the application. And how can you obtain that? For this, you need the ability to intelligently select what is relevant, and discard what is not.