实在抱歉,我们太懒了,该站点停止文章更新了~
AFK 文章停止更新~
2,577 浏览
2,577 浏览
实在抱歉,我们太懒了,该站点停止文章更新了~
1,646 浏览
小米DBaaS的设计与应用,PPT请见链接
1,474 浏览
alternative 命令用于管理系统上多个提供相同功能的软件包。如 jre mta editor 等。
该命令需要root 权限运行
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
]# alternatives alternatives version 1.3.49.3 - Copyright (C) 2001 Red Hat, Inc. This may be freely redistributed under the terms of the GNU Public License. usage: alternatives --install <link> <name> <path> <priority> [--initscript <service>] [--slave <link> <name> <path>]* alternatives --remove <name> <path> alternatives --auto <name> alternatives --config <name> alternatives --display <name> alternatives --set <name> <path> common options: --verbose --test --help --usage --version --altdir <directory> --admindir <directory> |
看起来 –install 分支较为复杂一些,其他分支看名字就能猜出意思来。
1 2 3 4 5 |
]# ll /var/lib/alternatives/ total 12 -rw-r--r-- 1 root root 113 Aug 13 11:42 links -rw-r--r-- 1 root root 689 Aug 13 11:26 mta -rw-r--r-- 1 root root 861 Aug 13 11:27 print |
1 2 3 4 5 6 |
]# alternatives --display links links - status is auto. link currently points to /usr/bin/elinks /usr/bin/elinks - priority 90 slave links-man: /usr/share/man/man1/elinks.1.gz Current `best' version is /usr/bin/elinks. |
1 2 |
]# readlink -f `which links` /usr/bin/elinks |
1 2 3 4 5 6 7 8 9 10 11 |
]# alternatives --verbose --install /usr/local/bin/editor editor /usr/bin/vim 10 reading /var/lib/alternatives/editor ]# readlink -f /usr/local/bin/editor /usr/bin/vim ]# alternatives --display editor editor - status is auto. link currently points to /usr/bin/vim /usr/bin/vim - priority 10 Current `best' version is /usr/bin/vim. |
1 2 |
]# man editor No manual entry for editor |
1 2 3 4 5 6 7 8 9 |
# alternatives --verbose --install /usr/local/bin/editor editor /usr/bin/vim 10 --slave /usr/local/share/man/man1/editor.1.gz editor-man /usr/share/man/man1/vim.1.gz reading /var/lib/alternatives/editor ]# alternatives --display editor editor - status is auto. link currently points to /usr/bin/vim /usr/bin/vim - priority 10 slave editor-man: /usr/share/man/man1/vim.1.gz Current `best' version is /usr/bin/vim. |
1 |
chmod +x jdk-6u31-linux-x64-rpm.bin && ./jdk-6u31-linux-x64-rpm.bin -x |
1 2 |
yum makecache yum list all jdk* --showduplicates |
见图
1 2 3 4 5 |
]# ll /usr/bin/java* lrwxrwxrwx 1 root root 26 Jan 13 2015 /usr/bin/java -> /usr/java/default/bin/java lrwxrwxrwx 1 root root 27 Jan 13 2015 /usr/bin/javac -> /usr/java/default/bin/javac lrwxrwxrwx 1 root root 29 Jan 13 2015 /usr/bin/javadoc -> /usr/java/default/bin/javadoc lrwxrwxrwx 1 root root 28 Jan 13 2015 /usr/bin/javaws -> /usr/java/default/bin/javaws |
1 2 3 |
]# alternatives --install /usr/bin/java jdk /usr/java/jdk1.6.0_31/bin/java 100 ]# java -version java version "1.6.0_31" |
1 2 3 |
jar javac javap jcontrol jinfo jrunscript jstat jarsigner javadoc javaws jdb jmap jsadebugd jstatd java javah jconsole jhat jps jstack jvisualvm |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
]# cat update_jdk_alternatives.sh #!/bin/bash JAVA_HOME=$1 if test -z "$JAVA_HOME";then echo "usage: $0 JAVA_HOME" exit -1 fi JAVA_BINS="jar javac javap jcontrol jinfo jrunscript jstat jarsigner javadoc javaws jdb jmap jsadebugd jstatd java javah jconsole jhat jps jstack jvisualvm" CMD="alternatives --install /usr/bin/java jdk ${JAVA_HOME}/bin/java 100" SLAVE_CMD="" for BIN in $JAVA_BINS;do # ls -l $JAVA_HOME/bin/$BIN SLAVE_CMD="--slave /usr/bin/$BIN jdk-$BIN ${JAVA_HOME}/bin/$BIN $SLAVE_CMD" done $CMD $SLAVE_CMD alternatives --display jdk alternatives --set jdk ${JAVA_HOME}/bin/java echo "export JAVA_HOME=$JAVA_HOME" > /etc/profile.d/jdk.sh ]# sh update_jdk_alternatives.sh /usr/java/jdk1.7.0_25/ ]# javac -version javac 1.7.0_25 |
这应该就是安装多版本JDK的正确姿势了。
PS: 根据实际的安装经验,jdk1.8的RPM已经自行安装 alternatives,不需要运行上面的脚本了。
参考:
http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7-on-fedora-centos-red-hat-rhel/
3,061 浏览
我们团队对外的博客是NoOps.me,我们的运维理念是:Ops Make No Ops,希望把运维的日常工作尽可能的自动化起来,减少手工运维操作。做为一个运维人员,没有人愿意每天重复那些繁琐的运维操作;更没有人愿意每天处于高度紧张的精神状态,随时准备应对线上故障。
我们的目标是打造一个技术型、学习型的团队,通过新技术的研究,学习分享提升整个团队的技术影响力,使我们的运维工作更加高效。提供类似SaaS、DaaS、PaaS、IaaS的服务,一层层的向上封装。最终使研发人员能够在运维体系的架构下自助的进行资源申请、服务部署、运行监控和容灾备份,提供稳定、高效和安全的互联网服务。使我们的运维人员能有更多的精力参与到运维自动化体系的建设中,能有更多的精力投入到业务架构设计和性能优化中。
做为运维人员,首要的任务是保证服务稳定高效的运行,7*24为用户提供互联网服务。由于互联网业务的特点,往往是研发周期短、功能不断迭代、文档不全、规模发展快速。那么对于运维人员在技能方面就有很高的要求,除过操作系统、网络、硬件、开源软件应用等基础要求外,还需要强调运维人员的研发能力。
一方面,运维人员具备研发能力可以快速上手研发人员交付的线上服务。充分理解程序的功能逻辑,才能提前发现隐患,给出合理的运维建议。在优化方面才能有的放矢,而不是查找网上资料,按照前人经验不断的调“试”。我们甚至希望每位运维工程都是产品架构师,能够对业务服务的系统架构进行合理性规划和改进。
另一方面,运维人员具备研发能力也能更直接有效的把运维经验形成工具和平台,更有效的推进服务运维的自动化。在运维人员,特别是应用运维人员招聘中,我们更关注是否具备研发能力。国内很多从事互联网运维的人员在研发能力方面都相对薄弱,大多属于操作维护类。所以在某国内大型互联网公司中,运维部中校招人员占比90%,招聘最基本的要求就是具备研发能力、掌握至少一种脚本语言,熟悉数据结构。另外做为运维人员,除了考虑研发能力和知识全面性之外,我们还会重点关注动手能力。
和一些公司的运维团队不同,我们虽然也有运维平台研发团队,但更多的工具和平台研发工作是由运维人员负责。专职的平台研发人员很多没有接触过运维,不清楚运维人员真正的需求和痛点,通用的平台不能满足所有运维人员的需求,专项的平台又很难在需求功能上达到平衡。以前经常遇到平台研发和运维相互指责的情况,平台研发认为运维不配合他们的工作,运维认为平台研发不懂运维需求。
我们的平台研发团队主要负责最基础的核心功能和UI研发,运维人员参与需求收集和设计评审,比如服务管理平台的服务树和权限的需求讨论和模型设计。而运维人员负责监控系统、部署系统、环境初始化以及各种的日常运维工具的研发。拿部署系统举例,运维人员负责了build模块、客户端、控制端的研发工作,平台研发人员负责Web界面的研发。
如运维平台章节介绍的那样,我们在运维平台的设计中,提供各种API接口给运维或研发人员使用,他们根据自己的运维场景封装成个性化的工具或平台。以前涉及到服务器装机、改名、重启等操作都需要系统工程师负责,应用运维工程师发单让系统工程师操作。系统工程师将这部分工作形成自动化,提供API给服务管理平台。服务管理平台基于服务树和权限模型,提供给应用运维工程师使用,应用运维工程师能够对有权限的服务器进行一系列基础操作。渐渐的应用运维工程师将这部分权限开放给研发人员,研发人员也可以使用。同理,对于服务器资源申请、模块部署、监控添加都交给研发人员去使用。
运维人员除了平台研发和维护外,能够将精力放到其他更重要的事情上,避免了繁琐的沟通,工作效率也提升了。Hadoop研发人员使用资产信息提供的API,服务器的分布、交换机的参数、机柜的分布,能够更方便的调度和决策数据如何存储,避免由于机柜级别故障导致的服务受损。部署系统使用监控系统提供的API进行运行状态查询和监控项添加,在每台服务器部署前暂停监控,部署完成后启动服务、更新监控,判断监控正常后继续下一台部署工作,做到部署动作与监控状态的联动。
我们需要具备研发能力的优秀运维人员来帮助业务提升稳定性,但优秀的人才都不愿长期从事繁琐的操作类事务,不仅需要给予他们研发项目提升技术能力,也需要给予他们“有趣的事情”,研究新的技术。在工作时间上,尽量给员工买时间、投资源,在不影响业务稳定的前提下,投入20%~40%在项目研发和新技术研究上。
比如Https网站的SSL运算会消耗大量的CPU资源,工程师在经过研究后提出了采用类GPU的方式,用硬件加速卡来进行RSA运算,同时又对Nginx进行代码优化充分发挥硬件加速卡的性能,提升了服务质量还降低了资源成本。这样做的目的不仅能使我们的运维工作越来越出色,还能帮助我们看清未来的方向。比如虚拟化、Docker的研究帮助我们更好的进行服务部署,对大数据的研究帮助我们识别网络4/7层攻击行为。
我们鼓励工程师多学习、多交流,也希望团队是一个开放型的团队,能够把我们遇到的问题,好的经验分享出来,帮助个人、帮助团队、帮助行业共同成长,这也是我们写这本书的目的。
在开源运维软件方面,我们保持着跟随不盲目的心态。任何一款开源软件,我们必须做到掌握到代码级别的能力,和运维公司内部的产品一样,不仅能很好的使用开源软件,还能够动手分析和解决遇到的问题。不重复造轮子,但对开源软件的使用,也要清楚认识我们使用它的场景。
我们使用了Puppet、Ansible、Zabbix、God、Docker、Mesos、Etcd等等,Puppet在部署工具的第一版,我们仅仅用它的DSL做部署行为的语法解析和执行,并没用到它的客户端和服务端配置管理功能。有服务管理平台提供的服务树和权限模型,不需要再单独维护Puppet的服务器列表。
Ansible主要使用它对服务器进行临时性的批量操作执行。我们每台服务器上已经有一个超级Agent,不希望引入太多有执行逻辑的Agent,所以我们选择使用Ansible和SSHD进行交互。同时,我们改造Ansible和服务树结合,工程师可以使用个人帐号很方便的对有权限的服务器,进行临时批量的任务执行。
Etcd主要用来做LVS的Real Server注册,Real Server上新增Nginx启动后往Etcd注册状态,LVS实时读取列表更新本机的配置文件并Reload。
监控最早也是使用Zabbix,和服务树结合进行监控和报警策略的管理,随后由于开源监控系统无法满足需求,才开始研发自己的监控系统。
最后,真的很痛恨Operator这个称呼,我们目标是提供各种运维自动化平台或工具,让研发自助式的完成产品运行发布所需要的各种动作,No Ops!
6,461 浏览
详细请移步: http://open-falcon.com/
github地址:https://github.com/xiaomi/open-falcon
1,079 浏览
6,711 浏览
大家都知道SSD成本比较高,而不少用户在考虑可用性时都会选用RAID 10作阵列,这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本,因此最近一直在研究性价比更高的RAID 50,它提供了接近RAID 10的可用性并且接近RAID 5的成本,像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。
为了能够直观了解不同RAID类型下的故障可用性,我们首先做个简单的可用性分析(以8盘RAID 10的同等容量作对比):
RAID 50中:4块盘组成单组RAID 5,然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50
案例分析:
我们以9块盘RAID 50(3组RAID 5)为例作分析(达到相同容量的RAID 10需要12块盘):
再以12块盘RAID 50(4组RAID 5)为例作分析(达到相同容量的RAID 10需要16块盘):
上面对比中RAID 50已经能够容忍第3甚至第4块盘的故障,只是可用性相比RAID 10低了些,但是两者都不能达到完美的100%,所以权衡可用性和成本RAID 50还是有相当大的优势。
接下来看看性能,为了能够很好地分析性能,我们沿用了第一组对比方案的作性能分析:
随机读分析:
随机写分析:
混合随机读写分析:
顺序读分析:
顺序写分析:
再来看看这些阵列方案的性能和容错特性:
性能测试结论:
总结:
RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性,具有较好的整体性价比优势,所以考虑使用RAID 50替换RAID 10把!
8,071 浏览
经过一年多的摸索和实践,小米运维在互联网企业级监控解决方案上的一些思考和实践,分享给各位,多多交流
3,008 浏览
没有开场白,直接切主题!各位把这篇当成是报告来阅读吧:
应用IO模型:大量读线程同时访问多块SSD,请求均为4KB随机读,并且被请求的数据有一定间隔连续性;
服务器硬件配置:LSI SAS 2308直连卡 + 8块SSD
优化前应用QPS:27K
第一轮优化:读策略优化
通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB,进一步观察iostat情况:
观察到每块SSD的rMB/s十分高,平均已经达到了250MB/s+,初步判断是由于read_ahead_kb的设置影响了应用的读效率(即预先读取了过多不必要的数据)。遂将read_ahead_kb设置为0,观察iostat情况如下:
而应用QPS却下降至25K!
分析原因:由于之前有预读功能存在,因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后,所有的读访问均通过随机读实现,一定程度上加重了SSD的访问压力(可以观察到之前%util大约在60~80%之间波动,而预读改成0之后%util则在80~90%之间波动)
尝试16K预读
通过IO模型了解到每次请求的数据大小为4KB,因此将read_ahead_kb设置为16KB进行尝试,结果QPS由25K猛增到34K!
观察iostat情况如下:
%util降了不少,而且通过rrqm/s可以发现出现了一部分读合并的请求,这说明优化确有成效。
此时CPU_WA也由原来的平均30%下降到20%,这说明处理器等待IO的时间减少了,进一步验证了IO优化的有效性。
第二轮优化:直连卡中断多核绑定
考虑到SSD的随机读写能力较强(通过上面的iostat可以发现),在多盘环境下每秒产生的IO请求数也已接近100K,了解到LSI SAS 2308芯片的IOPs处理极限大约在250K左右,因此判断直连卡控制芯片本身并不存在瓶颈。
其实我们担心更多的是如此大量的IO请求数必定会产生庞大数量的中断请求,如果中断请求全部落在处理器的一个核心上,可能会对单核造成较高的压力,甚至将单核压力打死。因此单核的中断请求的处理能力就有可能成为整个IO系统的瓶颈所在,于是我们通过mpstat观察每个核心上的中断数:
可以发现第二个核心中断数已经达到了十分恐怖的80K!再来观察实际的处理器核心压力情况,为了能够更加直观地了解,我们用了比较准确的i7z工具来观察:
果然不出所料,Core 1的Halt(idle)已经到了1,充分说明第二个核心确实已经满载。
那么通过观察/proc/interrupt的情况再来进一步验证我们的假设,:
我们截取了片段,可以发现mpt2sas0-misx的大部分压力都集中在了CPU 1上,并且我们发现直连卡模式是支持多队列的(注意观察irq号从107至122,mpt2sas驱动总共有16个中断号),因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上(这里就不再赘述有关多核绑定的原理,有兴趣的同学可以百度搜索以上命令的含义):
随后我们惊奇地观察到应用的QPS由34K再次猛增至39K!
通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上:
并且CPU_WA也由平均20%下降到15%,io wait被进一步优化!
优化总结:
2,005 浏览
这里我们不再赘述有关寄存器、ALC等处理器架构和原理知识。我们只从直观的数据去分析和了解我们正在使用的多核处理器的真实性能——正所谓“是骡子是马拉出来溜溜”。一切建立在实际运行的数据才是真正有价值的评判依据。
在开始数据分析之前,我们必须弄清楚处理器的计算能力到底是什么:是频率决定了性能?还是核数决定了性能?
首选我们必须了解处理器的一个简单的性能计算公式:
整体性能 = 单核性能 × 核心数
其次性能受哪些因素影响会有以下这些原则:
原则一:架构越新,单核计算性能越强!
对比同频率、同核心数的前后两代处理器的计算能力就能发现架构越新的处理器整体计算能力也越强,这也意味着处理器架构的改进确实提高了单核性能。
原则二:频率越高,单核计算性能越强!
对比同代同核心数不同频率的处理器就能发现频率越高的处理器计算性能也越好,但这并非完全的线性增长。原因是处理器频率上去以后由于受到内存访问速度的限制也会有一定的瓶颈,而频率越高的处理器耗费在数据等待上的时钟周期也越多。
原则三:核心数越多,整体计算性能越强!
对比同代同频率不同核心数的处理器不难发现核心数越多的处理器整体计算性能也越好。但是如果观察单核性能会发现其实核数越多的处理器单核性能比同频率核数较少的处理器会差一些,主要原因是核数越多对共享资源的争抢概率也越高,这些共享资源包括L3缓存、内存、QPI总线等,这也就是多核处理器总是要把L3缓存做得很大的原因,核数越多L3缓存也越大。
请重点区别单核性能和整体性能:
1、单核性能:它影响的是单线程或者单任务的计算能力(即计算的响应延迟),对于单个请求计算的响应延迟要求较高的应用,就要用高频处理器去满足,而不是用多核。因为应用的一个线程无论任何时候都只能运行在处理器的一个核心上,增加核心数量对于改善单个计算请求的响应延迟并没有帮助,也就是说对跑单线程、单任务的应用无法提升其性能;
2、整体性能:前面提到核数越多整体性能越好,这也意味着多线程和多任务的应用环境下,如果要提高单机的计算处理量最好的办法是增加核心数而不是靠提高频率。理由很简单,核数较少的处理器晶元面积也小。如果要一味提高性能便要提高频率,提高频率其实就是给处理器晶元加电压。晶元能够忍受的电压是有限的,电压耐受力越高的晶元成本也越高。因此从稳定性和成本去考虑的话,晶元面积更大的多核处理器才是提高整体计算能力的最好选择。
下面我们挑选几款主流的双路处理器来作性能分析:
主题1:核数相同、频率不同
数据说明:如下表所示从第7行(Geekbench Integer)起是各项性能指标:分别是Geekbench整数成绩、SuperPI运行百万次的时间、以及根据Geekbench整数性能分别除以“处理器数量”、“核心数量”、“核心数量和Ghz的乘积”等来分别针对整体性能,单核计算能力,单个处理器、单个核心以及单个核心下每个Ghz的性能进行分析评估。
数据分析:
1、SuperPI体现的是单核浮点性能,通过SuperPI成绩可以发现处理器频率越高单核计算性能也越好,这一点也可以通过“性能/每个核心”项目体现,频率越高单核的计算性能也越好;
2、Geekbench Integer评估的是处理器的整体性能,规律自然也是频率越高整体性能越好;
3、“性能/每Ghz/每个核心”项目评估的是处理器的计算效率,这个项目是将Geekbench的整数成绩按照核数拆分并根据单个Ghz去计算,可以发现核数相同的处理器这个数据相互比较接近。
主题2:频率相同、核数不同
数据分析:
1、SuperPI项目更加可以说明单核计算能力受频率的影响,虽然2640 v2有8个核心,但对SuperPI的成绩没有丝毫帮助;
2、通过“性能/每个核心”项目可以发现,同频率下核数更少的2620 v2在这项成绩略好一些,即频率相同核数较少的处理器在单核性能上总是会核数更多的处理器略好一些,这确实也验证了核心之间存在资源争抢的假设;
3、Geekbench Integer成绩也体现出多核的性能优势,同频率下核数较多的处理器整体性能也更好;
4、再来看看用以评估计算效率的“性能/每Ghz/每个核心”项目,可以发现核数较多的处理器在计算效率上处于劣势:八核处理器的单核Ghz性能明显要比六核处理器的低不少,这样也进一步验证了核心之间存在资源争抢的假设,并且核数越多资源争抢的现象也越显著。
主题3:整体性能相同
最后一组选取整体性能接近而频率和核数均不同的处理器
数据分析:
1、SuperPI的成绩依旧验证了单核性能只受频率影响的假设;
2、Geekbench Integer成绩说明2630 v2的性能整体略好于2640 v2;
3、通过“性能/每个核心”项依旧验证了频率决定了单核性能的假设;
根据以上数据我们可以进一步将计算公式细化为:
多核处理器的整体计算能力 = 单核Ghz计算能力 × 频率数 × 核数
结论:
1、处理器整体性能和频率、核数有关,但并非核数越多性能就一定越好,高频少核和低频多核整体性能很可能接近;
2、核数决定了计算承载能力,核数越多能够承载的计算量也越大;
3、频率决定了单核计算能力,频率越高单个计算请求的响应延迟也越低;
4、频率相同的情况下,核数越多单核计算效率也越低;