KEK 入射器における CSS Archiver の現状
PRESENT STATUS OF CSS ARCHIVER AT KEK INJECTOR LINAC工藤拓弥#, A), 草野史郎 A), 佐藤政則 B), 古川和朗 B)
Takuya Kudou #, A), Shiro KusanoA), Masanori SatohB), Kazuro FurukawaB)A)
Mitsubishi Electric System & Service Co., Ltd.
B)
KEK, Accelerator Laboratory/SOKENDAI, Department of Accelerator ScienceAbstract
In the KEK injector linac, the device history information has been stored to the CSS-based Archiver system since2011. Though PostgreSQL is used as the backend database in this system, its large database file size brings a slowreadout speed performance. For this reason, we divide the database file into smaller size one corresponding to eachmonth. In addition, we reorganize the tables in PostgreSQL database by using the pg_reorg without any locks. These
measures bring a smaller database file size and the improvement of readout speed performance. In this paper, wepresent the status of CSS Archiver system used for the KEK injector linac operation in detail.
Channel Access を 介 し て 情 報 を 収 集 す る Archive
Engine およびそれらを記録するバックエンドデータ
ベース部から構成されている。バックエンドデータ
KEK 入射器（以下、入射器）では、各制御機器の[2][2][2]状態監視を目的として、設定値および出力値の変化 ベースは、Oracle 、MySQL 、および PostgreSQL情報履歴を蓄積している。KEKB 運転開始時には、 などのリレーショナルデータベース管理システム
機器グループごとに専用の履歴ソフトウェアを開発 （RDBMS）から選択可能であるが、入射器では、[3]し、運用してきた。2004 年に、Spallation Neutron 電子ログブックシステム での運用実績のあったSource（SNS）で開発された Channel Archiver を導入 PostgreSQL を採用している。CSS Archiver においてし た 。 Experimental Physics and Industrial Control は、記録対象の追加や削除などの変更を反映させるSystem（EPICS）ツール群のひとつである Channel ために Archive Engine の再起動が必要になる。入射Archiver は、導入以降安定に運用されてきたが、イ 器では、Archive Engine 再起動による履歴情報収集
ンデックスファイル破損による障害が度々発生した。 の停止時間を最小限に抑えるため、デバイスごとに障害発生時には既に Channel Archiver の開発は終了 Archive Engine を分けて運用している。SuperKEKB
し て お り 、 障 害 対 処 は 困 難 で あ っ た 。 そ こ で 、 に向けた改造による制御機器の増加にともない、SuperKEKB 主リング制御システムにて導入予定であ Archive Engine 数および記録対象情報点数も増加しる Control System Studio[1]（CSS）Archiver を導入し、 ていった。Table 1 に示すとおり、2015 年 7 月現在、2011 年に運用を開始した。本稿では、CSS Archiver Archive Engine 数は 19、記録対象は約 55000 点にのぼる。の導入および運用状況について報告する。
2011 年の運用開始から現在まで、約 270 億点の履歴情報を記録し、データベースのファイルサイズは2. CSS Archiver システム
3.2 TB まで巨大化したが、比較的安定に運用をおこ
CSS は、DESY で開発が開始され、現在、多くの なっている。
研究機関が共同開発している制御システムツール群
Table 1: Current Operation Statusであり、Eclipse Platform 上で動作するものである。
CSS には、加速器制御に要求される標準的なコン
Operation date
2011/08 ~ 2015/07
ポーネントが豊富に用意されているため、短期間で[2]の シ ス テ ム 開 発 が 可 能 で あ る 。 ま た 、 Linux 、
Number of Archive Engine
19
Windows[2]、および Macintosh[2]など複数の OS 上で
Number of EPICS PVs
55597
動作可能なため、様々なシステムへ容易に導入する
Total number of archived data points
27.4 billion
ことができる。CSS は、前述のような利点から各研究所での利用が広まっており、SuperKEKB 主リング
Database file size
3.2 TB
制御システムでも導入が予定されている。
SuperKEKB 主リング運転開始以降は、入射器とのCSS Archiver の運用状況データ相関を解析することも想定されるため、CSS 3.のツールの一つである CSS Archiver を導入した。
3.1 概要CSS Archiver は、EPICS 通信プロトコルである
CSS Archiver は、履歴情報収集系から表示ツールまで揃っているため、独自の開発をおこなわずに運# kudoh@post.kek.jp

1.

はじめに

___________________________________________

用を開始することができた。しかしながら、運用期 一つのディスク上に格納できなくなることが予測さ間の長期化にともない蓄積データサイズは巨大化し、 れた。そのた め、本システムで は PostgreSQL の読み出し速度の低下がみられるようになった。入射 パーティショニング機能を用いて、履歴データテー器では、利便性の向上、長期運用に向けたデータ管 ブルを月単位で分割している。PostgreSQL は、テー理、および読み出し速度の高速化を目的として、以 ブルごとに格納先を指定できるテーブルスペースと呼ばれる機能を有しており、この機能を用いて分割下のような対策を実施している。
した履歴データテーブルを複数のディスク上に分散して格納することが可能である。パーティショニン
3.2 Viewer web アプリケーション
CSS Archiver の履歴データは、CSS ツール群の一 グ機能は、分割した複数のテーブルを一つのテーブ部である Data Browser を用いて参照可能である。し ルとして見せることができる。このため、パーティかしながら、使用する各端末へ CSS をインストール ショニング導入による参照側の変更は不要であった。
す る 必 要 が あ る た め 利 便 性 に 乏 し い 。 そ こ で 、 また、パーティショニング導入による読み出し速度
Adobe Flash[2]を用いた Viewer web アプリケーション の高速化も期待されたが、速度面での向上は見られを開発し、運用している。Adobe Flash を用いたアプ なかった。
リケーションは、単純な HTML で記述されたページ 3.4 ローカルディスクを用いた専用サーバ計算機と比して操作性および表現力に優れており、Adobeバックエンドデータベースに使用しているFlash Player[2]が動作する計算機環境であれば OS をPostgreSQL などの一般的な RDBMS では、ディスク問わず動作可能である。
アクセスが読み出しおよび書き込み速度高速化のボバックエンドデータベースと Viewer アプリケートルネックになる。メモリ上に全てを展開できる小ション間の通信には、ActionScript Message Format と規模データベースとは異なり、本システムのような呼ばれるバイナリフォーマットを基盤とした巨大データベースにおいては、ディスクアクセスが[4]amfphp を用いている。これにより、軽量かつ高速発生することは避けられない。そこで、高信頼性かに通信をおこなうことが可能となり、アプリケー
つ低アクセス速度のネットワークディスクを用いるションのパフォーマンス向上に大きく寄与している。
サーバ計算機および低信頼性かつ高アクセス速度の本アプリケーションは、複数のデータを同時にグローカルディスクを用いたサーバ計算機の 2 台を用ラフ化することが可能である。また、マウス操作にいた並列運用をおこなっている。Table 2 に示すとおよるグラフの拡大ができるため、複数データ間の相り、ローカルディスクを使用するサーバ計算機は、関解析を容易におこなうことができる。データ読み
ネットワークディスク上のデータ読み出しと比較し出し期間は、絶対日時指定に加え相対日時指定も可て、約 10 倍高速に読み出しをおこなうことが可能能となっており、自動更新機能と組み合わせることであり、通常の読み出しにはこちらを使用している。
で、最新の履歴情報を自動で表示することができる。
これにより、機器の状態監視が容易におこなえるよ
Table 2: Read Speed of 1-Hour History Data
うになった。Figure 1 は、本アプリケーションの表
Network disk
0.835 sec
示例を示している。
Local disk

3.5

0.091 sec

データベースチューニング

バックエンドデータベースに使用している
PostgreSQL は、チューニング未実施の状態に於いても一定の性能を確保することができる。しかしながら、サーバ計算機の性能を最大限活用するためのチューニングをおこなうことにより、読み出しおよび書き込み速度を大きく向上させることが可能である。本システムでは、メモリ関連の一般的なチューニングに加え、同期コミットの無効化を実施している。通常、PostgreSQL はデータの永続性を保証するために、ディスクへの書き込みが完了するまで待つ同期書き込みと呼ばれる機能を使用するが、同期コミットの無効化により、ディスクへの書き込みが非Figure 1: Viewer web application.
同期になる。これにより、データ損失のリスクは微増するが処理速度は大きく向上する。本システム稼動中のサーバ計算機においてディスク入出力待ちが3.3 データベースのパーティショニング頻発し、処理速度が低下していたが、同期コミット
本システムのデータベースサイズは、運用開始かの無効化によりディスク入出力待ちを大きく低減すら半年間で 362 GB にまで肥大化した。今後の連続ることができた。これにより、読み出しおよび書き運用により、さらにデータベースサイズは肥大化し、込み速度を大きく向上することができた。

をおこなったところ、Table 4 に示すとおりバックエバ ッ ク エ ン ド デ ー タ ベ ー ス に 使 用 し て い る ンドデータベースに PostgreSQL を用いる場合に比PostgreSQL は、追記型アーキテクチャを採用してい べ、データベースサイズが約 1/10 程度に大きく減少るため、データ更新を頻繁におこなうことにより実 することが確認できた。現在も運用試験を継続してデータサイズ以上にデータベースファイルサイズが おり、読み出し速度試験、長期安定試験を実施する肥大化する。これは、断片化と呼ばれる現象で有り、 予定である。
3.6

データベースの再編成

速度性能の著しい低下をもたらす。CSS Archiver は、Table 4: Database File Size of 1-Day Data
履歴データの追記のみをおこなうため、データの更Backend database
Database file size during
新は発生せずデータ自体は肥大化しない。しかしな
1 day operation
がら、読み出し速度高速化のために使用しているイ
ンデックスは、履歴データが追記されるごとに更新
PostgreSQL
16 GBを繰り返し、サイズが増加し続ける。PostgreSQL のApache Cassandra
1.65 GB
CLUSTER コマンドにてデータを再編成することにより、これを解消することが可能であるが、対象のテーブルがロックされてしまうため、システムの一 4.2 データ欠落問題
本システムは、履歴データ最終記録日時や接続の時的な停止が要求される。
このため、本システムではテーブルのロックを必 成否などの情報を、記録対象ごとに参照することが要としないデータ再編成ツールである pg_reorg[5]を 可能である。この情報の最終記録日時ではデータ収使用している。これを用いることにより、運用中に 集を続けているように見えるが、実際にはバックエシステムを停止することなく、データの再編成を定 ンドデータベースにデータが記録されていないとい期的におこなうことが可能となった。Table 3 に示す う不具合が度々発生した。不具合が発生していた
とおり、定期的なデータ再編成の導入により、イン サーバ計算機にて、メモリ不足によるスワップ使用デックスサイズが半減し、読み出し速度は導入前と が頻発していたため、より搭載メモリの多いサーバで Archive Engine を動作させるように変更したとこ比べ約 3 倍高速になった。
ろ不具合が発生しなくなった。問題調査のために構
Table 3: Result of 1-Month Data Reorganization
築した試験環境では症状が再現せず、明確な原因は特定できていないが、サーバ計算機のメモリ不足にBefore using
After using
起因してデータ欠落が発生したと推測される。
pg_reorg
pg_reorg

まとめData size

14 GB

14GB

5.

Index size

12 GB

665 MB

Read speed of2.237 sec

0.744 sec

入射器では、バックエンドデータベースにRDBMS を使用する CSS Archiver を導入し、2011 年に運用を開始した。運用を重ねるにつれ、データベースサイズは大きく肥大化し、読み出し速度の低下が見られた。このため、データベースのパーティショニング化、運用中のデータベース再編成などの対策を実施することにより、データベースファイルサイズの縮小および読み出し速度の向上を実現できた 。 現 在 、 バッ ク エ ン ドデ ー タ ベ ー スに ApacheCassandra を使用する Cassandra Archiver for CSS の試験中であり、満足な試験結果が得られれば、実運用に使用する予定である。今後も、新システムの試験および現システムの改良を重ね、安定した入射器ビーム運転に貢献していきたい。

1 day history data

4.

課題

4.1

PostgreSQL 以外のデータベースの検討

本システムのバックエンドデータベースに使用している PostgreSQL を始めとした RDBMS は、データの一貫性を保証するように設計および最適化されている。そのため、本システムのようなデータ追記が主である巨大システムでは、満足な速度性能を達成することが一般的に困難である。
速度性能の改善を目的として、バックエンドデー
タベースに Apache Cassandra[6] を用いる Cassandra
Archiver for CSS[7] の導入を検討している。ApacheCassandra は、Facebook 社にて開発が開始された大規模データ格納用のデータベース管理システムである。個々を識別する情報とそれに対応する値を格納するキー・バリュー型と呼ばれる単純な仕組みを採用しているため、RDBMS と比較して高速な動作が期待できる。また、データを複数の計算機で分散して格納する機能を有しており、サーバ計算機の台数を増やすにつれ性能や耐障害性を向上させることが可能である。Cassandra Archiver for CSS の運用試験

参考文献[1] http://controlsystemstudio.org/.
[2] 本論文中で使われているシステム・製品名は、一般に各社の商標または登録商標です。
[3] T. Kudou et al., “Upgrade of Electronic Logbook System at
KEK Injector Linac”, Proceedings of the 8th Annual
Meeting of Particle Accelerator Society of Japan, Tsukuba,Aug. 1-3, 2011.
[4] http://www.silexlabs.org/amfphp/.
[5] https://github.com/ossc-db/pg_reorg/.
[6] http://cassandra.apache.org/.
[7] http://oss.aquenos.com/epics/cassandra-archiver/.