- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- Solving performance problems
- CPU profiling
- Threads
- Deadlock detector
- Memory profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Events in user interface
- Event inspections
- Built-in probes
- Probe classes
- Monitoring method invocation events
- Data storage
- Tables, rows, columns
- Lasting events and point events
- Table API
- Scalability
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
- FAQ: How to profile in my scenario?
Tables, rows, columns
Conceptually, the storage is based on the relation database model.
The information is stored in tables.
Each table has fixed number of columns and arbitrary number of rows.
Each column can store values of particular type, which is specified on table creation.
Supported types are: int, long, String.
Also, column can refer to particular row in another table;
such columns are called foreign keys.
Each column has a name which is a free form text describing column content when table data is presented to user.
The number of columns, their types and names are specified on table creation and cannot be changed afterwards.
Each row stores information for all columns according to their data types.
When table is created, it contains no rows. New rows can be added and existing rows updated. Row removal is not supported.
Rows are numbered starting with 1. This number is called row index.
The number of rows is limited via startup option
probetablelengthlimit.