vServer und Ram-Verteilung Dienste sinnvoll konfigurieren

[stefkey]

Hallo zusammen,

ich müsste mich mal mit der Auslastung meines RAM beschäftigen. Meine Maschine ist ein Webserver mit 4GB Ram. Ich habe an den Standardkonfigurationen der Dienste bzgl. Ram nichts verändert, außer bei der DB.

Nur ich arbeite auf dem Server, es sind keine Kunden drauf, jedoch betreibe ich mehrere Projekte darauf die nichts miteinander zu tun haben sollen.

Es läuft darauf:
Ubuntu 16.04
nginx
php5.6 (inkl den üblichen Modulen)
php7.0 (inkl den üblichen Modulen)
php7.1 (inkl den üblichen Modulen)
mariadb
elasticsearch
redis-server
dovecot
postfix
amavis
clamav
clamav-daemon
spamassassin


Meine ersten Fragen:

1.
php7.1 wird zurzeit von keinem vhost benutzt. Soll ich das dann deinstallieren, oder braucht es auch so keinen RAM

2.
Insbesondere amavis, clamav, clamav-daemon, spamassassin brauchen relativ viel Ram. Stimmts?

3.
Gibt es typische Konfigurationen für Webserverbetrieb. Sowas wie zB "nutze 1GB für php". Vorallem was die php Geschichte angeht steh ich im dunkeln. jeder vhost hat einen eigenen "php-sock" Ist das sinnvoll

4. Be einem host habe ich folgende php-Konfig. Die ist aber vermutlich zu hoch und Frist Ram, oder:

pm = static
pm.max_children = 40
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 40

Im Anhang mal ein Screenshot von top

 

[PHP-Friends]

"It depends"

Wenn kein vHost PHP 7.1 nutzt, wird diese Version auch nicht in Form eines PHP-FPM-Pools vorgehalten. Das reine Vorhandensein der Software zieht keinen RAM. Grundsätzlich zieht deine Konfiguration wie du sie genannt hast natürlich mehr RAM für das Vorhalten von PHP-Prozessen, aber eine pauschale Aussage, ob das nun "zu viele" sind, ist nicht möglich. In top ist aber ersichtlich, dass dein Server den absoluten Großteil für den Disk-Cache verwendet, also ist eigentlich alles in Ordnung bzw. nichts "überlastet".

In der Regel ist es aber bei heutigen RAM-Preisen sinnvoll, lieber Apache-Worker, PHP-Prozesse etc. vorzuhalten, statt RAM zu "sparen", denn von freiem RAM hast du sowieso nichts. Das Starten / Forken etwaiger Prozesse "ondemand" ist immer langsamer, als wenn sie schon da sind, wenn sie gebraucht werden. Zudem geht gerade PHP-FPM auch bei vielen Workern bzw. Children extrem sparsam vor. Wir verwenden hier bei managed Servern auch gerne größere Werte.


Viele Grüße
Tim

 

[marce]

Hm. Ich würde sagen, solange es einigermaßen "produktiv" sein sol braucht allein jeder dieser Services

mariadb
elasticsearch
redis-server

je 4GB um einigermaßen stabil zu laufen.

 

[PHP-Friends]

Elasticsearch kann ich nicht beurteilen, aber bei Redis und MySQL kommt es primär darauf an, wie viele Daten da so drin liegen...

 

[stefkey]

Danke php-friends, habe gerade mal nach Ram Auslastung sortiert. Das sieht ja schon heftig aus. Grund warum ich mich näher damit beschäftigen will ist das mein mysql-server abstürzt, und zwar schon 2 mal in der Nacht.
Im Log steht:

Mar 14 06:16:30 vserva kernel: Out of memory: Kill process 10977 (mysqld) score 88 or sacrifice child
Mar 14 06:16:30 vserva kernel: Killed process 10977 (mysqld) total-vm:1687104kB, anon-rss:304816kB, file-rss:0kB
Mar 14 06:16:31 vserva mysqld_safe: Number of processes running now: 0
Mar 14 06:16:31 vserva mysqld_safe: mysqld restarted
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] /usr/sbin/mysqld (mysqld 10.0.29-MariaDB-0ubuntu0.16.04.1) starting as process 29500 ...
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Using mutexes to ref count buffer pool pages
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: The InnoDB memory heap is disabled
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Compressed tables use zlib 1.2.8
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Using Linux native AIO
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Using CPU crc32 instructions
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] InnoDB: Initializing buffer pool, size = 1.0G
Mar 14 06:16:31 vserva mysqld: InnoDB: mmap(558891008 bytes) failed; errno 12
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [ERROR] Plugin 'InnoDB' init function returned error.
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] Plugin 'FEEDBACK' is disabled.
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [ERROR] Unknown/unsupported storage engine: InnoDB
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [ERROR] Aborting
Mar 14 06:16:31 vserva mysqld: 
Mar 14 06:16:31 vserva mysqld: 170314  6:16:31 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 14 06:16:31 vserva mysqld: 
Mar 14 06:16:31 vserva mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mar 14 06:16:32 vserva freshclam[2262]: daily.cld updated (version: 23202, sigs: 1784417, f-level: 63, builder: neo)
Mar 14 06:16:32 vserva freshclam[2262]: bytecode.cvd is up to date (version: 291, sigs: 55, f-level: 63, builder: neo)

 

[PHP-Friends]

InnoDB: Cannot allocate memory for the buffer pool

Sieht so aus, als wäre etwas anderes das Problem gewesen, da du ja aktuell auch die 1 GB allozieren kannst. Vermutlich kannst du hier mit vmstat, atop und z.B. Munin weiterforschen, wann warum solche RAM-Peaks auftauchen.

Deine gesamte Konfiguration des mysqld wäre aber auch interessant. Man kann sich bei MySQL an sehr vielen Stellen die maximale RAM-Usage so verkonfigurieren, dass - wenn genug zusammen kommt - einzelne MySQL-Direktiven in Summe dann viel mehr RAM allozieren können (wollen), als das System hat.


Viele Grüße
Tim

 

[stefkey]

@marce. Jo, sowas hab ich mir schon gedacht ;-)

Aber die können theoretisch auch mit weniger laufen ohne das sie etwas "kaputt" machen, richtig? Nur sind sie dann nicht mehr vorteilhaft, kann man das so sehen?

PS Ich habe eine Neos CMS Seite. Damit das Backend einigermaßen flüssig läuft braucht es idealerweise elasticsearch zum cachen, daher das schon mal

 

[marce]

Klar, bei MariaDB und Redis kommt es auf die Datenmenge und Operationen darauf an.

ES - Da kommt es auch sehr auf die Daten an, aber grundlegend ist ein aktueller ES mit weniger als 2GB nicht zu betreiben. Der semmelt Dir bei fast jeder Anfrage mit einer OOM-Meldung ab. Die gleiche Menge an Speicher dann noch für Caches vorhalten.
Zu den konkreten Anforderungen siehe Doku von ES - "grob" kann man sagen, daß die search-Indices in den Ram passen müssen und der ES drumrum auch noch.

 

[danton]

ClamAV ist IMHO auch eine Sache, die überflüssig ist - viele False Positive und ansonsten eine schlechte Erkennungsleistung. Damit wäre auch Amavis überflüssig, Spamassassin läßt sich auch ohne in Postfix einbinden. Ich weiß nicht, wieviel es bringt, da ich ClamAV schon seit längerem von der Platte getreten habe.