Ich hatte in letzter Zeit einige Probleme mit der Serverleistung. Derzeit betreiben wir einen Fedora-Server mit 4 GB und 160 GB Festplattenspeicher. Mit all den Dateien, die wir an Bord haben, stoßen wir die Kapazität der Festplatte ziemlich an. Wir betreiben mehrere Websites mit mehreren Backups für jede Website. Allerdings hat nur eine Website tatsächlich Traffic. Es ist eine E-Commerce-Site mit vielen Besuchern.
In letzter Zeit gab es langsame Ladezeiten und ich merke, dass unser freier Speicher sehr knapp wird (unter einem GB). Ich werde den Server neu starten (was ich jetzt dreimal am Tag tun muss) und alles wird in Ordnung sein. Wir beginnen mit 2,2 GB freiem Speicher, aber nach 3 oder 4 Stunden merkt man, dass der Speicher voll ist und die Ladezeiten immer langsamer werden. Ich kann nicht herausfinden, woher das kommt oder ob es einfach Zeit ist, auf einen besseren Server zu aktualisieren. Ich möchte einfach nicht aktualisieren und dann feststellen, dass ich irgendwo einen Engpass bei MySQL-Anfragen habe.
Ich bin für alle Ideen und Vorschläge dankbar.
BEARBEITEN-
Es gibt auch 3 virtuelle Hosts und ich habe weit über 60.000 Dateien.
total used free shared buffers cached
Mem: 4003 3372 630 0 398 1717
-/+ buffers/cache: 1256 2746
Swap: 8189 0 8189
21:21:49 up 46 min, 1 user, load average: 3.75, 4.20, 4.03
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 0 592728 409640 1838360 0 0 165 411 953 473 9 8 47 36 0
Und hier ist der Top-Schnappschuss.
1356 mysql 20 0 1374m 219m 5320 S 5.6 5.5 14:06.21 mysqld
15796 root 20 0 103m 20m 440 D 1.0 0.5 0:04.42 sendmail
1081 root 20 0 103m 20m 440 D 0.7 0.5 0:21.73 sendmail
24013 root 20 0 97416 22m 2648 D 0.7 0.6 0:15.15 mailq
1525 root 20 0 247m 7980 3472 S 0.3 0.2 0:06.88 vlogger (access
1530 apache 20 0 539m 13m 3008 S 0.3 0.3 0:03.56 httpd
2399 apache 20 0 539m 12m 2748 S 0.3 0.3 0:00.85 httpd
5763 root 20 0 121m 4932 3868 S 0.3 0.1 0:00.07 sshd
12326 apache 20 0 539m 12m 2992 S 0.3 0.3 0:00.38 httpd
12421 apache 20 0 539m 12m 2988 S 0.3 0.3 0:00.45 httpd
16396 apache 20 0 538m 12m 2284 S 0.3 0.3 0:00.09 httpd
17050 root 20 0 15368 1256 868 R 0.3 0.0 0:00.09 top
1 root 20 0 37336 4104 1908 S 0.0 0.1 0:02.82 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0
7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H
8 root RT 0 0 0 0 S 0.0 0.0 0:00.11 migration/0
9 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/0
10 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/1
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
13 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/1
14 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/1
15 root RT 0 0 0 0 S 0.0 0.0 0:00.15 migration/2
17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/2
19 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/2
20 root RT 0 0 0 0 S 0.0 0.0 0:00.11 migration/3
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H
23 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/3
24 root RT 0 0 0 0 S 0.0 0.0 0:00.01 watchdog/3
25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
26 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 xenwatch
Antwort1
Steigern Sie den SAR-Wert und geben Sie die PS-Tabelle jede Minute aus. Siehe meine ausführliche AntwortHier.
Wenn der Server das nächste Mal abstürzt, verwenden Sie sar -rzur SucheWannes ist passiert. Verwenden Sie nun die Ausgabe von ps-cronjob oder von meinemPerl-Wrapper für PS auf GitHub, um herauszufinden, welcher Prozess der Übeltäter gewesen sein könnte.
Angenommen, der Server ist zwischen 12:00:00 und 13:00:00 abgestürzt. Verwenden Sie sar -r -s 12:00:00 -e 13:00:00. Daraufhin sollten Sie einen Spitzenwert in den Daten sehen. (Wenn es einfacher ist, gibt es ein Java-basiertes Dienstprogramm zum Erstellen von Diagrammen, aber normalerweise lohnt sich der Aufwand nicht.) Angenommen, Sie sehen einen Spitzenwert (oder einen Tiefpunkt) um 12:15. Durchsuchen Sie nun die in Spalten sortierte PS-Ausgabe für einen Zeitraum zwischen beispielsweise 12:00 und 12:15, sortieren Sie sie nach PID und dann nach Zeit und sehen Sie sich die Speicherspalten an:
awk '/^=== .* 12:00:/,/^=== .* 12:16:/' /var/log/sa/ps/today |
sort -k 1n -k 16
(Die Sortieroptionen gehen davon aus, dass die Zeit in Spalte 16 steht, was der Fall sein kann, aber nicht muss.) Jetzt können Sie diese Ausgabe erneut durch awk filtern, um Unterschiede zwischen den Ausgabezeilen zu finden:
... | awk 'lastpid && lastpid==$1 && last != $0 { print} /^[0-9]/ { lastpid=$1;last=$0; }'
Das ist ein ziemlich grober Filter. Für einige Prozesse (deren Befehlszeile sich ständig ändert, wie z. B. bei mysql, postgresql und snmpd) ist das nicht sehr hilfreich, aber hoffentlich können Sie das awk so optimieren, dass Sie den/die Übeltäter finden.