☰

如何在 Solaris SunOS 5.10 中存取竊取時間數據

tag-icon • tag-icon performance virtual-machines solaris performance-monitoring
如何在 Solaris SunOS 5.10 中存取竊取時間數據

我認為我們運行的 Solaris 版本太舊，無法在頂部報告竊取時間。有沒有辦法在舊版的 Solaris 上取得此資訊。以下是基本版本資訊：

-bash-3.2$  uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32

我對這些 Sun VM 系統沒有任何真正的專業知識，因此我可能會誤解一些事情，並且在這種情況下可能有更好的方法來完成我需要的操作。應用我的英特爾思維模型，我懷疑我們的 CPU 越來越擁擠，但我該如何衡量呢？

更新

請原諒英特爾的術語。我們基本上在單一刀片上運行兩個虛擬機，其中一個是應用程式伺服器，另一個提供應用程式的 SSO 支援。我們有時會出現應用程式伺服器速度顯著減慢的情況，有時也會出現第三方 SSO 應用程式陷入混亂的情況。

也涉及孤島和政治，因此我無法了解 SSO 主機或實際的硬體層。

我目前的操作假設是，當 SSO 應用程式變得瘋狂時，它會佔用大量 CPU，以至於應用程式伺服器無法獲得足夠的實際計算時間來跟上負載。我分析了應用程式的 GC 日誌，其中突出的一件事是這樣的條目：

[Times: user=0.71 sys=1.36, real=1.47 secs]

通常情況下，這是 10 個並行 GC 工作線程，user >> real >> sys奇怪時間模式的原因之一是虛擬機器無法獲得足夠的 CPU。 （我們不進行交換，系統都是基於 SSD 的，因此 IO 等待不是問題。）

此時我需要取得數據來幫助證明這個理論，在我的 Linux 思維中，我只會檢查頂部的 st%。谷歌搜尋也說在現代版本的 Solaris 中我可以做同樣的事情。我的問題是我們沒有運行現代版本的 Solaris。

答案1

您真正的問題似乎是性能下降。在 Solaris 10 T1000/T2000 伺服器上，竊取時間可能毫無意義。

若要找出您是否在區域中運行，請使用該/usr/bin/zonename命令（不同版本的 Solaris 上的位置可能不同 - 還要檢查/bin、/sbin/和/usr/sbin。）如果zonename返回除 之外的任何內容global，則表示您正在區域中運行。

如果您由於某些原因無法存取該zonename命令，您可以使用多個ps命令來查看您是否位於區域中。首先，尋找init：

ps -ef | grep init

如果沒有找到initPID 為 的進程1，則表示您處於區域。您也可以查找zsched（IIRC）：

ps -ef | grep zsched

如果返回一個進程，該進程是它自己的父進程（PID 和 PPID 相同且大於1），那麼您正在一個區域中運行。

如果您在某個區域中，您可能會遇到資源限制，從而減慢速度。但情況可能並非如此。

什麼別的正在伺服器上運行，但是？包括其他區域。我在 Sun T 系列伺服器上看到非常嚴重的效能問題，與您所描述的類似，這是由 ZFS ARC 和使用大內存頁的應用程式（例如 Oracle 資料庫）之間的交互引起的。

ZFS ARC 使用 4k 記憶體頁，因此它會產生記憶體碎片 - 並且會產生碎片全部伺服器上的記憶體。如果您的伺服器進入該狀態並且進程需要大量大記憶體頁面，則核心必須將一堆小頁面合併為大頁面，這涉及移動大量記憶體。而且這一切都是單線程完成的。早期 T 系列伺服器上的任何單線程都是慢的因為伺服器被設計為處理大量具有大延遲的執行緒 - 例如處理網路上的大量連接的 Web 伺服器或資料庫伺服器。

因此，核心會進入很長一段時間，它所做的幾乎所有事情都是將小記憶體頁面合併成大頁面。

然後，ZFS ARC 在大頁面使用過程完成後取回這些頁面，並且它們會變得碎片化。

我懷疑您可能遇到了完全相同的問題。

要找出答案，請運行

echo ::memstat | mdb -k

如果您正在執行區域，則以 root 身分在全域區域中。如果您的可用記憶體非常低，則可能會遇到此問題。

要找到答案，請再次以全域區域的 root 身分執行以下 dTrace 腳本，以確定核心所有時間都花在哪裡：

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

將其複製到一個文件，例如hot.d，將其設置為可執行文件 ( chmod 755 hot.d) 並從全域區域以 root 身份運行它：

./hot.d

當您遇到速度緩慢時運行它。讓它在發出後運行 10-20 秒（如果不是更長）matched 1 probe，然後用 來中斷它CTRL-C。然後它會發出一個很多輸出，其中大部分是您不關心的。然而，最後少數堆疊追蹤輸出將是最常見的取樣，這將告訴您核心在哪裡花費了所有時間。

這將明確告訴您問題出在哪裡。它可能不夠精確，無法完全解決問題，您可能需要做更多調查，但您會知道該去哪裡尋找。

如果您在其中看到大量堆疊跟踪，idle則wait表示存在用戶空間問題。您可以透過將stack()上面的 dTrace 腳本替換為來ustack()獲取使用者堆疊來識別這一點。

如果您在函數名稱中看到大量堆疊跟踪coalesce，則核心正在花費所有時間創建大記憶體頁面。解決這個問題的方法是釋放內存，最有可能的是透過限制 ZFS ARC 大小，甚至可能嚴格限制。我不得不髕骨一些伺服器上的 ZFS ARC，降至 1 GB 以下，以防止其影響效能。

相關內容