Hadoop内置一些脚本来运行指令，在集群内启动和终止守护进程。
这些脚本存放在bin目录中，通过masters和slaves文件指定集群内的所有机器。
masters文件有点误导人。
它主要记录拟运行辅助namenode（secondarynamenode）的所有机器。
slaves文件记录了运行datanode和tasktracker的所有机器。
masters和slaves文件存放在配置目录中。
用户也可以改变hadoop-env.sh的HADOOP_SLAVES项的值，将slaves文件放在其他地方（也可以改变文件名称）。
例如：start-dfs.sh脚本用于启动集群中所有的HDFS守护进程，但是该脚本运行时会在同一机器上运行namenode。
1）、在本地机器上启动一个namenode（脚本所运行的机器）
2）、在slaves文件中记录的各机器上启动一个datanode。
3）、在masters文件中记录的各机器上启动一个辅助namenode。
脚本start-mapred和start-dfs.sh类似，它启动集群中的所有MapReduce守护进程。
1）、在本地机器上启动一个jobtracker。
2）、在slaves文件列举的每台机器上启动一个tasktracker。
注意：
MapReduce控制脚本不使用masters文件。
此外，stop-dfs.sh和stop-mapred.sh脚本能终止由相关启动脚本启动的守护进程。
上述3、4脚本调用hadoop-daemon.sh脚本来启动和终止hadoop守护进程。
如果已经使用前述3、4脚本，则不宜直接调用hadoop-daemon.sh。
但是如果用户需要从其他系统(或利用自己编写的脚本)控制hadoop守护进程。则可以调用hadoop-daemon.sh。
类似的，hadoop-daemons.sh（多了一个“s”）用于在多个主机上启动同一个守护进程。
通过masters和slaves文件。
因为只有运行在namenode和jobtracker上的控制脚本能使用这些文件。
MapReduce控制脚本不使用masters文件。
运行namenode和jobtracker的机器由运行脚本的机器决定。它不由masters文件指定。
实际上，在masters文件指定机器，会导致这些机器上运行一个辅助namenode。
由于集群规模差异大，对于主节点守护进程的配置也差异很大。
主节点守护进程：namenode、辅助namenode、jobtracker
在一个运行大量MapReduce作业的高负载集群上，jobtracker会使用大量内存和CPU资源，因此最好运行在一个专用节点上。
1）、在namenode机器上运行HDFS控制脚本。
2）、masters文件包含辅助namenode的地址。
3）、在jobtracker机器上运行MapReduce控制脚本。
当namenode和jobtracker运行在不同节点之上时，集群中的各节点将运行一个datanode和一个tasktracker，以使slaves文件同步。
namenode在内存中保存整个命令空间的所有文件和块元数据，它的内存需求很大。
namenode会在内存中存储所有文件的每个数据块的引用，因此namnode很可能会“吃光”分配给它的所有内存。对于这种情况，我们可以不改变其他hadoop守护进程的内存分配量而只增加namenode的内存分配量。即：设置hadoop-env.sh文件的HADOOP_NAMENODE_OPTS，包含一个JVM选项以设定内存大小。HADOOP_NAMENODE_OPTS允许向namenode的JVM传递额外选项。
辅助namenode保存一份最新的检查点，记录文件系统的元数据。
将这些历史信息备份到其它节点上，有助于在数据丢失（或系统崩溃）情况下恢复namenode的元数据文件。
辅助namenode在大多数时间是空闲，但是它在创建检查时的内存需求与主namenode差不多。
一旦文件系统包含大量文件，单台机器的物理内存便无法同时运行主namenode和辅助namenode。
namenode、辅助namenode、jobtracker
默认情况下，Hadoop生成的系统日志文件存放在$HADOOP_INSTALL/logs目录之中，也可以通过hadoop-env.sh文件中的HADOOP_LOG_DIR来进行修改。
修改默认配置，使之独立于Hadoop的安装目录。这样，即使Hadoop升级之后安装路径发生改变，也不会影响日志文件的位置。
通常可以将日志文件存放在/var/log/hadoop目录中。
实现方法：在hadoop-env.sh中加入以下一行，export HADOOP_LOG_DIR=/var/log/hadoop
因为大部分应用程序的日志消息都写到该日志文件中，所以在对问题进行故障诊断时需要先查看这个文件。
标准的hadoop log4j配置采用日常滚动文件后缀策略(Daily Rolling File Appender)来命名日志文件。
系统不会自动删除过期的日志文件，而是留待用户定期删除或存档，以节约本地磁盘空间。
由于hadoop使用log4j记录日志，所以这个文件通常只包含少量记录，甚至为空。
重启守护进程时，系统会创建一个新文件来记录此类日志。系统仅保留最新的5个日志文件。旧的日志文件会附加一个数字后缀，值在1和5之间，5表示最旧的文件。
日志文件名称中的“用户名称”部分实际对应hadoop-env.sh文件中的HADOOP_IDENT_STRING项。
默认情况下，该功能并未启用。
为了启用该功能，需要在hadoop-env.sh文件中定义HADOOP_MESTER项。
工作节点的守护进程启动之后，会把以HADOOP_MASTER为根的目录树与本地的HADOOP_ISNTALL目录同步（？？？未理解如何运用？！）
对于小型集群来说很容易解决：
编写一个脚本文件，将主节点的hadoop-env.sh文件拷贝到所有工作节点即可。
对于大型集群来说：
可以采用类似dsh的工具，并行拷贝文件。
此外，还可以编写hadoop-env.sh文件，添加以上内容，并将这个文件作为自动安装脚本的一部分
为了避免发生这种情况，需要将HADOOP_SLAVE_SLEEP项设为一小段时间，例如0.1（表示0.1秒钟）。
这样的话，主节点会在相继调用两个工作节点的指令的间隙主动休眠一段时间间隔。
dfs.name.dir：描述一系列目录，来供namenode存储永久性的文件系统元数据
namenode存储永久性的元数据的目录列表。namenode在列表上的各个目录中均存放相同的元数据文件。
文件系统元数据：包括编辑日志（edits）和文件系统映像(image)
这些元数据会同时备份在所有指定的目录中。
dfs.name.dir描述一系列目录，其目的是支持冗余备份。
dfs.data.dir：虽然dfs.data.dir也描述了一系列目录，但是其目的是循环地在各个目录中写数据。
datanode存放数据块的目录列表。各个数据块分别存放于某一个目录中。
因此，为了提高性能，最好分别为各个本地磁盘指定一个存储目录。
这样一来，数据块跨磁盘分布，针对不同数据块的读操作可以并发执行，从而提升性能。
指定一系列目录来保存检查点。
与namenode类似，检查点映像文件会分别存储在各个目录中，以支持辅助namenode的冗余备份。
辅助namenode存放检查点的目录列表。在所列的各个目录中分别存放一份检查点文件的副本。
默认情况下，HDFS的存储目录放在Hadoop的临时目录之中（即hadoop.tmp.dir属性，默认值是/tmp/hadoop-${user.name}）
dfs.name.dir是用于配置元数据文件的。它描述一系列目录，其目的是支持冗余备份。
元数据文件会同时备份在所有由dfs.name.dir指定的一系列目录中。
通常情况下，配置dfs.name.dir将namenode的元数据写到一个（或两个）本地磁盘和一个远程磁盘（例如NFS挂载的目录）之中。
这样的话，即使本地磁盘发生故障，甚至整个namenode发生故障，都可以恢复元数据文件，并且重构新的namenode。
dfs.name.dir和dfs.data.dir都描述了一系列目录，但是他们的目的是不一样的。
dfs.name.dir描述的一系列目录，其目的是支持冗余备份。
dfs.data.dir描述的一系列目录，其目的是循环地在各个目录中写数据。
指定jobtracker的主机名或IP地址，以及它在监听的端口。并非URI格式，而是“主机：端口”格式。通常情况下，端口号被设为8021。
此属性表示，jobtracker的RPC服务器所在的主机名称和端口号。
存储作业中间数据的一个目录列表。作业终止时，数据被清除。
默认值为：${hadoop.tmp.dir}/mapred/local
此属性使用一个逗号分隔的目录名称列表，最好将这些目录分散到所有本地磁盘，以提升磁盘I/O效率。
通常情况下，会使用与datanode相同的磁盘和分区（但是不同的目录）存储MapReduce的临时数据。
datanode的数据块存储目录由dfs.data.dir属性项指定。
MapReduce使用分布式文件系统来和运行MapReduce任务的各个tasktracker共享文件。
在作业运行期间存储共享文件的目录，可以使针对默认文件系统的相对路径。（默认系统由fs.default.name属性设定，一般为HDFS）
mapred.system.dir指定这些文件的存储目录，可以是针对默认文件系统的相对路径。
默认文件系统由fs.default.name属性设定，一般为HDFS。
此属性表示tasktracker机器上有多少核是可用的。
在任一时刻，运行在tasktracker之上的map/reduce任务的最大数。默认值为2。
此属性表示tasktracker子JVM的有效内存大小
JVM选项，用于启动运行map和reduce任务的tasktracker子进程。
该属性可以针对每个作业进行设置。例如，可以设置JVM的属性，以支持调试。
被写到临时本地文件中。
因为执行MapReduce作业的过程中所产生的中间数据和工作文件，包括map任务的输出数据，数据量可能非常大。因此必须保证本地临时存储空间（有mapred.local.dir属性设置）的容量足够大。
该属性记录即将作为datanode加入集群机器列表。
该属性记录即将作为tasktracker加入集群的机器列表。
该属性记录待移除的机器列表。
更多关于移除委任机器的介绍详见笔记中的“解除委任节点”：《第十章-管理Hadoop-笔记》
配置缓冲区大小（core-site.xml）
增大缓冲区容量会显著提高性能。常用大小配置为64KB或128KB。默认大小为4KB。
设置HDFS块大小（hdfs-site.xml）
通过增大集群块大小，降低namenode的内存压力，并向mapper传输更多数据。
默认大小为64MB，许多集群把块大小设为128MB或256MB。
默认情况下，HDFS块大小是64MB。但是，许多集群把块大小设为128MB（134 217 728字节）或256MB（268 435 456字节）以降低namenode的内存压力，并向mapper传输更多数据。
默认情况下，datanode能够使用存储目录上的所有闲置空间，这可能导致没有空间可供其他应用程序使用。
如果计划将部分空间留给其他应用程序（非HDFS），则需要设置dfs.datanode.du.reserved属性项来指定待保留的空间大小（以字节为单位）。
指定待保留的空间大小（以字节为单位）
被删除的文件并未被真正删除，仅只转移到回收站（一个特定文件夹）中。
回收站中的文件在被永久删除之前仍会至少保留一段时间。
该信息由core-site.xml文件中的fs.trash.interval属性项（以分钟为单位）设置。默认情况下，该属性项的值是0，表示回收站特性无效。
回收站特性被启用时，每个用户都有独立的回收站目录，即：home目录下的.Trash目录。
core-site.xml文件中配置，配置回收站文件保留时间（以分钟为单位）。默认情况下，该属性项的值是0，表示回收站特性无效。
对于这些不自动删除回收站中文件的文件系统，用户必须定期执行指令来删除已在回收站中超过最小时间的所有文件：
% hadoop fs -expunge
Trash类的expunge（）方法也具有相同效果。
例如，假设一台运行tasktracker的机器的可用内存耗尽，则会影响其他正在运行的进程。为了防止由于map或reduce任务出现内存泄露，而影响集群中各个节点的正常工作，需要设置mapred.child.ulimit，限制由tasktracker发起的子进程的最大虚拟内存（单位是千字节）。该值要明显高于JVM内存（由mapred.child.java.opts设置），否则子JVM可能无法启动。
限制由tasktracker发起的子进程的最大虚拟内存（单位是千字节）。
在多用户的MapReduce设置中，若考虑将默认的FIFO（先进先出）作业调度方案改变为功能更强的调度方案，可参考《第6章-MapReduce的工作机制-作业的调度》一节。
通过core-site.xml文件中的io.file.buffer.size属性项来配置缓冲区大小。
hdfs-site.xml文件中的dfs.block.size。
与其他操作系统类似，hadoop回收站是用户级特性。
只有由文件系统shell直接删除的文件才会放到回收站中，用程序删除的文件会被直接删除。
当然，也有例外情况——使用Trash类。
构造一个Trash实例，调用moveToTrash()方法会把指定路径的文件移到垃圾箱中。如果操作成功，该方法返回一个值；否则，如果回收站特性未被启动，或该文件已经在回收站中，该方法返回false。
恢复也很简易：在.Trash的子目录中找到文件，并将其移出.Trash目录。
针对dfs.data.dir配置的一系列目录。为了提高性能，最好分别为各个本地磁盘指定一个存储目录。
这样一来，数据块跨磁盘分布，针对不同数据块的读操作可以并发执行，从而提升读性能。
为了充分发挥性能，需要使用noatime选项挂载磁盘。
该选项意味着执行读操作时，所读文件的最新访问时间信息并不刷新，从而显著提升性能。
Hadoop使用使用一个4KB大小的缓冲区辅助I/O操作。
但对于现代硬件和操作系统来说，这个容量太过于保守了。增大缓冲区容量会显著提高性能。
例如，64KB（65535字节）或256MB（131072字节）更为常用。
可以通过core-site.xml文件中的io.file.buffer.size属性项来设置缓冲区大小。
