yCrash Capacity Requirements

yCrash is a powerful analysis tool designed to run seamlessly across various environments with minimal resource requirements. This document provides insights into the system specifications needed to deploy yCrash Server, the impact of the yc-360 script on server performance, and its compatibility with different infrastructures. Whether you're running on bare metal, virtual machines, containers, or cloud environments, yCrash ensures efficient and lightweight crash diagnostics with negligible overhead. Below are the key details regarding its setup and performance.

1. What are the system requirements to run yCrash Server?

yCrash server capacity is dependent on number of crash analysis you intend to do. Here is the rough estimate you can use.

Infrastructure: yCrash Server is platform agnostic. It can run on any infrastructure (bare metal, cloud, container), any operating system(Unix, Linux, Solaris, Windows,...).

Software: All it needs is Java 8 (or above) version. No other external softwares needs to be installed.

CPU: Doesn't really matter. Any modest CPU capacity is fine.

Memory: You want to allocate 2x the size of your application's JVM heap size (i.e. -Xmx). Let's say you want to monitor multiple applications whose heap size (i.e. -Xmx) varies, then you want to pick the largest heap size. Let's say your largest application's heap size is 2GB, then you want to allocate 4GB as the RAM size requirement for yCrash server. If you would like to ensure high availability, yCrash server can be deployed on multiple nodes behind a load balancer.

Storage: Again storage depends on the amount of crash reports you want to archive. Approximately 100GB. yCrash's analysis results can be stored in local disk, NFS, AWS S3 storage, PureStorage (or any AWS S3 API compatible storages).

2. What is the overhead yc-360 script adds to our servers?

The yc-360 script adds very negligible overhead (if at all it can be measured), for following reasons:

Dormant: yc-360 script doesn't always run your server. It runs only when it's triggered. Once triggered, it captures the dumps, transmits them to yCrash server and then immediately becomes dormant.

Duration: yc-360 script runs for less than < 1 minute when triggered. Within this time period it captures all the data and transmits to yCrash server. (Note: if your application's heap size is large then it can take a few more seconds to complete).

Non-Intrusive: Unlike APM tools which run within the JVM, yc-360 script runs on the server (outside the JVM). They don't intercept every single transaction. Only when a problem happens, it reads and transmits dump files which are written to the disk. Thus It adds very negligible overhead.

3. Can yCrash run on BareMetal, VMWare, Containers/Kubernetes, native cloud environments?

yCrash is platform agnostic. It can run on all the environments.