字體:小 中 大 | |
|
|
2007/01/24 18:15:05瀏覽2127|回應1|推薦0 | |
首先您必定發現執行一應用程式的效能無法為人所接受, 請執行 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 經由應用程式的修改, 我們相信系統的 執行效能將大大地改進 |
|
( 休閒生活|旅人手札 ) |