你真的了解系統(tǒng)平均負載嗎贞岭？
通常我們利用uptime或top分析系統(tǒng)平均負載情況，那如何通過該值分析系統(tǒng)繁忙程度鄙才？
Linux的平均負載不僅追蹤可運行的任務赏迟，還追蹤處于不可中斷睡眠狀態(tài)的任務。
Linux平均負載是"系統(tǒng)平均負載"，它顯示系統(tǒng)上運行的線程(任務)需求血当，即運行線程的平均數(shù)量加上等待線程。（非CPU平均負載）
大多數(shù)工具顯示了平均負載三個平均值，分別為1分鐘臊旭、5分鐘和15分鐘:
$ uptime
16:48:24 up 4:11, 1 user, load average: 25.25, 23.40, 23.46
top - 16:48:42 up 4:12, 1 user, load average: 25.25, 23.14, 23.37
$ cat /proc/loadavg
25.72 23.19 23.35 42/3411 43603
關于平均負載數(shù)值的一些解釋:
- 如果平均值是0.0落恼，說明系統(tǒng)處于空閑狀態(tài)
- 如果1分鐘的平均值高于5或15分鐘的平均值，那么負載處于降低狀態(tài)
- 如果1分鐘的平均值低于5或15分鐘的平均值离熏，那么負載處于升高狀態(tài)
- 當平均值高于系統(tǒng)的CPU計數(shù)佳谦，那么系統(tǒng)可能會遇到性能問題
通過上面的解釋，我們了解到：通過系統(tǒng)1分鐘滋戳、5分鐘和15分鐘的平均負載值钻蔑，可以分析出系統(tǒng)繁忙程度及趨勢。
將平均負載值與系統(tǒng)CPU核數(shù)相比較奸鸯，可以判斷出系統(tǒng)是否存在性能問題咪笑。
歷史回溯
起初平均負載只顯示CPU需求: 運行的進程數(shù)加上等待運行的進程數(shù)。
在1973年8月RFC 546 的《TENEX平均負載》中有一個很好的描述:
TENEX平均負載是衡量CPU需求的一個指標娄涩。平均負載是給定時間段內(nèi)可運行進程數(shù)量的平均值窗怒。
例如，每小時平均負載為10意味著(對于單個CPU系統(tǒng))在這一小時內(nèi)的任何時候蓄拣，都可能看到1個進程在運行扬虚，另外9個進程準備運行(即，沒有阻塞I/O)等待CPU球恤。
下面是一張1973年7月手工繪制的TENEX平均負載圖表的PDF掃描
舊操作系統(tǒng)的源代碼也可以在網(wǎng)上找到孔轴。下面內(nèi)容是TENEX(20世紀70年代早期)SCHED.DEC宏匯編的摘要:
NRJAVS==3 ;NUMBER OF LOAD AVERAGES WE MAINTAIN
GS RJAV,NRJAVS ;EXPONENTIAL AVERAGES OF NUMBER OF ACTIVE PROCESSES
[...]
;UPDATE RUNNABLE JOB AVERAGES
DORJAV: MOVEI 2,^D5000
MOVEM 2,RJATIM ;SET TIME OF NEXT UPDATE
MOVE 4,RJTSUM ;CURRENT INTEGRAL OF NBPROC+NGPROC
SUBM 4,RJAVS1 ;DIFFERENCE FROM LAST UPDATE
EXCH 4,RJAVS1
FSC 4,233 ;FLOAT IT
FDVR 4,[5000.0] ;AVERAGE OVER LAST 5000 MS
[...]
;TABLE OF EXP(-T/C) FOR T = 5 SEC.
EXPFF: EXP 0.920043902 ;C = 1 MIN
EXP 0.983471344 ;C = 5 MIN
EXP 0.994459811 ;C = 15 MIN
下面內(nèi)容摘自現(xiàn)代Linux(include/linux/sched/loadavg.h):
#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */
#define EXP_5 2014 /* 1/exp(5sec/5min) */
#define EXP_15 2037 /* 1/exp(5sec/15min) */
Linux依舊硬編碼了平均負載1分鐘、5分鐘和15分鐘常量碎捺。
在舊系統(tǒng)中也有類似的平均負載指標路鹰，包括Multics，它具有指數(shù)級調(diào)度隊列平均值收厨。
平均負載的三個數(shù)字
這三個數(shù)字分別是系統(tǒng)過去1晋柱、5和15分鐘的平均負載。但它們并不是平均值诵叁，也不是1分鐘雁竞、5分鐘或15分鐘。
從上面的資料中可以看出拧额，1碑诉、5和15分鐘是函數(shù)中使用的常數(shù)，用于計算5秒平均值的指數(shù)阻尼移動侥锦。得到的1进栽、5和15分鐘的平均負載實際遠遠超過1、5和15分鐘的負載恭垦。
如果您使用一個空閑的系統(tǒng)快毛，然后開啟一個單線程cpu綁定的工作負載(循環(huán)中有一個線程)格嗅， 那么60秒后一分鐘的平均負載是多少?
如果它是一個普通的平均值，它應該是1.0唠帝。
下面為實驗的圖表:
所謂的"一分鐘平均值"在一分鐘的時候只能達到0.62左右屯掖。
關于這個等式和類似實驗的更多信息，Neil Gunther博士寫了一篇關于平均負載的文章:How It Works襟衰，另外在loadavg.c中有許多Linux源代碼塊注釋贴铜。
Linux TASK_UNINTERRUPTIBLE
當平均負載第一次出現(xiàn)在Linux中時，與其他操作系統(tǒng)一樣它們反映了系統(tǒng)對CPU實際需求瀑晒。
隨著Linux的發(fā)展绍坝，平均負載不僅包括可運行的任務，還包括不可中斷狀態(tài)的任務(TASK_UNINTERRUPTIBLE或nr_uninterruptible)瑰妄。
不可中斷狀態(tài)由代碼路徑使用陷嘴，以避免信號的中斷映砖，其中包括在磁盤I/O和一些鎖上阻塞的任務间坐。
您以前可能見過這種狀態(tài): 它在輸出ps和top中顯示為D狀態(tài)。ps(1)手冊頁稱其為不間斷睡眠(通常為IO)邑退。
添加不可中斷狀態(tài)意味著Linux平均負載可能會由于磁盤(或NFS) I/O工作負載而增加竹宋，而不僅僅是CPU需求。
對于熟悉其他操作系統(tǒng)及其平均CPU負載的人來說地技，添加這種狀態(tài)一開始會讓人感到非常困惑蜈七。
那么Linux為什么要這么做呢？
很多關于平均負載的文章都指出了Linux nr_uninterruptible問題莫矗，
但卻沒有任何文章中解釋或猜測為什么Linux nr_uninterruptible會被包括在內(nèi)飒硅。
或許系統(tǒng)平均負載反映更廣泛意義上的需求，而不僅僅是CPU需求作谚。
“不可中斷”的起源
下面為oldlinux.org上的一個1993年的壓縮郵件文件內(nèi)容三娩，
郵件中闡述了系統(tǒng)平均負載應該包含不可中斷任務的必要性：
From: Matthias Urlichs <urlichs@smurf.sub.org>
Subject: Load average broken ?
Date: Fri, 29 Oct 1993 11:37:23 +0200
The kernel only counts "runnable" processes when computing the load average.
I don't like that; the problem is that processes which are swapping or
waiting on "fast", i.e. noninterruptible, I/O, also consume resources.
It seems somewhat nonintuitive that the load average goes down when you
replace your fast swap disk with a slow swap disk...
Anyway, the following patch seems to make the load average much more
consistent WRT the subjective speed of the system. And, most important, the
load is still zero when nobody is doing anything. ;-)
--- kernel/sched.c.orig Fri Oct 29 10:31:11 1993
+++ kernel/sched.c Fri Oct 29 10:32:51 1993
@@ -414,7 +414,9 @@
unsigned long nr = 0;
for(p = &LAST_TASK; p > &FIRST_TASK; --p)
- if (*p && (*p)->state == TASK_RUNNING)
+ if (*p && ((*p)->state == TASK_RUNNING) ||
+ (*p)->state == TASK_UNINTERRUPTIBLE) ||
+ (*p)->state == TASK_SWAPPING))
nr += FIXED_1;
return nr;
}
--
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.sub.org
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
這證實了平均負載是故意更改的，以反映對其他系統(tǒng)資源的需求妹懒，而不僅僅是cpu雀监。Linux從"平均CPU負載"變成了"平均系統(tǒng)負載"。
郵件提及的使用較慢交換磁盤的例子是有意義的: 隨著系統(tǒng)性能的降低眨唬，系統(tǒng)的負載需求(以運行+排隊的方式測量)應該會增加会前。
但是，平均負載下降了匾竿，因為它們只跟蹤CPU運行狀態(tài)瓦宜，而不跟蹤交換狀態(tài)。馬提亞斯認為這是不直觀的岭妖，事實也是如此歉提，所以他修正了它笛坦。
現(xiàn)如今的“不可中斷”
但是Linux的平均負載有時不是太高了嗎，超過了磁盤I/O所能解釋的范圍?
是的苔巨，在Linux 0.99.14中版扩，有13個代碼路徑直接設置TASK_UNINTERRUPTIBLE或TASK_SWAPPING(交換狀態(tài)后來從Linux中刪除)。
現(xiàn)在侄泽，在Linux 4.12中礁芦，有將近400個代碼路徑設置TASK_UNINTERRUPTIBLE，包括一些鎖原語悼尾。
原文作者給上文提到的馬提亞斯發(fā)了郵件柿扣，問他如何看待20多年后平均負載的變化。馬提亞斯回復道:
平均負載的意義是從人的角度得出一個與系統(tǒng)繁忙程度相關的數(shù)字闺魏。
TASK_UNINTERRUPTIBLE意味著(或曾經(jīng)意味著?)進程正在等待類似磁盤讀取的操作未状，這會增加系統(tǒng)負載。
大量使用磁盤的系統(tǒng)可能非常緩慢析桥，但TASK_RUNNING的平均值只有0.1司草，這對任何人都沒有幫助
所以馬提亞斯仍然認為它是有意義的，至少考慮到TASK_UNINTERRUPTIBLE過去的含義泡仗。
不間斷測量任務
下面是一個生產(chǎn)機的Off-CPU火焰圖埋虹，跨度為60秒，只顯示內(nèi)核堆棧娩怎，過濾后只包括處于TASK_UNINTERRUPTIBLE狀態(tài)(即下圖內(nèi)容)的內(nèi)核堆棧搔课。
它提供了許多不可中斷代碼路徑的例子:
[圖片上傳失敗...(image-e2c4d0-1657865246125)]
如果您之前不了解off-CPU火焰圖:
您可以單擊幀來放大，查看顯示為一個幀塔的完整堆棧截亦。x軸大小與off-CPU阻塞所花費的時間成正比爬泥，排序順序(從左到右)沒有實際意義。
非cpu棧的顏色是藍色(我對cpu棧使用暖色)崩瓤，飽和度有隨機方差來區(qū)分幀袍啡。
火焰圖通過bcc 生成（需要Linux 4.8+ 內(nèi)核eBPF特性支持）
$ ./bcc/tools/offcputime.py -K --state 2 -f 60 > out.stacks
$ awk '{ print $1, $2 / 1000 }' out.stacks | ./FlameGraph/flamegraph.pl --color=io --countname=ms > out.offcpu.svgb>
從上面的火焰圖可以看出: 60秒中只有926毫秒處于不可中斷睡眠狀態(tài)。這只會讓我們的平均負載增加0.015谷遂。
在一些cgroup路徑上是時間葬馋，但是這個服務器沒有做太多的磁盤I/O。
下面是跨度為10秒的Off-CPU火焰圖：
[圖片上傳失敗...(image-cfa3ea-1657865246125)]
右邊的寬塔在proc_pid_cmdline_read()(讀取/proc/PID/cmdline)中顯示systemd-journal肾扰，被阻塞畴嘶，平均負載為0.07。
左側(cè)還有一個更寬的頁面錯誤塔集晚，它也以rwsem_down_read_failed()結(jié)束(平均負載0.23)窗悯。
下面是rwsem_down_read_failed()的摘錄:
/* wait to be given the lock */
while (true) {
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (!waiter.task)
break;
schedule();
}
這是獲取使用TASK_UNINTERRUPTIBLE鎖代碼。
Linux有不可中斷和可中斷版本的互斥鎖獲取函數(shù)(例如偷拔，mutex_lock() vs mutex_lock_interruptible()蒋院，以及用于信號量的down()和down_interruptible())亏钩。
可中斷版本允許任務被一個信號中斷，然后在獲得鎖之前被喚醒處理它欺旧。不可中斷鎖睡眠中的時間通常不會對平均負載增加太多姑丑，但在本例中增加了0.30。
如果這個值較高就需要進行分析辞友，分析如何減少鎖爭用(例如上面的：systemd-journal和proc_pid_cmdline_read())栅哀，這將可能提高系統(tǒng)性能并降低平均負載。
將這些代碼路徑包含在平均負載中有意義嗎? 我覺得是有意義的称龙。
那些正在工作的線程碰巧阻塞在一個鎖上留拾。
Those threads are in the middle of doing work, and happen to block on a lock. They aren't idle. They are demand on the system, albeit for software resources rather than hardware resources.
分解Linux平均負載
能否將Linux負載平均值完全分解為組件? 下面是一個示例:
在一個空閑的8核CPU系統(tǒng)上，啟動tar來歸檔一些未緩存的文件鲫尊。該操作會花費幾分鐘的時間痴柔，主要是在讀取磁盤時被阻塞。以下是來自三個不同終端窗口的統(tǒng)計數(shù)據(jù):
- 窗口-
terma
terma$ pidstat -p `pgrep -x tar` 60
Linux 4.9.0-rc5-virtual (bgregg-xenial-bpf-i-0b7296777a2585be1) 08/01/2017 _x86_64_ (8 CPU)
10:15:51 PM UID PID %usr %system %guest %CPU CPU Command
10:16:51 PM 0 18468 2.85 29.77 0.00 32.62 3 tar
- 窗口-
termb
termb$ iostat -x 60
[...]
avg-cpu: %user %nice %system %iowait %steal %idle
0.54 0.00 4.03 8.24 0.09 87.10
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvdap1 0.00 0.05 30.83 0.18 638.33 0.93 41.22 0.06 1.84 1.83 3.64 0.39 1.21
xvdb 958.18 1333.83 2045.30 499.38 60965.27 63721.67 98.00 3.97 1.56 0.31 6.67 0.24 60.47
xvdc 957.63 1333.78 2054.55 499.38 61018.87 63722.13 97.69 4.21 1.65 0.33 7.08 0.24 61.65
md0 0.00 0.00 4383.73 1991.63 121984.13 127443.80 78.25 0.00 0.00 0.00 0.00 0.00 0.00
- 窗口-
termc
termc$ uptime
22:15:50 up 154 days, 23:20, 5 users, load average: 1.25, 1.19, 1.05
[...]
termc$ uptime
22:17:14 up 154 days, 23:21, 5 users, load average: 1.19, 1.17, 1.06
下圖為Off-CPU火焰圖
[圖片上傳失敗...(image-d5a169-1657865246125)]
最后一分鐘的平均負載是1.19疫向。我們來分解一下:
- 0.33來自
tar的CPU時間(pidstat) - 0.67是來自
tar的不可中斷磁盤讀取咳蔚，推斷(offcpu火焰圖在0.69，我懷疑因為它開始收集有點晚鸿捧，跨越的時間范圍略有不同) - 0.04是來自其他CPU消費者(iostat用戶+系統(tǒng)屹篓，減去來自pidstat的tar的CPU)
- 0.11是來自內(nèi)核worker的不間斷磁盤I/O時間疙渣，刷新磁盤寫(offcpu火焰圖匙奴，左邊的兩個塔)
加起來是1.15，缺少0.04妄荔，其中一些可能是四舍五入和測量間隔偏移誤差泼菌，但很多可能是由于負載平均值是指數(shù)阻尼移動，而我使用的其他平均值(pidstat, iostat)是正常平均值啦租。
在1.19之前哗伯，一分鐘平均水平是1.25，所以這部分仍將把我們拉高篷角。 從我之前的圖表中可以看出焊刹，在1分鐘這一標記處，62%的指標來自這一分鐘恳蹲，其余的則更早虐块。
所以0.62 x 1.15 + 0.38 x 1.25 = 1.18。這與報告中的1.19非常接近嘉蕾。
在這個系統(tǒng)中贺奠，一個用戶線程(tar)加上一些系統(tǒng)線程(在內(nèi)核工作線程中)處于工作狀態(tài)，Linux的平均負載為1.19错忱。
如果Linux平均負載測量的是CPU平均負載儡率，上述值應為0.37(從mpstat的摘要中推斷)而非1.19挂据，
此時該值只能描述CPU計算資源需求，但是隱藏了一個事實儿普，即該操作需要超過一個線程的系統(tǒng)資源崎逃。
理解Linux的平均負載
不同版本Linux系統(tǒng)的平均負載指代內(nèi)容并不明確。也許問題根源來自平均負載這個詞和I/O一樣含糊不清眉孩。I/O指的到底是磁盤I/O? 還是文件系統(tǒng)I/O? 還是網(wǎng)絡I/O ?
同樣婚脱，平均負載指的是? CPU負載平均? 系統(tǒng)平均負載? 或許下面的總結(jié)更容易理解:
- 在
Linux平臺上，平均負載指的是系統(tǒng)平均負載勺像，用于整個系統(tǒng)障贸，
度量正在工作和等待工作的線程數(shù)量(CPU、磁盤吟宦、不可中斷鎖)篮洁。換句話說，它度量非完全空閑的線程的數(shù)量殃姓。優(yōu)點: 反應對不同系統(tǒng)資源的需求袁波。 - 在其他操作系統(tǒng)上，平均負載指的是
CPU平均負載蜗侈，衡量的是CPU運行線程數(shù) + CPU可運行線程數(shù)篷牌。優(yōu)點:可以更容易理解和推理(僅針對cpu)。
如何評估系統(tǒng)平均負載的值踏幻？
有些人已經(jīng)找到了適合他們的系統(tǒng)和工作負載的值:他們知道當負載超過X時枷颊，應用程序延遲就會很高，客戶就會開始抱怨该面。當然夭苗，這個值并不唯一。
評估CPU平均負載時隔缀，可以將系統(tǒng)平均負載值除以CPU計數(shù)题造，然后如果該比率超過1.0，則表示CPU運行于飽和狀態(tài)猾瘸，這可能會導致性能問題界赔。
這有點模棱兩可，因為這是一個長期平均值(至少一分鐘)牵触，可能會隱藏變化淮悼。
一個比率為1.5的系統(tǒng)可能運行得很好，而另一個比率為1.5的系統(tǒng)在幾分鐘內(nèi)突然爆發(fā)荒吏，可能運行得很糟糕敛惊。
評估Linux的系統(tǒng)平均負載時，由于涉及不同的資源類型绰更，所以這些數(shù)據(jù)更加模糊瞧挤，所以不能只除以CPU計數(shù)锡宋。
它對于相對以下場景比較更有用: 如果您知道系統(tǒng)在負載為20時運行良好，現(xiàn)在是40特恬，那么就該排查下系統(tǒng)存在的問題了执俩。
更好的負載指標
當Linux平均負載增加時，您知道對資源(cpu癌刽、磁盤和一些鎖)的需求增加了役首，但不確定是哪一個。您可以使用其他指標進行說明显拜。例如衡奥，對于cpu:
- 每個cpu利用率: 如使用
mpstat -P ALL 1 - 每個進程的CPU利用率: 如
top, pidstat <pid>等 - 每個線程運行隊列(調(diào)度器)延遲: 例如，
cat /proc/<pid>/schedstats,delaystats,perf sched - CPU運行隊列延遲: 例如远荠，
cat /proc/schedstat,perf sched - CPU運行隊列長度: 例如矮固，使用
vmstat 1和'r'列
前兩個是利用率指標，后三個是飽和度指標譬淳。利用率度量對于工作負載表征很有用档址，飽和度量對于識別性能問題很有用。
最好的CPU飽和指標是度量運行隊列(或調(diào)度器)延遲: 任務/線程處于可運行狀態(tài)邻梆，但必須等待輪到CPU運行它的時間守伸。
通過上述指標可以計算出性能問題的大小，例如浦妄，線程花費在調(diào)度器延遲上的時間百分比尼摹。
在Linux 4.6中，schedstats功能被設置為內(nèi)核可調(diào)特性(sysctl kernel.sched_schedstats)校辩，默認關閉窘问。
$ awk 'NF > 7 { if ($1 == "task") { if (h == 0) { print; h=1 } } else { print } }' /proc/sched_debug
task PID tree-key switches prio wait-time sum-exec sum-sleep
systemd 1 5028.684564 306666 120 43.133899 48840.448980 2106893.162610 0 0 /init.scope
ksoftirqd/0 3 99071232057.573051 1109494 120 5.682347 21846.967164 2096704.183312 0 0 /
kworker/0:0H 5 99062732253.878471 9 100 0.014976 0.037737 0.000000 0 0 /
migration/0 9 0.000000 1995690 0 0.000000 25020.580993 0.000000 0 0 /
lru-add-drain 10 28.548203 2 100 0.000000 0.002620 0.000000 0 0 /
watchdog/0 11 0.000000 3368570 0 0.000000 23989.957382 0.000000 0 0 /
cpuhp/0 12 1216.569504 6 120 0.000000 0.010958 0.000000 0 0 /
xenbus 58 72026342.961752 343 120 0.000000 1.471102 0.000000 0 0 /
khungtaskd 59 99071124375.968195 111514 120 0.048912 5708.875023 2054143.190593 0 0 /
[...]
dockerd 16014 247832.821522 2020884 120 95.016057 131987.990617 2298828.078531 0 0 /system.slice/docker.service
dockerd 16015 106611.777737 2961407 120 0.000000 160704.014444 0.000000 0 0 /system.slice/docker.service
dockerd 16024 101.600644 16 120 0.000000 0.915798 0.000000 0 0 /system.slice/
[...]
除了CPU指標之外辆童，您還可以查找磁盤設備的利用率和飽和度指標宜咒。
雖然有更明確的指標，但這并不意味著平均負載無用把鉴。它們被成功地用于云計算微服務的彈性擴展策略，以及其他指標。
這有助于微服務響應不同類型的負載增加翘单，如CPU或磁盤I/O拾并。
總結(jié)
1993年，一位Linux工程師發(fā)現(xiàn)了一個關于平均負載的不夠直觀的例子怠缸，并通過一個三行補丁將其從平均CPU負載永久地更改為人們可能稱之為平均系統(tǒng)負載诗轻。
他的更改包括了處于不可中斷狀態(tài)的任務，這樣平均負載就反映了對磁盤資源的需求揭北，而不僅僅是cpu的需求扳炬。
這些系統(tǒng)負載平均值為正在工作和等待工作的線程數(shù)量吏颖，并總結(jié)為指數(shù)阻尼移動和平均值的三元組，在方程中使用1恨樟、5和15分鐘作為常數(shù)半醉。
這三個數(shù)字可以讓您看到負載是增加還是減少，它們的最大值可能用于與它們本身的相對比較劝术。
此后缩多，不可中斷狀態(tài)的使用在Linux內(nèi)核中得到了發(fā)展，現(xiàn)在包括了不可中斷鎖原語养晋。
如果平均負載是運行和等待線程(嚴格來說不是需要硬件資源的線程)的需求度量衬吆，那么它們?nèi)匀话凑瘴覀兿Ｍ姆绞焦ぷ鳌?/p>
所謂原語，一般是指由若干條指令組成的程序段绳泉，用來實現(xiàn)某個特定功能咆槽，在執(zhí)行過程中不可被中斷。
在這篇文章中圈纺，原作者挖掘了1993年的Linux平均加載補丁——這是令人驚訝的難以找到的——包含了作者最初的解釋秦忿。
并在現(xiàn)代Linux系統(tǒng)上使用bcc/eBPF測量了不可中斷狀態(tài)下的堆棧跟蹤和時間，并可視化為off-CPU火焰圖蛾娶。
可視化提供了許多不可中斷睡眠的例子灯谣，并且可以在需要解釋異常高的平均負載時生成。并且他還提出了其他指標蛔琅，可以用來更詳細地了解系統(tǒng)負載胎许，而不是平均負載。
參考文獻
linux-performance-analysis
Linux Load Averages: Solving the Mystery
