一. This Vuser already started a transaction with the same name, and has not yet processed the corresponding lr_end_transaction statement.
在做
性能测试的时候，有时候会遇到下面的错误：This Vuser already started a transaction with the same name, and has not yet processed the corresponding lr_end_transaction statement.
解释：就是脚本中有一个事物开始了，但是没有结束事物，此时loadrunner就会报错，因为开始和结束是一一对应的，谁也不能把它们拆开，拆开了就会报错。
异常再现:
下列代码中,如果业务方法报了异常(Throw Exception),那么下面的if判断的代码不会被执行,而直接跳到catch子句里,那么已经开始的业务"searchItemList_man"就没有被结束,当你再次开始业务时,就会报错~
1 public int action() throws Throwable { 2 3 misc = generateManItemSearchCondition(); 4 lr.start_transaction("searchItemList_man"); 5 try { 6 //业务方法 7 items = searchService.searchItemList(misc); 8 if (items.isSuccess()) { 9 lr.end_transaction("searchItemList_man",lr.PASS); 10 11 } else { 12 lr.end_transaction("searchItemList_man",lr.FAIL); 13 } 14 orderMap.clear(); 15 productIdSet.clear(); 16 productStatusList.clear(); 17 } catch (Exception e) { 18 19 20 e.printStackTrace(); 21 } 22 23 24 misc = null; 25 items = null; 26 return 0; 27 }//end of action |
解决办法: 在catch字句里加上一个 事务结束代码,修改后的catch段代码如下:
catch (Exception e) { // TODO Auto-generated catch block lr.end_transaction("searchItemList_man",lr.FAIL); e.printStackTrace(); } |
二.Function two_way_comm_post_message / two_way_comm_post_message_ex failed错误
在Controller里运行脚本，运行一段时间以后出现如下error messages。
1. Code - 60990 Error: Two Way Communication Error: Function two_way_comm_post_message / two_way_comm_post_message_ex failed.
2. Code - 29739 Error: Service client with id=1 failed to post a message, reason - communication error.
3. Code - 16895 Error: Failed to post xdr buffers data array by post_ex.
4. Code - 10343 Error: Communication error: Cannot send the message since reached the shared memory buffer max size.
问题诱因1：
共享内存缓存溢出，造成Controller和Load Generator之间通讯出现问题。
解决方案：
修改两个配置文件。
1. $installation folder$\dat\channel_configure.dat
2. $installation folder$\launch_service\dat\channel_configure.dat
在这两个文件中的[general]部分下添加如下配置。
shared_memory_max_size=100 (修改共享内存为100MB，默认是50MB)
重新启动Controller，问题解决。
问题诱因2
打开 controller中的 diagnostics菜单,点掉复选框.. 步骤如下图
1.
2. 点掉 Enable the following diagnostics
3. 整理了一下 这个功能是干么滴:
当场景中打开 Diagnostics 菜单下 Web Page Diagnostics 功能后, 才能得到网页分析组图。
通过该图, 可以对事务的组成进行抽丝剥茧的分析, 得到组成这个页面的每一个请求的时间分析, 进 一步了解响应时间中有关网络和服务器处理时间的分配关系。
可以实现对网站的前端性能分析, 明确系统响应时间较长是由服务器端处理能力不足还是客户端链接 到服务器的网络消耗导致的。
三. Fatal Error -26000: Not enough memory (12320 bytes) for "new buffer in LrwSrvNetTaskIt 问题解决及lr脚本心得
现象: 用loadrunner跑场景的时候报错:
Action.c(28): Fatal Error -26000: Not enough memory (12320 bytes) for "new buffer in LrwSrvNetTaskItem::AllocSrvNetBuf". Aborting 的错误,
同时任务管理器里mmdrv.exe 内存占用一直增大,最终mmdrv.exe崩溃. 网上有人认为是 lr的 emulation browser设置问题,最后发现系脚本问题,原脚本声明了好几个变量,而且都未使用:
1 Action() 2 { 3 4 //返回的字符串 5 char resp_txt[200] = {0}; 6 //写入流的数据 7 long myfile; 8 //当前日期时间 9 long now; 10 ..... 11 ...... 12 13 return 0; 14 } |
解决方法及总结:
后将此三个变量注释之后问题解决.
结论:LR的脚本要注意内存的使用,尽量减少变量声明,对于char类型的变量要及时用free:即:
1 char * a;
2 free (a)；
关于
敏捷转型，存在两种现象。有时候高层管理者要求“使用敏捷”，但中层经理“抵抗”；另外有些中层经理在高层并不关心敏捷的情况下，做到了转型。
作者观察到，高级和中层管理者都看到了转向团队为基础的组织和迭代增量式开发的好处。据她的经验，中层经理往往对现有模式不愿放手。为什么？如果他们在敏捷组织中没有看到自己的位置，他们不会拥抱敏捷。而敏捷方法对中层经理的角色所言甚少。泛泛的说消除对经理的需要没有帮助。
组织向敏捷转型仍然需要管理层，而且经常需要管理角色的人，特别是在大型复杂的组织中。在传统层级中，中层经理从高层确认未来的方向，并将
工作重点放在一线人员，让他们完成。当团队从队列中拉取任务并自我管理来完成目标，中层经理们真正的机遇是跨越部门边界来观察组织，以改进系统和培养人员及团队。 所以当中层经理不再指挥日常工作，他们做什么？作者认为有很多，特别是帮助同事，上司和团队：
中层管理者应该做什么
不同读者在评论中指出以下几点：
通常，中层经理起着承上启下的作用。他们不断扮演救火英雄来克服扔过来的挑战，大多数中层没有机会也没有动力去拥抱新方法。转型的能够取得的进步取决于组织成熟度，当组织和激励手段倾向于保持现有模式，新模式就难以形成。
让曾在风口浪尖的中层经理们退居幕后，他们会成为从瀑布式转型的最大障碍。不幸的是，他们会对敏捷转型造成最大的伤害，并导致脱轨（也有人认为在足够成熟的组织或流程中，中层经理并无如此大的破坏力）。更糟的情况是，此时很难让高层管理者来出面解决。
越要求他们承认错误，他们越会坚持己见。
帮助中层经理关注于“恰当的角色”是改进团队的好办法，给他们有价值的位置，让他们来塑造更好的团队型组织，给他们更多授权使变化发生，他们将重新投入热情。
另外，高级管理角色在敏捷组织中的定位也是个有意思的话题。
单元
测试(unit testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的
自动化测试手段，
单元测试可以在类和函数级别对代码进行质量守护，有助于避免尴尬、耗时的错误。当然，相比
功能测试(Functional testing)和端到端测试(end-to-end testing)，单元测试能够寄予的产品级别的信心要略低一些，因而各个粒度的测试应该是相辅相成的，互为补充。
常常听到一些组织要求开发团队提高单元测试覆盖率，换来的却是怨声载道，或者是一堆应付差事的垃圾测试（没有断言的测试，都见过吧）。尽管，低测试覆盖率意味着对质量的信心不足，但是，单元测试覆盖率真的要达到100%才好吗？
100%听起来肯定比95%要好，但是区别在于那些额外测试的价值对你可能是微不足道的。这要看哪种代码没有被测试覆盖，以及你的测试能否暴露程序的错误。100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了，而不管程序的行为是否满足要求。与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。
测试越多，额外测试的价值越少。第一个测试最有可能是针对代码最重要的区域，因此带来高价值与高风险。当我们为几乎所有事情编写测试后，那些仍然没有测试覆盖的地方很可能是最不重要和最不可能破坏的。
编写一些测试是不费脑筋的，但随着我们接近完全的代码覆盖率，我们不那么确定了——我们差不多已经为一切都编写了测试，而剩下的没有测试的代码是微不足道，几乎不会破坏。这就是所谓的收益递减。要想从单元测试中获得更多的收益，需要重新将单元测试从质量工具定位成设计工具。TDD等方式可以帮助我们做到这一点。
换句话说，向代码基增加100个精挑细选的自动化测试是明显的改善，但当我们已有30000个测试时，这些额外的100个测试就无足轻重了。
比赛场上的赢家是那些将注意力集中在赛场上的选手，而不是紧盯着计分板的人。—巴菲特
总之，当你觉得生产环境中报来的bug很少了，或者你能够自信地对代码随时进行修改，单元测试就已经足够多了。
另一方面，也有些观点认为，不但不值得追求高覆盖率，甚至写单元测试本身就是非常耗时和难以维护的重复
工作。这种极端观点我同样不赞同。
代码覆盖率不能告诉我们代码质量的高低，也不能用了评判开发人员的绩效。但它能够告诉我们哪些代码还没有被测试覆盖，哪里有漏网之鱼。至于这鱼值不值得抓，还是取决于开发人员的经验进行风险判断。那么，接下来我们再来分析一下，到底哪些鱼值得抓。
unit-test-quadrants
图中，产品代码可以分为四个类别，纵轴是从单元测试中得到的收益，横轴是单元测试的成本，我们从投入产出的角度来分析，到底哪些代码适合于进行单元测试：
琐碎且无甚依赖的代码。比如getter/setter, 比如简单地调用系统时间，比如 toString()等等，基本是不需要测试的。虽然测起来容易，但我们有信心说它们出错的概率也非常低，测这种代码的确索然无味。
承上启下的代码。比如用MVC框架实现的代码里，某些service层只是简单地被Action层调用，然后转发到下一层去。这种粘合代码不具备太多被测试的价值，而且由于是衔接上下两层的传话筒，测起来却需要对周围各层进行mock或打桩。要想验证其所做的那一点点工作，其实还挺麻烦的。当然，也有一些观点比如”London School TDD”坚持认为，对于企业级应用，就要像制作香肠一样，一层一层地对交互(interaction-based)进行测试，每测一层都需要mock的帮助。
具有算法和业务逻辑的代码。比如排序或处理数据等代码，这些是最值得进行单元测试的代码了。虽然有一定的成本，但是由于算法逻辑的输入输出非常确定，结构复杂且具有业务价值，外部依赖较少，在这上面投入是一定可以得到丰厚回报的。这即是”Classic TDD”观点，对状态进行测试(state-based)。
过于复杂的代码。充满复杂逻辑、交织在一起、散发着各种坏味道的遗留代码，就像一座未开发的金矿，你需要做很多清理工作，才能顺利地进行开采，否则将寸步难行，不知从何下手，而且成本极高。这种代码建议先进行粗粒度重构和接口测试（孰先孰后要根据实际情况），破除掉严重的依赖，找到所谓的接缝(Seam)，将具有逻辑的部分与承上启下的代码分离开，然后立即将单元测试注入到接缝中，形成对有逻辑代码的保护网，随后继续缩小重构的范围，不断地添加测试和重构，逐渐渗透形成一张网，将又臭又硬的代码块切碎。
除了3）以外的代码怎么测？可以采用其他测试手段，比如功能性测试来进行粗粒度覆盖，同样能提升对产品的信心，并且成本更低，特别适合敏捷迭代式开发，能够在有限的时间盒内达到预期的质量水平。
此外，持续地重构代码，同时编写更有效的单元测试，也是敏捷开发者应该具备的基本功，有助于提高投入产出比。
测试DAO层最常见的就是直接组织数据，调用相关的方法，然后查看
数据库，看看相关数据是否在DB中正确的展示。这样
测试，效率低下，容易出错，过多的依赖了人肉。如果选择测试数据来配置，根据配置的测试数据验证相关信息，或许能够达到事半功倍的效果。
测试数据配置选择(YAML)
在JavaBean中，传统的对象set是这样的：
对象属性多时，对象的set显得有些复杂，自动代码生成工具生成的代码较多都是set数据的，代码看起来不够雅观，需要把测试数据和测试代码分离。可以提供参考的又xml，wiki的方式。xml的方式读取大家都比较清楚，这里介绍一下wiki：
wiki语法
|table|表名称|
|字段名称1|字段名称2|字段名称3|
|字段值|字段值|字段值|
|字段值|字段值|字段值|
|字段值|字段值|字段值|
通过wiki配置的方式，和表字段一一对应，看起来比较直观，只是在字段较多时容易造成混淆，同时需要自己写代码支持wiki语法，框架级别的支持不够。xml配置也麻烦，数据阅读也不够直观。
yaml简单，直观，方便阅读，
java支持框架(http://yaml.org/)较多，所以选择yaml来配置测试数据。和TestNg保持一致，使用snakeyaml (http://code.google.com/p/snakeyaml/)
测试过程：
测试数据包括BaseDao对DB的基本操作：insert , update , find , findById , list , listCount , delete。由于findById和delete都是只有一个字段，所以测试数据基本生成只有insert ， update ，delete ， list这四个，业务模块可以根据自己的需求添加相关的Dao层测试数据。
测试修改示例：
1.首先获取一个eclipse版本，你可以从这里（http://www.eclipse.org/downloads/）获取
2. 获取
Selenium RC开发包，你可以从这里（http://seleniumhq.org/download/）获取，选择最新版本的Selenium RC，解压保存在任意文件夹中，为了方便管理，我保存Selenium RC到eclipse的根目录下，如图2所示。
图2
3. 打开eclipse，新建一个普通的
java项目TestSelenium，如图3所示，
图3
4. 添加一个包含selenium java开发包的用户库：进入eclipse首选项的构建路径下的用户库，如图4所示，点击新建创建一个用户库selenium1.0.3，选择新建的用户库selenium1.0.3，点击添加JAR，进入Selenium RC根目录下的selenium-java-client-driver-1.0.1目录，找到文件selenium-java-client-driver.jar，添加完成，如图5所示。
图4
图5
5. 为项目TestSelenium添加JUnit和Selenium RC java开发库：右键点击项目->构建路径->添加库，如图6所示，分别添加JUnit库和用户库中”selenium1.0.3”
图6
6. 启动Selenium RC的selenium-server，如图7所示。使用Selenium RC的selenium-server-1.0.3文件下的selenium-server，不能运行testcase。后来下了一个selenium-server-standalone-2.25.0.jar才成功。
启动命令：java -jar selenium-server-standalone-2.25.0.jar
图7
7. 在测试项目下新建junit test case编写测试脚本执行，或者将selenium ide录制的脚本copy项目的src目录下，以JUnit测试运行方式运行，你会看到Selenium在Firefox中打开www.baidu.com,然后在搜索框中输入”test”,并点击”百度一下”，然后页面跳转到搜索结果页，最后Firefox关闭。
AppSec Labs最近研制了一个名为AppUse的虚拟机，这个系统是一个免费的
Android移动应用
安全测试环境，并且包括了AppSec Labs开发的用户定制工具。
AppUse
使用AppUse不需要安装虚拟机和测试工具，不需要SSL认证代理软件，所有的一切都已预装完毕。当安全专家看到这款虚拟机后都非常激动，称它为下一个‘BackTrack’。
如果你正在开发一个
移动的应用，非常高的可能性这个应用是需要跟后端的 Web API 进行交互的，这个 API 可能是你们团队自己开发的，或者是第三方提供的。毫无疑问，在过去的这两三年里，API 已经成为企业和应用的催化剂，通过 API 可瞬间让设备和平台更具灵活性。
在这片
文章中，我们将谈谈关于 API 的质量以及如何通过 SmartBear 工具来确保 API 的质量
背景
一个移动应用（原生，混合或者网页），通过标准协议与其后端API交互，大多数基于HTTP和REST协议，使用JSON或者XML格式的数据。这些API可能是你们自己的或者来自于任何一个第三方（比如说Twitter或者
Google Maps），可以直接从你的应用中调用或者通过你们的API后端间接调用：
间接集成有如下几个优势：
你的API后端选择返回给
手机客户端的数据，减少宽带需求。
你可以更改第三方API，而不需更新手机应用
你可以在第三方API集中处理和隐藏错误和异常
你可以在不影响客户的情况下，你可以换掉第三方API提供者（当然新的API提供者要提供一样的功能）
你可以再API后端处理身份认证及API密钥--向客户隐藏逻辑
直接集成有如下优势：
第三方提供者的响应不需要通过中介，可以减少延迟
可能使用对许多第三方API提供者开放的用户库
更容易使用身份认证登入机制
你还可以扩展更多优劣势——最终根据你的需求和资源归纳。
API后端自身既可以为Node.js或者Grails应用服务，也可以用于基于J2EE或.NET的面向服务的应用。底层数据有可以用关系型
数据库操作，可以用NoSQL存储，也可以带有REST API。后端程序可以运行在本地服务器，也可以上传到虚拟云服务中。
无论你选择怎样的解决方案，你都需要解决API的测试和性能问题。现在让我们具体说说。
1.功能测试
最初，API测试将专注于功能测试，确保预期和非预期的输入结果正确。您可以使用一个关键字驱动的测试方法，使测试者可以在更高层次上定义测试范例来进行测试。另外，可以使用数据驱动的测试，测试大的输入和期望的输出数据集。
2.性能测试
性能测试是必须的，以此来保证你设计的API在高并发下的响应能力，只有保证了性能，才可以使得你的API有较好的多用户承载能力。在测试的时候你可以对你的API有个预期承受能力估值
如何对 API 进行代码质量测试
我们都知道代码的质量是整个项目开始时就要非常注意的一个方面。需求需要进行评审、UI 模型需要进行测试、积压的问题需要优先处理、架构需要被评估等等。
如果你使用敏捷开发，你将在你的整个应用生命周期中进行不断的迭代。如果你使用瀑布流模型，那么前期你需要做更多的工作。不管是什么方式，你的 API 设计都应该得到绝对的重视，包括技术选择、数据格式、安全、认证和管理等等。
单元测试和代码评审是在实际编码阶段中比较常用的质量手段。但你必须确保你把各个部分组合起来以正确的方式来测试 API。你可以看到 API 的测试是作为你的类、对象、脚本、数据存储的集成测试。
3.安全测试
安全测试是额外重要的.APIs常常可以直接访问核心数据与那些组成你商业核心价值的逻辑.你必须确保你的APIs可以避免一般的攻击,比如SQL注入,错误的数据输入,越界.
确认当系统遇到环境错误或者输入错误时不会向那些潜在的恶意的人员发送详细的系统信息,以防止被用来控制系统.对于性能测试.重新用"功能测试去"测试"安全测试"(即功能安全测试)是有好处的.它可以在你进行功能测试的时候扫描你的安全缺陷(比如在你的客户端验证完你的APIs后进行SQL漏洞扫描).
所有的这些测试(功能,性能,安全)需要被创建的尽可能的早,不断的运行你那些还在发展与不断成熟的APIs.包括你自己的单一独立的测试执行单元.(我也不太懂这句,,,,-_-!!再查查)
确保每周回来看看,了解第三方APIs如何复杂化了你对质量保证的努力,而且可以帮助你监控你部署后的APIs....
想必大家对于
jQuery这个最流行的javascript类库都不陌生，而且只要是前端开发人员肯定或多或少的使用或者接触过，在今天的这篇
文章中，我们将介绍一些书写高质量jQuery代码的原则，我们不单单会告诉你如何去书写，也会告诉你为什么这样书写，希望大家会觉得有所帮助。
注意定义jQuery变量的时候添加var关键字
这个不仅仅是jQuery，所有javascript开发过程中，都需要注意，请一定不要定义成如下：
$loading = $('#loading'); //这个是全局定义，不知道哪里位置倒霉引用了相同的变量名，就会郁闷至死的
如果你定义成这样的话，运气好，可能没有任何问题，或者出现一个绝对会让你debug一周，然后骂娘一个月的问题。
请使用一个var来定义变量
如果你使用多个变量的话，请如下方式定义：
var page = 0, $loading = $('#loading'), $body = $('body'); |
不要给每一个变量都添加一个var关键字，除非你有严重的强迫症
定义jQuery变量
申明或者定义变量的时候，请记住如果你定义的是jQuery的变量，请添加一个$符号到变量前，如下：
var $loading = $('#loading');
这里定义成这样的好处在于，你可以有效的提示自己或者其它阅读你代码的用户，这是一个jQuery的变量。
DOM操作请务必记住缓存（cache）
在jQuery代码开发中，我们常常需要操作DOM，DOM操作是非常消耗资源的一个过程，而往往很多人都喜欢这样使用jQuery：
$('#loading').html('完毕');
$('#loading').fadeOut();
代码没有任何问题，你也可以正常运行出结果，但是这里注意你每次定义并且调用$('#loading')的时候，都实际创建了一个新的变量，如果你需要重用的话，记住一定要定义到一个变量里，这样可以有效的缓存变量内容，如下：
var $loading = $('#loading');
$loading.html('完毕');$loading.fadeOut();
这样性能会更好。
使用链式操作
上面那个例子，我们可以写的更简洁一些：
var $loading = $('#loading');
$loading.html('完毕').fadeOut();
这样是不是更省力气书写呢？ 但是注意链式操作不要串的过多了，如果太多了，对于你自己的debug的眼力是一个巨大的挑战
精简jQuery代码
尽量把一些代码都整合到一起，请勿这样编码：
// ！！反面人物$button.click(function(){ $target.css('width','50%'); $target.css('border','1px solid #202020'); $target.css('color','#fff'); }); |
应该这样书写：
$button.click(function(){ $target.css({'width':'50%','border':'1px solid #202020','color':'#fff'}); }); |
避免使用全局类型的选择器
请勿如下方式书写：
$('.something > *');
这样书写更好：
$('.something').children();
不要叠加多个ID
请勿如下书写：
$('#something #children');
这样就够了：
$('#children');
多用逻辑判断||或者&&来提速
请勿如下书写：
if(!$something) {
$something = $('#something ');
}
这样书写性能更好：
$something= $something|| $('#something');
尽量使用更少的代码
与其这样书写
if(string.length > 0){..}
不如这样书写：
if(string.length){..}
尽量使用 .on方法
如果你使用比较新版本的jQuery类库的话，请使用.on，其它任何方法都是最终使用.on来实现的。
尽量使用最新版本的jQuery
最新版本的jQuery拥有更好的性能，但是最新的版本可能不支持ie6/7/8，所以大家需要自己针对实际情况选择。
尽量使用原生的Javascript
如果使用原生的Javascript也可以实现jQuery提供的功能的话，推荐使用原生的javascript来实现。
以上就是所有的jQuery代码书写技巧，如果你也有其它的书写技巧，请与我们分享！
来操作的。如果您的环境不是LVM的，可以考虑改成LVM的，否则后文无需再读。具体执行过程将细细道来。
第一步、使用VMware工具扩容分配的硬盘空间
1、 vmware 提供一个命令行工具，在Windows下为vmware-vdiskmanager.exe位于 vmware 的安装目录下，比如 C:Program FilesVMwareVMware Workstationvmware-vdiskmanager.exe.
在
Linux下有直接的vmware-vdiskmanager指令。
进行的操作：在 windows 下运行 CMD , 转到 vmware 的安装目录,可执行vmware-vdiskmanager.exe；在Linux下，直接敲入vmware-vdiskmanager ,可执行该指令扩充使用的指令: vmware-vdiskmanager -x 16Gb myNewlinux.vmdk
说明：要扩容的系统这时不能在运行 ，参数 "-x" 表示要扩展虚拟机硬盘空间，紧随其后的数字是要扩展到的大小 ，而非增加量 (本例为扩展到 16GB ，这是一个磁盘总量，包含了原先的磁盘容量 ) 。最后是指定要操作的虚拟机磁盘的具体文件，要是路径名中有空格，必须以双引号括起来。按回车键开始执行，执行完毕，退出命令提示符窗口，重启 VMware ，会发现虚拟机硬盘空间已变成 16GB 了。
2、我们重启虚拟机后，发现虚拟机的硬盘是变成 16GB 了，但进入 linux 系统后，用 "df -h"查看发现硬盘空间还是原先那么大。虽然已经扩大了磁盘，但是由于还没有经过分区，指定文件系统，所以 linux
操作系统无法识别。其实就相当于你的硬盘虽然大了，但是你并没有对其进行分区是一个道理。
第二步、使用Linux下的fdisk工具进行分区
首先，需要以root身份登录系统。
fdisk 命令： fdisk -l : 打印当前的磁盘分区表，这时我们可以看到磁盘的总量的确增加到16GB 了，但是分区只有以前的那几个原有的分区。
键入命令： fdisk /dev/sda “sda 就是经过扩容的硬盘，为 SCSI 硬盘， IDE 类型硬盘对应为 hda ，是对该硬盘进行操作 ”
键入： m “ 列出 fdisk 的帮助 ”
我们在这里是要添加一个新分区，即将扩容出来的那部分做成一个新分区，这样才能被操作系统挂载识别。
键入： n ” 命令 n 用于添加新分区 "
此时， fdisk 会让你选择添加为逻辑分区呢（编号从 5 开始）还是主分区（编号 1 到 4 ）。
选择主分区吧，则键入 p ；选择逻辑分区键入 l 。
我们选择主分区于是：
键入： p " 选择创建主分区 "
此时， fdisk 会让你选择主分区的编号，如果已经有了主分区 sda1 ， sda2 ，那么编号就选3 ，即要创建的该分区为 sda3.
键入： 3
此时， fdisk 又会让你选择该分区的开始值这个就是分区的 Start 值（ start cylinder ）；这里最好直接按回车，如果您输入了一个非默认的数字，可能会造成空间浪费；
对于分区的 End 值（end cylinder），同样直接按回车。这时候会显示出你新建分区的柱面范围和空间大小。
此时键入： w 表示" 保存所有并退出，分区划分完毕 "
我们的新建分区/dev/sda3，却不是LVM的。所以，接下来使用fdisk将其改成LVM的。
[root@CNGI-SIP6-BUPT ~]# fdisk /dev/sda Command (m for help): m Command (m for help): n //创建分区 Command action e extended p primary partition (1-4) p //创建主分区 Partition number (1-4): 3 //创建id号为3的分区 First cylinder (2611-5221, default 2611): 2611 //指定开始位置 Last cylinder or +size or +sizeM or +sizeK (2611-5221, default 5221): 5221 //结束位置 Command (m for help): t //改变分区系统id Partition number (1-4): 3 //指定分区号 Hex code (type L to list codes): 8e //指定要改成的id号，8e代表LVM。 Command (m for help): w |
我们现在还不能用这个分区 , 因为我们没格式化。这时要重启系统就能够在 dev 下面看到 sda3 ，如果不重启不能进行下面操作。
重启后，在此查看fdisk -l
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 1044 8281507+ 8e Linux LVM
/dev/sda3 1045 2088 8385930 8e Linux LVM
可以看到/dev/sda3已支持LVM。
第三步、格式化该新添加的分区
键入：
mkfs -t ext3 /dev/sda3
或者
mkfs.ext3 /dev/sda3
运行mkfs.ext3 /dev/sdb3报错“Could not stat /dev/sdb3”，但是这个分区肯定是存在的，刚刚 fdisk 加上去的，查了一下资料：
运行
partprobe
再执行mkfs.ext3 /dev/sdb4 ，就可以了
来格式化指定的分区,依次类推,现在的系统大部分都是 ext3 格式,如果你需要其它的,可以查看mkfs 的帮助。
到此为止，我们就新建了一个分区/dev/sda3，此时我们已经可以通过挂载，来使用这个新的空间。但是对于我，这并不能满足我的需求，因为服务器的服务程序是在根目录上的，目前根目录空间已经使用完毕，所以能把新建的分区使用在更目录上，分担根目录的空间，才能解决问题。
下面用到的理论是基于LVM的，如果不知道的话，建议稍微查些资料有助于理解。当然，一步步的跟我做，应该也没有问题。
第四步、扩充根分区
接着，使用vgextend 命令加到lvm组里面去，做如下操作：
[root@CNGI-SIP6-BUPT ~]# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert LogVol00 VolGroup00 -wi-ao 3.97G LogVol01 VolGroup00 -wi-ao 3.91G [root@CNGI-SIP6-BUPT ~]# pvcreate /dev/sda3 Physical volume "/dev/sda3" successfully created [root@CNGI-SIP6-BUPT ~]# vgextend VolGroup00 /dev/sda3 （其中是当前需要扩充的lvm组名，可以通过df -h查看，例如我的是： /dev/mapper/VolGroup00-LogVol00） Volume group "VolGroup00" successfully extended You have new mail in /var/spool/mail/root [root@CNGI-SIP6-BUPT ~]# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 15.84 GB PE Size 32.00 MB Total PE 507 Alloc PE / Size 252 / 7.88 GB Free PE / Size 255 / 7.97 GB VG UUID 3vSeag-Q74D-Gn1b-OHEq-zyH1-YgSO-ThhBCp [root@CNGI-SIP6-BUPT ~]# |
主要查看Free PE / Size 255 / 7.97 GB，说明我们最多可以有7.97G的扩充空间。
最后，给根分区增加空间
[root@CNGI-SIP6-BUPT ~]# lvextend -L +7.96G /dev/VolGroup00/LogVol00 /dev/sda3 Rounding up size to full physical extent 7.97 GB Extending logical volume LogVol00 to 11.94 GB Logical volume LogVol00 successfully resized [root@CNGI-SIP6-BUPT ~]# [root@CNGI-SIP6-BUPT ~]# vim /etc/fstab /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 ~ |
逻辑卷现在使用的就是ext3的文件系统最后扩展一下文件系统，此处不需要卸载，就ok了
要先做fsck，检查文件系统：e2fsck -f /dev/VolGroup00/LogVol00
告诉系统，分割区大小有调整了，以下以实际情况为主
[root@CNGI-SIP6-BUPT ~]# resize2fs /dev/VolGroup00/LogVol00 resize2fs 1.39 (29-May-2006) Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required Performing an on-line resize of /dev/VolGroup00/LogVol00 to 3129344 (4k) blocks. The filesystem on /dev/VolGroup00/LogVol00 is now 3129344 blocks long. |
到此所有操作完毕，使用df -h来查看扩充后的空间大小。是不是如愿以偿的增加了，成就感呼呼的~~
虽然
SQL数据库是非常有用的工具，但经历了15年的一支独秀之后垄断即将被打破。这只是时间问题：被迫使用关系数据库，但最终发现不能适应需求的情况不胜枚举。
但是NoSQL数据库之间的不同，远超过两 SQL数据库之间的差别。这意味着软件架构师更应该在项目开始时就选择好一个适合的 NoSQL数据库。针对这种情况，这里对Cassandra、Mongodb、CouchDB、Redis、 Riak、Membase、Neo4j 和 HBase 进行了比较：
（编注1：NoSQL：是一项全新的数据库革命性运动，NoSQL的拥护者们提倡运用非关系型的数据存储。现今的计算机体系结构在数据存储方面要求具 备庞大的水平扩 展性，而NoSQL致力于改变这一现状。目前
Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。 参见NoSQL词条。）
1. CouchDB
所用语言： Erlang
特点：DB一致性，易于使用
使用许可： Apache
协议： HTTP/REST
双向数据复制，
持续进行或临时处理，
处理时带冲突检查，
因此，采用的是master-master复制（见编注2）
MVCC – 写操作不阻塞读操作
可保存文件之前的版本
Crash-only（可靠的）设计
需要不时地进行数据压缩
视图：嵌入式 映射/减少
格式化视图：列表显示
支持进行服务器端文档验证
支持认证
根据变化实时更新
支持附件处理
因此， CouchApps（独立的 js应用程序）
需要 jQuery程序库
最佳应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。
例如： CRM、CMS系统。 master-master复制对于多站点部署是非常有用的。
（编注2：master-master复制：是一种数据库同步方法，允许数据在一组计算机之间共享数据，并且可以通过小组中任意成员在组内进行数据更新。）
2. Redis
所用语言：C/C++
特点：运行异常快
使用许可： BSD
协议：类 Telnet
有硬盘存储支持的内存数据库，
但自2.0版本以后可以将数据交换到硬盘（注意， 2.4以后版本不支持该特性！）
Master-slave复制（见编注3）
虽然采用简单数据或以键值索引的哈希表，但也支持复杂操作，例如 ZREVRANGEBYSCORE。
INCR & co （适合计算极限值或统计数据）
支持 sets（同时也支持 union/diff/inter）
支持列表（同时也支持队列；阻塞式 pop操作）
支持哈希表（带有多个域的对象）
支持排序 sets（高得分表，适用于范围查询）
Redis支持事务
支持将数据设置成过期数据（类似快速缓冲区设计）
Pub/Sub允许用户实现消息机制
最佳应用场景：适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
例如：股票价格、数据分析、实时数据搜集、实时通讯。
（编注3：Master-slave复制：如果同一时刻只有一台服务器处理所有的复制请求，这被称为 Master-slave复制，通常应用在需要提供高可用性的服务器集群。）
3. MongoDB
所用语言：C++
特点：保留了SQL一些友好的特性（查询，索引）。
使用许可： AGPL（发起者： Apache）
协议： Custom, binary（ BSON）
Master/slave复制（支持自动错误恢复，使用 sets 复制）
内建分片机制
支持 javascript表达式查询
可在服务器端执行任意的 javascript函数
update-in-place支持比CouchDB更好
在数据存储时采用内存到文件映射
对性能的关注超过对功能的要求
建议最好打开日志功能（参数 –journal）
在32位操作系统上，数据库大小限制在约2.5Gb
空数据库大约占 192Mb
采用 GridFS存储大数据或元数据（不是真正的文件系统）
最佳应用场景：适用于需要动态查询支持；需要使用索引而不是 map/reduce功能；需要对大数据库有性能要求；需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。
例如：你本打算采用 MySQL或 PostgreSQL，但因为它们本身自带的预定义栏让你望而却步。
4. Riak
所用语言：Erlang和C，以及一些Javascript
特点：具备容错能力
使用许可： Apache
协议： HTTP/REST或者 custom binary
可调节的分发及复制(N, R, W)
用 JavaScript or Erlang在操作前或操作后进行验证和安全支持。
使用JavaScript或Erlang进行 Map/reduce
连接及连接遍历：可作为图形数据库使用
索引：输入元数据进行搜索（1.0版本即将支持）
大数据对象支持（ Luwak）
提供“开源”和“企业”两个版本
全文本搜索，索引，通过 Riak搜索服务器查询（ beta版）
支持Masterless多站点复制及商业许可的 SNMP监控
最佳应用场景：适用于想使用类似 Cassandra（类似Dynamo）数据库但无法处理 bloat及复杂性的情况。适用于你打算做多站点复制，但又需要对单个站点的扩展性，可用性及出错处理有要求的情况。
例如：销售数据搜集，工厂控制系统；对宕机时间有严格要求；可以作为易于更新的 web服务器使用。
5. Membase
所用语言： Erlang和C
特点：兼容 Memcache，但同时兼具持久化和支持集群
使用许可： Apache 2.0
协议：分布式缓存及扩展
非常快速（200k+/秒），通过键值索引数据
可持久化存储到硬盘
所有节点都是唯一的（ master-master复制）
在内存中同样支持类似分布式缓存的缓存单元
写数据时通过去除重复数据来减少 IO
提供非常好的集群管理 web界面
更新软件时软无需停止数据库服务
支持连接池和多路复用的连接代理
最佳应用场景：适用于需要低延迟数据访问，高并发支持以及高可用性的应用程序
例如：低延迟数据访问比如以广告为目标的应用，高并发的 web 应用比如网络游戏（例如 Zynga）
6. Neo4j
所用语言： Java
特点：基于关系的图形数据库
使用许可： GPL，其中一些特性使用 AGPL/商业许可
协议： HTTP/REST（或嵌入在 Java中）
可独立使用或嵌入到 Java应用程序
图形的节点和边都可以带有元数据
很好的自带web管理功能
使用多种算法支持路径搜索
使用键值和关系进行索引
为读操作进行优化
支持事务（用 Java api）
使用 Gremlin图形遍历语言
支持 Groovy脚本
支持在线备份，高级监控及高可靠性支持使用 AGPL/商业许可
最佳应用场景：适用于图形一类数据。这是 Neo4j与其他nosql数据库的最显著区别
例如：社会关系，公共交通网络，地图及网络拓谱
7. Cassandra
所用语言： Java
特点：对大型表格和 Dynamo支持得最好
使用许可： Apache
协议： Custom, binary (节约型)
可调节的分发及复制(N, R, W)
支持以某个范围的键值通过列查询
类似大表格的功能：列，某个特性的列集合
写操作比读操作更快
基于 Apache分布式平台尽可能地 Map/reduce
我承认对 Cassandra有偏见，一部分是因为它本身的臃肿和复杂性，也因为 Java的问题（配置，出现异常，等等）
最佳应用场景：当使用写操作多过读操作（记录日志）如果每个系统组建都必须用 Java编写（没有人因为选用 Apache的软件被解雇）
例如：银行业，金融业（虽然对于金融交易不是必须的，但这些产业对数据库的要求会比它们更大）写比读更快，所以一个自然的特性就是实时数据分析
8. HBase
（配合 ghshephard使用）
所用语言： Java
特点：支持数十亿行X上百万列
使用许可： Apache
协议：HTTP/REST （支持 Thrift，见编注4）
在 BigTable之后建模
采用分布式架构 Map/reduce
对实时查询进行优化
高性能 Thrift网关
通过在server端扫描及过滤实现对查询操作预判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby（ JIRB）的shell
对配置改变和较小的升级都会重新回滚
不会出现单点故障
堪比MySQL的随机访问性能
最佳应用场景：适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合。
例如： Facebook消息数据库（更多通用的用例即将出现）
编注4：Thrift 是一种接口定义语言，为多种其他语言提供定义和创建服务，由Facebook开发并开源。
当然，所有的系统都不只具有上面列出的这些特性。这里我仅仅根据自己的观点列出一些我认为的重要特性。与此同时，技术进步是飞速的，所以上述的内容肯定需要不断更新。我会尽我所能地更新这个列表。