GroupSession
お世話になってます。弊社でGSを使用して、かれこれ4年になります。DBのサイズが大きいので最適化をしようと試みております。基本的には1:コマンドラインからDBのバックアップをとる 2:H2コンソールから”DROP ALL OBJECTS DELETE FILES;”を実行する。3:残った残骸を削除する rm -rm gs2db/gs2db*4:コマンドラインからリストアする とgs2db.h2.dbが半分のサイズになりますが、Exception in thread "main" org.h2.jdbc.JdbcSQLException: 関数の別名 "FTL_CREATE_INDEX" はすでに存在します が発生し、最後まで完了しません。このあたり改善していただけると有りがたいです。宜しくお願い致します。環境：OS:Debian7.0(Wheezy) 64bit java version "1.7.0_25"Tom:7物理メモリ:4GBヒープ:JAVA_OPTS="-Xms2816M -Xmx2816M -XX:PermSize=256M -XX:MaxPermSize=256M -Xss1024K -XX:NewSize=1024M -XX:MaxNewSize=1024M -XX:NewRatio=2 -XX:SurvivorRatio=4 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=32 -XX:TargetSurvivorRatio=80 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8010 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`"DBオプション:LOCK_MODE=3LOCK_TIMEOUT=5000DEFAULT_LOCK_TIMEOUT=5000MULTI_THREADED=0IFEXISTS=TRUEAUTOCOMMIT=OFFDB_CLOSE_ON_EXIT=FALSECACHE_SIZE=512000PAGE_SIZE=1024MAX_LENGTH_INPLACE_LOB=10240CACHE_TYPE=SOFT_LRUMVCC=TRUEMAX_QUERY_TIMEOUT=36000MAX_COMPACT_TIME=9900MAX_MEMORY_ROWS_DISTINCT=90000LARGE_RESULT_BUFFER_SIZE=12800DEFRAG_ALWAYS=FALSEMAX_LOG_SIZE=1TRACE_MAX_FILE_SIZE=1TRACE_LEVEL_SYSTEM_OUT=1
スペック書き忘れH2DBのjar(手動で入替):h2-1.3.170.jarTomは問題なく起動しているので、大丈夫っぽい。
H2のバックアップもしくはリストアの問題ですね。H2のメーリングリストで報告された方が良いと思います。
> H2のバックアップもしくはリストアの問題ですね。> > H2のメーリングリストで報告された方が良いと思います。なるほど。一応Googleの方は目を通しました（英語版)DBサイズの縮小はSHUTDOWN COMPACTでもダメなようで、バックアップしてオブジェクトを全部削除し、リストア（リカバリー）させることでサイズが小さくなるようです。で、GSの場合新たに追加されたWEBメール用のindex作成処理が原因でExceptionしているようです。H2のメーリングリストに投稿するとjavaプログラム本体の方に手を加える必要がありそうな回答が予想されるので、メーリングリストへの投稿は今のところ考えていません。
Geo様が開発の方かどうかは分かりませんが、つれないお返事ありがとうございました。以下の内容は弊社での環境なので「参考になるorならない」はそれぞれでご判断下さい。＊＊＊最適化の話＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ながーく運用しているとDBが肥大化してくると思います。昨日まで大丈夫だったけど。。なんか今日は重いなぁというケースは最適化で改善するかもしれません。＊＊＊私がやったこと＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊１：H2DBのjarを手動で入替る(gsession/WEB_INF/lib/の直下にあるjarファイルを入替る)Tomcatを停止して作業すること。h2-1.3.172.jar(7月１日現在1.3系の最新版)２：H2DBをサーバモードで起動する(サーバ側作業)java -Xms2048M -Xmx2048M -cp /var/tomcat/webapps/gsession/WEB-INF/lib/h2-1.3.172.jar org.h2.tools.Server(ヒープの設定は個人環境のフィジカルメモリによる)３：ブラウザでH2DBコンソールを起動する(クライアントＰＣでＯＫ)例:http://[ｈｏｓｔ名]:8082/ 接続方法はサポートページにあったかな？？４：右側のSQL入力用の窓で SHUTDOWN DEFRAG; を実行する(クライアントＰＣ側だよ)(ブラウザに～すでにDBが停止している～見たいな赤文字が出れば完了）５：サーバ側の２番のプロセスを終了する６：再度２番の作業をする(H2DBをサーバモードで立ち上げ)7：３番の作業をする８：右側のSQL入力用の窓で SHUTDOWN COMPACT; を実行する(クライアントＰＣ側だよ)(ブラウザに～すでにDBが停止している～見たいな赤文字が出れば完了）９：サーバ側のH2DBのプロセスを終了する１０：とりあえずどの程度コンパクトになったか確認する（任意）gsession/WEB-INF/db/gs2db/gs2db.h2.dbのサイズ※DEFRAGだけだとdbのサイズは肥大化します。※上記を実行する前に必ず gsession/WEB-INF/db をどこかにコピーした方が無難です (手動バックアップ)。※Googleで外人さんがミューラ氏に質問してる方法だとGroupSessionでは100%コケます (ScriptしてObject削除してRunScriptする方法)。※弊社のGS運用ではショートメール主体なので、indexを追加した方が速度が向上しました。 ただし検索オプションを送信者にして送信者を２人以上にして検索実行するとコケます (QueryTimeOut indexがうまく働いてない？EXPLAINして要調査)。※DBの設定のCACHE_SIZEをちょっと大きめに設定※DBの終了時に自動でSHUTDOWN COMPACTが実行されるので、connectOption.propertiesにMAX_COMPACT_TIMEを設定する（任意）。※GSessionのバックアップ設定で実行される処理はCPUが１つしか使われないので効率がよくない (1CPU-4COREの1つしか使用していない)。圧縮率や効率重視のため別にバッチを書いた。また２台構成や外付けHDD/別ディレクトリを構成可能な場合は該当のファイルをRsyncした方が早い。考察：デフラグ＆コンパクト化の箇所はバッチにした方がいいですな。少しでもGsession無料ユーザの助けになればうれしいです。でも自己責任でどうぞ。以上人柱でした。
TOP