BH12.12/SPARQLthon16/DDBJ

提供：TogoWiki

（版間での差分）
移動： 案内, 検索
(→ロード作業内容(ケース5))
(→ロード作業内容(ケース5))
 
234行： 234行：
==ロード作業内容(ケース5)==
==ロード作業内容(ケース5)==
 +
release 94のデータをロード<br>
フルテキストインデックスを自動生成するように戻して、全データの一活ロードを試した。<br>
フルテキストインデックスを自動生成するように戻して、全データの一活ロードを試した。<br>
-
ロード後にインデックス生成が始まるように、再起動を掛けてジョブは長時間のsleepを掛けて終了させないようにした。
+
フルテキストインデックス生成が始まるように、ロード後に再起動して長時間のsleepを掛けてジョブが終了しないようにした。
*ロード環境：mediumノード
*ロード環境：mediumノード
*メモリ設定
*メモリ設定

2014年1月24日 (金) 08:42時点における最新版

目次

エンドポイント構築

DDBJエントリーのRDFをトリプルストアにロードする。トリプル数は97億。
過去のページ
SPARQLthon10
SPARQLthon15


ロード作業内容(ケース1)

前回の調査(計測で分かったこと)で、メモリ不足によりロードができなくなる現象がみられたため、スパコンのFat,Medium環境で大量のメモリを確保してロードを試した。
結果：全データのロードに成功


サーバ環境

  • 環境1 (DDBJスパコンFatノード) 
Processors:	2 x Intel(R) Xeon(R) @ 2.66GHz (8cores) x 96式
Memory:	10TB
Hard Disks	ファイルサーバ(Lustre) RAID1
Operating System:	Red Hat Enterprise Linux Server 6.1
  • 環境2 (DDBJスパコンMediumノード) 
Processors:	2 x Intel(R) Xeon(R) CPU E5-2670 0 @ 2.40GHz (10cores) x 8式
Memory:	2TB
Hard Disks	ファイルサーバ(Lustre) RAID1
Operating System:	Red Hat Enterprise Linux Server 6.1

データ

DDBJエントリーデータ(release_93_rdf_v1)
RDFファイル行数:97億
ロード後のトリプル数：90億
※様子を見ながら進めたかったため、データを3回に分けてロード

  • 1回目(約42億)

bct,con,env,gss

  • 2回目(約30億)

est

  • 3回目(約25億)

htc,htg,hum,inv,nan,pat,phg,pln,pri,rod,sts,syn,tsa,una,vrl,vrt

設定ファイル

OSS版のデフォルトのからの変更点。 BSBMの変更を参考にして適宜設定。 

[Database]
;MaxCheckpointRemap           = 2000 ←[Parameters]セクションへ移動

[Parameters]
MaxMemPoolSize                  = 1500000000 ←増やしたがロードには関係なさそう

[Parameters] ↓必要メモリ量に応じて増やす。枠下の「メモリ量の見積もり」を参照
NumberOfBuffers          = 80000000
MaxDirtyBuffers          = 60000000
MaxCheckpointRemap       = 24000000
UnremapQuota             = 0

[Parameters]↓ ロードする RDF データの置いてあるディレクトリを追加する
DirsAllowed                   = ., /home/w3sw/store/virtuoso_medium/share/virtuoso/vad, /home/sw/tf/ddbj/release_93_rdf_v1
  • メモリ量の見積もり
    • ロード時にどの程度メモリを消費するかについては、各データ長にも依存するため単純にトリプル数から計算できない。似た形式のデータであれば、使用メモリ量はトリプル数に比例して増加するので、見当がつかない場合にはサンプルデータをロードして見積もる。
    • NumberOfBuffers, MaxDirtyBuffers, MaxCheckpointRemapはドキュメントでは8K/bufferと記載があるが8.5K/bufferで見積もった方がよい。参考
    • swapを起さないようにNumberOfBuffersはサーバ搭載RAMの2/3程度に留める。
    • MaxDirtyBuffersはNumberOfBuffersの3/4程度を目安にする。
    • MaxDirtyBuffersはMaxCheckpointRemapの1/4程度がよいらしい参照。
    • スパコンのFAT、Midiumノードではプロセス単体に対するメモリ量を要求するので、NumberOfBuffersがスパコン要求メモリの4/5程度でも良い。

ロード用スクリプト(抜粋)

  • ロードファイルの登録用SQLファイル

add_load_list5.sql 

ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjhtc*.ttl' , 'http://ddbj.nig.ac.jp/graph/htc/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjhtg*.ttl' , 'http://ddbj.nig.ac.jp/graph/htg/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjhum*.ttl' , 'http://ddbj.nig.ac.jp/graph/hum/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjinv*.ttl' , 'http://ddbj.nig.ac.jp/graph/inv/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjmam*.ttl' , 'http://ddbj.nig.ac.jp/graph/mam/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjpat*.ttl' , 'http://ddbj.nig.ac.jp/graph/pat/');
ld_dir_all('/home/sw/tf/ddbj/release_93_rdf_v1', 'ddbjphg*.ttl' , 'http://ddbj.nig.ac.jp/graph/phg/');
  • ロード用スクリプト

スパコンにジョブを投げるため、実行サーバ上でVirtuoso起動＋ロードファイルの登録 + ロード + チェックポイント + Virtuoso停止の一連の処理を行う
bulk_load_fat.sh 

#!/bin/sh
#$ -S /bin/sh

echo  `date +'%Y/%m/%d %H:%M:%S'` "Bulkload start"

VIRTUOSO_HOME=/home/w3sw/store/virtuoso_medium
DBBASE=/home/w3sw/store/virtuoso_medium/var/lib/virtuoso/db
LOGFILE=/home/w3sw/store/virtuoso_medium/var/lib/virtuoso/db/load.log
PIDFILE=$DBBASE/virtuoso.lck

echo  `date +'%Y/%m/%d %H:%M:%S'` " Virtuoso start..."
$VIRTUOSO_HOME/bin/virtuoso-t +config $DBBASE/virtuoso_fat.ini +wait

if [ -f "$PIDFILE" ]; then
  echo  `date +'%Y/%m/%d %H:%M:%S'` " Virtuoso has been started"

  $VIRTUOSO_HOME/bin/isql 1116 dba dba < $DBBASE/add_load_list5.sql
  echo  `date +'%Y/%m/%d %H:%M:%S'` " Load start"
  $VIRTUOSO_HOME/bin/isql 1116 dba dba exec="rdf_loader_run();"

  echo  `date +'%Y/%m/%d %H:%M:%S'` " Checkpoint start"
  $VIRTUOSO_HOME/bin/isql 1116 dba dba exec="checkpoint;"
  echo  `date +'%Y/%m/%d %H:%M:%S'` " Checkpoint end"

  echo  `date +'%Y/%m/%d %H:%M:%S'` " Virtuoso shutdown..."
  $VIRTUOSO_HOME/bin/isql 1116 dba dba exec="shutdown();"
  echo  `date +'%Y/%m/%d %H:%M:%S'` " Virtuoso has been ended"
else
  echo "ERROR! Virutuoso start"
fi

echo  `date +'%Y/%m/%d %H:%M:%S'` "Bulkload end"
  • ジョブ投入(fatノードの場合) 
qsub -l s_vmem=768G -l mem_req=768G -l month -l fat bulk_load_fat.sh

ロードログ

データ 並列ロード 工程 所要時間 所要時間/10億トリプル 備考
1回目(約42億) 4並列 ロード 9時間54分 141分 メモリ設定(256G)が足りず、後半は失速したため、所要時間は不明
チェックポイント 3時間18分 47分
再起動 10分 2分
フリーテキスト 8時間13分 117分
2回目(約30億) 4並列 ― ― ― ロードは出来たがチェックポイントでスレッドエラーが発生し強制終了
無し ロード 6時間45分 135分
チェックポイント 5時間17分 105分
再起動 4時間10分 83分 ロード後の初回起動に時間がかかる。その後は30分程度で起動する。
フリーテキスト 8時間51分 177分
3回目(約25億) 無し ロード 6時間21分 152分
チェックポイント 9時間10分 220分
再起動 6時間03分 145分 ロード後の初回起動に時間がかかる。その後は30分程度で起動する。
フリーテキスト 4時間49分 115分
ロード計 23時間00分
チェックポイント計 17時間45分
再起動計 10時間23分
フリーテキスト計 20時間53分
総計 72時間01分

ロード作業内容(ケース2:失敗)

データを分けず、全データの一活ロードを試した。

  • ロード環境：fatノード
  • メモリ設定 
NumberOfBuffers          = 80000000
MaxDirtyBuffers          = 60000000
MaxCheckpointRemap       = 20000000
UnremapQuota             = 0
  • ジョブ 
qsub -l s_vmem=800G -l mem_req=800G -l month -l fat bulk_load_fat.sh
  • 結果：失敗
  • 結果詳細：チェックポイントでロード処理が中断され、速度が遅かったため停止。

ロード作業内容(ケース3:失敗)

チェックポイントを発生させないように変更してロード 

checkpoint_interval(6000);
  • ロード環境：fatノード 
NumberOfBuffers          = 80000000
MaxDirtyBuffers          = 60000000
MaxCheckpointRemap       = 20000000
UnremapQuota             = 0
  • ジョブ 
qsub -l s_vmem=800G -l mem_req=800G -l month -l fat bulk_load_fat.sh
  • 結果：失敗
  • 結果詳細：ディスクエラーが発生したため、停止。 
07:07:21 Write failure on database /home/w3sw/store/virtuoso_fat/var/lib/virtuoso/db/virtuoso.db
07:07:22 /home/w3sw/store/virtuoso_fat/bin/virtuoso-t() [0x8db8da]
07:07:22 /home/w3sw/store/virtuoso_fat/bin/virtuoso-t() [0x8db938]
07:07:22 /home/w3sw/store/virtuoso_fat/bin/virtuoso-t() [0x4b9b75]
07:07:22 /home/w3sw/store/virtuoso_fat/bin/virtuoso-t(iq_loop+0x3bb) [0x5113cb]
07:07:22 /home/w3sw/store/virtuoso_fat/bin/virtuoso-t() [0x8e31dc]
07:07:22 /lib64/libpthread.so.0() [0x35c40077e1]
07:07:22 /lib64/libc.so.6(clone+0x6d) [0x35c3ce68ed]
07:07:22 GPF: disk.c:2231 internal error

ロード作業内容(ケース4)

データを分けず、全データの一活ロードを試した。
また、フルテキストインデックスが自動生成されないように設定を変更し、ロードが終了した後に明示的に作成した。

  • ロード環境：mediumノード
  • メモリ設定 
NumberOfBuffers          = 80000000
MaxDirtyBuffers          = 60000000
MaxCheckpointRemap       = 20000000
UnremapQuota             = 0
  • フルテキストインデックスの自動生成削除 
DB.DBA.RDF_OBJ_FT_RULE_DEL('', '', 'ALL');
  • ジョブ 
qsub -l s_vmem=700G -l mem_req=700G -l month -l medium bulk_load_medium.sh
  • 結果：成功。ただし、テキストインデックス作成に8日間掛かった。

ロード作業内容(ケース5)

release 94のデータをロード
フルテキストインデックスを自動生成するように戻して、全データの一活ロードを試した。
フルテキストインデックス生成が始まるように、ロード後に再起動して長時間のsleepを掛けてジョブが終了しないようにした。

  • ロード環境：mediumノード
  • メモリ設定 
NumberOfBuffers          = 80000000
MaxDirtyBuffers          = 60000000
MaxCheckpointRemap       = 20000000
UnremapQuota             = 0
  • ジョブ 
qsub -l s_vmem=700G -l mem_req=700G -l month -l medium bulk_load_medium.sh
  • 結果：成功。

ロードログ

工程 所要時間 備考
ロード 26時間55分 メモリ(RES)使用 317G → 557G
チェックポイント 8時間16分 メモリ(RES)使用 557G → 560G　チェックポイント工程ではメモリはほとんど増加しない
再起動 0時間13分 メモリ(RES) → 326G
テキストインデックス生成 23時間17分 メモリ(RES)使用 326G → 380G
合計 58時間41分

気付いたこと

メモリ使用量

  • 今回の最大メモリ使用量は472G。但し、途中再起動を行っているため、一括ロードの場合は600G程度が必要だと思われる。
  • NumberOfBuffersの設定値に応じて起動時にVIRT、RESともメモリ確保される(データが全くロードされていない状態でも大量に確保される)。
  • VIRTはNumberOfBuffersの上限値に近い値で確保される。RESの確保基準は不明。
  • ロードが始まるとRESが徐々に増加する。ロード量に比例して増加し、再起動しない限り下がることはない。
  • NumberOfBuffersで設定したメモリ量までRESが上がりきった後は、ロードの速度が低下する。
  • ロード終了後にVirtuosoを再起動すると、使用メモリは終了時のRESではなく、再びNumberOfBuffersの設定値基準に応じて確保される。
  • ロード時より低いメモリ設定でも再起動は可能。例：RES500Gでロードが終わっても50G設定に変更して再起動
  • 再度追加でロードを行った場合、最初のファイルのロードに先立ちRESが増加し、前回ロード終了時のRESに近い値まで増加した後、ロードが始まる。
  • 前回ロード終了時よりやや低めのRESでロードがスタートするため、再起動を挟むことで使用メモリを若干抑えることができる。
  • チェックポイント実行中には使用メモリの増加は見られない。
  • フリーテキストインデックス作成時には使用メモリは徐々に増加する。ロード時と同様に大量にメモリを消費する。

スレッドエラー

スレッド系のエラーに何度か遭遇した。並列ロードが原因だと思われる。

  • ロードは正常に終わるがチェックポイント(disk書き出し)でエラーが発生する。
  • 同じデータでもエラーが出る場合と出ない場合がある。
  • エラーログは出力されるが、サービスは動き続ける。
  • サーバのLoad averageの値がかなり上がっていた(ように思う)。
  • エラーログは以下の通り 
14:33:30 Read failure on database /home/w3sw/store/virtuoso_medium/var/lib/virtuoso/db/virtuoso.db
14:33:31 /home/w3sw/store/virtuoso_medium/bin/virtuoso-t() [0x8db8da]
14:33:31 /home/w3sw/store/virtuoso_medium/bin/virtuoso-t() [0x8db938]
14:33:31 /home/w3sw/store/virtuoso_medium/bin/virtuoso-t() [0x4b978c]
14:33:31 /home/w3sw/store/virtuoso_medium/bin/virtuoso-t(iq_loop+0x9b) [0x5110ab]
14:33:31 /home/w3sw/store/virtuoso_medium/bin/virtuoso-t() [0x8e31dc]
14:33:31 /lib64/libpthread.so.0() [0x35c40077e1]
14:33:31 /lib64/libc.so.6(clone+0x6d) [0x35c3ce68ed]
14:33:31 GPF: disk.c:2082 internal error

次回のロードで試すこと

  • 一括で97億トリプルのロードを実行する。NumberOfBuffersは700Gで設定する
  • フリーテキストは自動作成されないように初回起動時に削除し、ロード完了後明示的に作成する。
  • ストライピングを設定する(ディスクに余裕がある場合)。

課題

  • スレッドエラーが発生し、サーバのLoad averageが上昇する傾向がある。現状では並列ロード時のみ発生するため、並列ロードによる高速化が困難。
  • 大量のメモリ要求(見込み700G)が必要なため、スパコンの稼働状況によってはロードのジョブが実行できない可能性がある
  • SSD環境でメモリ量が抑えられるか検証する環境がない

リソースURI用Webページ構築

構成

  • 公開ページはDDBJサイトの既存WordPressを流用する
  • Ontologyファイルからのデータ抽出はARQを使ってSPAQRLを叩いて、その結果でHTMLを生成する

課題

Taxonomy(taxdump.owl)の定義

各taxonomyidについてはddbjドメインではなく、identifired.orgで定義されているており、ddbjサイトでリソースURIとして公開できない
→owlファイルに"idtax:1148 rdfs:seeAlso ddbjtax:1148"を追加する

ddbjのPREFIXの最後が"#(フラグメント)"になっているが、リソースURIページは全定義を１つのページで公開しなければならないため、個々のページを用意するのであれば"/"のURI区切りに変更する
→片山さんに変更依頼

「/mw/BH12.12/SPARQLthon16/DDBJ」より作成