ケーススタディ-20180913-カフカ&プロセス・ソリューションをハングアップ

問題の説明

2018年頃XX XX月夜04時20分のxxx xxxは、オンラインで見ることが起こった場合を尋ねるその後、カフカのクラスターを発生する問題のトラブルシューティングを行う、とされている、機械カフカプロセスがハングアップしているプラットフォームを表示したとき、彼はヒバリにありましたエラーログ情報は、その後、私は一緒に問題のトラブルシューティング参加しました。
事故期間:xxのxxは2018年5月午前16時30 - 17時25時2018年9月13日の
ビジネスへの影響:理論的には効果なし、自動フォールトトレラントビジネス、識字失敗時の再試行の生産と消費は別のノードにルーティングカフカ上。
処理に関わる人々 :XXX、XXX

プロセス

2018 XX XX月42月16:00分には、エラー・ログの解析、表示ヒバリログをxxxは
2018 16:00 XX月XX日48ポイントがカフカマシン10.136.40.2システムパラメータを表示するにはログインしますxxx
55ポイントを仕上げ2018 16:00 XX月XX日をXXXシステム最適化パラメータリスト
2018 XX XX月17:12システムのパラメータを変更XXX
2018年XX XX XXX日夜05時25カフカサービス、ログを観察を再起動し、通常のスタートのオープンソースプラットフォームClouderaの

ポジショニングプロセス

エラーログヒバリをチェック1.

 

 

 

 

 

看到もっとによって引き起こさ:java.lang.OutOfMemoryErrorを:地図(ネイティブメソッド)sun.nio.ch.FileChannelImpl.map0で失敗した错误

マシン上のログイン(SSH 10.136.40.2)表示:

 

 

上記の数値は、JVMのヒープのOutOfMemoryErrorエラーでない場合は、新しく作成されたインデックスファイルは、mmapのメモリマッピングエラーを行うされ、分析を判定することにより、おそらく不十分な数のmax_map_countによるものです。
問題のGoogle検索の原因ます。https://stackoverflow.com/questions/43042144/kafka-server-failed-to-start-java-io-ioexception-map-failed

 

 

基本的な構成はmax_map_countの原因を判断するには低すぎる
のシステムパラメータを表示
[@ C3-労働者カフカd13-136-40-2が住んでいた] $ sudoのはsysctl -a | grepの「max_map_count」
vm.max_map_count = 65530

カフカによるシステムの構成パラメータは、弾性検索の起動パラメータの前に必須のシステム構成を考える、またはエラーを開始します

 

 

パラメータのES vm.max_map_count

 

 

ESは練習が学習の価値がある起動するオプティマイザを強制します 

 

 

なぜ、この障害があります

  • 1.完全な警報監視システムの欠如は、タイムリーに警告することはできません
  • 2.私たちは理解していない、カフカのクラスタラインの操作にはありません
  • パラメータ最適化を行うことなく3.centosシステム

なぜ監視警報システムの欠如

  • そのため建設中の当社カフカのエコシステム

なぜカフカクラスタラインは理解、把握せずに実行しています

  • カフカはあまり理解されていない前にあるので、制御できないとカフカの全体的な意識

なぜ、パラメータの最適化を行うことなくシステムを行います

  • 運用・保守システムがインストールされているので、我々だけで過ごしたので、オペレーティング環境への影響がカフカのない深い理解を必要としませんが気付くことはありません

max_map_count効果分析

用語解説:仮想メモリのプロセスの最大数は、領域にマッピングされました。
公式の説明:https://www.oschina.net/translate/understanding-virtual-memory?print
max_map_countファイルには、制限プロセスの数はVMA(仮想メモリ領域)を持つことができますが含まれています。仮想メモリ領域は、連続した仮想アドレス空間の領域です。プログラムの試みは、共有メモリ・セグメントにリンクされているメモリ内のファイルを、マップ、または時間のヒープ領域を割り当てるたびプロセスのライフサイクルでは、これらの領域が作成されます。チューニング・プロセスを制限します。この値は、VMAの番号を持つことができます。プロセスは、プロセスがVMA上のラインに到達したが、唯一のオペレーティングシステムがメモリ不足エラーがスローされます、他のカーネルプロセスに少量のメモリを解放することができるときので、アプリケーションの総数は、エラーにつながる可能性がVMAの制限があります。メモリの量が少ないと通常領域で、お使いのオペレーティングシステムの場合、この値は、使用するカーネルメモリの解放を減らすことができます。
Baiduの品質分析参考:http://www.10tiao.com/html/473/201606/2651473114/1.html

 

 

研究プログラムのmalloc、のmmapコールや共有ライブラリとMPROTECTの直接ロードを根底に、JavaクラスFileChannel.map方法は、メモリ・マップ領域を作り出します。

事前に割り当てられたので、Scalaの言語の開発を使用してカフカサービスは、JVMは、JVMヒープのプラットフォーム上で動作するので、非常に小さな仮想仮想メモリ領域を占有し、メモリです。カフカのプログラムで最大の占有率は、マッピングのmmapを達成するための高速読み取りと書き込み速度するために、ファイルマッピング(mmap関数呼び出しを)やっているカフカは、データファイルとインデックスファイルに格納され、読み取りおよび書き込みデータ・ファイルを直接にmmapマッピングせずに、インデックスファイルメカニズム、各> map_count番号は現在map_countまでインクリメントされ、システムmax_map_countを仮想メモリマッピングを行うには、インデックスファイルを作成し、出口へ、そしてJavaプロセスをOutOfMemoryErrorがスローされます。以下は、行うには、インデックスファイルマッピングコードです

 

フォロー

カフカクラスタが直面するリスク
ピークまたはデータがスキューため、システムパラメータ最適化せずに他のノードが、カフカノードが要求することができる場合は、クラスタ内のすべてのノードがカフカを調整し、予防措置を講じなければならないので、リスクブロックオフでもあります。ここで仕事をTODO。

カーディングシステムパラメータリスト最適化パラメータがリストされているのXXX XXすべてのシステムをDONE(日)
作業指示書を提出実行するスクリプトの行には、運用・保守はXXX XX XX(日)を実施する責任DONEです 

 

ブログのアドレス参照:https://www.cnblogs.com/lizherui/p/12650254.html

おすすめ

転載: www.cnblogs.com/lizherui/p/12650254.html