一. 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開發并開源。
當然，所有的系統都不只具有上面列出的這些特性。這里我僅僅根據自己的觀點列出一些我認為的重要特性。與此同時，技術進步是飛速的，所以上述的內容肯定需要不斷更新。我會盡我所能地更新這個列表。