顯示具有 RTB 標籤的文章。 顯示所有文章
顯示具有 RTB 標籤的文章。 顯示所有文章

2009年5月17日 星期日

PostgreSQL 的測試 - 4

繼續之前的測試, 這一次是 nb27 升級到 2.6.29.1, 及 postgresq-8.3.7.

測試環境及結果:

pc26
nb27
pc34
pc200
OS
2.6.9-34.EL 2.6.9-34 .ELsmp 2.6.9-34 .ELsmp2.6.9-42.0 .10.ELsmp2.6.29.1 #2 SMP
2.6.20-rc6 #1 SMP2.6.20-rc6 #1 SMP2.6.9-42.0 .10.ELsmp
2.6.9-55.ELsmp
python
2.3.4
2.3.4
2.3.4
2.3.4
PostgreSQL
8.1.8
8.1.4
8.2.3
8.2.3
8.3.7
8.1.8
8.2.38.2.3
8.2.3
PyGresSQL
3.8.1
3.8.1
3.8.1
3.8.1
CPU Intel(R) Pentium(R) 4 CPU 2.80GHz
512 KB Cache (5605.85)
Genuine Intel(R) CPU T2400 @ 1.83GHz
2048 KB Cache (1998.36)
(DualCore)
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
4096 KB Cache (4819.82)
(DualCore)
Intel(R) Xeon(R) CPU 5140 @ 2.33GHz
4096 KB Cache (4657.86)
(DualCore x2)
RAM
1GB
1GB
2GB
4GB
duration
5:32:36
(22:39:05 - 04:11:41)
2:28:11
(16:33:14 - 19:01:25)
2:08:56
(15:11:55 - 17:20:51)
2:30:14
(17:47:33 - 20:17:48)
1:41:49 (15:59:31 - 17:41:12)
4:20:45
(22:40:28 - 03:01:13)
3:51:15

1:40:30
1:24:22 (09:42:26 - 11:06:42)
1:24:50
(noatime)
0:10:05
(noatime/ atime, noprint)
/0:10:17
0:48:35
(noatime, nohexdump)

(noatime,
print=time.ctime,
nohexdump)
average dur./call
19.956ms
8.891ms
7.737ms
9.015ms
6.109ms
15.605ms
13.876ms
6.030ms
5.062ms
5.091ms
0.605ms
0.617ms
2.915ms
1.636ms
min dur. /1000call
11.29sec
7.23sec
7.19sec
7.19sec
6.0842sec
4.54sec
4.54sec
5.26sec
4.963sec
4.971sec
0.566sec
0.565sec
2.854sec
1.566sec
max dur. /1000call
57.45sec
20.25sec
17.72sec
17.72sec
7.577sec
33.39sec
36.68sec
9.96sec
5.714sec
5.700sec
1.281sec
1.425sec

3.792sec
2.313sec
mean /1000call
19.956sec
8.891sec
7.737sec
9.015sec
6.109sec15.605sec
13.876sec
6.030sec
5.062sec5,091sec
0.605sec
0.617sec
2.915sec
1.636sec
std devi. /1000call
8.35sec
2.58sec
0.76sec
0.31sec
0.079sec
6.22sec
6.42sec
0.91sec
0.079sec
0.084sec
0.059sec
0.071sec
0.090sec
0.087sec


當 nb27 升級到 2.6.29.1/8.3.7 之後, 可以發現, 整個 performance 提升了不少. 且運作起來比較平順 (standard deviation 較小). 使得 nb27 /pc34 原本不是同一等級的機器, 但有了相同的表現.

也許 在 pc34 上的表現也更明顯, 有機會, 可以再試試.

2007年8月22日 星期三

PostgreSQL 的測試 - 3

繼續之前的測試, 這次多了 pc200 (是一台 Dell 的機器)

測試環境及結果:

pc26
nb27
pc34
pc200
OS
2.6.9-34.EL 2.6.9-34 .ELsmp 2.6.9-34 .ELsmp2.6.9-42.0 .10.ELsmp2.6.20-rc6 #1 SMP2.6.20-rc6 #1 SMP2.6.9-42.0 .10.ELsmp
2.6.9-55.ELsmp
python
2.3.4
2.3.4
2.3.4
2.3.4
PostgreSQL
8.1.8
8.1.4
8.2.3
8.2.3
8.1.8
8.2.38.2.3
8.2.3
PyGresSQL
3.8.1
3.8.1
3.8.1
3.8.1
CPU Intel(R) Pentium(R) 4 CPU 2.80GHz
512 KB Cache (5605.85)
Genuine Intel(R) CPU T2400 @ 1.83GHz
2048 KB Cache (1998.36)
(DualCore)
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
4096 KB Cache (4819.82)
(DualCore)
Intel(R) Xeon(R) CPU 5140 @ 2.33GHz
4096 KB Cache (4657.86)
(DualCore x2)
RAM
1GB
1GB
2GB
4GB
duration
5:32:36
(22:39:05 - 04:11:41)
2:28:11
(16:33:14 - 19:01:25)
2:08:56
(15:11:55 - 17:20:51)
2:30:14
(17:47:33 - 20:17:48)
4:20:45
(22:40:28 - 03:01:13)
3:51:15

1:40:30
1:24:22 (09:42:26 - 11:06:42)
1:24:50
(noatime)
0:10:05
(noatime/ atime, noprint)
/0:10:17
0:48:35
(noatime, nohexdump)

(noatime,
print=time.ctime,
nohexdump)
average dur./call
19.956ms
8.891ms
7.737ms
9.015ms
15.605ms
13.876ms
6.030ms
5.062ms
5.091ms
0.605ms
0.617ms
2.915ms
1.636ms
min dur. /1000call
11.29sec
7.23sec
7.19sec
7.19sec
4.54sec
4.54sec
5.26sec
4.963sec
4.971sec
0.566sec
0.565sec
2.854sec
1.566sec
max dur. /1000call
57.45sec
20.25sec
17.72sec
17.72sec
33.39sec
36.68sec
9.96sec
5.714sec
5.700sec
1.281sec
1.425sec

3.792sec
2.313sec
mean /1000call
19.956sec
8.891sec
7.737sec
9.015sec
15.605sec
13.876sec
6.030sec
5.062sec5,091sec
0.605sec
0.617sec
2.915sec
1.636sec
std devi. /1000call
8.35sec
2.58sec
0.76sec
0.31sec
6.22sec
6.42sec
0.91sec
0.079sec
0.084sec
0.059sec
0.071sec
0.090sec
0.087sec

可以發現, 即使是使用了 4GB 的 ram, 只可以改善 std. dev.
據此可以推論, 會出現 比較大的執行時間, 應該是 os 的 buffer layer 的影響.

另外, noatime 這個 mount 選項並沒有多少改善. (反而延長了時間)

若是讓 rad.py 不列印任何資訊的話(noprint), 可以改善整個測試的時間. 而且是很可觀的.
noprint 表示將程式內的 InfoPrint() 全部 註解 掉. 這除了 不 call time.time() 外, 也不 call hexDump().
若只是讓 rad.py 不執行 hexDump 的話(直接 return 空字串), 可以節省(與noatime比) 40%左右.

2007年4月18日 星期三

DCE/RPC 測試

今天到 A 公司測試 MGC 的 CDR 介面. 一開始對 i5_recLstLength 的意義上有誤解, 以為是接收到的單筆 CDR 的長度. 後來發現是收到資料的總長度. 然後問題就解決了. 算是蠻順利的.

這次的測試算是順利的, 對方也很專業, 整個測試環境早就 ready 了. 很久沒遇到這樣的合作廠商了.

接著就要對 DCE/RPC 的 API 進一步的深入了解. 避免可能的 memory leak. 大部份的 demo 程式, 都不會注重在這些細節. 只能靠自己一個 function 一個 function 去讀, 確認該 free 的東西都 free.

這一版 API 是 blocking mode, 要跟現有的程式框架結合的話, 必須將這一部份放在 thread 中, 並且透過 PIPE/MSG 來傳遞訊息 可能最方便.

2007年3月26日 星期一

Freedce

今天安裝好 freedce, 並且跑了一下 rpcd, echo_server, echo_client, 已經確定可以用了.

接下來, 應該是多點接入的問題.

真的要 coding 之前, 可能得多看看相關的 API 說明.

別忘了收集到的資料 放在 kunsheng.chen@gmail.com 資料收集 DCE RPC 的 E-MAIL 內.

2007年3月23日 星期五

DCE/RPC

Alcatel-Lucent 的 RTB interface 竟然是使用 DCE/RPC.

找了一堆東西, 發現 python 並沒有 支持 DCE/RPC. (但是有 ONC/RPC), 這可是麻煩了.

試著 google 'DCE/RPC +SOURCE', 找到了 www.opengroup.org, 在 非商務應用的前提下, 是 LGPL 的 License. 試著去用一下. 先了解是否可以滿足這個應用.

接著 google '"DCE/RPC" +linux', 找到 freedce.sf.net 這個網站. 似乎是將 public domain 的 dce/rpc port 到 linux. 試一下.

另外有一篇文章值得參考 http://www.linuxjournal.com/article/2204 , 有列一些 reference.

2007年3月21日 星期三

apache +mod_python +PyGreSQL 突然跑不起來

今天打算把 http://nb27/bcf/ 重新跑起來, 結果竟然失敗, 出現

PythonHandler mod_python.publisher: ImportError: libpq.so.4: failed to map segment from shared object: Permission denied

試著重裝一下 PostgreSQL 8.1.4, PyGreSQL, mod_python, 結果都不行.

google 了一下, 發現原來也有人遇到類似的問題. 原因是 selinux 不允許 apache 使用該目錄下的內容.

是需要執行

# cd /usr/local/pgsql
# chcon -R system_u:object_r:httpd_modules_t lib/
這是跟 selinux 相關的 設定, 但不知道是什麼原因造成這個問題.

也許是因為我執行過

# cd /usr/local
# mv pgsql pgsql-8.2.3-9-42
# ln -s pgsql-8.1.4 pgsql

2007年3月15日 星期四

PostgreSQL 的測試

繼續之前的測試,

測試環境及結果:

pc26
nb27
pc34
OS
2.6.9-34.EL 2.6.9-34 .ELsmp 2.6.9-34 .ELsmp2.6.9-42.0 .10.ELsmp2.6.20-rc6 #1 SMP2.6.20-rc6 #1 SMP2.6.9-42.0 .10.ELsmp
python
2.3.4
2.3.4
2.3.4
PostgreSQL
8.1.8
8.1.4
8.2.3
8.2.3
8.1.8
8.2.38.2.3
PyGresSQL
3.8.1
3.8.1
3.8.1
CPU Intel(R) Pentium(R) 4 CPU 2.80GHz
512 KB Cache (5605.85)
Genuine Intel(R) CPU T2400 @ 1.83GHz
2048 KB Cache (1998.36)
(DualCore)
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
4096 KB Cache (4819.82)
(DualCore)
RAM
1GB
1GB
2GB
duration
5:32:36
(22:39:05 - 04:11:41)
2:28:11
(16:33:14 - 19:01:25)
2:08:56
(15:11:55 - 17:20:51)
2:30:14
(17:47:33 - 20:17:48)
4:20:45
(22:40:28 - 03:01:13)
3:51:15

1:40:30
average dur./call
19.956ms
8.891ms
7.737ms
9.015ms
15.605ms
13.876ms
6.030ms
min dur. /1000call
11.29sec
7.23sec
7.19sec
7.19sec
4.54sec
4.54sec
5.26sec
max dur. /1000call
57.45sec
20.25sec
17.72sec
17.72sec
33.39sec
36.68sec
9.96sec
mean /1000call
19.956sec
8.891sec
7.737sec
9.015sec
15.605sec
13.876sec
6.030sec
std devi. /1000call
8.35sec
2.58sec
0.76sec
0.31sec
6.22sec
6.42sec
0.91sec

有趣的是, 對 nb27 而言, 更換到最新的 kernel 並不會讓執行速度加快.
也許應該在 pc34 上再試試這個條件.

另外, noatime 這個 mount 選項也可以試試, 看看可以有多少改善.

2007年3月13日 星期二

PostgreSQL 的測試

因為 S 廠商的需求, 做了一些關於 Radius/PostgreSQL 的測試.

測試程式:
1. rtls.py - 將預先產生的 1,000,000 筆記錄以 radius 的方式送出.
(每一筆記錄會產生 3 個 radius packets, 分別是 ringing, answer, release)
(收到 rad.py 的 ack 後才會送下一個 radisu packet)
2. rad.py - 將收到的 radius 資料轉發給 rtbsvr.py, 並回 radius 的 ack 給 rtls.py.
(只有 release packet 中的資料會轉發)
3. rtbsvr.py - 將收到的資料加入資料庫中.
以上程式, 都只跑在同一台機器. (與網路 stack 無關)

測試環境及結果:

pc26
nb27
pc34
OS
2.6.9-34.EL 2.6.9-34.ELsmp 2.6.20-rc6 #1 SMP
python
2.3.4
2.3.4
2.3.4
postgresql
8.1.8
8.1.4
8.1.8
pygresql
3.8.1
3.8.1
3.8.1
cpu
Intel(R) Pentium(R) 4 CPU 2.80GHz
512 KB Cache (5605.85)
Genuine Intel(R) CPU T2400 @ 1.83GHz
2048 KB Cache (1998.36)
(DualCore)
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
4096 KB Cache (4819.82)
(DualCore)
memory
1GB
1GB
2GB
duration
5:32:36
(22:39:05 - 04:11:41)
2:28:11
(16:33:14 - 19:01:25)
4:20:45
(22:40:28 - 03:01:13)
handling average/call
19.956 ms
8.891 ms
15.605 ms
1000筆的 min dur.
11.29 sec
7.23 sec
4.54 sec
1000筆的 max dur. 57.45 sec
20.25 sec
33.39 sec
1000筆的 mean
19.956 sec
8.891 sec
15.605 sec
1000筆的 std var.
8.35 sec
2.58 sec
6.22 sec

軟體上的不同點 (下次測試時可以調整的):
1. postgresql 版本. 應該都調到 8.1.8 或 8.2.*
2. OS 版本. 應該都用 2.6.9-34.ELsmp. (但 pc34 是 修明的工作 設備, 舊版沒有 對應的 driver) 或都採用 2.6.20 系列.