程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SyBase數據庫 >> SyBase綜合文章 >> sybase性能調優

sybase性能調優

編輯:SyBase綜合文章
  問題:Sybase數據庫運行一段時間後,系統運行很慢? 可以isql登錄ASE 執行
select @@version
go
查看數據庫版本。如果你使用的是ASE12.0,建議使用ASE12.5以上版本,因為自從Sybase在數據庫市場被Oracle反超後,Sybase推新產品的速度非常快,ASE12.5算是比較可靠的產品。在使用上,ASE12.5也比較方便,尤其對高速內存的配置可以動態實現,不需要重新啟動數據庫。這對企業級用戶來說比較有利。ASE對資源的使用設計的比較精簡,浪費的資源很少。在安裝完ASE後其中的所有參數default 是比較低的,不能滿足企業級用戶的需要,做做demo還行。第一步,你必須要根據數據量和用戶數,還有應用的特點對ASE的參數做出合理的調整。通常的做法是:
max memory = physical memory * 70-80%
default data cache = max memory * 50%
procedure cache size = max memory * 20-30%number of user connections = n (default = 25)
number of lock = n * 單個用戶所需的最大鎖數 * 120%
(一般這個比較難估計,syabse的資深工程師給我的參考值:有用戶配到180萬,對於你的10G的數據量我估計先配 100000)
number of open objects = 10000
number of open indexed = 10000這樣的配置基本能正常使用了,具體怎麼配置可以到Sybase官方網站下載手冊,英文好的看洋文,也有中文的。然後,如果發現性能不如你預期的好,就需要發揮你的DBA才能來調優了。對於調優,我也沒有獨門秘笈,這裡需要運用的知識較多,這次就不細說了。
ASE提供有一些工具可以幫助你找到影響性能的瓶頸:
用法很簡單:
sp_sysmon "00:03:00"
這會顯示3分鐘內所有的計數信息,有四大類 18 項。
其中第一項'kernel'信息,顯示這段時間內cpu的使用率,io的繁忙度。這很有幫助。我再費點口舌:以後sp_configure的輸出信息不需要發出來了,沒什麼大用。給sp_sysmon信息就行了。提醒一下:對數據庫的大小安排,tempdb大小,log的大小分配都可以通過利用並行io提高ASE性能。
給的通常的公式:
數據庫大小=DB
tempdb = DB * 20% (經驗值)
log size = DB * 20% sp_sysmon詳解本篇文章采摘自時代朝陽數據庫(原曉通數據庫)培訓部 Sybase 技術資料庫。

本篇文章描述了通過sp_sysmon對Adaptive Server系統運行情況有一個全面系統了解,有利於更好地熟悉系統性能,更為有效地進行系統管理,合理地利用和配置系統資源,達到系統性能調優的目的。

sp_sysmon可以從18個方面了解在用系統性能狀況,並在適當的時候利用環境參數進行性能調優:

1、內核管理(kernal)     2、應用管理(appmgmt)     3、數據緩存管理(dcache)

4、ESP管理(esp)          5、索引管理(indexmgmt)     6、鎖管理(locks)

7、內存管理(memory)     8、元數據高速緩存管理(mdcache)9、任務管理(taskmgmt)

10、監視器訪問SQL的執行(monAccess)     11、網絡I/O管理(netio)

12、並行查詢管理(parallel)13、過程緩存管理(pcache)14、恢復管理(recovery)

15、事務管理(xactmgmt)16、事務概要(xactsum)     17、磁盤I/O管理(diskio)

18、工作進程管理(wpm)

括號後英文短詞是該模塊參數。

環境: 1、用戶數據庫中有練習所用數據表auths和article

2、數據表各有10萬行數據

3、用戶具有查詢、修改、刪除等基本的數據庫表操作權限

步驟:執行sp_sysmon “00:10:00”(server級系統存貯過程,不需要打開某個數據庫),或者執行如下格式的過程,查看具體操作批命令對應系統性能情況:

sp_sysmon begin_sample

SQL語句或者存貯過程

sp_sysmon commit_sample

本實驗采用 sp_sysmon “hh:mm:ss”,性能模塊名。

通過sp_sysmon,可了`解當前系統在各方面的系統運行狀況,性能出現什麼問題和不平衡不協調之處,學會使用相應的參數和措施進行解決和調優,不斷比較對照調整前後的性能狀況,最終改善系統性能。

說明:1、該命令執行結果集的開頭相同如下,各分塊實驗不再一一列示:

======================================================================

      Sybase Adaptive Server Enterprise System Performance Report

======================================================================

Server Version:        Adaptive Server Enterprise/11.9.2/1031/P/NT (IX86)/OS 3.

Server Name:           Server is Unnamed

Run Date:              May 28, 2001

Statistics Cleared at: 15:57:27

Statistics Sampled at: 16:07:28

Sample Interval:       00:10:00

2、執行結果集的每列信息提示:

      per sec :       采樣期間每秒的平均值

      per xact: 采樣期間每提交一個事務的平均值

      count   :       采樣期間每秒的總計值

% of total:       占總數的百分比,根據不同情況各有不同

3、結果集對應給出性能情況描述、分析以及可調性說明

4、本練習只給出部分模塊的監視結果(可能有刪節),用sp_sysmon “hh:mm:ss”可看全部詳細情況。

單元一:監視內核利用情況

命令行:sp_sysmon “00:10:00”,kernal

結果:

Kernel Utilization      (內核利用)

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

  Engine Busy Utilization

Engine 0                        1.8 %

    引擎繁忙程度應在80%-90%之間,如果長期在90%以上,應考慮增加引擎數來改善性能。因為此時內部管理進程無法向磁盤寫入,則檢查點需要將許多頁寫回磁盤,而檢查點進程很可能將CPU的利用率提高到100%,導致響應時間明顯增加。

  CPU YIElds by Engine            per sec      per xact       count  % of total

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

Engine 0                          6.6           0.6        3949     100.0 %

  引擎放棄CPU次數:% of total=1個引擎放棄次數/所有引擎放棄次數,如果顯示引擎利用率較低,可通過放棄數判斷是否真實反映引擎的停止情況。增加“runnable process search count”(引擎放棄CPU給OS之前一個引擎循環查找可執行任務的次數)參數可增加CPU的駐留時間,而如果想減少引擎在空閒時檢查I/O的時間,可減少該參數的值。

  Network Checks

Total Network I/O Checks          0.0           0.0           0       n/a  

引擎發送或接收網絡包的次數。引擎空閒時頻繁檢查網絡包,如果該值很低而“CPU YIElds by Engine”的值高,表明引擎可能被頻繁放棄。

可能包括阻塞和非阻塞兩種檢查方式。非阻塞方式不管有無I/O等待都對網絡進行I/O檢查。如果引擎已被放棄並正執行阻塞網絡檢查,則在網絡包到達以後仍保持一段睡眠時間(潛伏期)。此時增加“runnable process search count”(缺省2000)參數可減少潛伏期,保持引擎有較長的循環檢查時間,而不是過早被放棄。

  Disk I/O Checks磁盤I/O檢查情況:

    Total Disk I/O Checks           693.2          58.8      415939       n/a  

Checks Returning I/O            469.9          39.9      281921      67.8 %

引擎對I/O情況的有效檢查(I/O完成次數),如過高或過低,用“i/o polling process count”(Server的調度程序在檢查磁盤I/O或網絡I/O之前可執行的最大進程數)參數增加或減少檢查頻率。通常說增加該值可增加有大量磁盤或網絡I/O的應用的吞吐量,反之,減少該值有可改善其響應時間。

Avg Disk I/Os Returned            n/a           n/a     0.03020       n/a  

 增加引擎在檢查期間的等待時間可改善吞吐量,因為減少引擎檢查I/O時間相應增加執行進程的時間。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved