1 / 8

JLab RDB-based Archiver

JLab RDB Archiver is a scalable and manageable data storage solution designed to support monitoring of 1M channels with low data latency. It addresses issues like independent deadbanding, data loss, and CPU loading. The performance of the system is tested and confirmed with a test setup. The hardware used includes Dell PowerEdge 2850 and EonStore RAID box. The archiver can handle 50,000 channels, 25,000 updates/second, and 4,000 database insertions/second, with a history data retrieval rate of 160,000/second. The next steps include transitioning to MYA for operations and implementing a sandbox archiving system.

lesterpayne
Download Presentation

JLab RDB-based Archiver

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. JLab RDB-based Archiver Matt Bickley (work by Anthony Bavuso and Chris Slominski)

  2. What? Another Archiver? • ScalabilityRequirement to support monitoring of 1M channels • ManageabilityRequiring no interaction by administrators • Design issues • Data latency (10-20 minutes from Czar) • Independent deadbanding (not using ADEL) • Data loss

  3. Data loss from Czar • Users saw transients in StripTool that were not recorded by Czar • IOC CPU loading less than 30% • Czar system loading less than 20% • Confirmed data loss with a test setup Archive Analyzer Czar Test IOC Database FFFF FFFE FFFC . . CA Server FFFF FFFE FFFD FFFC . . FFFF FFFE FFFC . .

  4. MYA Design Work Queue Work Queue Work Queue Scribe Thread Scribe Thread Scribe Thread User Commands Copycat Thread Watchdog Thread Main Thread MySQL Database EPICS Thread Control System

  5. MYA realtime thread scheduling • Prioritization, highest to lowest • Channel Access communication • Database scribe threads • Client communication, watchdog, etc. • No loss of data • If work queue > 2M events then database insertions are prioritized • Peak queue length 160,000 events • Average queue length 5,000 events

  6. System Hardware • Dell PowerEdge 2850 • Dual quad-core CPUs • 16 GB memory • ~$8K in 2006 ($4K for the memory) • EonStore RAID box • 16 300GB SCSI disks (~2 TB of storage) • RAID 0+1 • ~$21K in 2006 ($17K for the disks)

  7. Performance • 50,000 channels monitored • 25,000 updates/second • 4,000 database insertions/second • History data retrieval rate of 160,000/second(Get one day of a 1 HZ channel’s data in 0.5 seconds) • Store at least 1 year of data online

  8. What’s Next… • Cut over to MYA for operations • “Sandbox” archiver • Users specify archive requests • Limited data retention (up to 1 month) • Limited archive request lifetime OR • Archive everything • 300,000+ channels • Keep the data for 1 week (?) • Needs more memory, much less disk space

More Related