README.performance_monitoring 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263
  1. Performance analysis with Firebird.
  2. Document version 0.2
  3. Created by Nickolay Samofatov
  4. Performance monitoring framework is consisted of 2 parts:
  5. - Trace API
  6. - Reference implementation of analysis plugin
  7. Trace API.
  8. Trace API allows to plug a monitoring module into the engine and notify it of
  9. processes happening there. List of analysis plugins is specified in firebird.conf
  10. parameter TracePlugins. Each trace plugin receives notifications on each database
  11. opened by the engine as a call of procedure having following signature:
  12. NTRACE_BOOLEAN trace_attach(const char* db_filename, const TracePlugin** plugin);
  13. Conceptually TracePlugin is the plugin trace interface. It is implemented as a
  14. structure of function pointers and void* object pointer to be passed as first
  15. argument for each function.
  16. Given this interface plugin may install hooks for particular events and receive
  17. notifications for them. If plugin has interest in some kind of events for given
  18. database it sets plugin pointer to a structure containing non-null hook function
  19. pointers and returns NTRACE_TRUE value. Otherwise it should return NTRACE_FALSE.
  20. One category of hooks receives the same parameters as corresponding Y-Valve
  21. (public API) methods plus internal objects identifiers, generated PLANs for
  22. statements and performance counters. One more hook receives performance
  23. statistics for each procedure execution.
  24. Each hook function returns boolean value indicating success or failure. When hook
  25. function fails engine collects error message from plugin in the same thread
  26. context as hook was called, writes message to firebird.log and stops calling
  27. hooks for this particular database and trace plugin.
  28. See jrd/ntrace.h module for definitions of structures and events supported.
  29. Default analysis module.
  30. Reference implementation of analysis plugin is centered around a concept of
  31. performance snapshot. Snapshot detail may vary, but in any case it contains
  32. information on all activities performed by server for database during a given
  33. period of time, possibly in aggregated form. All snapshots may be compared to
  34. allow quantitative measurements of performance improvements due to various
  35. optimization activities or changes in user applications and infrastucture.
  36. Snapshot data is collected by trace module in raw form in a binary log file and
  37. then may be loaded into a stats database using ntrace utility.
  38. Stored snapshots may contain data on usage of indices, statements executed, their
  39. plans and performance counters, IO statistics and other performance data.
  40. Level of detail for information collected is set up in analysis trace module
  41. configuration file on per-database basis.
  42. Default analysis module does not have GUI and only provides a database with data
  43. on server activities and some stored procedures to use and maintain it.
  44. It is expected that third parties develop GUI tools, custom trace modules and
  45. statistics tools to statisfy rich client needs.