語錄一

posted @ 2008-11-18 23:32 tacy lee 閱讀(251) | 評(píng)論 (0) | 編輯 收藏

oracle 的lob & long

一直認(rèn)為lob類型的性能要好過long，但是之前只了解到long的種種限制，oracle也是不推薦使用long類型，這幾天由于一個(gè)項(xiàng)目問題，產(chǎn)品里面一個(gè)表字段用了long類型，分析下來操作long的時(shí)候，性能有所影響，想把它改成lob，就簡單驗(yàn)證了一下

首先創(chuàng)建兩個(gè)測試表：

create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);

用附件java代碼，往兩個(gè)表里面各插入100條數(shù)據(jù)，保證插入數(shù)據(jù)是一樣的，lob字段長度為10k（如果小于4k，oracle可以把它保存到到表內(nèi)，不會(huì)存儲(chǔ)在表外，性能沒有問題，這個(gè)我基本確定，而且我們應(yīng)用中這個(gè)字段經(jīng)常會(huì)超過4k）。

做一個(gè)簡單查詢對(duì)比一下：

SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;

統(tǒng)計(jì)信息
----------------------------------------------------------
        331  recursive calls
          0  db block gets
         69  consistent gets
          4  physical reads
          0  redo size
       1278  bytes sent via SQL*Net to client
        837  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
         12  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> select * from test_long where a=1;

統(tǒng)計(jì)信息
----------------------------------------------------------
        236  recursive calls
          0  db block gets
         43  consistent gets
          0  physical reads
          0  redo size
        675  bytes sent via SQL*Net to client
        531  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
          1  rows processed

對(duì)比一下，long開銷比lob小，當(dāng)然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產(chǎn)生的redo比long大，就不列出來了，有興趣的可以自己試試

測試下來，看來之前的認(rèn)識(shí)不對(duì)，不確定的東西最好還是動(dòng)手試試，當(dāng)然對(duì)于新應(yīng)用，還是不建議用long，畢竟oracle已經(jīng)廢棄它了。

testClobLong.java

posted @ 2008-06-24 01:18 tacy lee 閱讀(464) | 評(píng)論 (0) | 編輯 收藏

殺掉服務(wù)器上的遠(yuǎn)程桌面連接

用遠(yuǎn)程桌面連接登入服務(wù)器的時(shí)候，你可能會(huì)經(jīng)常碰到下面的情況：

也就是說，服務(wù)器的連接數(shù)已經(jīng)滿了，很多時(shí)候，可能是別人異常斷開連接，導(dǎo)致連接沒有釋放，一般這時(shí)候你需要去機(jī)房登入服務(wù)器斷開連接，其實(shí)windows提供了tsdiscon命令來做這事情

posted @ 2008-06-22 17:12 tacy lee 閱讀(474) | 評(píng)論 (0) | 編輯 收藏

通過保存錯(cuò)誤頁面到日志中解決一些后臺(tái)看不到異常的錯(cuò)誤

有時(shí)候，我們可能希望看到lr的出錯(cuò)頁面：比如lr出錯(cuò)，但是后臺(tái)服務(wù)器沒有錯(cuò)誤日志，這時(shí)候，我們希望能看到錯(cuò)誤頁面的內(nèi)容來判斷問題出在什么地方，但是lr沒有提供類似的功能

我們可以通過一種變通的辦法來實(shí)現(xiàn)：

首先找到你出錯(cuò)的頁面，保存該頁面到參數(shù)里面：

web_set_max_html_param_len(“2048”);

web_reg_save_param(“FILED”,”LB=”,”RB=”,”Search=Body”,LAST);

然后輸出到日志里面： lr_output_message(”#######################################%s”,lr_eval_string(”{FILED}”));

修改lr run-time的幾個(gè)設(shè)置：

1、Always send messages

2、continue on error （這樣才能保證運(yùn)行l(wèi)r_output_message)

這樣lr會(huì)把所有的lr_output_message輸出保存到日志文件

當(dāng)然你不要下載資源文件，否則保存到的就不是html頁面了，可能是一個(gè)gif :(

最后，結(jié)合lr controller的錯(cuò)誤信息，定位到出錯(cuò)的vuser id，查看該vuser的log文件就能看到錯(cuò)誤頁面了

非常有效的一個(gè)小技巧，用它解決了一個(gè)難纏的問題。

posted @ 2008-05-28 23:05 tacy lee 閱讀(843) | 評(píng)論 (3) | 編輯 收藏

捐款

posted @ 2008-05-18 19:45 tacy lee 閱讀(256) | 評(píng)論 (0) | 編輯 收藏

地震

posted @ 2008-05-14 10:17 tacy lee 閱讀(248) | 評(píng)論 (0) | 編輯 收藏

ibm jdk 1.5缺省用的gc策略性能很差

posted @ 2008-04-14 20:38 tacy lee 閱讀(4465) | 評(píng)論 (2) | 編輯 收藏

Sybase 鎖模式

Sybase ASE有三種鎖模式：AllPages,DataPages,DataRows

Sybase的數(shù)據(jù)有table pages和index pages，最小分配單位為pages，不同的鎖模式對(duì)于table pages和index pages有不同的表現(xiàn)，具體如下：

如上表所示：
1、AllPages鎖模式對(duì)于并發(fā)的限制最高，他對(duì)index pages和table pages都加頁鎖（當(dāng)頁被鎖住的時(shí)候，頁上的所有rows都不能被其他session訪問）
2、DataPages對(duì)table pages加頁鎖
3、DataRows：強(qiáng)烈建議用這個(gè)鎖模式，對(duì)于oltp應(yīng)用，如果用前兩種鎖模式會(huì)導(dǎo)致頻繁死鎖

另外，DataPages和DataRows對(duì)于index pages的控制采用latch方式，一種輕量級(jí)的鎖機(jī)制（熟悉oracle會(huì)比較清楚）

對(duì)于Sybase ASE來說，鎖是非常寶貴的資源，不要長時(shí)間持有鎖，所以一般我們?cè)趯憫?yīng)用的時(shí)候盡量減少長事務(wù)

另：Sybase ASE缺省的事務(wù)隔離級(jí)別：Read Committed

posted @ 2008-04-01 10:50 tacy lee 閱讀(929) | 評(píng)論 (0) | 編輯 收藏

并發(fā)是啥

一個(gè)用戶點(diǎn)擊就是一個(gè)用戶請(qǐng)求，一個(gè)webservice類似的調(diào)用也算一個(gè)請(qǐng)求，等等

一個(gè)用戶在某個(gè)時(shí)間點(diǎn)上當(dāng)然只能發(fā)起一個(gè)用戶請(qǐng)求，一個(gè)用戶請(qǐng)求就是一個(gè)并發(fā)

我們一般糾纏在同一事物并發(fā)還是不同事務(wù)并發(fā)。

可能在一個(gè)時(shí)間點(diǎn)上，有100個(gè)用戶在發(fā)送瀏覽，查詢動(dòng)作，10個(gè)用戶在下訂單，5個(gè)用戶在做付款動(dòng)作，你說這個(gè)時(shí)間點(diǎn)上有多少個(gè)并發(fā)請(qǐng)求，當(dāng)然是115個(gè)了

衡量一個(gè)系統(tǒng)性能主要靠的就是這個(gè)吞吐量（tps）

當(dāng)然我們也非常關(guān)心同時(shí)100個(gè)用戶并發(fā)下訂單的時(shí)候系統(tǒng)是否能支撐（這是通常我們大部分人理解的并發(fā)），我們會(huì)說這是核心業(yè)務(wù)，我們要得出數(shù)據(jù)（是否要考慮背景業(yè)務(wù)呢，呵呵，很難說的清楚，我一般就不考慮）

posted @ 2008-03-18 15:33 tacy lee 閱讀(299) | 評(píng)論 (0) | 編輯 收藏

工作日志-OOM事件

某項(xiàng)目，年前開始報(bào)OOM，頻率保持在一月一次，發(fā)生OOM的時(shí)候，heap free size還有7～800M，比較奇怪，年后系統(tǒng)上集群，系統(tǒng)發(fā)生OOM的頻率開始變得頻繁，基本在4-5天，由于用的是sun jdk 1.4.2_08，無法獲取到heap dump，建議用戶升級(jí)到1.4.2_14（該版本以后sun添加了HeapDumpOnOutOfMemoryError參數(shù)，便于獲取dump幫助診斷該類問題），4天之后，我們獲取到了heapdump文件，通過對(duì)dump的分析，基本上排除了對(duì)象泄漏。

根據(jù)環(huán)境（64bit Solaris + 32bit JDK），客戶把Heap最大設(shè)置為2G，開始懷疑32bit JDK無法分配這么大的Heap，經(jīng)過驗(yàn)證，不存在這樣的問題（sun網(wǎng)站也有相關(guān)說明，在solaris 64bit系統(tǒng)上，32bit jdk最大可以設(shè)置到4G）

但是從dump看到application classes loader大小已經(jīng)到了60M以上，有點(diǎn)懷疑Perm區(qū)設(shè)置太小導(dǎo)致，查了一下sun的文檔，Perm區(qū)缺省大小為64M，估計(jì)是應(yīng)用加載太多classes導(dǎo)致Perm區(qū)溢出，

我們也簡單模擬了一下Perm溢出，強(qiáng)制設(shè)置max perm大小為32M，并對(duì)GC進(jìn)行了監(jiān)控，結(jié)果和我們預(yù)想的一致，看下面的gc log：

151.836: [Full GC 151.836: [Tenured: 25735K->25736K(1048576K), 0.8380858 secs] 25911K->25736K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8382804 secs]
152.676: [Full GC 152.676: [Tenured: 25736K->25722K(1048576K), 0.8464782 secs] 25752K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8466638 secs]
153.525: [Full GC 153.525: [Tenured: 25722K->25724K(1048576K), 0.8419056 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8420986 secs]
154.368: [Full GC 154.368: [Tenured: 25724K->25724K(1048576K), 0.8398816 secs] 25724K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8400498 secs]
155.212: [Full GC 155.212: [Tenured: 25724K->25725K(1048576K), 0.8365448 secs] 25788K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8367370 secs]
156.050: [Full GC 156.050: [Tenured: 25725K->25722K(1048576K), 0.8422488 secs] 25725K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8424328 secs]
156.895: [Full GC 156.895: [Tenured: 25722K->25724K(1048576K), 0.8443532 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8445450 secs]
157.740: [Full GC 157.741: [Tenured: 25724K->25724K(1048576K), 0.8427754 secs] 25740K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8429634 secs]
158.587: [Full GC 158.588: [Tenured: 25724K->25726K(1048576K), 0.8352290 secs] 25820K->25726K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8354212 secs]
159.424: [Full GC 159.424: [Tenured: 25726K->25723K(1048576K), 0.8435336 secs] 25726K->25723K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8437092 secs]
160.270: [Full GC 160.270: [Tenured: 25723K->25725K(1048576K), 0.8477722 secs] 25739K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8479596 secs]
161.119: [Full GC 161.119: [Tenured: 25725K->25725K(1048576K), 0.8543338 secs] 25725K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8545040 secs

從日志看，和我們現(xiàn)場的狀況非常相似，heap空間充足，但是perm已經(jīng)到了32M，無法再進(jìn)一步分配空間，直接導(dǎo)致jvm頻繁做Full GC，控制臺(tái)也開始拋出OOM（Perm引起的回收都是full gc），這樣看基本我們判斷是Perm太小，導(dǎo)致無法加載classes導(dǎo)致的

和客戶溝通之后，我們本來打算進(jìn)一步驗(yàn)證（在生產(chǎn)環(huán)節(jié)打開PrintGCDetail，獲取詳細(xì)的GC log），后面仔細(xì)檢查nohup.out,發(fā)現(xiàn)里面已經(jīng)拋出了 OutOfMemoryError:PermGen Space，至此我們確定是Perm設(shè)置不合理導(dǎo)致了本次事故，和客戶確認(rèn)之后，我們?cè)趩?dòng)參數(shù)中加上了MaxPermSize

后面想到中間上了集群之后，eos加載了大量的jboss cache class，這也直接解釋了為什么這段時(shí)間OOM出現(xiàn)的頻率比之前更頻繁的原因

這里總結(jié)一下，希望對(duì)碰到類似問題的tx有借鑒意義，強(qiáng)烈建議用sun jdk 1.4.2的同學(xué)升級(jí)到>=1.4.2_12，便于對(duì)OOM問題的診斷，并加上GC log協(xié)助驗(yàn)證。

這里再介紹一下JVM發(fā)生OOM的幾種情況：

1、java.lang.OutOfMemoryError: Java heap space

這是我們平常理解的OOM，是由于heap space確實(shí)沒有空間分配，這種一般是由于內(nèi)存泄漏導(dǎo)致，也有可能是heap space設(shè)置太小。需要具體分析

2、java.lang.OutOfMemoryError: PermGen space

jvm規(guī)范里面有定義一個(gè)method space，這里主要放classes和method list和一個(gè)string pool，string有一個(gè)intern方法，通過這個(gè)方法定義的string都放在這里（好像不常用），這里設(shè)置不太小會(huì)導(dǎo)致OOM，缺省64M，主要由于現(xiàn)在應(yīng)用依賴的第三方類越來越多，導(dǎo)致這類問題頻繁發(fā)生，需要引起重視

3、Requested array size exceeds VM limit
這種是由于申請(qǐng)的array size超出了heap space大小，比如在一個(gè)256M的heap space中申請(qǐng)一個(gè)512M的array，這種基本都是應(yīng)用bug導(dǎo)致

4、request <size> bytes for <reason>. Out of swap space?
這種是由于heap size設(shè)置相對(duì)于系統(tǒng)物理內(nèi)存太大，導(dǎo)致系統(tǒng)swap space不足，這種的解決辦法就是減小heap size大小

5、<reason> <stack trace> (Native method)
這種估計(jì)是最麻煩的了，也是最少碰到的，是由于jni或native method導(dǎo)致，如果自己沒有寫這類的東西，基本可以說是jdk問題

posted @ 2008-03-16 22:38 tacy lee 閱讀(2743) | 評(píng)論 (2) | 編輯 收藏

觀影日記

之前就準(zhǔn)備了一堆的片子，好好享受了一把，留下幾部有映象的吧：

強(qiáng)烈推薦型：

咱們自家的片子先推薦：《盲山》

看盲山，讓我想起Michael Moore，我一直認(rèn)為，嚴(yán)肅題材的電影本身就是電影存在的意義所在，我們需要用影像真實(shí)的記錄這個(gè)時(shí)代，我們需要這些“冷名人”，他們也許不是名利場的寵兒，但是他們一樣會(huì)有無數(shù)喜歡他們的人

《我在伊朗長大》

聽主人公瑪嘉娓娓道來，伊朗社會(huì)的變遷，依稀可以看到我們的影子，影片沒有去譴責(zé)或者反省或者什么高深的立意，只是要告訴你這個(gè)社會(huì)的樣子

《進(jìn)退維谷》

只要是Paul Haggis，都值得你關(guān)注，呵呵，反戰(zhàn)的片子，我感覺比之前的撞車有過之而無不及，不知為啥挺冷的，Tommy應(yīng)該提名最佳男演員，不過他好像評(píng)老無所依提名

《偷心》

老片子，看吧，不后悔，愛死這個(gè)精靈古怪的Natalie了，哈哈，真真假假誰又能分得清楚呢

《老無所依》

那個(gè)僵尸男實(shí)在太酷了，Tommy今年也挺火的，哈哈

隨便看看：

神探，喜歡記憶碎碎片，搏擊俱樂部這類片子的人可以看看，劉青云的表演我個(gè)人覺得一般，反正也就

美國黑幫（Denzel Washington新片，值得一看）

諜影重重3（這個(gè)還是比較經(jīng)典，今年馬特達(dá)蒙很火，整部片子非常緊湊，緊張刺激），

我的盛大同志婚禮（無厘頭Adam Sandler，去年的神奇遙控器記憶猶新），

一年到頭（騙了我一把眼淚）

C+偵探

贖罪（最近很火，看看吧）

哈哈，不記得了，還有一些，另外看了第一季反恐24，感覺一般

posted @ 2008-02-13 14:02 tacy lee 閱讀(265) | 評(píng)論 (0) | 編輯 收藏

公司同事拍的mv 歡迎捧場！

posted @ 2008-02-01 13:26 tacy lee 閱讀(257) | 評(píng)論 (0) | 編輯 收藏

集結(jié)號(hào)

應(yīng)該來說，場面還是不錯(cuò)的，國內(nèi)戰(zhàn)爭大片

太追求效果了，說實(shí)話，看過之后就忘了，在腦海里沒留下啥東西，雖然沒經(jīng)歷過戰(zhàn)爭，但是在解放戰(zhàn)爭年代的巷戰(zhàn)竟然打著手勢，為演戲而演戲，挺搞笑的，懷念黑鷹墜落中的那段伏擊戰(zhàn)，谷子地站在空地里手舞足蹈那段看著太怪了，這是戰(zhàn)爭嗎，整個(gè)讓人感覺挺滑稽的，像一群新兵蛋子第一次上戰(zhàn)場，哭爹喊娘，太過啦馮導(dǎo)

耳朵被轟的夠嗆，后面開始打感情牌，賺點(diǎn)眼淚

馮導(dǎo)還是要加油啊，其實(shí)大家是喜歡看馮導(dǎo)還是葛優(yōu)呢，哈哈

posted @ 2008-01-04 16:05 tacy lee 閱讀(271) | 評(píng)論 (4) | 編輯 收藏

關(guān)于oracle中的timestamp和date類型

posted @ 2007-12-26 00:42 tacy lee 閱讀(1929) | 評(píng)論 (0) | 編輯 收藏

Websphere Classes沖突診斷

作者：tacy lee

由于大量開源框架的采用，Classes沖突的問題在我們的項(xiàng)目中越來越常見，下面寫了一個(gè)簡單的jsp，用來查找當(dāng)前使用類的位置：

<%@page contentType="text/html; charset=gb2312" %>

<html>
  <head>
    <title>Class conflict</title>
  </head>
  
  <body>
      Example input: com.primeton.tp.web.driver.webdriver.PageDriver<br>
    <form action="<%=request.getRequestURI()%> " method="post">
      <input type="text" name="className" size="50" ><br>
      <input type="submit" value="submit">
    </form>
    <%
            String classLocation = null;
            String className =request.getParameter("className");

            if ((className != null) && ((className = className.trim()).length() != 0)) {
              try{
                classLocation = Class.forName(className).getProtectionDomain().getCodeSource().toString();
                }catch(Throwable e){
                    log("error=" + e, e);
                }

                if (classLocation != null) {
                    out.println("Class " + className + " found in <br>" + classLocation );
                }
              else {
                  out.println("Class '" + className + "' not found" );
                }
            }
    %>
  </body>
<html>

通過這個(gè)jsp頁面可以輸入需要查詢的類

-----------------------------------------------------------------------------------------------------------------------------------------------------

另外，websphere可以通過下面兩個(gè)方法來改變類的加載：

1、在"Applications" >"Enterprise Applications" >" yourear ">" Class Loading and File Update Detection"

修改："Class loader mode" 為 "Parent Last"，這樣應(yīng)用類可以覆蓋父裝載器的類

當(dāng)然但如果你混合使用了被覆蓋的類和沒有被覆蓋的類，則此操作有可能會(huì)導(dǎo)致 ClassCastException 或 LinkageErrors

2、在"Servers" > "Application servers" > "yourserver" > "Process Definition" > "Java Virtual Machine"

添加CLASSPATH，讓你的類先加載

posted @ 2007-12-21 18:05 tacy lee 閱讀(1349) | 評(píng)論 (0) | 編輯 收藏

google提供的翻譯機(jī)器人

posted @ 2007-12-20 17:04 tacy lee 閱讀(266) | 評(píng)論 (0) | 編輯 收藏

firefox 3 beta 2釋放出來了

posted @ 2007-12-19 14:58 tacy lee 閱讀(313) | 評(píng)論 (0) | 編輯 收藏

Websphere到底是否需要配置IHS

作者：tacy lee

有用Websphere做過項(xiàng)目的人可能都知道，ibm一般都建議在Websphere前面加一個(gè)IHS來做webserver，據(jù)說這樣性能會(huì)提高30%左右，這樣說是否有道理呢，下面我做了一個(gè)簡單的測試來驗(yàn)證：

測試環(huán)境：

硬件：

應(yīng)用服務(wù)器：Dell6600

壓力測試客戶端：自用筆記本（T2050 1.6G)

軟件：

系統(tǒng)：CentOS 4.4

Websphere 6.0.2.17+IHS6.0.2.17（部署在同一臺(tái)機(jī)器上）

首先配置好Websphere和IHS，發(fā)布一個(gè)簡單的測試應(yīng)用，用loadrunner來測試一下不同的組合看看（錄制一個(gè)打開首頁就可以了），下面是我的測試數(shù)據(jù)：

數(shù)據(jù)顯示，這還不是一點(diǎn)點(diǎn)提升，竟然快接近50%，把靜態(tài)資源放置到IHS中測試了一把，基本和通過IHS轉(zhuǎn)發(fā)差不多，稍微有些提升，不過放到IHS中可以方便Cache（Edge Server就包括了Caching Proxy component）

下面記錄一下如何放置靜態(tài)資源文件到IHS中：

1、打開Plugins中的plugin-cfg.xml，修改如下內(nèi)容：

<UriGroup Name="default_host_eos_URIs">
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.jsp"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.do"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eosmgr/*"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis/*"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis2/*"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eoshome_deploy/*"/>
</UriGroup>

也可以通過修改WEB-INF下ibm-web-ext.xmi中的fileServingEnabled為false，然后重新生成plugin-cfg.xml，但是我試了一下好像不好用。

另外Websphere（fixpacks 5.1.1.17, 6.0.2.25 and 6.1.0.15）之后的版本給Webcontainer增加了一個(gè)自定義參數(shù)

com.ibm.ws.webcontainer.disallowAllFileServing

設(shè)定它為true產(chǎn)生同樣的效果（而且他會(huì)覆蓋ibm-web-ext.xmi中的設(shè)置）。

2、拷貝你的所有資源文件到IHS的Root Directory中

3、重啟IHS

posted @ 2007-12-13 14:19 tacy lee 閱讀(5257) | 評(píng)論 (7) | 編輯 收藏

誰在使用這個(gè)端口？

作者：tacy lee

經(jīng)常，我們?cè)趩?dòng)應(yīng)用的時(shí)候發(fā)現(xiàn)系統(tǒng)需要的端口被別的程序占用，如何知道誰占有了我們需要的端口，很多人都比較頭疼，下面就介紹一種非常簡單的方法，希望對(duì)大家有用

假如我們需要確定誰占用了我們的9050端口

1、Windows平臺(tái)
在windows命令行窗口下執(zhí)行：

C:\>netstat -aon|findstr "9050" 

TCP    127.0.0.1:9050         0.0.0.0:0              LISTENING       2016 

看到了嗎，端口被進(jìn)程號(hào)為2016的進(jìn)程占用，繼續(xù)執(zhí)行下面命令：

C:\>tasklist|findstr "2016" 

tor.exe                     2016 Console                 0     16,064 K

很清楚吧，tor占用了你的端口

2、AIX

$netstat -Aan|grep 30542 

f10000f303321b58 tcp4 0 0 *.30542 *.* LISTEN 

$rmsock f10000f303321b58 tcpcb 

The socket 0x3321800 is being held by proccess 692476 (db2sysc).

這個(gè)我就不解釋了

3、Linux

$netstat -pan|grep 2809

tcp    0   0 0.0.0.0:2809   0.0.0.0:*   LISTEN   9493/java 

posted @ 2007-12-12 17:01 tacy lee 閱讀(1519) | 評(píng)論 (10) | 編輯 收藏