搭建 Docker 环境

安装 Docker Docker 软件包已经包括在默认的 CentOS-Extras 软件源里。因此想要安装 docker,只需要运行下面的 yum 命令: yum install docker-io -y 直接yum安装,安装成功后查看版本 docker -v 启动docker service docker start 设置开机启动 chkconfig docker on 配置 Docker 因为国内访问 Docker Hub 较慢, 可以使用腾讯云提供的国内镜像源, 加速访问 Docker Hub 依次执行以下命令 echo "OPTIONS='--registry-mirror=https://mirror.ccs.tencentyun.com'" >> /etc/sysconfig/docker systemctl daemon-reload service docker restart Docker 的简单操作 任务时间:10min ~ 20min 下载镜像 下载一个官方的 CentOS 镜像到本地 docker pull … Continue reading "搭建 Docker 环境"

优化了du性能的hadoop 2.8.1

性能提升1000+倍。 原理是使用df 代替du, wget https://www.strongd.net/dl/hadoop-common-2.8.1.jar -C /usr/local/hadoop-2.8.1/share/hadoop/common/   wget https://www.strongd.net/dl/mydu -C /usr/bin/ chmod a+x /usr/bin/mydu   然后重启hadoop就可以了。

Jenkins 环境搭建

Jenkins 简介 Jenkins 是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。 Java 安装 首先我们需要准备 Java 环境,使用下面命令来安装 Java: yum -y install java-1.8.0-openjdk-devel Jenkins 安装 为了使用 Jenkins 仓库,我们要执行以下命令: sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key 如果您以前从 Jenkins 导入过 key,那么 rpm --import 将失败,因为您已经有一个 key。请忽略,继续下面步骤。 安装 接着我们可以使用 yum 安装 Jenkins: yum -y install jenkins 启动 Jenkins 任务时间:5min ~ 10min 启动 启动 Jenkins 并设置为开机启动: systemctl start jenkins.service chkconfig jenkins on … Continue reading "Jenkins 环境搭建"

搭建 Hadoop 伪分布式环境

软硬件环境 CentOS 7.2 64位 OpenJDK-1.7 Hadoop-2.7 关于本教程的说明 云实验室云主机自动使用root账户登录系统,因此本教程中所有的操作都是以root用户来执行的。若要在自己的云主机上进行本教程的实验,为了系统安全,建议新建一个账户登录后再进行后续操作。 安装 SSH 客户端 任务时间:1min ~ 5min 安装SSH 安装SSH: sudo yum install openssh-clients openssh-server 安装完成后,可以使用下面命令进行测试: ssh localhost 输入root账户的密码,如果可以正常登录,则说明SSH安装没有问题。测试正常后使用exit命令退出ssh。 安装 JAVA 环境 任务时间:5min ~ 10min 安装 JDK 使用yum来安装1.7版本OpenJDK: sudo yum install java-1.7.0-openjdk java-1.7.0-openjdk-devel 安装完成后,输入java和javac命令,如果能输出对应的命令帮助,则表明jdk已正确安装。 配置 JAVA 环境变量 执行命令: 编辑 ~/.bashrc,在结尾追加: export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk 保存文件后执行下面命令使JAVA_HOME环境变量生效: source ~/.bashrc 为了检测系统中JAVA环境是否已经正确配置并生效,可以分别执行下面命令: java -version $JAVA_HOME/bin/java … Continue reading "搭建 Hadoop 伪分布式环境"

Facebook针对hbase的优化方案分析

使用hbase的目的是为了海量数据的随机读写,但是在实际使用中却发现针对随机读的优化和gc是一个很大的问题,而且hbase的数据是存储在Hdfs,而Hdfs是面向流失数据访问进行设计的,就难免带来效率的下降。下面介绍一下Facebook Message系统在HBase online storage场景下的一个案例(《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011),最近他们在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他们在使用HBase中遇到的一些问题和解决方案。该论文首先讲了Facebook的分析方法包括tracing/analysis/simulation,FM系统的架构和文件与数据构成等,接下来开始分析FM系统在性能方面的一些问题,并提出了解决方案。 FM系统的主要读写I/O负载 Figure 2描述了每一层的I/O构成,解释了在FM系统对外请求中读占主导,但是由于logging/compaction/replication/caching导致写被严重放大。 HBase的设计是分层结构的,依次是DB逻辑层、FS逻辑层、底层系统逻辑层。DB逻辑层提供的对外使用的接口主要操作是put()和get()请求,这两个操作的数据都要写到HDFS上,其中读写比99/1(Figure 2中第一条)。 由于DB逻辑层内部为了保证数据的持久性会做logging,为了读取的高效率会做compaction,而且这两个操作都是写占主导的,所以把这两个操作(overheads)加上之后读写比为79/21(Figure 2中第二条)。 相当于调用put()操作向HBase写入的数据都是写入了两份:一份写入内存Memstore然后flush到HFile/HDFS,另一份通过logging直接写HLog/HDFS。Memstore中积累一定量的数据才会写HFile,这使得压缩比会比较高,而写HLog要求实时append record导致压缩比(HBASE-8155)相对较低,导致写被放大4倍以上。    Compaction操作就是读取小的HFile到内存merge-sorting成大的HFile然后输出,加速HBase读操作。Compaction操作导致写被放大17倍以上,说明每部分数据平均被重复读写了17次,所以对于内容不变的大附件是不适合存储在HBase中的。由于读操作在FM业务中占主要比例,所以加速读操作对业务非常有帮助,所以compaction策略会比较激进。 HBase的数据reliable是靠HDFS层保证的,即HDFS的三备份策略。那么也就是上述对HDFS的写操作都会被转化成三倍的local file I/O和两倍的网络I/O。这样使得在本地磁盘I/O中衡量读写比变成了55/45。 然而由于对本地磁盘的读操作请求的数据会被本地OS的cache缓存,那么真正的读操作是由于cache miss引起的读操作的I/O量,这样使得读写比变成了36/64,写被进一步放大。    另外Figure 3从I/O数据传输中真正业务需求的数据大小来看各个层次、各个操作引起的I/O变化。除了上面说的,还发现了整个系统最终存储在磁盘上有大量的cold data(占2/3),所以需要支持hot/cold数据分开存储。 总的来说,HBase stack的logging/compaction/replication/caching会放大写I/O,导致业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写占据了主导。 FM系统的主要文件类型和大小   FM系统的几种文件类型如Table 2所示,这个是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应一个或者多个HFile文件。FM系统中有8个column family,由于每个column family存储的数据的类型和大小不一样,使得每个column family的读写比是不一样的。而且很少数据是读写都会请求的,所以cache all writes可能作用不大(Figure 4)。 对于每个column family的文件,90%是小于15M的。但是少量的特别大的文件会拉高column family的平均文件大小。例如MessageMeta这个column family的平均文件大小是293M。从这些文件的生命周期来看,大部分FM的数据存储在large,long-lived files,然而大部分文件却是small, … Continue reading "Facebook针对hbase的优化方案分析"

Face Recognition

Recognize and manipulate faces from Python or from the command line with the world’s simplest face recognition library. Built using dlib‘s state-of-the-art face recognition built with deep learning. The model has an accuracy of 99.38% on theLabeled Faces in the Wild benchmark. This also provides a simple face_recognition command line tool that lets you do face recognition on a … Continue reading "Face Recognition"

L2TP/IPSec一键安装脚本

本脚本适用环境: 系统支持:CentOS6+,Debian7+,Ubuntu12+ 内存要求:≥128M 更新日期:2017 年 05 月 28 日 关于本脚本: 名词解释如下 L2TP(Layer 2 Tunneling Protocol) IPSec(Internet Protocol Security) IKEv2 (Internet Key Exchange v2) 能实现 IPsec 的目前总体上有 openswan,libreswan,strongswan 这3种。 libreswan 是基于 openswan 的 fork,所以现在各个发行版基本已经看不到 openswan 的身影了。 当然也有使用 strongswan 的。 之所以要更新 L2TP 一键安装脚本,是因为随着各个 Linux 发行版不断推陈出新,原有的脚本已经不适应现在的需求。 本脚本通过编译安装最新版 libreswan 来实现 IPSec(CentOS7 下则是全部 yum 安装),yum 或 apt-get 来安装 xl2tpd,再根据各个发行版的使用方法不同,部署防火墙规则。 写在前面: … Continue reading "L2TP/IPSec一键安装脚本"

PostgreSQL on Linux 最佳部署手册

背景 数据库的安装一直以来都挺复杂的,特别是Oracle,现在身边都还有安装Oracle数据库赚外快的事情。 PostgreSQL其实安装很简单,但是那仅仅是可用,并不是好用。很多用户使用默认的方法安装好数据库之后,然后测试一通性能,发现性能不行就不用了。 原因不用说,多方面没有优化的结果。 PostgreSQL数据库为了适应更多的场景能使用,默认的参数都设得非常保守,通常需要优化,比如检查点,SHARED BUFFER等。 本文将介绍一下PostgreSQL on Linux的最佳部署方法,其实在我的很多文章中都有相关的内容,但是没有总结成一篇文档。 OS与硬件认证检查 目的是确认服务器与OS通过certification Intel Xeon v3和v4的cpu,能支持的RHEL的最低版本是不一样的, 详情请见:https://access.redhat.com/support/policy/intel Intel Xeon v3和v4的cpu,能支持的Oracle Linux 的最低版本是不一样的, 详情请见:http://linux.oracle.com/pls/apex/f?p=117:1 第一:RedHat生态系统–来自RedHat的认证列表https://access.redhat.com/ecosystem 第二:Oracle Linux 对服务器和存储的硬件认证列表 http://linux.oracle.com/pls/apex/f?p=117:1 安装常用包 # yum -y install coreutils glib2 lrzsz mpstat dstat sysstat e4fsprogs xfsprogs ntp readline-devel zlib-devel openssl-devel pam-devel libxml2-devel libxslt-devel python-devel tcl-devel gcc make smartmontools flex bison perl-devel perl-ExtUtils* … Continue reading "PostgreSQL on Linux 最佳部署手册"

分析java进程假死情况

1 引言   1.1 编写目的   为了方便大家以后发现进程假死的时候能够正常的分析并且第一时间保留现场快照。   1.2编写背景   最近服务器发现tomcat的应用会偶尔出现无法访问的情况。经过一段时间的观察最近又发现有台tomcat的应用出现了无法访问情况。简单描述下该台tomcat当时具体的表现:客户端请求没有响应,查看服务器端tomcat的进程是存活的,查看业务日志的时候发现日志停止没有任何最新的访问日志。连tomcat下面的catalina.log也没有任何访问记录,基本断定该台tomcat已不能提供服务。   2 分析步骤   根据前面我描述的假死现象,我最先想到的是网络是否出现了问题,是不是有什么丢包严重的情况,于是我开始从请求的数据流程开始分析,由于我们业务的架构采用的是nginx+tomcat的集群配置,一个请求上来的流向可以用下图来简单的描述一下:       2.1检查nginx的网络情况   更改nginx的配置,让该台nginx请求只转到本机器的出现问题的tomcat应用上面,在access.log里看是否有网络请求,结果可以查看到当前所有的网络请求,也就是说可以排除是网络的问题。   2.2检查tomcat 的网络情况   分析业务配置的tomcat访问日志xxxx.log上是否有日志访问记录,经过查询该台tomcat应用日志完全没有任何访问记录,由于我们的部署是本机的nginx转到本机的tomcat应用,所以可以排除不是网络问题。到此基本可以断定网络没有问题,tomcat 本身出现了假死的情况。在tomcat的日志里有报过OutOfMemoryError的异常,所以可以肯定tomcat假死的原因是OOM   3 分析JVM内存溢出   3.1为什么会发生内存泄漏   在我们学习Java的时候就知道它最为方便的地方就是我们不需要管理内存的分配和释放,一切由JVM自己来进行处理,当Java对象不再被应用时,等到堆内存不够用时JVM会进行GC处理,清除这些对象占用的堆内存空间,但是如果对象一直被应用,那么JVM是无法对其进行GC处理的,那么我们创建新的对象时,JVM就没有办法从堆中获取足够的内存分配给此对象,这时就会导致OOM。我们出现OOM原因,一般都是因为我们不断的往容器里存放对象,然而容器没有相应的大小限制或清除机制,这样就容易导致OOM。   3.2快速定位问题   当我们的应用服务器占用了过多内存的时候,我们怎么样才能快速的定位问题呢?要想快速定位问题,首先我们必需获取服务器JVM某时刻的内存快照。Jdk里面提供了很多相应的命令比如:jstack,jstat,jmap,jps等等. 在出现问题后我们应该快速保留现场。   3.2.1 jstack   可以观察到jvm中当前所有线程的运行情况和线程当前状态.   sudo jstack -F 进程ID 输出内容如下: 从上面的图我们可以看到tomcat进程里面没有死锁的情况,而且每个线程都处理等待的状态。这个时候我们可以telnet命令连上tomcat的端口查看tomcat进程是否有任务回应。这时发现tomcat没有任何回应可以证明tomcat应用已没有响应处理假死状态。   3.2.2 jstat … Continue reading "分析java进程假死情况"