第 18 章：平台優化

此章節主要介紹 SAS 平台如何進行系統優化

基本介紹

首先當在 SAS 9 平台中會有大量平行處理的程式數和不斷成長的資料量，為了確保使用者操作獲得最佳的體驗，則管理員需要確保有足夠的系統資源配置，以利 SAS 9 平台中的網站應用程式能夠正常執行。但若使用者開始抱怨操作變緩慢或經常無法使用時，則我們需要針對 SAS 9 平台進行效能優化時，通常會有一套方法程序可以用來確認不同方面的問題、解決方案、症狀診斷和結果驗證，主要有四個步驟，分別為：

  1. 定義問題：主要針對因為效能不佳導致的抱怨進行文件記錄，並且明確定義效能問題。

  2. 定義目標和解決方案：主要針對明確定義的效能問題，建立一個目標，以及相對應的解決方案。

  3. 診斷效能問題：主要查看 SAS 記錄檔資訊和測量系統效能進行效能問題的症狀診斷。

  4. 診斷結果糾正：主要針對症狀診斷的結果進行驗證和糾正，以利調整系統參數以利優化效能。

接著診斷效能問題我們主要先查看相關記錄檔，以利從中找出根本原因，當然我們也能夠透過 LogConfigSweeper 工具自動將記錄檔和設定檔進行收集，並且還會自動根據不同的服務產生對應的壓縮檔，非常實用且方便，請注意 LogConfigSweeper 工具必須在設定目錄中才能夠正常運作，並且需要指定輸出的記憶檔儲存的目錄路徑。

再來除了查看相關記錄檔之外，我們更能夠透過工作管理員或 PsTools 工具查看相關硬體資源的使用情況，若是發現 CPU、記憶體、磁碟和網路資源皆沒有大量使用時，則建議透過 JConsole 工具和 VisualVM 工具查看網站應用程式使用 JVM 的情況，至於要如何連線至特定的網站應用程式伺服器，則主要能夠透過 JMX 進行連線，預設連線埠能夠在各自的網站應用程式設定檔 catalina.properties 中取得，至於登入的帳號和密碼則能夠在各自的網站應用程式設定檔 jmxremote.password 中取得。此時我們主要能夠觀察 JVM 中堆記憶體的使用情況，判斷是否因為無法正常進行垃圾回收，而導致網站應用程式發生錯誤或緩慢，其實僅要觀察當問題發生時堆記憶體是否一直處於滿載的使用情況。

最後我們就能夠先透過查看記錄檔和資源使用情況初步診斷效能問題，判斷是否能夠直接透過參數調整就能夠提升效能。若是則我們就按照標準流程進行參數的調整，並且當參數調整之後，持續針對診斷結果進行觀察與糾正，直到使用者回饋能夠很順暢的使用為止，就能夠暫時完成階段性的任務，但若是使用者需求不斷增加，則建議透過專業服務針對目前硬體資源進行重新評估，以利下一階段系統效能調整與優化。

SAS 9

系統優化

當我們在使用 SAS 軟體時要如何透過設定進行優化呢？首先我們可以先開啟「SAS 9.4」輸入下述 SAS 程式查詢可以調整的選項。

PROC OPTIONS;
RUN;

其中有幾個選項建議進行調整，以利優化 SAS 系統的整體運作效能。

總結當我們在維運 SAS 系統時，時間久了經常會需要透過參數的調整優化 SAS 系統整體的效能，此時我們就能夠在 SAS 設定資料夾 (D:\SAS\Config\Lev1\SASApp) 中的 sasv9_usermods.cfg 檔案加入上述選項進行效能優化。

網站優化

首先在 SAS 9 平台中的 Middle Tier 環境主要是提供網站應用程式伺服器執行商業分析，我們可以透過 SAS 部署精靈自動化設定 SAS 網站應用程式的叢集環境優化執行效能和提高擴展性，其中效能需求則是由交易反應時間、每秒交易數、輸出量、資源使用率、可用性、…等項目進行優化評估。然而提高擴展性的目標則是提高元件的速度、改善元件處理的效率和降低元件的負載。

接著我們除了透過叢集環境優化執行效能和提高擴展性之外，還能夠透過參數的方式進行優化，主要有五大優化方式，分別為：

  1. 優化 SAS 網站應用程式伺服器。

  2. 優化 SAS 網站應用程式。

  3. 優化 Java 虛擬機器。

  4. 優化作業系統。

  5. 優化 PostgreSQL 資料伺服器。

優化 SAS 網站應用程式伺服器

我們可以透過設定網站應用程式伺服器的參數改善效能，像是我們可以修改「SAS-configuration-directory\Levn\Web\WebAppServer\SASServer1_n\conf\server.xml」中的「maxThreads」參數設定提高執行緒池中的執行緒數，以利被用於處理請求數，建議多個應用程式伺服器皆採用相同參數值，預設值為 300，建議值為 300 ～1024。

優化 SAS 網站應用程式

我們可以透過設定網站應用程式的參數改善效能，像是我們可以修改 Visual Analytics Transport Service 中的「vat.xmlParserPoolSize」參數設定允許 XML 解釋器重複使用以利提高讀取報表時的效能，預設值為 0，建議值為 200。

優化 Java 虛擬機器

我們可以透過設定 Java 虛擬機器的參數改善效能，尤其在於記憶體使用量和垃圾回收循環等機制，目標主要最大化客戶端連線數，像是我們可以修改「SAS-configuration-directory\Levn\Web\WebAppServer\SASServer1_n\conf\wrapper.conf」中的 JVM 相關參數，請參考下表。

優化作業系統

我們可以透過設定作業系統的參數改善效能，像是我們可以修改 Linux 作業系統中 TCP/IP 相關參數。

$ /sbin/sysctl -w net.ipv4.tcp_fin_timeout=30
$ /sbin/sysctl -w net.core.netdev_max_backlog=3000
$ /sbin/sysctl -w net.core.somaxconn=3000
$ /sbin/sysctl -w net.ipv4.tcp_keepalive_intvl=15
$ /sbin/sysctl -w net.ipv4.tcp_keepalive_probes=5

以及修改「/etc/security/limits.conf」相關檔案，請注意不同 Linux 作業系統限制設定檔 (*.conf) 會在不同的位置，像是「/etc/security/limits.d」，以利設定 Linux 作業系統的限制，請參考下表。

優化 PostgreSQL 資料伺服器

我們可以透過設定 PostgreSQL 資料伺服器相關參數，以及優化資料庫綱要設計和存取查詢，以利改善效能。

再來我們更能夠透過 SAS Environment Manager 網站服務進行監控和故障排除，像是觀察每個伺服器死結偵測、記憶體使用量、垃圾回收時間、…等指標參數。

最後當我們在部署 SAS 解決方案時皆會進行設定，其中會需要選擇伺服器大小為「小型系統」、「中型系統」或「大型系統」其差別在於參數值的設定，其中包括 -Xms 、-Xmx 、-XX:PermSize 、 -XX:MaxPermSize 、 MaxPoolSize 、MaxThreads、ThreadsPerChild、TThreadLimit、MaxKeepAliveRequest、… 等參數系統將會根據過去經驗與測驗結果提供適當的參數設定值，請注意若是部署正式環境，則會建議直接選擇「大型系統」避免浪費硬體資源。

總結我們能夠透過不同參數設定的方式優化 SAS 9 平台中網站應用程式伺服器的效能，充份利用硬體資源，達到更佳的使用者體驗。

程式優化

首先 SAS 程式碼提供使用者有許多選擇存取、操作、分析和處理資料與結果，然而系統效能可能會大大影響應用程式的行為，因此我們應該在應用程式開發過程的早期設計階段了解客戶的期望，以利提供更高效能的應用程式。但是往往在專案系統開始上線前導入正式資料時，將會發現應用程式處理的效率和效能需要進行改善，主要可以針對效能統計和系統效能進行改善。所謂效能統計主要是使用於處理 DATA STEP 和 PROC STEP 的總輸入和輸出的操作、記憶體和 CPU 時間測量，我們將能夠透過 SAS 系統選項獲取統計資訊，以利協助我們衡量工作的初始效能，並且確定如何改善效能。所謂系統效能主要是使用於處理 SAS 程式的總輸入和輸出的操作、記憶體和 CPU 時間測量，我們將會重新分配關鍵資源的使用，以利改善系統效能，並且選擇最適合特定情況的技術進行優化，此外我們針對效率和效能的改善的策略，分別為：

  1. 資料儲存

  2. I/O

  3. 記憶體

  4. CPU 時間

  5. 使用時間

其中 CPU 時間和使用時間主要是測量的基準，然而透過遵循準則將能夠有效提升應用程式處理的效率和效能。一般來說，透過簡單的策略將能夠改善多達 90% 的效率，但是最後的 10% 往往將會是個挑戰，此時我們則需要進行判斷，以利確保應用程式達到相對最佳的效率，同時維持時間和成本之間的平衡。

接著我們針對五大改善的策略有哪些關鍵的技術重點呢？針對資料儲存技術主要使用資料壓縮策略，以利降低儲存資料集的儲存空間，以及使用 KEEP 或 DROP 資料集選項保留需要的變數。 針對 I/O 技術主要是考慮使用大量資料集的資料壓縮，以及建立索引資料集，以利改善資料集的存取。針對記憶體技術主要使用在記憶體中執行 DATA STEP 建立雜湊物件，以利透過可用的記憶體和記憶體速度進行改善，以及使用 MEMSIZE 系統選項控制記憶體的使用情況。針對 CPU 技術主要是在 DATA STEP 中使用 IF-THEN/ELSE 或 SELECT-WHEN/OTHERWISE 指令，或者在 PROC SQL 中使用 CASE 條件表達式處理資料，以及使用 SASFILE 敘述式在多個時間處理相同的資料，以利降低 CPU 時間和使用時間。

再來我們若要優化系統效能除了針對資料儲存透過資料壓縮的 COMPRESS 系統選項降低儲存資料集的儲存空間，並且透過 Cleanwork 工具搭配工作排程器定期清理 SAS WORK 暫存資料夾改善效能之外。我們更能夠針對 I/O 、記憶體和 CPU 效能透過系統選項的設定進行優化。

最後我們可以使用 Windows 內建的效能監控工具進行 SAS 程式處理資料時的效能監控，我們僅需要在執行對話框中輸入「perfmon」就能夠開啟效能監控工具。此時效能監控工具將會立即收集並且顯示有關所選計數器的資訊，並且我們能夠監控多個 SAS 程式相關的計數器，主要包括八個與 SAS 程式相關的計數器，分別為：

  1. Virtual Alloc’ed Memory：虛擬記憶體總配置量。

  2. Disk ReadFile Bytes Read Total：讀取硬碟檔案的總位元數。

  3. Disk ReadFile Bytes Read/Sec：每秒讀取硬碟檔案的位元數。

  4. Disk WriteFile Bytes Written Total：寫入硬碟檔案的總位元數。

  5. Disk WriteFile Bytes Written/Sec：每秒寫入硬碟檔案的位元數。

  6. Disk SetFilePointer/Sec：成功使用硬碟檔案的次數。

  7. Memlib/Memcache Current Usage K：指定目前正在使用擴展記憶體數量。

  8. Memlib/Memcache Peak Usage K：指定目前最大使用擴展記憶體數量。

其中每個受監控的實體皆是獨立的 SAS 程序，同時以 PID 編號的方式進行識別，當然我們也能夠透過工作管理員處理所有程序的列表。此外我們還能夠在 Process 計數器中 %Processor Time、%User Time、%Privileged Time、…等 CPU 處理相關測量參數進行報表設定。

總結 SAS 系統效能優化我們能夠從資料儲存、I/O、記憶體、 CPU 時間和使用時間五大策略開始規劃進行 SAS 系統效能優化的改善，同時使用 Windows 內建的效能監控工具進行 SAS 程式處理資料時的系統效能監控，以利找出瓶頸點持續進行效率與效能的改善。

SAS Viya

系統配置

首先 SAS Viya 主要提供可擴展的資料處理步驟和統計程序有效平行處理大量資料，並且透過高效能的硬體架構解決方案來支持可擴展性和大數據模型，以利提高使用者體驗，以及在短時間內提供最大的商業價值，至於 SAS Viya 高效能設定的最佳實務我們主要會修改硬件和網路選項，像是 CPU、記憶體、CAS_Disk_Cache 設定和伺服器之間的網路頻寬，以利我們透過平行處理快速地完成非常長時間執行或高資料量的作業，當減少作業執行時間，將有益於資料管理和建模工作負載。而在 SAS Viya 中平行處理主要可以透過以下幾個方面來實現，分別為：

  1. 根據 I/O、記憶體使用情況和內容優化所有低效率程式碼和任務活動，

  2. 橫向擴展硬體基礎架構，以利支援平行負載和處理任務集的即時資源需求。

  3. 透過適當硬體規模調整、規劃和設定，以利支援應用程式工作負載的績效目標。

接著根據 I/O、記憶體使用情況和內容優化所有低效率程式碼和任務活動，有許多使用 SAS 9 的客戶所撰寫的 SAS 程式碼我們除了可以透過調整程式碼獲得更高效能的資料處理之外，更能夠 CAS 橫向擴展作業架構進行高效能的處理工作任務規模。此外在 SAS 中處理資料的效率主要與將被提升至記憶體中的資料進行排序和分析處理有關，若是 SAS 9 使用者則會認為執行此操作的最佳方法是使用 PROC SORT，但是在 SAS Viya 中我們使用DATA STEP 程式碼和 BY GROUP 處理來取代 PROC SORT，主要原因有兩個，分別為：

  1. 記憶體速度：SAS Viya 主要執行記憶體中的程序，其需要保持在記憶體中才能正常執行，而 PROC SORT 是使用 SAS 9 中的記憶體，因此我們將其替換為 SAS Viya 中的DATA STEP 程式碼，以利透過更少的記憶體更有效的執行任務。

  2. 平行工作負載管理：DATA STEP 程式碼主要可以利用 CAS 中的高度並行處理資源 (Parallel DATA STEP)，其可以將資料進行劃分，並且發送到大量擴展的伺服器，並且同時在許多伺服器的記憶體中進行處理，這大大減少了整個工作負載時間，僅佔原始任務執行時間的一小部分。

此時我們透過適當硬體規模調整、規劃和設定，以利支援應用程式工作負載的績效目標，我們主要針對工作負載進行規劃，SAS Viya CAS 和 SAS 9 在操作和效能方面有很大差異，對於大小調整和設定，需要考慮常見的工作負載關鍵因素，分別為：

  1. 資料擷取的類型是序列或平行，以及 SMP 架構或 MPP 架構。

  2. 混合作業類型所需的 I/O 、CPU 和記憶體，以及平行處理的作業數量。

  3. 期望執行的時間或解決方案的時間，工作負載資源管理資源限制和優先順序。

深入了解上述關鍵因素，以利協助調整 CPU 核心數、記憶體大小和速度、網路頻寬和速度、儲存容量和輸出量以及主機系統或應用程式的工作負載限制等系統管理資源 (cgroup、ulimit、…) 的要求。請注意 CAS是一種記憶體處理系統，我們主要透過 CAS 在記憶體中以高記憶體的速度進行資料處理，替換記憶體對應，以利透過傳統文件系統從磁盤向磁盤進行較慢的硬分頁，記憶體大小和效能非常重要，透過並行處理 CAS 作業和提高記憶體處理速度將有助於縮短解決方案的時間，此外由於許多工作任務是並行啟動的，因此需要大量資源來滿足瞬間負載的需求。

再來在 MPP 架構中我們可能會被分配 CAS 主節點、CAS 工作節點和微服務節點，而微服務啟動時將會需要初始化 60 GB 的記憶體，若我們嘗試將 CAS 微服務與另一個節點相結合，此時我們必須提供足夠的CPU 、記憶體、網路和 I/O 等要求。其中 CAS 授權的最小 CPU 核心數為 4 個核心，並且強烈建議啟用 Hyper-threading。而記憶體建議為傳入文件大小的 2-3 倍以上，以及建議使用最低記憶體速度為 1600 MHz。而網路主要涉及讀入的非常大的資料來源和結果集，建議 SMP 架構提供每個主機核心數至少每秒 100 MB 的網路頻寬，而 MPP 架構建議每個 CAS 伺服器節點使用多個 10 Gbit 最小適配器來實現所需的頻寬，像是若在 CAS Worker 節點中使用 16 個核心數，則通常需要的最小帶寬為每個核心至少每秒 100 MB 的網路頻寬，或著每個節點的總頻寬為 1.6 GB 的網路頻寬。

最後我們針對資料傳輸的 I/O 主要探討載入到 MPP CAS 的序列資料，CAS Controller 將會對本地磁碟上的傳入資料，當所有資料皆傳入完成之後，CAS Controller 就會將資料分發給 CAS Workers，也適用於將數據儲存回雲端提供商，像是 Amazon S3，此時所有 CAS 伺服器節點的臨時暫存該資料的本地磁碟位置建議 I/O 頻寬為每秒 100 - 150 MB。此外當我們發生資料超過記憶體空間時，CAS 則會使用記憶體對應的檔案系統 (CAS_Disk_Cache) 為後續記憶體資料的存儲提供額外的空間。所謂記憶體對應的檔案系統主要是將虛擬記憶體對應至另一個資料來源，像是 HDD、SSD 或 NVMe 儲存設備，而 CAS_Disk_Cache 會指定記憶體對應的檔案系統，其主要是​​一個儲存記憶體可存取 CAS 資料區塊的位置，或由 CAS 處理需要後續儲存或複制副本，其資料區塊預設大小為16MB，我們能夠增加至 512 MB，以利更高效地操作非常大的文件檔案，以及建議 CAS_Disk_Cache 的大小至少為 CAS 節點中記憶體大小的 1.5 - 3 倍。

儲存配置

首先當我們在部署 SAS Viya 平台時除了規劃適當的 CPU 和記憶體之外，規劃適當的硬碟空間和效能配置也是非常重要，但是往往我們會忽略這部份的規劃，特別是當我們需要透過容器部署 SAS Viya 平台時，為了方便後續維運管理我們就需要了解在 SAS Viya 平台中目錄用途和相關路徑。一開始我們必須了解部署 SAS Viya 至少需要 48 GB 的硬碟空間可用於安裝，安裝檔案會自動下載到「/var/cache/yum」目錄中，接著每台目標伺服器的「/opt」部署目錄，至少需要 50 GB 的硬碟空間，而若要增加可用的硬碟空間，則建議增加「/opt/sas 」目錄的硬碟空間，而不是「/opt/sas」子目錄的磁碟空間。此外若是硬碟空間有限，則建議從日誌記錄檔目錄建立連接至足夠可用硬碟空間的分區，像是我們能夠建立從日誌記錄檔的目錄「/var/log/sas/viya」至具有額外可用硬碟空間的目錄連接，其目錄預設連接為「/var/log/sas/viya」->「../../../opt/sas/viya/config/var/log/sas/」，並且會從 SAS Viya 平台中的所有服務擷取所有日誌記錄的活動，以利用於管理 CAS 伺服器的硬體資源，所以 SAS Viya 平台營運一段時間之後，若我們沒有針對日誌記錄檔目錄進行 House Keeping 將會造成空間不足，發生 SAS Viya 平台中服務異常的問題。

接著當 CAS 伺服器在處理大小超過可用記憶體時會自動在硬碟上的 CAS_DISK_CACHE 暫存目錄中，預設為「/tmp」，以及若有使用 Model Studio 則請考慮在「/opt /sas/viya/config/data/cas/default/projects」專案目錄中分配額外儲存專案的硬碟空間，當執行專案中第一個資料節點時，Model Studio 將會複製資料來源，因此專案所需的空間量取決於已儲存專案的數量和資料來源的大小，所以為了讓專案執行最佳效能，請在高效能的儲存設備上建立暫存目錄和專案目錄。至於 CASLIB 則是一個記憶體空間，其主要讓 CAS 伺服器能夠存取資料表，存取控制資料表和資料來源資訊，所有資料皆能夠透過 CASLIB 用於 CAS 伺服器，並且使用資料進行存取操作，此外 CASLIBS 需要額外的持久儲存，當我們增加或編輯 CASLIB 定義時，可以提供具有其它儲存空間的其它位置的儲存路徑，以利進行持久儲存能夠讓我們進行備份和恢復，尤其當報表讀取不到記憶體中的資料時將會自動將持久儲存的資料檔提升至記憶體中的資料表，以利正常呈現報表內容，請注意每個 CAS 使用者皆有一個名為 CASUSER 的個人 CASLIB ，而預設則是寫入使用者的個人目錄，此時需要多大的空間，則取決於個別使用者的需求。。

再來我們主要能夠從四大方面來規劃 SAS Viya 平台硬碟空間和效能配置，分別為：

  1. 大小：哪些檔案會快速成長，像是記錄檔、資料庫內容、暫存空間、快取空間、… 等。

  2. 效能：哪些檔案需要更好的效能，像是實際資料檔、暫存空間、快取空間、… 等。

  3. 保留：哪些檔案需要被保留，像是設定內容、資料內容、… 等。

  4. 共享：哪些檔案需要被共享，像是實際資料檔、備份內容、… 等。

(註：Shared Vault 備份路徑必須設定為共享目錄，否則會發生備份檔合併的問題，造成無法正常還原 SAS Viya 平台中的備份內容。)

再來我們能夠透過 SAS Viya 平台中的 SAS Report Viewer 檢視報表開啟「SAS 內容」->「Products」->「SAS Environment Manager」->「Dashboard Items」->「Disk Space」硬碟空間報表提供有關硬碟空間使用情況的詳細資訊，除了視覺化的圖表呈現過去 24 小時內硬碟空間使用情況之外，更有提供 48 小時內硬碟空間使用情況的預測分析應用。此外當我們發現 SAS Viya 平台中服務開始發生異常時，則建議先透過「df -h」指令確認 SAS Viya 平台相關伺服器中的硬碟空間是否足夠，若是發現「/opt/sas」目錄所在的硬碟空間不足夠時，則我們僅需要先停止 SAS Viya 平台的所有服務，清理 SAS Viya 平台相關日誌記錄檔的硬碟空間之後，並且重新啟動 SAS Viya 平台的所有服務，通常就能夠解決 SAS Viya 平台中服務異常的問題。

報表優化

首先 SAS 官方網站所提供的 SAS Viya 管理任務清單中建議每週需要監控每個使用者的工作負載的效能，並且嘗試優化最長的執行時間流程，針對這項目建議我們主要能夠在 SAS Environment Manager 中查看相關報表，像是應用程序活動報表、伺服器活動報表和其它活動報表，以利要尋找最近過去繁重工作量的跡象，以及尋找需要很長時間才能執行的報表。

接著我們需要考慮資料模型的設計、資料儲存的位置，資料傳送的效能，此時我們需要思考更多資料預處理的前置步驟，像是資料先匯整完成之後再進行傳送至 CAS 伺服器。而當資料匯整完成之後傳送至 CAS 伺服器，下一步就要查找需要很長時間才能打開的報表，此時可以查看有關每個報表在 SAS Visual Analytics 中打開所需時間的診斷資訊，我們主要在 SAS Visual Analytics Designer 中按下「Ctrl + Alt + q」使用查詢診斷工具進行報表開啟查詢診斷分析，此外按下「Ctrl + Alt + p」使用報表診斷工具查看效能摘要分析，請注意 SAS Report Viewer 中不提供這診斷工具，以及若是 SAS 應用程式或解決方案使用 SQL 查詢處理傳送到資料庫中，則應該使用資料庫管理員工具查看資料查詢效能。

再來 SAS Visual Analytics 可以針對在單一報表中物件顯示的資料量進行限制，這些限制主要在於提高效能，並且最大限度地降低網頁瀏覽器或報表資料服務崩潰的風險。若超出這些限制，報表物件的行為會有所不同，此時查詢診斷工具中若沒有產生相關日誌時，則我們應該將報表資料服務的 com.sas.bidata 元件進行啟用，報表資料服務的日誌將包含列出屬性和預期限制，它還將包含可能提供問題所在位置的其他錯誤，像是若出現「com.sas.cas.CASException: The analytic server action stopped because the number of elements in the result set exceeds the specified limit (50000)」的異常狀況訊息，則此異常代表已經超出 MaxRowsLookup 屬性值或 categoryCardinalityServerLimit 屬性值，此時我們就能夠嘗試調大 MaxRowsLookup 屬性值或 categoryCardinalityServerLimit 屬性值解決異常問題，至於若要啟用詳細的日誌內容，請執行以下步驟：

  1. 以管理員身份登錄「SAS Environment Manager」網站界面 。

  2. 點選「設定」->「所有服務」->「Report Data Service」。

  3. 編輯「logging.level」->「com.sas.bidata」將等級別設定為「DEBUG」。

  4. 按下「儲存」鈕進行儲存。

  5. 等待 30 秒讓設定值生效。

最後具有複雜過濾器，多個資料來源，每頁多個物件以及復雜計算的更複雜報表皆會需要更長時間才能正常顯示，因此在設計報告時需要特別注意這一點。此外報表中不同物件也會有不同的高基數臨界值設定，像是交叉資料表預設若伺服器傳回超過 40,000 列，則顯示錯誤訊息，以及我們也可以使用覆寫系統資料限制選項來指定物件的不同系統資料限制。

開始使用

mkdir /backup
chmod 777 /backup
Previous第 17 章：平台部署Next第 19 章：工作流程

Last updated