yarn的简介：
Yarn是facebook发布的一款取代npm的包管理工具。

yarn的特点：

速度超快。

Yarn 缓存了每个下载过的包，所以再次使用时无需重复下载。 同时利用并行下载以最大化资源利用率，因此安装速度更快。


超级安全。

在执行代码之前，Yarn 会通过算法校验每个安装包的完整性。


超级可靠。

使用详细、简洁的锁文件格式和明确的安装算法，Yarn 能够保证在不同系统上无差异的工作。




yarn的安装:

下载node.js，使用npm安装

npm install -g yarn

查看版本：yarn --version
安装node.js,下载yarn的安装程序:

提供一个.msi文件，在运行时将引导您在Windows上安装Yarn
Yarn 淘宝源安装，分别复制粘贴以下代码行到黑窗口运行即可

yarn config set registry https://registry.npm.taobao.org -g

yarn config set sass_binary_site http://cdn.npm.taobao.org/dist/node-sass -g


yarn的常用命令：


安装yarn

npm install -g yarn



安装成功后，查看版本号：

yarn --version



创建文件夹 yarn

md yarn



进入yarn文件夹

cd yarn



初始化项目

yarn init // 同npm init，执行输入信息后，会生成package.json文件



yarn的配置项：

yarn config list // 显示所有配置项
yarn config get <key> //显示某配置项
yarn config delete <key> //删除某配置项
yarn config set <key> <value> [-g|--global] //设置配置项



安装包：

yarn install //安装package.json里所有包，并将包及它的所有依赖项保存进yarn.lock
yarn install --flat //安装一个包的单一版本
yarn install --force //强制重新下载所有包
yarn install --production //只安装dependencies里的包
yarn install --no-lockfile //不读取或生成yarn.lock
yarn install --pure-lockfile //不生成yarn.lock



添加包（会更新package.json和yarn.lock）：

yarn add [package] // 在当前的项目中添加一个依赖包，会自动更新到package.json和yarn.lock文件中
yarn add [package]@[version] // 安装指定版本，这里指的是主要版本，如果需要精确到小版本，使用-E参数
yarn add [package]@[tag] // 安装某个tag（比如beta,next或者latest）

//不指定依赖类型默认安装到dependencies里，你也可以指定依赖类型：

yarn add --dev/-D // 加到 devDependencies
yarn add --peer/-P // 加到 peerDependencies
yarn add --optional/-O // 加到 optionalDependencies

//默认安装包的主要版本里的最新版本，下面两个命令可以指定版本：

yarn add --exact/-E // 安装包的精确版本。例如yarn add foo@1.2.3会接受1.9.1版，但是yarn add foo@1.2.3 --exact只会接受1.2.3版
yarn add --tilde/-T // 安装包的次要版本里的最新版。例如yarn add foo@1.2.3 --tilde会接受1.2.9，但不接受1.3.0



发布包

yarn publish



移除一个包

yarn remove <packageName>：移除一个包，会自动更新package.json和yarn.lock



更新一个依赖

yarn upgrade 用于更新包到基于规范范围的最新版本



运行脚本

yarn run 用来执行在 package.json 中 scripts 属性下定义的脚本



显示某个包的信息

yarn info <packageName> 可以用来查看某个模块的最新版本信息



缓存

yarn cache

yarn cache list # 列出已缓存的每个包 yarn cache dir # 返回 全局缓存位置 yarn cache clean # 清除缓存






npm 与 yarn命令比较:


npm 与 yarn相关问题比较:
npm模块的依赖:

npm存在一些历史遗留问题，请看下图：




比如说你的项目模块依赖是图中描述的，@1.2.1代表这个模块的版本。在你安装A的时候需要安装依赖C和D，很多依赖不会指定版本号，默认会安装最新的版本，这样就会出现问题：比如今天安装模块的时候C和D是某一个版本，而当以后C、D更新的时候，再次安装模块就会安装C和D的最新版本，如果新的版本无法兼容你的项目，你的程序可能就会出BUG，甚至无法运行。这就是npm的弊端，而yarn为了解决这个问题推出了yarn.lock的机制，这是作者项目中的yarn.lock文件。

yarn.lock文件格式:


大家会看到，这个文件已经把依赖模块的版本号全部锁定，当你执行yarn install的时候，yarn会读取这个文件获得依赖的版本号，然后依照这个版本号去安装对应的依赖模块，这样依赖就会被锁定，以后再也不用担心版本号的问题了。其他人或者其他环境下使用的时候，把这个yarn.lock拷贝到相应的环境项目下再安装即可。

注意：这个文件不要手动修改它，当你使用一些操作如yarn add时，yarn会自动更新yarn.lock。

使用yrm工具管理一些npm源
安装

yarn global add yrm

查看可用源

yrm ls

选择源

yrm use yarn

快速删除node_modules
手动删除真的很慢：

安装： npm install rimraf -g
使用：rimraf node_modules

rimraf是node的一个包，可以快速删除node_modules，再也不用等半天了

yarn add :在当前目录安装

yarn install :根据package.json安装包

yarn global add :安装到全局

yarn remove : 卸载

yarn cache clean :清除缓存。

yarn config  set global-folder ‘目标路径’：修改yarn全局安装包下载位置

yarn global bin 查看是否修改成功

yarn config set cache-folder ‘目标路径’：修改yarn全局安装包缓存位置

yarn global dir查看是否修改成功

YARN 是 分布式资源管理系统


架构图



a.png

#组件组成: 
Client, ResourceManager, ApplicationMaster, NodeManager, Container

#各组件描述: 
Client:
负责提交应用程序

ResourceManager:
全局的资源管理器, 整个集群只有一个, 负责集群资源的统一管理和调度分配;
The ResourceManager has two main components: Scheduler and ApplicationsManager.
1、调度器：调度器根据容量、队列等限制条件(如每个队列分配一定的资源，最多执行一定数量的作业等)，将系统中的资源分配给各个正在运行的应用程序中，需要注意的是，该调度器是一个”纯调度器”，它不再从事任何与具有应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用程序失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成，调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念”资源容器”(resource container，简称container)表示，container是一个动态资源分配单位，它将内存、cpu、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量，此外该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供多种直接可用的调度器，比如 fair scheduler和capacity scheduler等 
2、应用程序管理器 
应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它等
功能: 
1. 处理客户端请求
2. 启动/监控 ApplicationMaster
3. 监控NodeManager
4. 资源分配和调度

ApplicationMaster:
在yarn上运行的应用程序实例对象,负责管理此应用程序的执行; 
功能:
1. 数据切分
2. 为应用程序申请资源, 和进一步分配
3. 任务监控和容错处理

NodeManager:
整个集群有多个, 负责本节点的资源管理和使用, NodeManager管理抽象容器container
功能:
1. 单个节点上的资源管理和任务管理
2. 处理来自 ResourceManager 的命令
3. 处理来自 ApplicationMaster 的命令 

Container:
yarn中对资源的抽象, 封装本节点上的内存,cpu,磁盘,网络等资源, 此资源就是用container表示;


yarn工作流程



b.png

#yarn工作流程

1. client端向ResourceManager提交应用程序, 也就是client端会将 jar包,参数等数据上传到hdfs上的某路径下;

2. resourceManager将此应用程序添加到任务队列中;

3. 等待资源充沛时, resourceManager为该应用程序分配第一个container，在这个container中启动应用程序的ApplicationMaster; 

4. ApplicationMaster首先向ResourceManager注册，用户可以直接通过ResourceManager查看应用程序的运行状态, 还会进行分片等工作, 之后向ResourceManager申请运行任务所需的资源;

5. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源, 发送命令让NodeManager创建container, 之后执行task;

6. ApplicationMaster监控job执行作业, 必要时候进行容错处理, 直到ApplicationMaster检测到job完成后, 向ResourceManager通知, 注销自己




 

Yarn ResourceManager GC overhead limit exceeded
问题
FATAL yarn.YarnUncaughtExceptionHandler (YarnUncaughtExceptionHandler.java:uncaughtException(51)) - Thread Thread[Timer for 'ResourceManager' metrics system,5,main] threw an Error.  Shutting down now...
java.lang.OutOfMemoryError: GC overhead limit exceeded
        at java.util.ArrayList.iterator(ArrayList.java:840)
        at org.apache.hadoop.metrics2.source.JvmMetrics.getGcUsage(JvmMetrics.java:134)
        at org.apache.hadoop.metrics2.source.JvmMetrics.getMetrics(JvmMetrics.java:103)
        at org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:199)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.snapshotMetrics(MetricsSystemImpl.java:420)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.sampleMetrics(MetricsSystemImpl.java:407)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.onTimerEvent(MetricsSystemImpl.java:382)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl$4.run(MetricsSystemImpl.java:369)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)


解决办法
最简单有效的修改ResourceManager Java heap size 增加即可
分析（网上一大堆但是解决方法都不行，这里copy一个分析不较好的）
1.最先想到的是由于内存泄漏导致，因此到集群上取Dump文件，最开始使用的是命令（jmap
-dump:live,format=b,file=dump.hprof 22439）获取dump文件的，但是导致的一个结果就是把ResourceManager搞挂了，后来才知道是因为探索环境的yarn使用的是G1垃圾回收机制，对于G1垃圾回收机制，使用上面的方式可能会将进程搞挂掉，改成下面的命方式即可成功的获取dump文件：jmap-J-d64 -dump:live,format=b,file=yarn-22439.dump 22439  。
2.通过对dump文件的内存泄漏检测分析，发现
在类AsyncDispatcher中的一个属性（BlockingQueue eventQueue）的对象占用了大量的内存，因此怀疑是该对象发生了内存泄漏。

通过类AsyncDispatcher的源码，发现其内部类GenericEventHandler会在处理消息的时候将上面怀疑是内存泄漏的对象eventQueue的size打印出来，因此决定查看线上yarn的日志，看此队列的长度

下图是列出的队列的长度，可明显可以看出该队列的尺寸达到了上千万，这肯定是有问题的。而正常的大集群的日志中队列的长度只有几千，很明显该对象是有问题的。
4.再通过内存分析工具发现，上述有异常的队列中存放的都是ContainerFinishedEvent和ContainerCreatedEvent对象，因此去查看该对象是在哪被创建和消费的。


通过对源码进行分析定位到ContainerFinishedEvent事件是在类SystemMetricsPublisher中被消费掉的，该类是将ContainerFinishedEvent封装成TimelineEntity实体之后通过Http的post方式发送给yarn的TimelineServer进程。


综上分析，目前的主要原因是由于消费者（也就是往TimelineServer发送Event事件数据）发送数据的能力不够，导致消息队列中缓存的大量的消息，随着时间的推移，消息数据不断增多，从而导致yarn内存不够用，从而需要重启。


原文地址