1

パフォーマンスがかなり「悪い」と想定している Hadoop クラスターがあります。ノードはかなり頑丈です.24 コア、60+G RAM など. また、基本的な linux/hadoop のデフォルト設定によって、hadoop がハードウェアを完全に利用できないようになっているのではないかと考えています。

ここに、私が真実であると思われるいくつかの可能性を説明した投稿があります。

lsofroot、hdfs、および自分自身としてnamenodeにログインして、の出力と設定を確認しようとしましたulimit。これが出力です。設定が開いているファイルの数と一致しない理由を誰でも理解できます。

たとえば、ルートとしてログインしたとき。は次のlsofようになります。

[root@box ~]# lsof | awk '{print $3}' | sort | uniq -c | sort -nr
   7256 cloudera-scm
   3910 root
   2173 oracle
   1886 hbase
   1575 hue
   1180 hive
    801 mapred
    470 oozie
    427 yarn
    418 hdfs
    244 oragrid
    241 zookeeper
     94 postfix
     87 httpfs
         ...

しかし、ulimit出力をチェックアウトすると、次のようになります。

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 806018
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

私は、1 人のユーザーが 1024 個を超えるファイルを開くべきではないと想定していますが、の出力を見ると、lsof1 人のユーザーが 7000 個以上のファイルを開いています。ulimitとの関係の理解に誤りがあった場合は、訂正してくださいlsof。

どうもありがとう！

4

2 に答える 2

2

プロセスの制限を確認する必要があります。シェル セッションとは異なる場合があります。

元：

[root@ADWEB_HAPROXY3 ~]# cat /proc/$(pidof haproxy)/limits | grep open
Max open files            65536                65536                files     
[root@ADWEB_HAPROXY3 ~]# ulimit -n
4096

私の場合、haproxy の構成ファイルには、開いているファイルの最大数を変更するためのディレクティブがあり、hadoop にも何かがあるはずです。

于 2014-05-16T22:53:29.177 に答える
1

非常によく似た問題があり、クラスターの YARN TimeLine サーバーの 1 つが魔法の 1024 ファイル制限に達し、「開いているファイルが多すぎます」エラーでクラッシュしたために停止しました。

いくつかの調査の結果、TimeLine の LevelDB であまりにも多くのファイルを処理する際に深刻な問題があることが判明しました。何らかの理由で、YARN は yarn.timeline-service.entity-group-fs-store.retain-seconds 設定を無視しました (デフォルトでは 7 日間、604800 ミリ秒に設定されています)。1 か月以上さかのぼる LevelDB ファイルがありました。

ここで説明されている修正を適用すると、非常に役立ちました: https://community.hortonworks.com/articles/48735/application-timeline-server-manage-the-size-of-the.html

基本的に、私が試したいくつかのオプションがあります。

TTL (存続可能時間) 設定を縮小する最初に TTL を有効に します。

<property>
 <description>Enable age off of timeline store data.</description>
 <name>yarn.timeline-service.ttl-enable</name>
 <value>true</value>
</property>

次に、 yarn.timeline-service.ttl-ms を設定します (一定期間、低い設定に設定します): \

<property>
 <description>Time to live for timeline store data in milliseconds.</description>
 <name>yarn.timeline-service.ttl-ms</name>
 <value>604800000</value>
</property>

2 番目のオプションは、前述のとおり、TimeLine サーバーを停止し、LevelDB 全体を削除して、サーバーを再起動することです。これにより、ATS データベースが最初から開始されます。他のオプションで失敗した場合でも問題なく動作します。

これを行うには、yarn.timeline-service.leveldb-timeline-store.path からデータベースの場所を見つけてバックアップし、そこからすべてのサブフォルダーを削除します。この操作には、TimeLine があるサーバーへのルート アクセスが必要です。

それが役に立てば幸い。

于 2016-10-20T06:58:16.470 に答える