Application checkpointing is a widely used recovery mechanism that consists of saving an application's state periodically to be used in case of a failure. In this study we investigate the utilisation of distributed checkpointing for replicated state machines. Conventionally, for replicated state machines, checkpointing information is stored in a replicated way in each of the replicas or separately in a single instance. Applying distributed checkpointing provides a means to adjust the level of fault tolerance of the checkpointing approach by giving away from recovery time. We use a local cluster and cloud environment to examine the effects of distributed checkpointing in a simple state machine example and compare the results with conventional approaches. As expected, distributed checkpointing gains from memory consumption and utilise different levels of fault tolerance while performing worse in terms of recovery time.

Software as a Service(SaaS) solutions are state-ofthe-art advancement of the cloud computing technologies that bring on new challenges in terms of cloud system management. It is the usual case where user jobs (macros, scripts, programs, etc.) are executed as threads inside platform processes making the distinction between user jobs very hard to perform. In case of a problematic thread(such as a thread with memory leakage) system administrator needs to manually detect the problematic thread or even kill the entire process harming the rest of the user jobs in the process. In this paper, we propose a novel approach based on processing the memory footprint of the problematic process. We use Fourier analysis to calculate the energy spectral densities of the memory footprints where threads with different characteristics produce different densities in case of a memory leakage. We represent a thread's memory usage characteristic as a periodic signal with a memory consumption frequency and a unit memory consumption amount. Our results show that for a process involving two threads, it is possible to distinguish the problematic thread by observing the memory footprint's energy density after the anomaly begins. We further investigate our results to relate the thread parameters with the difference between energy densities and derive guidelines on identifying the specific thread causing the problem. As a result we found out that certain thresholds exist for unit memory consumption to be able to identify the problematic thread and also the decomposability of the memory footprint has an exponential relation with the rate of memory consumption frequencies of process' threads.