如何在 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 越來越擁擠，但我該如何衡量呢？

更新

原諒 Intelish 術語。我們基本上在單個刀片上執行兩個 VM，其中一個是應用程序伺服器，另一個提供應用程序的 SSO 支持。我們有時會出現應用程序伺服器顯著變慢的情況，也有時會出現第三方 SSO 應用程序陷入困境的情況。

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

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

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

那是 10 個並行 GC 工作執行緒，通常user >> real >> sys情況下，奇數時間模式的一個原因是您無法獲得足夠 CPU 的 VM。（我們沒有交換，系統都是基於 SSD 的，所以 IO 等待不是問題。）

在這一點上，我需要獲取數據來幫助證明這個理論，在我的 Linux 頭腦中，我只會檢查頂部的 st%。Google搜尋還說在現代版本的 Solaris 中我可以做同樣的事情。我的問題是我們沒有執行現代版本的 Solaris。

您真正的問題似乎是您的性能下降。在 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，以阻止它降低性能。

引用自：https://serverfault.com/questions/903592