Ich habe einen Linux-Server, auf dem unser Bacula-Backup-System ausgeführt wird. Die Maschine schleift wie verrückt, weil es schwer ist, zu tauschen. Das Problem ist, dass es nur 60% seines physischen Speichers verwendet!
Hier ist die Ausgabe von free -m:
free -m
total used free shared buffers cached
Mem: 3949 2356 1593 0 0 1
-/+ buffers/cache: 2354 1595
Swap: 7629 1804 5824
und einige Beispielausgaben von vmstat 1:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 1843536 1634512 0 4188 54 13 2524 666 2 1 1 1 89 9 0
1 11 1845916 1640724 0 388 2700 4816 221880 4879 14409 170721 4 3 63 30 0
0 9 1846096 1643952 0 0 4956 756 174832 804 12357 159306 3 4 63 30 0
0 11 1846104 1643532 0 0 4916 540 174320 580 10609 139960 3 4 64 29 0
0 4 1846084 1640272 0 2336 4080 524 140408 548 9331 118287 3 4 63 30 0
0 8 1846104 1642096 0 1488 2940 432 102516 457 7023 82230 2 4 65 29 0
0 5 1846104 1642268 0 1276 3704 452 126520 452 9494 119612 3 5 65 27 0
3 12 1846104 1641528 0 328 6092 608 187776 636 8269 113059 4 3 64 29 0
2 2 1846084 1640960 0 724 5948 0 111480 0 7751 116370 4 4 63 29 0
0 4 1846100 1641484 0 404 4144 1476 125760 1500 10668 105358 2 3 71 25 0
0 13 1846104 1641932 0 0 5872 828 153808 840 10518 128447 3 4 70 22 0
0 8 1846096 1639172 0 3164 3556 556 74884 580 5082 65362 2 2 73 23 0
1 4 1846080 1638676 0 396 4512 28 50928 44 2672 38277 2 2 80 16 0
0 3 1846080 1628808 0 7132 2636 0 28004 8 1358 14090 0 1 78 20 0
0 2 1844728 1618552 0 11140 7680 0 12740 8 763 2245 0 0 82 18 0
0 2 1837764 1532056 0 101504 2952 0 95644 24 802 3817 0 1 87 12 0
0 11 1842092 1633324 0 4416 1748 10900 143144 11024 6279 134442 3 3 70 24 0
2 6 1846104 1642756 0 0 4768 468 78752 468 4672 60141 2 2 76 20 0
1 12 1846104 1640792 0 236 4752 440 140712 464 7614 99593 3 5 58 34 0
0 3 1846084 1630368 0 6316 5104 0 20336 0 1703 22424 1 1 72 26 0
2 17 1846104 1638332 0 3168 4080 1720 211960 1744 11977 155886 3 4 65 28 0
1 10 1846104 1640800 0 132 4488 556 126016 584 8016 106368 3 4 63 29 0
0 14 1846104 1639740 0 2248 3436 428 114188 452 7030 92418 3 3 59 35 0
1 6 1846096 1639504 0 1932 5500 436 141412 460 8261 112210 4 4 63 29 0
0 10 1846104 1640164 0 3052 4028 448 147684 472 7366 109554 4 4 61 30 0
0 10 1846100 1641040 0 2332 4952 632 147452 664 8767 118384 3 4 63 30 0
4 8 1846084 1641092 0 664 4948 276 152264 292 6448 98813 5 5 62 28 0
Darüber hinaus scheint die Ausgabe von top sortiert nach CPU-Zeit die Theorie zu stützen, dass Swap das ist, was das System blockiert:
top - 09:05:32 up 37 days, 23:24, 1 user, load average: 9.75, 8.24, 7.12
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 76.1%id, 20.6%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4044632k total, 2405628k used, 1639004k free, 0k buffers
Swap: 7812492k total, 1851852k used, 5960640k free, 436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
4174 root 17 0 63156 176 56 S 8 0.0 2138:52 35,38 bacula-fd
4185 root 17 0 63352 284 104 S 6 0.0 1709:25 28,29 bacula-sd
240 root 15 0 0 0 0 D 3 0.0 831:55.19 831:55 kswapd0
2852 root 10 -5 0 0 0 S 1 0.0 126:35.59 126:35 xfsbufd
2849 root 10 -5 0 0 0 S 0 0.0 119:50.94 119:50 xfsbufd
1364 root 10 -5 0 0 0 S 0 0.0 117:05.39 117:05 xfsbufd
21 root 10 -5 0 0 0 S 1 0.0 48:03.44 48:03 events/3
6940 postgres 16 0 43596 8 8 S 0 0.0 46:50.35 46:50 postmaster
1342 root 10 -5 0 0 0 S 0 0.0 23:14.34 23:14 xfsdatad/4
5415 root 17 0 1770m 108 48 S 0 0.0 15:03.74 15:03 bacula-dir
23 root 10 -5 0 0 0 S 0 0.0 13:09.71 13:09 events/5
5604 root 17 0 1216m 500 200 S 0 0.0 12:38.20 12:38 java
5552 root 16 0 1194m 580 248 S 0 0.0 11:58.00 11:58 java
Hier ist das Gleiche, sortiert nach der Größe des Images des virtuellen Speichers:
top - 09:08:32 up 37 days, 23:27, 1 user, load average: 8.43, 8.26, 7.32
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 3.4%sy, 0.0%ni, 62.2%id, 30.2%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 4044632k total, 2404212k used, 1640420k free, 0k buffers
Swap: 7812492k total, 1852548k used, 5959944k free, 100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
5415 root 17 0 1770m 56 44 S 0 0.0 15:03.78 15:03 bacula-dir
5604 root 17 0 1216m 492 200 S 0 0.0 12:38.30 12:38 java
5552 root 16 0 1194m 476 200 S 0 0.0 11:58.20 11:58 java
4598 root 16 0 117m 44 44 S 0 0.0 0:13.37 0:13 eventmond
9614 gdm 16 0 93188 0 0 S 0 0.0 0:00.30 0:00 gdmgreeter
5527 root 17 0 78716 0 0 S 0 0.0 0:00.30 0:00 gdm
4185 root 17 0 63352 284 104 S 20 0.0 1709:52 28,29 bacula-sd
4174 root 17 0 63156 208 88 S 24 0.0 2139:25 35,39 bacula-fd
10849 postgres 18 0 54740 216 108 D 0 0.0 0:31.40 0:31 postmaster
6661 postgres 17 0 49432 0 0 S 0 0.0 0:03.50 0:03 postmaster
5507 root 15 0 47980 0 0 S 0 0.0 0:00.00 0:00 gdm
6940 postgres 16 0 43596 16 16 S 0 0.0 46:51.39 46:51 postmaster
5304 postgres 16 0 40580 132 88 S 0 0.0 6:21.79 6:21 postmaster
5301 postgres 17 0 40448 24 24 S 0 0.0 0:32.17 0:32 postmaster
11280 root 16 0 40288 28 28 S 0 0.0 0:00.11 0:00 sshd
5534 root 17 0 37580 0 0 S 0 0.0 0:56.18 0:56 X
30870 root 30 15 31668 28 28 S 0 0.0 1:13.38 1:13 snmpd
5305 postgres 17 0 30628 16 16 S 0 0.0 0:11.60 0:11 postmaster
27403 postfix 17 0 30248 0 0 S 0 0.0 0:02.76 0:02 qmgr
10815 postfix 15 0 30208 16 16 S 0 0.0 0:00.02 0:00 pickup
5306 postgres 16 0 29760 20 20 S 0 0.0 0:52.89 0:52 postmaster
5302 postgres 17 0 29628 64 32 S 0 0.0 1:00.64 1:00 postmaster
Ich habe versucht, den swappinessKernel-Parameter sowohl auf hohe als auch auf niedrige Werte einzustellen, aber nichts scheint das Verhalten hier zu ändern. Ich weiß nicht, was los ist. Wie kann ich herausfinden, was das verursacht?
Update: Bei dem System handelt es sich um ein 64-Bit-System, sodass aufgrund von 32-Bit-Problemen keine Speicherbeschränkungen auftreten sollten.
Update2: Wie ich bereits in der ursprünglichen Frage erwähnt habe, habe ich bereits versucht, swappiness auf alle möglichen Werte abzustimmen, einschließlich 0. Das Ergebnis ist immer dasselbe, wobei ungefähr 1,6 GB Arbeitsspeicher ungenutzt bleiben.
Update3: Top-Ausgabe zu den obigen Informationen hinzugefügt.
Antworten:
Die Leistung von Bacula hängt stark von der Datenbank ab. Wahrscheinlich ist es Postgresql, das Ihren Server umbringt. Der Durchschnitt der hohen Auslastung und der relativ hohe Prozentsatz der CPU-Zeit, die im Wartezustand verbracht wurde, zeigen deutlich, dass sie auf Disk I / O wartet ... Und das macht PostgreSQL. Für jede Datei in Ihrem Sicherungssatz wird mindestens eine UPDATE-Anweisung ausgeführt. Mach dir keine Sorgen über das Tauschen.
Optimieren Sie die PostgreSQL-Installation. Geben Sie einzelnen Datenbanken (oder sogar Tabellen) möglicherweise ihre eigenen Festplatten / RAID-Sätze, um die E / A zu verteilen. Sie können PostgreSQL zwingen, aynchrone Schreibvorgänge auszuführen, wenn dies noch nicht geschehen ist. Nutzen Sie den gemeinsam genutzten Speicher, der PostgreSQL zur Verfügung steht. Das wird zumindest einen Großteil des Lesens in der Datenbank erleichtern. Wenn Sie dies noch nie getan haben, führen Sie VACCUM ANALYZE auch in der Bacula-Datenbank aus, um dem Abfrageoptimierer eine Funktion zu geben, mit der Sie arbeiten können.
Der mit Abstand schwächste Punkt von Bacula sind die Datenbankabhängigkeiten (und die Hirnschädigung einiger davon ...). Führen Sie eine Bereinigung eines kürzlich erstellten umfangreichen Backups durch und stellen Sie fest, wie lange (Stunden) das Ausführen von ein paar Dutzend Millionen Abfragen dauert. Bacula mag vergleichsweise wenige große Dateien, sonst ist es ein Hund.
quelle
Sie sind I / O-gebunden. Ihr System ist ein kleines Rettungsfloß, das von einer stürmischen Flut von Puffern / Cache / VM-Paging-Wellen überflutet wird, die 30 Meter hoch sind.
Beeindruckend. Einfach wow. Sie verschieben Ihre E / A um etwa 100 MB / s, die Wartezeit für die E / A liegt weit über 50%, und Sie verfügen über 4 GB RAM. Der Gegendruck auf der VM dieses Servers muss enorm sein. Unter "normalen" Umständen wird jedes freie RAM, das Sie hatten , in weniger als 40 Sekunden bei lebendigem Leib aufgebraucht , wenn das System zu puffern / zu cachen beginnt .
Wäre es möglich, die Einstellungen von zu posten
/proc/sys/vm? Dies würde einen Einblick geben, was Ihr Kernel für "normal" hält.Diese
postmasterProzesse zeigen auch an, dass Sie PostgreSQL im Hintergrund ausführen. Ist das normal für dein Setup? PostgreSQL in einer Standardkonfiguration benötigt sehr wenig RAM, aber sobald es auf Geschwindigkeit eingestellt ist, kann es schnell 25% -40% Ihres verfügbaren RAM aufbrauchen. Daher kann ich nur raten, dass Sie angesichts der Anzahl der in der Ausgabe enthaltenen Daten eine Art Produktionsdatenbank ausführen, während Sie Sicherungen ausführen. Das ist kein gutes Zeichen. Kannst du uns etwas mehr darüber erzählen, warum es läuft? Was ist die Größe des Shared Memory-Parameters für alle?postmasterProzesse? Ist es möglich, den Dienst herunterzufahren oder die Datenbank vorübergehend neu zu konfigurieren, um weniger Verbindungen / Puffer zu verwenden, während die Sicherungen ausgeführt werden? Dies wird dazu beitragen, den Druck auf die bereits belasteten E / A und den freien Arbeitsspeicher zu verringern. Beachten Sie, dass jederpostmasterProzess mehr RAM verbraucht, als die Datenbank für das interne Caching benötigt. Achten Sie also beim Anpassen der Speichereinstellungen darauf, welche "gemeinsam" und welche "pro Prozess" verwendet werden .Wenn Sie PostgreSQL als Teil Ihres Sicherungsprozesses verwenden, optimieren Sie es erneut, um nur die minimale Anzahl von Verbindungen zu akzeptieren , und reduzieren Sie die Parameter pro Prozess auf einen vernünftigen Wert (jeweils nur wenige Megabyte). Der Nachteil dabei ist, dass PostgreSQL auf die Festplatte verschüttet wird, wenn es nicht wie gewünscht mit dem Dataset im RAM arbeiten kann, sodass die Festplatten-E / A tatsächlich erhöht wird .
X11 an und für sich nimmt nicht viel Speicherplatz in Anspruch, aber eine vollständige Desktopsitzung kann mehrere Megabyte in Anspruch nehmen. Melden Sie alle aktiven Sitzungen ab und führen Sie Ihre Verbindung über die Konsole oder über SSH aus.
Trotzdem denke ich nicht, dass es sich nur um ein Gedächtnisproblem handelt. Wenn Sie mehr als 50% der E / A-Vorgänge abwarten (und Zahlen veröffentlichen, die die 70er Jahre berühren), wird der Rest des Systems durch den daraus resultierenden Engpass möglicherweise überlastet. Ähnlich wie Darth Vader den Hals zerquetscht.
Für wie viele bündige Threads sind Sie konfiguriert? Verwenden
herauszufinden und
um es auf einen einzelnen Thread zu setzen. Beachten Sie, dass der letzte Befehl ihn beim Neustart permanent laden lässt. 1 oder 2 zu sehen ist nicht ungewöhnlich. Wenn Sie mehrere Kerne oder viel Spindel- / Buskapazität für E / A haben, sollten Sie diese (geringfügig) anstoßen. Mehr Flush-Threads = mehr E / A-Aktivität, aber auch mehr CPU-Zeit für E / A-Wartezeiten.
Ist es der Standardwert oder haben Sie ihn überschritten? Haben Sie in Erwägung gezogen, die Anzahl zu verringern, um den Druck auf die E / A-Operationen zu verringern? Oder haben Sie eine große Anzahl von Spindeln und Kanäle zur Arbeit mit, wobei in diesem Fall, haben Sie darüber nachgedacht , Erhöhung der Anzahl der bündig Fäden?
PS Sie möchten die Swap-Funktion auf die niedrigeren Werte und nicht auf die höheren Werte einstellen, um ein Auslagern zu verhindern. Höchster Wert = 100 = wie verrückt tauschen, wenn es sich richtig anfühlt, niedrigster Wert = 0 = überhaupt nicht tauschen.
quelle
Wenn Sie sich die Blöcke ansehen, die pro Sekunde (bi) unter IO eingelesen wurden, wird die Swap-Aktivität um mehrere Größenordnungen in den Schatten gestellt. Ich glaube nicht, dass die Auslagerungsnutzung dazu führt, dass Ihre Festplatte kaputt geht. Ich denke, dass auf der Box etwas läuft, das einfach eine Menge Festplattenaktivität (Lesevorgänge) verursacht.
Ich würde die laufenden Anwendungen untersuchen und herausfinden, ob Sie den Täter finden können.
quelle
Sehen Sie, ob dieser Link einige Ihrer Fragen beantwortet. Ich sehe regelmäßig, wie Linux lange vor 60% Auslastung den Speicher auslagert (nicht auslagert). Dies ist ein erwarteter Teil der Speicheroptimierung:
http://www.sheepguardingllama.com/?p=2252
Aber Ihr Mangel an Puffern / Cache macht mir Sorgen. Das sieht sehr ungewöhnlich aus. Also denke ich, dass etwas mehr nicht stimmt.
quelle
Können Sie versuchen, Swap vollständig zu deaktivieren?
oder so - zumindest wird dies bestätigen, dass es sich bei dem Tausch um Ihr Problem handelt und nicht um etwas anderes.
quelle
Standardmäßig ist swappiness auf 60 eingestellt.
cat / proc / sys / vm / swappiness 60
Swappiness ist ein Kernel, der verwendet wird, um festzulegen, wie sehr der Kernel den Austausch über RAM bevorzugt. Hohe Auslagerungsrate bedeutet, dass der Kernel viel auslagert, und niedrige Auslagerungsrate bedeutet, dass der Kernel versucht, keinen Auslagerungsbereich zu verwenden.
Wir können diese Änderung am Wert von vm.swappiness in /etc/sysctl.conf vornehmen .
quelle
/proc/sys/vm/swappiness.Sie können das manuell einstellen Status des Kernels Sie bei der
/proc/sys/vm/swappinessAusgabe des Befehls sehen könnensysctl vm.swappiness. Die Swap-Funktion ist eine Kernel-Einstellung, die bestimmt, wie oft der Swap verwendet wird.Mit dieser Einstellung
sudo sysctl vm.swappiness=0deaktivieren Sie die Swap-Partition effektiv. Um diese Änderung dauerhaft können Sie hinzufügen / ändernvm.swappiness=0in/etc/sysctl.conf. Sie sollten sehen, was für Sie ein guter Wert ist. Ich persönlich habe es so konfiguriertvm.swappiness=10, dass 60 der Standardwert ist.quelle
Eine andere Sache, die Sie sich ansehen möchten, ist die Warteschlange für die Kernelausführung und nicht unterbrechbare Prozesse (die Spalten 'r' und 'b' in vmstat) sind ein Indikator dafür, dass das System zeitweise überlastet ist. Nebenbei bemerkt, verwechseln Sie nicht Sättigung mit Auslastung ... das eigentliche Problem kann ein ausgehungerter Prozessstapel gegen den gesättigten Kernel sein :-(
Sie können auch 'pmap -x [PID]' ausführen, um zusätzliche Speicherdetails von einigen der aufwändigeren Prozesse abzurufen. Ich wünsche Ihnen Glück!
Matt
quelle
Möglicherweise haben Sie kurzlebige Prozesse, die viel Arbeitsspeicher verbrauchen. Beenden Sie sie dann, bevor Sie die Möglichkeit haben, sie zu bemerken.
Dies würde im Einklang mit dem stehen, was Sie sowieso sehen.
quelle
Haben Sie Probleme mit dem Inode-Cache untersucht?
slabtopsollte Ihnen zumindest einen Ausgangspunkt geben, wenn Sie auf so etwas stoßen.quelle
Während Ihr System 64-Bit ist, kann das System möglicherweise nicht den gesamten verfügbaren Speicher adressieren. Dies ist eine Chipsatzbeschränkung. Zum Beispiel "unterstützt" der Mac mini der vorherigen Generation 4 GB RAM, aber nur 3,3 GB waren tatsächlich adressierbar.
quelle