http://blog.udn.com/keithmin/680899
首先您必定發現執行一應用程式的效能無法為人所接受, 請執行 UNIX 的指令
“vmstat” 確定主要原因在於 CPU 的系統資源, 而不是過少的 Free 記憶體, 或是 Disk I/O “iostat”, 網路 I/O “netstst” 的問題. 至於 CPU 的系統資源的使用又偏重於 system (kernel) mode. 請執行 UNIX 的指令 “collect” 確認沒有過多的IO wait 如下:
# collect –i 5 –sc
Initializing (5.0 seconds) ... done.
#### RECORD 1 (1082365399:0) (Mon Apr 19 17:03:19 2004) ####
# CPU SUMMARY
# USER SYS IDLE WAIT INTR SYSC CS RUNQ AVG5 AVG30 AVG60 FORK VFORK
8 73 19 0 503 54911 4322 4 5.68 6.61 6.32 13.91 0.00
# SINGLE CPU STATISTICS
# CPU USER SYS IDLE WAIT
0 6 70 24 0
1 8 76 16 0
2 8 75 16 0
3 8 72 19 0
#### RECORD 2 (1082365404:0) (Mon Apr 19 17:03:24 2004) ####
# CPU SUMMARY
# USER SYS IDLE WAIT INTR SYSC CS RUNQ AVG5 AVG30 AVG60 FORK VFORK
8 63 29 0 451 67136 3936 3 2.51 3.35 3.53 10.94 0.00
# SINGLE CPU STATISTICS
# CPU USER SYS IDLE WAIT
0 6 57 37 0
1 9 66 25 0
2 8 65 27 0
3 9 63 28 0
同時也沒有過重的 RUNQ 代表待執行的 Processes 過多, 而只有很高量的“System Call”
2-2) 利用“truss”工具來分析過高的 “System Call” 是否正常. 此 “truss” 工具須另行安裝一“SYSTEM V ENVIRONMENT” kit. 如果您有這方面的需求請和 HP 聯繫.
範例: 下列試以同一應用程式的執行,用“truss”來分析其中所呼叫使用的“System Call”的數量和在與 ORACLE 資料庫連結後, 其所呼叫使用的 “System Call” 的數量的變化.
# truss -o /var/tmp/AP_noDB.log -c AP
. ====e 等到 AP 執行結束.
# cat /var/tmp/AP_noDB.log
signals ------------
SIGCLD 1
total: 1
syscall seconds calls errors
_exit .00 1
fork .00 1
read 12.37 472941
write .50 15254
close .00 39
wait4 .00 1
brk .00 14
lseek 3.66 482933
getpid .00 6
getuid .00 3
pipe .00 1
set_program_ .00 1
open .00 44 9
getgid .00 3
sigprocmask .00 2
ioctl .00 15 3
execve .00 1
getpagesize .00 3
pre_F64_stat .00 38 5
mmap .00 12
madvise .00 3
setitimer .00 32
pre_F64_fsta .00 30
fcntl 4.76 259344
socket .00 1
sigreturn .94 119728
gettimeofday .00 74
sendto .00 1 1
getrlimit .00 4
sigaction .00 45
msgctl .00 2
msgget .00 2
msgrcv .00 3
msgsnd .00 4
shmat .00 2
shmdt .00 2
shmget .00 2
stat .00 1
fstat .00 7
---- --- ---
sys totals: 22.27 1350600 18
usr time: 2.69
elapsed: 126.17
#
# truss -o /var/tmp/AP_DB.log -c AP
. . ====e 等到 AP 執行結束.
# cat /var/tmp/AP_DB.log
signals ------------
SIGCLD 1
total: 1
syscall seconds calls errors
_exit .00 1
fork .00 1
read 15.59 472973
write .62 15256
close .00 45
wait4 .00 1
brk .00 25
lseek 10.07 482961
getpid .00 48
getuid .00 3
pipe .00 1
set_program_ .00 1
open .00 53 13
getgid .00 3
sigprocmask 2.26 119773
ioctl .00 15 3
execve .00 1
getpagesize .00 5
mmap .00 24
madvise .00 3
setitimer .00 32
table .00 12
gethostname .00 1
fcntl 6.76 259356
socket .00 2
sigreturn 2.32 119735
sigstack 2.07 119770
gettimeofday .00 74
hab=OSF/1 sy .00 75 62
sendto .00 2 2
getrlimit .00 6
sigaction .00 91
msgctl .00 2
msgget .00 2
msgrcv .00 3
msgsnd .00 4
uname .00 1
shmat .00 2
shmdt .00 2
shmget .00 2
stat .00 46 6
fstat .00 41
getsysinfo .00 8
rt_rt_getpri .00 1
rt_aio_init .00 1
rt_aio_info .00 1
---- --- ---
sys totals: 39.73 1590465 86
usr time: 3.00
elapsed: 192.19
#
由以上 “truss” 指令追蹤 AP runtime 出現各種 system call 的總次數，以及其所
花費的總時間所產生 LOG觀察發現:
2-2-1) AP的 Runtime 若是包含 DB 時，則系統會有明顯過多的 System call
及CPU花費的時間會明顯變長。所以不含DB時的 Runtime 效率遠較含 DB
的 Runtime 為高。
2-2-2) 大量的read、write、lseek、sigprocmask、fcntl、sigreturn、sigstack
等system call次數，及其所花費的時間總和，足以作為系統和應用程式修改
的參考依據. 非必要的 system call 經由應用程式的修改, 我們相信系統的
執行效能將大大地改進
首先您必定發現執行一應用程式的效能無法為人所接受, 請執行 UNIX 的指令
“vmstat” 確定主要原因在於 CPU 的系統資源, 而不是過少的 Free 記憶體, 或是 Disk I/O “iostat”, 網路 I/O “netstst” 的問題. 至於 CPU 的系統資源的使用又偏重於 system (kernel) mode. 請執行 UNIX 的指令 “collect” 確認沒有過多的IO wait 如下:
# collect –i 5 –sc
Initializing (5.0 seconds) ... done.
#### RECORD 1 (1082365399:0) (Mon Apr 19 17:03:19 2004) ####
# CPU SUMMARY
# USER SYS IDLE WAIT INTR SYSC CS RUNQ AVG5 AVG30 AVG60 FORK VFORK
8 73 19 0 503 54911 4322 4 5.68 6.61 6.32 13.91 0.00
# SINGLE CPU STATISTICS
# CPU USER SYS IDLE WAIT
0 6 70 24 0
1 8 76 16 0
2 8 75 16 0
3 8 72 19 0
#### RECORD 2 (1082365404:0) (Mon Apr 19 17:03:24 2004) ####
# CPU SUMMARY
# USER SYS IDLE WAIT INTR SYSC CS RUNQ AVG5 AVG30 AVG60 FORK VFORK
8 63 29 0 451 67136 3936 3 2.51 3.35 3.53 10.94 0.00
# SINGLE CPU STATISTICS
# CPU USER SYS IDLE WAIT
0 6 57 37 0
1 9 66 25 0
2 8 65 27 0
3 9 63 28 0
同時也沒有過重的 RUNQ 代表待執行的 Processes 過多, 而只有很高量的“System Call”
2-2) 利用“truss”工具來分析過高的 “System Call” 是否正常. 此 “truss” 工具須另行安裝一“SYSTEM V ENVIRONMENT” kit. 如果您有這方面的需求請和 HP 聯繫.
範例: 下列試以同一應用程式的執行,用“truss”來分析其中所呼叫使用的“System Call”的數量和在與 ORACLE 資料庫連結後, 其所呼叫使用的 “System Call” 的數量的變化.
# truss -o /var/tmp/AP_noDB.log -c AP
. ====e 等到 AP 執行結束.
# cat /var/tmp/AP_noDB.log
signals ------------
SIGCLD 1
total: 1
syscall seconds calls errors
_exit .00 1
fork .00 1
read 12.37 472941
write .50 15254
close .00 39
wait4 .00 1
brk .00 14
lseek 3.66 482933
getpid .00 6
getuid .00 3
pipe .00 1
set_program_ .00 1
open .00 44 9
getgid .00 3
sigprocmask .00 2
ioctl .00 15 3
execve .00 1
getpagesize .00 3
pre_F64_stat .00 38 5
mmap .00 12
madvise .00 3
setitimer .00 32
pre_F64_fsta .00 30
fcntl 4.76 259344
socket .00 1
sigreturn .94 119728
gettimeofday .00 74
sendto .00 1 1
getrlimit .00 4
sigaction .00 45
msgctl .00 2
msgget .00 2
msgrcv .00 3
msgsnd .00 4
shmat .00 2
shmdt .00 2
shmget .00 2
stat .00 1
fstat .00 7
---- --- ---
sys totals: 22.27 1350600 18
usr time: 2.69
elapsed: 126.17
#
# truss -o /var/tmp/AP_DB.log -c AP
. . ====e 等到 AP 執行結束.
# cat /var/tmp/AP_DB.log
signals ------------
SIGCLD 1
total: 1
syscall seconds calls errors
_exit .00 1
fork .00 1
read 15.59 472973
write .62 15256
close .00 45
wait4 .00 1
brk .00 25
lseek 10.07 482961
getpid .00 48
getuid .00 3
pipe .00 1
set_program_ .00 1
open .00 53 13
getgid .00 3
sigprocmask 2.26 119773
ioctl .00 15 3
execve .00 1
getpagesize .00 5
mmap .00 24
madvise .00 3
setitimer .00 32
table .00 12
gethostname .00 1
fcntl 6.76 259356
socket .00 2
sigreturn 2.32 119735
sigstack 2.07 119770
gettimeofday .00 74
hab=OSF/1 sy .00 75 62
sendto .00 2 2
getrlimit .00 6
sigaction .00 91
msgctl .00 2
msgget .00 2
msgrcv .00 3
msgsnd .00 4
uname .00 1
shmat .00 2
shmdt .00 2
shmget .00 2
stat .00 46 6
fstat .00 41
getsysinfo .00 8
rt_rt_getpri .00 1
rt_aio_init .00 1
rt_aio_info .00 1
---- --- ---
sys totals: 39.73 1590465 86
usr time: 3.00
elapsed: 192.19
#
由以上 “truss” 指令追蹤 AP runtime 出現各種 system call 的總次數，以及其所
花費的總時間所產生 LOG觀察發現:
2-2-1) AP的 Runtime 若是包含 DB 時，則系統會有明顯過多的 System call
及CPU花費的時間會明顯變長。所以不含DB時的 Runtime 效率遠較含 DB
的 Runtime 為高。
2-2-2) 大量的read、write、lseek、sigprocmask、fcntl、sigreturn、sigstack
等system call次數，及其所花費的時間總和，足以作為系統和應用程式修改
的參考依據. 非必要的 system call 經由應用程式的修改, 我們相信系統的
執行效能將大大地改進
全站熱搜
留言列表
程式語言 (17)
