Lösung 1:
Sie können Ihr eigenes SystemTap-Skript entwickeln. Sie müssen die folgenden zwei Subsysteme berücksichtigen:
- VFS:Dies repräsentiert alle E/A-Anforderungen vor dem Buffer-Cache (d. h. absolut jede E/A-Anforderung); Überprüfen Sie die Sonden "vfs.read", "vfs.write" und "kernel.function("vfs_*")". Sie müssen die Blockgeräte, die Sie überwachen möchten, anhand ihrer jeweiligen Major- und Minor-Nummern herausfiltern.
- Block:Dies stellt alle E/A-Anforderungen dar, die vor dem E/A-Scheduler an die Blockgeräte gesendet wurden (der auch die E/A-Anforderungen zusammenführt + neu ordnet); hier wissen wir, welche Anfragen vom Buffer-Cache verpasst wurden; Überprüfen Sie den "ioblock.request"-Probe.
Die SystemTap-Entwicklung braucht einige Zeit, um zu lernen. Wenn Sie ein mäßiger Entwickler sind und gute Kenntnisse in Linux haben, sollten Sie in 3-4 Tagen fertig sein. Ja, es braucht Zeit zum Lernen, aber Sie werden mit den Ergebnissen sehr zufrieden sein - SystemTap gibt Ihnen die Möglichkeit, Sonden (sicher) an fast jeder Stelle im Linux-Kernel zu platzieren.
Beachten Sie, dass Ihr Kernel das Laden und Entladen von Kernelmodulen unterstützen muss. Die meisten Standard-Kernel unterstützen dies heutzutage. Sie müssen auch die Debug-Symbole für Ihren Kernel installieren. Für mein Ubuntu-System war das so einfach wie das Herunterladen einer mehrere hundert MB großen .deb-Datei, die das Ubuntu-Kernel-Entwicklungsteam für mich kompiliert hat. Dies wird zum Beispiel auf der SystemtapOnUbuntu-Wiki-Seite erklärt.
P.S. Nehmen Sie den SystemTap-Ansatz nur, wenn Sie keine andere Lösung haben, denn es ist ein völlig neues Framework, das Sie lernen müssen, und das Zeit/Geld und manchmal Frustration kostet.
Lösung 2:
Ich ging voran und schrieb ein Stap-Skript dafür. Es gibt eine im Systemtap-Wiki, aber sie scheint nicht korrekt zu sein. In grundlegenden Tests scheint dies ziemlich genau zu sein, aber YMMV.
#! /usr/bin/env stap
global total_bytes, disk_bytes, counter
probe vfs.read.return {
if (bytes_read>0) {
if (devname=="N/A") {
} else {
total_bytes += bytes_read
}
}
}
probe ioblock.request
{
if (rw == 0 && size > 0)
{
if (devname=="N/A") {
} else {
disk_bytes += size
}
}
}
# print VFS hits and misses every 5 second, plus the hit rate in %
probe timer.s(5) {
if (counter%15 == 0) {
printf ("\n%18s %18s %10s %10s\n",
"Cache Reads (KB)", "Disk Reads (KB)", "Miss Rate", "Hit Rate")
}
cache_bytes = total_bytes - disk_bytes
if (cache_bytes < 0)
cache_bytes = 0
counter++
hitrate = 10000 * cache_bytes / (cache_bytes+disk_bytes)
missrate = 10000 * disk_bytes / (cache_bytes+disk_bytes)
printf ("%18d %18d %6d.%02d%% %6d.%02d%%\n",
cache_bytes/1024, disk_bytes/1024,
missrate/100, missrate%100, hitrate/100, hitrate%100)
total_bytes = 0
disk_bytes = 0
}
Lösung 3:
/proc/slabinfo ist ein guter Anfang, gibt Ihnen aber nicht ganz die Informationen, nach denen Sie suchen (lassen Sie sich nicht von den Hit/Miss-Prozentsätzen auf Systemen mit mehreren Kernen und aktivierten Statistiken täuschen; das ist etwas anderes). Soweit ich weiß, gibt es keine Möglichkeit, diese speziellen Informationen aus dem Kernel herauszuholen, obwohl es nicht allzu schwierig sein sollte, ein bisschen Code zu schreiben, der zu tun ist.
Bearbeiten:http://www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html
Lösung 4:
Jetzt gibt es das Dienstprogramm cachestat aus dem Paket perf-tools.
Der Autor listet auch einige (möglicherweise gröbere) Alternativen auf, die die Leute benutzen:
A) Untersuchen Sie die Page-Cache-Miss-Rate, indem Sie iostat(1) verwenden, um Plattenlesevorgänge zu überwachen, und nehmen Sie an, dass es sich um Cache-Miss handelt und nicht zum Beispiel um O_DIRECT. Die Fehlschlagrate ist in der Regel sowieso eine wichtigere Metrik als das Verhältnis, da Fehlschläge proportional zum Anwendungsschmerz sind. Verwenden Sie auch free(1), um die Cache-Größen anzuzeigen.
B) Löschen Sie den Seiten-Cache (echo 1> /proc/sys/vm/drop_caches) und messen Sie, wie sehr die Leistung schlechter wird! Ich liebe die Verwendung eines negativen Experiments, aber dies ist natürlich eine schmerzhafte Methode, um etwas Licht in die Cache-Nutzung zu bringen.
C) Verwenden Sie sar(1) und untersuchen Sie kleinere und größere Fehler. Ich glaube nicht, dass das funktioniert (zB normale I/O).
D) Verwenden Sie das SystemTap-Skript cache-hit-rate.stp, das die Nummer zwei bei einer Internetsuche nach der Cache-Trefferquote von Linux-Seiten ist. Es instrumentiert den Cache-Zugriff ganz oben im Stack, in der VFS-Schnittstelle, sodass Lesevorgänge auf jedem Dateisystem oder Speichergerät sichtbar sind. Cache-Misses werden über ihre Disk-I/O gemessen. Dies vermisst auch einige Workload-Typen (einige werden in „Lektionen“ auf dieser Seite erwähnt) und Anrufverhältnisse „Raten“.