Ambari服务器性能调整和故障排除检查

2019年7月15日 0 条评论 1.05k 次阅读 0 人点赞

Ambari是HDP集群的核心。它为我们提供了配置,管理,监控和保护Hadoop/HDP集群的功能。它是一个Java程序,它与数据库交互以读取集群详细信息并在嵌入式jetty服务器上运行。很多时候我们发现ambari服务器性能问题。

它的Ambari UI操作有时响应缓慢,或者如果未正确调整启动可能需要更长的时间。因此,为了解决ambari服务器性能相关问题,我们应该查看一些数据/统计信息和调整参数,以使ambari服务器性能更好。在本文中,我们将讨论一些非常基本的调优参数和与性能相关的故障排除。

需要什么信息?

当我们注意到ambari服务器响应缓慢时,我们应首先查看以下详细信息:

  • 添加到ambari群集的主机数。因此,我们可以相应地调整ambari代理线程池。
  • 一次访问ambari服务器的并发用户(或视图用户)的数量。因此我们可以调整ambari线程池。
  • ambari集群的版本。如果ambari服务器太旧,则可能是某些操作日志和警报历史记录将消耗大量数据库,这可能导致am​​bari数据库查询响应缓慢。
  • Ambari数据库运行状况及其与ambari服务器的地理位置,以隔离是否存在任何网络延迟。
  • Ambari服务器内存相关的调整参数,以查看是否正确设置了ambari堆。
  • 对于ambari UI缓慢,我们应该检查网络代理问题,看看是否在客户端ambari服务器机器或网络缓慢之间添加了任何网络代理。
  • 如果ambari用户与AD或外部LDAP同步,并且服务器和AD/LDAP之间的通信良好。
  • 此外,ambari主机上的资源可用性(如可用空闲内存)以及在ambari服务器上运行的任何其他服务/组件正在消耗更多内存/CPU/IO。

如何排除故障?

通常我们首先检查ambari服务器内存设置,主机级资源可用性(如:内存/CPU/IO)和线程,以查看线程卡住的位置或花费很长时间执行某些api/数据库调用。

  • 我们将检查ambari-server日志以查看是否有任何重复的警告或错误消息。
  • 首先,我们应检查ambari-server主机是否有足够的可用内存和可用的CPU,还有打开文件列表(查看是否有泄漏),netstat输出以查明是否有任何CLOSE_WAIT或TIME_WAIT套接字。我们可以通过在ambari服务器主机上运行以下命令来检查。
    # free -m 
    # top
    # lsof -p $AMBARI_PID
    # netstat -tnlpa | grep  $AMBARI_PID
    
  • 如果我们看到有足够的可用内存和CPU可用,那么我们可以检查线程是否显示卡住/阻塞的线程或线程的活动是否正常?

    为此,我们可以收集ambari-server线程。我们可以参考以下文章来了解如何收集ambari服务器线程。我们可以使用\$JAVA_HOME/bin/jcmd\$ JAVA_HOME/bin/jstack类型的jvm实用程序来实现。

    https://community.hortonworks.com/articles/72319/how-to-collect-threaddump-using-jcmd-and-analyse-i.html

    建议在每个线程运行的10秒内收集至少5-6个线程。这为我们提供了一段时间内线程活动的详细信息。当我们看到来自ambari服务器的响应缓慢时,应收集线程,否则线程转储将显示正常行为。

  • 有时我们可能会在ambari-server日志中遇到OutOfMemoryError,如下所示,表示ambari服务器堆大小未正确调整或需要增加一点:

        Exception in thread "qtp-ambari-agent-91" java.lang.OutOfMemoryError: Java heap space
    

    根据可用于堆调整文档的一部分的群集大小,有一些建议可用于ambari服务器堆调整:

    https://docs.hortonworks.com/HDPDocuments/Ambari-2.6.0.0/bk_ambari-administration/content/ch_tuning_ambari_performance.html

    我们还应该检查ambari服务器的当前内存利用率统计信息。我们可以使用JVM实用程序“jmap”。

    /usr/jdk64/jdk1.8.0_112/bin/jmap -heap $AMBARI_SERVER_PID
    

    输出:

    # /usr/jdk64/jdk1.8.0_112/bin/jmap -heap `cat /var/run/ambari-server/ambari-server.pid`
    Attaching to process ID 673, please wait...
    Debugger attached successfully.
    Server compiler detected.
    JVM version is 25.112-b15
    using parallel threads in the new generation.
    using thread-local object allocation.
    Concurrent Mark-Sweep GC
    Heap Configuration:
       MinHeapFreeRatio         = 40
       MaxHeapFreeRatio         = 70
       MaxHeapSize              = 2147483648 (2048.0MB)
       NewSize                  = 134217728 (128.0MB)
       MaxNewSize               = 536870912 (512.0MB)
       OldSize                  = 402653184 (384.0MB)
       NewRatio                 = 3
       SurvivorRatio            = 8
       MetaspaceSize            = 21807104 (20.796875MB)
       CompressedClassSpaceSize = 1073741824 (1024.0MB)
       MaxMetaspaceSize         = 17592186044415 MB
       G1HeapRegionSize         = 0 (0.0MB)
    Heap Usage:
    New Generation (Eden + 1 Survivor Space):
       capacity = 120848384 (115.25MB)
       used     = 78420056 (74.78719329833984MB)
       free     = 42428328 (40.462806701660156MB)
       64.89127401157471% used
    Eden Space:
       capacity = 107479040 (102.5MB)
       used     = 72431960 (69.07649993896484MB)
       free     = 35047080 (33.423500061035156MB)
       67.39170725752668% used
    From Space:
       capacity = 13369344 (12.75MB)
       used     = 5988096 (5.710693359375MB)
       free     = 7381248 (7.039306640625MB)
       44.7897518382353% used
    To Space:
       capacity = 13369344 (12.75MB)
       used     = 0 (0.0MB)
       free     = 13369344 (12.75MB)
       0.0% used
    concurrent mark-sweep generation:
       capacity = 402653184 (384.0MB)
       used     = 87617376 (83.55844116210938MB)
       free     = 315035808 (300.4415588378906MB)
       21.760010719299316% used
    37359 interned Strings occupying 3641736 bytes.
    

    如果使用的堆使用率很高并达到最大堆,那么我们可以尝试通过编辑/var/lib/ambari-server/ambari-env.sh文件并增加堆内存来增加amabri-server 内存(-Xmx4g)在属性“ AMBARI_JVM_ARGS ”如下:

    # grep 'AMBARI_JVM_ARGS' /var/lib/ambari-server/ambari-env.sh
    export AMBARI_JVM_ARGS=$AMBARI_JVM_ARGS' -Xms4g -Xmx4g -XX:MaxPermSize=128m -Djava.security.auth.login.config=$ROOT/etc/ambari-server/conf/krb5JAASLogin.conf -Djava.security.krb5.conf=/etc/krb5.conf -Djavax.security.auth.useSubjectCredsOnly=false'
    
  • 如果我们想要监视一段时间内的堆和垃圾收集详细信息,那么我们还可以通过在ambari-env.sh文件中添加GC日志选项来启用ambari服务器的垃圾收集日志记录,如下所示:
    # grep 'AMBARI_JVM_ARGS' /var/lib/ambari-server/ambari-env.sh
    export AMBARI_JVM_ARGS=$AMBARI_JVM_ARGS' -Xms512m -Xmx2048m -XX:MaxPermSize=128m -Djava.security.auth.login.config=$ROOT/etc/ambari-server/conf/krb5JAASLogin.conf -Djava.security.krb5.conf=/etc/krb5.conf -Djavax.security.auth.useSubjectCredsOnly=false  -Xloggc:/var/log/ambari-server/ambari-server_gc.log-`date +'%Y%m%d%H%M'` -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps'
    

使用Grafana进行Ambari JVM监控

从Ambari 2.5开始,我们还可以检查与ambari jvm和数据库相关的ambari性能统计数据。有关这方面的更多信息,请访问:https://docs.hortonworks.com/HDPDocuments/Ambari-2.5.1.0/bk_ambari-operations/content/grafana_ambari_component_dashboards.html

http://$GRAFANA_HOST:3000/dashboard/db/ambari-server-jvm
http://$GRAFANA_HOST:3000/dashboard/db/ambari-server-database

如果未启用ambari服务器指标,则我们可以启用它。要启用Ambari Server指标,请确保在Ambari Server启动/重新启动期间存在以下配置文件 - /etc/ambari-server/conf/metrics.properties

目前,只实现了2个度量标准源 - JVM度量标准源和数据库度量标准源。
要添加/删除要跟踪的度量标准源,需要在metrics.properties文件中修改以下配置。

metric.sources=jvm,database

例如:

# grep 'metric.sources' /etc/ambari-server/conf/metrics.properties
metric.sources=jvm,database

注意:请不要忘记在ambari.properties文件中添加以下行。

# grep 'profiler' /etc/ambari-server/conf/ambari.properties
server.persistence.properties.eclipselink.profiler=org.apache.ambari.server.metrics.system.impl.AmbariPerformanceMonitor

Ambari线程池调整

如果簇大小很大,那么我们还应调整/etc/ambari-server/conf/ambari.properties文件中的agent.threadpool.size.max属性。

agent.threadpool.size.max:property设置用于处理来自ambari代理的心跳的最大线程数。此属性的默认值为“25”。这基本上表示用于处理传入的Ambari代理请求的Jetty连接池的大小。

# grep 'agent.threadpool.size.max' /etc/ambari-server/conf/ambari.properties
50

如果在我们的ambari服务器中,我们有一些视图(如Hive / File View ..等),许多并发用户可以访问这些视图或者如果有许多用户同时访问ambari UI或进行Ambari Rest API调用。然后在这种情况下,我们还应该在/etc/ambari-server/conf/ambari.properties中增加client.threadpool.size.max属性值(默认值为25).

client.threadpool.size.max:用于处理传入REST API请求的Jetty连接池的大小。这应该足够大,以处理来自Web浏览器和嵌入式视图的请求。

# grep 'client.threadpool.size.max' /etc/ambari-server/conf/ambari.properties
100

如果没有正确设置客户端线程池大小,那么在访问ambari UI或进行Ambari API调用时,我们可能会看到以下类型的响应:

{
  status: 503,
  message: "There are no available threads to handle view requests"
}

Ambari连接池调整

我们还可以添加以下属性来调整大型集群(如100个以上节点)或根据需要的JDBC连接池设置:

server.jdbc.connection-pool.acquisition-size=5
server.jdbc.connection-pool.max-age=0
server.jdbc.connection-pool.max-idle-time=14400
server.jdbc.connection-pool.max-idle-time-excess=0
server.jdbc.connection-pool.idle-test-interval=7200

如果使用MySQL作为Ambari数据库,在MSQL配置中,将wait_timeout和interacitve_timeout增加到8小时(28800)和最大值。连接从32到128。

server.jdbc.connection-pool.max-idle-timeserver.jdbc.connection-pool.idle-test-interval的Ambari配置必须低于MySQL的wait_timeout并且在MySQL端设置interactive_timeout。如果您选择减少这些超时值,请在Ambari配置中相应地调整server.jdbc.connection-pool.max-idle-timeserver.jdbc.connection-pool.idle-test-interval,以便它们小于wait_timeout和interactive_timeout。

Ambari缓存调整

如果群集大小超过200个节点,则调整缓存有时会有所帮助。为此,我们使用以下关系计算新的缓存大小,其中是群集中的节点数。

计算逻辑:

ecCacheSizeValue=60*<cluster_size>

在Ambari Server主机上,在/etc/ambari-server/conf/ambari-properties中添加以下属性和值。如果群集有500个节点,那么我们可以将其设置为:

server.ecCacheSize=30000

Ambari警报相关调整

设置alerts.cache.enabled,如果此属性的值设置为“true”,则“AlertReceivedListener”处理的警报不会在每个事件上将警报数据写入数据库。相反,时间戳和文本等数据将保存在缓存中并定期刷新到数据库。默认值为“false”。警报缓存是围绕ambari 2.2.2版本进行实现的。

我们可以启用警报缓存,然后监视它几天以查看它的效果。我们需要将此参数添加到/etc/ambari-server/conf/ambari.properties。与警报缓存和警报执行调度程序相关的一些其他属性如下所示。

alerts.cache.enabled=true
alerts.cache.size=100000
alerts.execution.scheduler.threadpool.size.core=4
alerts.execution.scheduler.threadpool.size.max=8

alerts.cache.size定义警报缓存是默认设置为50000。
alerts.execution.scheduler.threadpool.size.core定义用于处理传入警报事件的核心线程数。随着群集大小的增加,该值应该增加。
alerts.execution.scheduler.threadpool.size.max定义将处理已发布警报事件的最大线程数。默认值为“2”。

Ambari API响应时间检查

在ambari缓慢期间,我们可以尝试运行以下curl调用(尝试获取集群详细信息)以查看获取集群详细信息所需的时间。它让我们知道群集json响应花费的时间。

# time curl -i -u admin:admin -H 'X-Requested-By: ambari' -X GET http://amb25101.example.com:8080/api/v1/clusters/plain_cluster
real    0m20.234s
user    0m0.009s
sys     0m0.017s
# time curl -i -u admin:admin -H 'X-Requested-By: ambari' -X GET  http://amb25101.example.com:8080/api/v1/clusters/plain_cluster?fields=Clusters/desired_configs
# time curl -i -u admin:admin -H 'X-Requested-By: ambari' -X GET  http://amb25101.example.com:8080/api/v1/clusters/plain_cluster?fields=Clusters/health_report,Clusters/total_hosts,alerts_summary_hosts

user表示用户空间,因此在JVM代码中执行工作所花费的CPU秒数。用户是进程内用户模式代码(内核外)花费的CPU时间。这只是执行过程时使用的实际CPU时间。流程花费的其他流程和时间不计入此数字。
sys表示内核空间,因此在内核中工作的cpu-seconds数量。Sys是进程内核中花费的CPU时间。这意味着执行内核中系统调用所花费的CPU时间,而不是仍在用户空间中运行的库代码。与'user'一样,这只是进程使用的CPU时间。
realwall lock”时间。这是所有经过的时间,包括其他进程使用的时间片和进程花费的时间(例如,等待I/O完成)。

示例:例如[“user = 3.00 sys = 0.05 real = 1.00”]

>>> 50ms of kernel work, 
>>> 3s of jvm work and 
>>> overall it took 1 second

Ambari数据库查询记录

在某些情况下,启用数据库查询日志记录以了解查询的执行方式以及执行查询的次数非常有用。

我们可以在etc/ambari-server/conf/ambari.properties文件中启用server.jdbc.properties.loglevel = 2属性并重新启动ambari服务器,服务器将开始将JDBC查询写入/var/log/ambari-server/ambari-server.out文件。

# grep 'server.jdbc.properties.loglevel' /etc/ambari-server/conf/ambari.properties
server.jdbc.properties.loglevel=2

输出日志:

# grep 'SELECT alert_' ambari-server.out 
16:17:19.432 (3)  FE=> Parse(stmt=null,query="SELECT alert_id, alert_definition_id, alert_instance, alert_label, alert_state, alert_text, alert_timestamp, cluster_id, component_name, host_name, service_name FROM alert_history WHERE (alert_id = $1)",oids={20})
16:17:19.439 (6)  FE=> Parse(stmt=null,query="SELECT alert_id, alert_definition_id, alert_instance, alert_label, alert_state, alert_text, alert_timestamp, cluster_id, component_name, host_name, service_name FROM alert_history WHERE (alert_id = $1)",oids={20})
16:26:38.424 (3)  FE=> Parse(stmt=null,query="SELECT t1.alert_id AS a1, t1.definition_id AS a2, t1.firmness AS a3, t1.history_id AS a4, t1.latest_text AS a5, t1.latest_timestamp AS a6, t1.maintenance_state AS a7, t1.occurrences AS a8, t1.original_timestamp AS a9 FROM alert_history t0, alert_definition t2, alert_current t1 WHERE ((((t0.cluster_id = $1) AND (t2.definition_name = $2)) AND (t0.host_name = $3)) AND ((t0.alert_id = t1.history_id) AND (t2.definition_id = t0.alert_definition_id))) LIMIT $4 OFFSET $5",oids={20,1043,1043,23,23})

Ambari数据库查询/性能监视器

在某些情况下,启用QueryMonitorPerformanceMonitor统计信息也很有用。QueryMonitor用于测量查询执行和缓存。这对于复杂系统中的性能分析非常有用。批量写入,默认值:100。

QueryMonitor不同的是,我们还使用本地的EclipseLink PerformanceMonitor来计算实际有多少查询到达DB。性能监视器和查询监视器可以通过/etc/ambari-server/conf/ambari.properties启用。使用以下属性:

server.persistence.properties.eclipselink.profiler=PerformanceMonitor
server.persistence.properties.eclipselink.jdbc.batch-writing.size=25
server.persistence.properties.eclipselink.profiler=QueryMonitor

为了更多地了解如何正确使用它们,我们可以参考以下文章:

https://community.hortonworks.com/articles/73269/how-to-analyze-the-ambari-servers-db-activity-perf.html

Ambari数据库清理/清除

在一些旧的集群中,我们看到数据库中存在大量旧的“alert_history”或旧警报通知数据条目,导致速度变慢。随着时间的推移,这些条目在数据库上的增长很多。因此,数据库转储大小也会增加,并且数据库查询可以响应缓慢的结果。我们可以使用以下命令执行一些数据库清理。

# ambari-server db-cleanup -d 2016-09-30 --cluster-name=MyCluster

有关详细信息,请参阅:

https://community.hortonworks.com/articles/134958/ambari-database-cleanup-speed-up.html

https://issues.apache.org/jira/browse/AMBARI-20687

db-cleanup在ambari 2.5.0/2.5.1上工作良好(ambari 2.4报告了一些问题)。

从Ambari 2.5.2开始,此操作的名称将更改为db-purge-history,除了Alert相关表之外,还应该考虑其他表名为host_role_command和execution_commands以及其他表。

# ambari-server db-purge-history --cluster-name Prod --from-date 2017-08-01

https://docs.hortonworks.com/HDPDocuments/Ambari-2.5.2.0/bk_ambari-administration/content/purging-ambari-server-history.html

db-purge-history命令将分析Ambari Server数据库中的以下表,并删除那些可以删除的行,这些运行命令可以指定--from-date创建日期之后的数据。

AlertCurrent
AlertNotice
ExecutionCommand
HostRoleCommand
Request
RequestOperationLevel
RequestResourceFilter
RoleSuccessCriteria
Stage
TopologyHostRequest
qianmoQ

qianmoQ

这个人太懒什么东西都没留下

文章评论(0)