1 / 13

Status of the Channel Access Zippy Archiver (CZAR)

Status of the Channel Access Zippy Archiver (CZAR). B. Bevins , et. al. Outline. Status Performance Limitations Development Activities New Features Future Plans. Status. CZAR has been our production archiver for over a year. Common History API (HAPI) supplies data to:

gordy
Download Presentation

Status of the Channel Access Zippy Archiver (CZAR)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 (we’re 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.

More Related