Hi,
ich habe einen vServer mit Ubuntu 16 LTS, auf dem ich mir aktuell - also
zu einer Zeit mit minimaler bzw. gar keiner Besucher-Last - mal mit
"free" eine Übersicht des Arbeitsspeichers in MB ausgegeben habe...
1
total used free shared buff/cache available
2
Mem: 7983 668 532 134 6782 6857
3
Low: 7983 7450 532
4
High: 0 0 0
5
Swap: 1022 0 1022
Verstehe ich das richtig, dass 7450 MB ein Auslastungs-"Peak" ist und
das RAM somit mindestens ein mal in der Vergangenheit fast am Limit
gewesen ist?
Free scheint mir nur inklusive "buff/cache" zu stimmen:
7983 - ( 6782 + 668 )
Warum wird das so umständlich angezeigt bzw. ist man nicht eher an der
Anzeige der im Bedarfsfall für Anwendungen tatsächlich nutzbare Menge
RAM interessiert? Ich vermute mal, dass dann der Cache weniger wird,
wenn z.B. PHP oder MySQL mehr Speicher benötigen?
Und sind nur ca. 1 GB Swap verfügbar? Ist das nicht etwas zu wenig?
Wann werden die Low-Werte zurückgesetzt, beim reboot?
Und kann man irgendwie mit Bordmitteln abschätzen, ob der Peak ein
einsames Ereignis in ferner Vergangenheit war, oder ob der Server
häufiger mit hoher RAM-Auslastung zu kämpfen hat? Also ohne apt-get
install...
Und wie fein aufgelöst sind die Low-Daten überhaupt? Wenn z.B. nur alle
5 Sekunden gemessen wird, können dann nicht entscheidende Peaks
unbemerkt bleiben?
Fragen über Fragen, ich hoffe hier gibt es Server-Spezialisten, die
etwas Licht ins Dunkel bringen können.
Vielen Dank und viele Grüße
Kreskin
The Amazing Kreskin schrieb:> Free scheint mir nur inklusive "buff/cache" zu stimmen:> 7983 - ( 6782 + 668 )> Warum wird das so umständlich angezeigt bzw. ist man nicht eher an der> Anzeige der im Bedarfsfall für Anwendungen tatsächlich nutzbare Menge> RAM interessiert? Ich vermute mal, dass dann der Cache weniger wird,> wenn z.B. PHP oder MySQL mehr Speicher benötigen?
Weil ein Unix-Kernel freien Speicher nutzt, um Diskzugriffe zu
beschleunigen (Cache). Genauso schnell gibt er ihn wieder auf, wenn
eine Anwendung mehr Speicher anfordert. Das ist uebrigens nicht nur bei
Linux so, sondern auch bei anderen Unix'en.
Ich habe inzwischen aufgehoert zu zaehlen, wie oft jemand in der Firma
mit dem falschen Lesen von "free" in Panik ausgebrochen ist, anstatt
sich das noetige Grundwissen anzueigenen. "free" ist gut fuer einen
schnellen Ueberblick, aber nicht fuer eine Performance-Analyse
geeignet. Dafuer nimmt man sar.
The Amazing Kreskin schrieb:> Und sind nur ca. 1 GB Swap verfügbar? Ist das nicht etwas zu wenig?>
1GB reicht, wenn dein Server Swap benutzt hast du zu wenig RAM,
eigentlich braucht man den nicht mehr, meist ist der nur noch vorhanden
weil einige wenige Programme aus Historischen gründen den noch benutzen
um den RAM nicht zu belasten auf einem reinen Server ehr nicht.
Hallo,
mal angenommen es kommt zu etwas mehr Last als gewöhnlich und 8GB würden
nicht mehr reichen, 10GB theoretisch jedoch schon...was würde dann
passieren, wenn "nur" 1 GB Swap vorhanden ist? Ich habe in einem Blog
gelesen, dass sich der mysqld runtergefahren hat, weil er für den
InnoDB-Buffer-Pool keinen Speicher allozieren konnte. Wenn dann für alle
nichts geht mehr bis jemand den Service manuell startet, wäre das
ungünstig. Mir ist schon klar, dass Swap bzw. auch eine SSD immer noch
viel langsamer ist als RAM, aber RAM ist leider aktuell ziemlich teuer
bei Servern und wenn da ab 9GB Speicherbedarf essentielle Prozesse hart
abstürzen sollten, würde ich die Langsamkeit dem Absturz vorziehen.
@TO
Mach dir darüber Gedanken wenn es mal soweit kommen sollte.
Probleme bekommt mann eigtl nur wenn insgesamt zu wenig ram vorhanden
ist. Auslastung bei Webservern ist meistens ein CPU/Bandbreiten
Problem... solange die Prozesse sich genug ram reserviert haben passt
das schon...
Wenn du mehr Last hast als gewöhnlich, werden die Prozesse normalerweise
nicht gekillt ehr wird als erstes verhindert das neue Prozesse gestartet
werden, Mysqld sollte damit eigentlich klar kommen und den eignenden
Cache aufräumen in der Theorie jedenfalls du kannst ja auch mysqld sagen
das er sich beim start genug RAM reservieren soll, bei anderen Prozessen
sieht es dann aber anders aus und irgendwann geht auch das nicht mehr,
es kann aber auch sein das vorher schon das Managmentsystem des vservers
eingreift, kommt etwas auf die Einstellungen an.
Da dein vserver das Swapen zulässt kannst den auch beliebig erweitern
mit einer Auslagerungsdatei das ist auch nicht wesentlich langsamer als
eine eignende Partition.
Würde mir da aber auch erstmal keine Gedanken drum machen 8GB muß man
erstmal voll bekommen.
The Amazing Kreskin schrieb:> Ich habe in einem Blog> gelesen, dass sich der mysqld runtergefahren hat, weil er für den> InnoDB-Buffer-Pool keinen Speicher allozieren konnte.
Dann war er vermutlich falsch konfiguriert.
Der OOM Killer von Linux hat seine Macken, da würde es zufällige
Prozesse treffen - auch mySQL.
Wenn Du bei einem VServer den SWAP ständig nutzt, zieht der Betreiber
wegen übertriebenem IO schnell den Stecker (oder legt Dir einen dickeren
Vertrag nahe). Daher sind die 1GB schon OK, auch wenn sie weit unter der
üblichen Empfehlung (1-2x RAM) liegt.
> eigentlich braucht man den nicht mehr, meist ist der nur noch vorhanden> weil einige wenige Programme aus Historischen gründen den noch benutzen
Die Leute, die Java Programme in Betrieb nehmen, machen sich oft nicht
die Mühe, die Speicher-Parameter an den wirklichen Bedarf anzupassen.
Denn das ist oft mit umfangreichen Last-Tests verbunden.
Dann Belegen diese Programme gleich beim Start viel mehr Speicher als
nötig. Das OS kann den unbenutzten Part in die Auslagerungsdatei
verschieben. Gilt für Linux und Windows gleichermaßen.
Jim M. schrieb:> Wenn Du bei einem VServer den SWAP ständig nutzt, zieht der Betreiber> wegen übertriebenem IO schnell den Stecker (oder legt Dir einen dickeren> Vertrag nahe). Daher sind die 1GB schon OK, auch wenn sie weit unter der> üblichen Empfehlung (1-2x RAM) liegt.
vor allem will niemand einen server betreiben der RAM auslagern muss -
ein paar ungenutzte pages sind OK, aber wenn der speicher knapp wird,
und genutzter RAM ausgelagert wird, laggt die maschine nur noch so vor
sich hin.
da es anscheinend um mysql geht, kann man dort die caching parameter
anpassen, so dass der speicher eben nicht voll läuft.
dabei, vor allem wenn nebenbei noch was läuft, eher konservativ bleiben
- es bringt schon viel wenn die indices gecached sind - und wenn
überhaupt zur anwendung passende angelegt sind.
The Amazing Kreskin schrieb:> Verstehe ich das richtig,
Leider nicht. Low und High haben hier nichts mit der Speicherbelegung zu
tun, sondern mit dem Konzept von "High Memory" [1-3]. Das hatte etwas
mit dem Memory-Mapping in den PAE-Erweiterungen für 32Bit-Systeme zu
tun. Auf einem 64Bit-System wie Deinem spielt diese Ausgabe keine Rolle
mehr -- Du kannst sie daher getrost ignorieren.
[1] http://tldp.org/HOWTO/KernelAnalysis-HOWTO-7.html
[2] http://linux-mm.org/HighMemory
[3] https://www.kernel.org/doc/gorman/html/understand/understand012.html> Und sind nur ca. 1 GB Swap verfügbar? Ist das nicht etwas zu wenig?
Nein, es sei denn, Deine Maschine wäre stark unterdimensioniert.
> Und kann man irgendwie mit Bordmitteln abschätzen, ob der Peak ein> einsames Ereignis in ferner Vergangenheit war, oder ob der Server> häufiger mit hoher RAM-Auslastung zu kämpfen hat? Also ohne apt-get> install...
Nein. Mit dem Paket "sysstat" gibt es ein Paket, in dem (unter anderem)
die SAR-Suite (system activity reporter) enthalten ist. Dieses Paket
kannst Du mit "apt install sysstat" installieren und SAR in
/etc/default/sysstat und /etc/sysstat/* so konfigurieren, daß periodisch
die Performancecounter des Linux-Kernels ausgelesen, zurückgesetzt und
die gelesenen Daten gespeichert werden. Diese Daten können dann mit dem
Programm sar(1) tabellarisch, oder mit dem ebenfalls in der SAR-Suite
enthaltenen Programm sadf(1) in einigen gebräuchlichen Formaten wie XML
oder JSON ausgegeben werden. Ebenfalls im sysstat-Paket enthalten sind
eine Reihe weiterer nützlicher Werkzeuge zur Messung und Analyse der
Systemperformance, zum Beispiel vmstat, pidstat, iostat und mpstat zur
Beobachtung von Virtual Memory, Prozessen, CPU-Last, I/O-Last von
Speichergeräten und Partitionen sowie Prozessoren. Es gibt noch
Alternativen zu SAR wie zum Beispiel collectd, das kenne ich aber
bislang nur dem Namen nach -- YMMV.
Beiden Paketen gemein ist allerdings, daß sie erstens vermutlich erst
installiert werden müssen und es zweitens gewisser Kenntnisse bedarf, um
sie sinnvoll nutzen und ihre Ergebnisse gewinnbringend interpretieren zu
können. Ein Werkzeug, dessen Aufgaben Du nicht verstehst, ist im besten
Falle verwirrend und im schlimmsten Falle sogar kontraproduktiv, weil Du
aus den Ausgaben wahrscheinlich die falschen Schlüsse ziehen und
deswegen höchstwahrscheinlich falsche Entscheidungen treffen würdest.
Versteh' mich nicht falsch, ich will Dich keinesfalls entmutigen. Aber
Du solltest wissen, daß Performanceoptimierung ein sehr weites Feld ist,
für dessen Beherrschung man sehr viel lernen muß und das sich trotzdem
häufig nicht lohnt, weil leistungsfähigere Hardware wesentlich billiger
ist, als mit einem enormen Aufwand an Fachkompetenz und Arbeit das
letzte bisschen Leistung aus einer vorhandenen Hardware zu kitzeln. ;-)
> Und wie fein aufgelöst sind die Low-Daten überhaupt?
Gar nicht, free(1) zeigt nur einen aktuellen Snapshot.
The Amazing Kreskin schrieb:> mal angenommen es kommt zu etwas mehr Last als gewöhnlich und 8GB würden> nicht mehr reichen, 10GB theoretisch jedoch schon...was würde dann> passieren, wenn "nur" 1 GB Swap vorhanden ist?
Dann schlägt Linux OOM-Killer zu und tötet den Prozeß, der ihm nach
diversen Kriterien am Unwichtigsten erscheint. Deswegen ist es Deine
Aufgabe, dies zu verhindern, indem Du die Limits von Apache, MySQL und
PHP setzt sowie die ulimit-Konfiguration des Systems passend einstellst.
Ein sehr guter Hoster mit einer LAMP-Komplettlösung könnte diese
Konfigurationen in Abhängigkeit von dem von Dir bestellten Systemsizing
bereits mit (für Dich mal mehr, mal weniger) sinnvollen Defaultwerten
vorbelegt haben.
> Ich habe in einem Blog> gelesen, dass sich der mysqld runtergefahren hat, weil er für den> InnoDB-Buffer-Pool keinen Speicher allozieren konnte.
Das wird an einer fehlerhaften MySQL-Konfiguration gelegen haben.