最適化の目的
私たちは、クラスタグループのオンラインHBaseのグループ化機能を使用しますが、特にビジネスの異なるグループの特性に合わせて最適化していない、サービスの機能が完全に覚醒ないのHBase。
この記事書類事業グループ化パラメータ最適化の探査は、指標とマシンの負荷を監視リージョンサーバー異なる形状の影響を理解する機会を取ります。最適化の後、低レイテンシーリージョンサーバー単一のクエリ、ディスクIOを削減、システムはより安定しています。これにより、これにより、マシン、リソース使用率を増強する能力、コスト削減を削減、スループットを向上させることができます。
これらの問題を解決するために、
問題は、現在、主にサービスのパケットライトで見つかりました。リソース使用率は高いが、時間から遅い時間rpcp99にはありませんが。あなたがモニターから見ることができ、断続的なキューの待ち時間が長くなります。ルックリージョンサーバーのログは、hlogsは、あまりにも多くのブラシ領域は、フラッシュやコンパクトな圧力が集中し、同時にトリガリミット。小さなたくさんのファイルを磨き、書き込み増幅効果は明らかです。
分析
パケットリージョンサーバーの17セットがあり、520つの地域については、要求量は、1日の間に比較的安定しています。駅の利用を分析します。
物理リソースの使用状況
マシンタイプ
2 * E5-2650v4（2つの* 12の核）、8×32G、2 * 150G（120G）SATA SSD + 12 * 800G（960G）SATA SSD
マシンの負荷
CPU負荷が高くありません。
より保守的なアプリケーションメモリの割り当てに起因するメモリ、150グラムの総外部リージョンサーバー・ヒープ内のヒープ、データノードの4G、キャッシュを読み取るためのオペレーティング・システムの大部分。しかし、自身も読み取りキャッシュの100グラムが装備されているリージョンサーバー、オペレーティング・システムは、無用のキャッシュをお読みください。
ハイフローディスクの読み取りと書き込みトラフィック50メガバイト/秒。80メガバイトの変動へのネットワークでは20メガバイト、アウト40。
ディスクは、主にローカルビジネスリージョンサーバーの読み取りとコンパクトな読み書き流れ、他のデータノードの主にローカルリージョンサーバーの書き込みWAL、フラッシュ、コンパクトな、よく書かれたコピーを流し読み。
主な事業のネットワークは、書き込み要求と要求の他のデータノード書かれたコピーである、ビジネスのうちネットワークは、主にクエリとリージョンサーバーの書き込みWAL、フラッシュ、コンパクトな書き込み要求、他のデータノードのコピーに対応しています。
あなたはIO IOべき唯一のネットワーククエリ応答百を読んで、ディスクによって引き起こされるサーバー側のデータフィルタリング、トラフィックの場合を考慮していない場合は、メインのビジネスのお問い合わせは、キャッシュ（95％）、メモリ行くと、hifile非常に高い圧縮比（5 1）を持っています1ポイント。
もちろん、それはフィルタリングサービス側のデータに影響考慮すべきであるが、ディスクのうち、通常のネットワークよりも、あまりにも多くのトラフィックを読んでいません。コンパクトな小さなファイルの読み書き、大容量ファイルの圧縮率は、交通ネットワークディスクよりも大きい増加可能読み出します。ディスクは、命令は、小さなファイルの多くは増幅を書き起こすことがあり、この時間と圧縮していない主要の原因となったトラフィックの多くは、コンパクトな読書する必要があります読んで。
リージョンサーバーの使用状況
regionserver配置
バージョン0.98.21、コンフィギュレーション付録I.
モニタリング指標
P99は、150msのは、キューに入れ、待ち時間あり、45ms内の実行時間P99（ProcessCallTime_99th_percentile）。
95％の読み取りキャッシュヒット率、もOK
いくつかの低速の書き込みがあります。
約20分で、全体的なブラシをmemstoreときmemstore、ブラシはslowputに表示されます
圧縮は、無大手、リフレッシュ周波数とmemstoreは基本的に同じキューに入れられ、大きなフラッシュ原因定期的にそのmemstoreを説明しました。
フラッシュラインはまた、定期的なmemstoreフラッシュで発生します
定期的にルックリージョンサーバーログhlogsは、ブラシの小さなファイルの多くは、とすぐにコンパクト、書き込み増幅効果が明らかである一方で、同時にmemstoreブラシ5メガバイトのhifileの22メガバイトをブラシ領域の多くをトリガー制限されます。
09:34:04,075 INFO [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 69 regions(s) ...
09:34:27,339 INFO [regionserver60020.logRoller] wal.FSHLog: Too many hlogs: logs=53, maxlogs=52; forcing flush of 222 regions(s) ...
...
09:34:27,601 INFO [MemStoreFlusher.1] regionserver.DefaultStoreFlusher: Flushed, sequenceid=311232252, memsize=22.6 M, hasBloomFilter=true, into tmp file ...
09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HStore: Added ...., entries=27282, sequenceid=311232252, filesize=5.4 M
09:34:27,608 INFO [MemStoreFlusher.1] regionserver.HRegion: Finished memstore flush of ~23.6 M/24788698, currentsize=0/0 for region .... in 267ms, sequenceid=311232252, compaction requested=true
ときブラシmemstoreとGCヒープメモリ、サイクル変動が主に起こります。
問題の概要
1.hbase.regionserver.maxlogs少なすぎます、
関係式のハントとmemstoreによると、
hbase.regionserver.hlog.blocksize * hbase.reionserver.logroll.mutiplier*hbase.regionserver.maxlogs
>= hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE
それは、少なくとも95でなければなりません。あまりにも頻繁に起因する[ハント]リミットトリガ数百領域フラッシュの設定、フラッシュは小さなファイル、フラッシュ、コンパクトな圧力も大きいです。
2.メモリのアイドルはあまり、それの上に置き、20％のアイドルを設定します。しかし、G1メモリへの注意を払うには、GC時間が長くなるとつながる可能性が大きすぎます。
3.region 128メガバイトには、いくつかの非常に多くの、地域のmemstoreのほとんどなし必須フラッシュ。通常は、各領域は、それによって、その後の圧縮のオーバーヘッドを削減、できるだけFlushsizeメモリのサイズ、フラッシュサイズの大きいファイルに割り当てることができることを確認してみてください。地域別には、数を減らすために合併することができますが、これはメモリを増やすことで道を容易に、最初の最適化ではありません。
最適なパラメータ
最初のリビジョン
最適化hlogsに見ると、強力なブラシmemstoreを誘発します。
hbase.regionserver.maxlogs 52が95に変更されました。
再起動リージョンサーバー。
HLOGトリガー制限が47分にはブラシをmemstoreなります。
ログ見て、約47分hlogs限度とリフレッシュトリガ257地域。ブラシの前に、強力な、多くのmemstore20MBのように、hfile5MBを圧縮しました。総ピークmemstore最も18.35ギガバイト、領域128MBの事前フラッシュの一部、そうではない22.5ギガバイトに理論的な上限。
圧密キューの頻度を減らします
ピークキュー待機時間間隔が長くなると、改善されています。
GCと通常の値がわずかに減少した回数は、ピークが増加します。
slowputはわずかに減少しました。
いくつかの効果を持つ最適化。
憲法修正第2条
あまりにも多くの地域番号なので、一つの領域が128メガバイトは[ハント]強力なブラシをトリガー未満であってもよいです。これにより、メモリ転送大memstoreとhlogs限界を増加させます。ハント上限は確かに時間あたりのブラシをトリガーする前に、コンピューティングが期待されています。ハンドラスレッド数を上げます。
hbase-env.sh
1.jvm XX:MaxDirectMemorySize 调为110GB
2.堆内Xmx调为80g
HBaseの-site.xmlの
3.hbase.bucketcache.size 112640 110g，hfile.block.cache.size 0.14
4.hbase.regionserver.global.memstore.upperLimit 0.56 44.8g，
hbase.regionserver.global.memstore.lowerLimit 0.5 40g，
5.hbase.regionserver.hlog.blocksize 268435456 256MB，显示配置，默认和hdfs块大小一致，也是配置的这个值。
hbase.regionserver.maxlogs 177
6.hbase.regionserver.handler.count 384
再起動はリージョンサーバー、モニターを観察します。
memstore1時間をドロップ天井が[ハント]トリガされていない、それが定期的にトリガ時間ごとに更新されます。
ルックログ、別のregion128MBフラッシュ後の夜4時31分。午後4時59 memstore 17.5ギガバイトは、地域のほとんどは1時間のリフレッシュをトリガしたときに125をhlogs、数十秒に数秒を遅らせます。リフレッシュ時間がより濃縮され、フラッシュコンパクトなラインがあります。ポイントの六大compactsizeと持続的な、それはHFILE大きなのコンパクトな地域のニーズの多くでなければなりません。
ゆっくりと投入の増加は、ピークのRPCの実行時間が高くなり、P99最長のキューは、実際に2秒までの時間を待っています！
その理由は、GCピークは、影響力のリージョンサーバー事業をより高くなるということです。
ヒープメモリが大きく、GCリサイクル増加を取得し、GC時間が長くなります。
最適化のいくつかの副作用を排除します。
第三の改正
最適化が引き起こされ、GCヒープメモリの問題が増加すると予想しました。memstoreリフレッシュ間隔256メガバイトに変更2時間リフレッシュサイズ
1.XX:InitiatingHeapOccupancyPercent=65 调整为XX:InitiatingHeapOccupancyPercent=75 之前hmaxlogs52限制实际memstore最大12g左右，堆内读写缓存加起来0.45左右。现在读写缓存加起来最多0.7了，所以调大触发gc的上限(bad modify)
2. -XX:ConcGCThreads=8,-XX:ParallelGCThreads=30,-XX:G1MixedGCCountTarget=32 增大gc并发，文档说建议逻辑核的5/8,48核30。并发标记跟着调大。拆解gc次数降低单次时间。
3.hbase.regionserver.optionalcacheflushinterval 改 7200000
4.hbase.hregion.memstore.flush.size 268435456 128MB的压缩会也就22MB hfile没多大，所以单个memstore内存改为256MB。
再起動して観察。
これは、同時転送大間隔と同一平面サイズ、及び1時間40分[ハント]限界トリガー強いブラシとなることを見出しました
ブラシ領域、170、フラッシュコンパクトな行の数が少ない改善されているが、ログを見てください。
RPCとキュー時間のピークP99は依然として高すぎる、遅いの多くを置きます
全体のGC数の削減、ピーク時間が変更に高いGCで
ルックGCログ、同時調整GC、GCシステムは、まだ調整し続ける必要があり、非常に長い時間です。
5つの修正の第
先にGCの下GCトリガしきい値、。GC同時断片的、領域の最大10％。間隔は1時間に戻します。次のように2回交換、最終的には修正します
1.XX:InitiatingHeapOccupancyPercent=65， 又改到60 提前
2. -XX:ConcGCThreads=4,-XX:ParallelGCThreads=16，-XX:G1OldCSetRegionThresholdPercent=10 提高一次gc最多回收的region数。
3. hbase.regionserver.optionalcacheflushinterval 去掉，改回一小时。
再起動して観察。
数サイクルの実行を開始する唯一の短い時間が分散されていないので、memstoreブラシは、リージョン1時間がたくさんあります。
フラッシュコンパクトラインや時間が表示さによって
スロープット以下、RPCおよびp99が待っているキューを低減し、より低いことにしたいです。
gcが多くを変更しましたが、少し何かが、ピーク時間はまだ高価で、非常に長いが若いのGC GCログの時間を見て、混合GCはまだかなり長い時間です。
チューニングを継続する必要があります。
第6変形
チューニングGCパラメータ、若いGC制御メモリサイズに進みます。memstoreブラシ2時間を配置し高めるために継続させることができます。あまりにも多くの地域番号なので、フラッシュ256MBの設定を削除します。
-XX:G1MixedGCCountTarget=16 增大一次全局标记后mixed gc最多执行的次数
-XX:G1HeapWastePercent=10 允许保留10%垃圾
-XX:G1MaxNewSizePercent=20 young 上限20%，避免young区太大gc慢
hbase.regionserver.global.memstore.upperLimit 0.6 调大上限
hbase.regionserver.global.memstore.lowerLimit 0.54
hbase.regionserver.maxlogs 200 调大上限
hbase.regionserver.optionalcacheflushinterval 7200000 2小时一刷
hbase.hregion.memstore.flush.size 去掉用默认128MB
リージョンサーバーのインデックス
2時間ブラシmemstore
フラッシュとコンパクトなラインが少ないです
ゆっくりと入れ、RPCキュー待機時間、および全体的な減少のP99の削減、また、多くのピークを削減
ピークよりバランスGC、短い時間
マシンの負荷
CPU負荷が低いまま
ディスクは1/4までIOを読んで、ネットワークアウトが減少しました。
メモリと20％+無料、また、より多くのポイントを使用することができます。
最適化効果的。
概要
最適化の結果
最適化パラメータと調整リージョンサーバーGC・パラメータ・ファイルは、フラッシュ小型、コンパクト低下し、書き込み増幅を低減します。平均応答時間は、ピーク応答時間の数を減らす、低減されます。ディスクの使用時間を増加させるディスク読み出しおよび書き込みIOの数を減少させます。
後続の最適化の方向
地域の数を減らします
ハイ側の単一領域をリージョンサーバー。
領域は、プレスは、事前パーティションのデータパーティションサイズの計算の合計数を推定したが、HFILE圧縮を考慮していない、事前パーティションです。いくつかの大規模なストレージ領域フォームつの領域は、容量フラクションHFILEの上限であり、数領域を減らす、複合領域であってもよいです。
増加したメモリ構成
ご予約は10％アイドル状態になることができます
GC-深さの調整
GCパラメータのチューニングは、深さがで、明確な目的の最適化に向けて、明確な方法論で、GCのパラメータを詳細に明確な目的、最適化なしの方法論、二重盲検の最適化、作業の重複はありません。ご期待。
サーバーを削減
記憶容量の可能性のあるボトルネック。HDFS論理記憶36.0 T、17リージョンサーバー局はコスト削減を達成するために、50TBの論理記憶容量は、いくつかの反復を低減することができるサポートすることが可能でした。
付録
HBaseの-site.xmlの元の構成
わずかに
hbase-env.sh元の構成
export HBASE_REGIONSERVER_OPTS="-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-Xloggc:${HBASE_LOG_DIR}/gc-`date +'%Y%m%d%H%M'` -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=512M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${HBASE_LOG_DIR}/hbase.heapdump -XX:ErrorFile=${HBASE_LOG_DIR}/hs_err_pid%p.log
-XX:+PrintAdaptiveSizePolicy -XX:+PrintFlagsFinal -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UnlockExperimentalVMOptions
-XX:+ParallelRefProcEnabled -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:G1NewSizePercent=5
-XX:G1MaxNewSizePercent=60 -XX:MaxTenuringThreshold=1 -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=8 -XX:InitiatingHeapOccupancyPercent=65
-XX:MaxDirectMemorySize=100g -XX:G1OldCSetRegionThresholdPercent=5 -Xmx50g -Xms50g"
G1リファレンス
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
