Status of the Channel Access Zippy Archiver CZAR

1
Status of the Channel Access Zippy Archiver (CZAR)

• B. Bevins, et. al.

2
Outline

• Status
• Performance
• Limitations
• Development Activities
• New Features
• Future Plans

3
Status

• CZAR has been our production archiver for over a
  year.
• Common History API (HAPI) supplies data to
• XARR, StripTool, ArchiveViewer
• hapiget (command line tool)
• TCL programs using the Combat ORB
• A working prototype of a TCL archive viewer was
  written in an afternoon!
• Specialized data collection such as
  event-triggered mode has reduced the need for
  other data collection tools.
• Lead developer left for private industry

4
TCL Archive Viewer
5
Performance Data

• 37,272 signals connected
• Stores about 2 GB/day
• About 810 GB of data available online dating back
  to June 2004
• 253.5 billion data points available online
• Platform
• Redhat ES3, dual 3GHz P4, 16 GB memory, 1 TB RAID
  array

6
Retrieval Performance
7
Limitations

• Data acquisition engine has failed a few times
• Scaling issues
• Data retrieval server fails often, requiring
  constant monitoring
• Possibly vulnerable to ill-behaved clients
• Initial version is incompletely documented
• Backup system only partially implemented and not
  automated

8
Limitations

• Awkward management of data streams and groups
• results in archiving unneeded streams
• Scaling problem with original design
• many data chunks contain only one point in
  time, resulting in very large database tables
• causes slow data retrieval times
• one system failure was a table index overflow!

9
Development Activities

• Goal is to achieve a stable system requiring
  minimal monitoring
• New version is test case project using more
  rigorous Software Engineering practices
• Formal requirements, design review, development
  standards, code review, testing

10
New Features

• Automated backups to Computer Center tape silos
  (were a drop in the bucket to them)
• Stream/group management policies and tools to
  assist in management
• Data culling capabilities similar to Epics ADEL
  but will work on fields other than .VAL
• Fixing and documenting the data retrieval access
  mechanism

11
Future Plans

• Decommissioning system clogged with redundant and
  damaged data
• Starting over with a clean database using data
  culling wherever appropriate
• Managing stream requests so data is only archived
  for the period of user interest
• High performance lossless data compression

12
Summary

• Current czar archiver is meeting customer needs,
  but has problems
• Development activities are underway to shore up
  holes in the current system
• Planning to start with a fresh system that is
  more thoroughly engineered and tested up front

13
Status of the Channel Access Zippy Archiver (CZAR)

• B. Bevins, et. al.