apache und mysql - RAM-Verteilung


E

efanucar

New Member
Hallo zusammen!

Ich hoffe Ihr könnt einem etwas unerfahrenen Admin bei einer Konfiguration helfen, muss schnell einen Server einigermaßen konfigurieren.
Der Server hat 12 GB RAM und Intel i7 975 (3.33 Ghz), laut /proc/cpuinfo 8 cores.

Apache und mysql laufen auf dem Server und sollen mit den 12 GB zurecht kommen, ohne zu swappen. In der momentan Konfiguration hat ein apache-Prozess im Schnitt VIRT 280m und RES 20m, mysql belegt zusammen VIRT 2700m und RES 720m. Freien Speicher habe ich derzeit 500M aber teilweise wird schon geswapped.

Ich glaube mysql verhält sich ganz ordentlich und belegt nicht allzuviel speicher (die Konfiguration ist angelehnt an my-huge.cnf, wo 4 GB als verfügbar angenommen werden).
Das Problem ist glaube ich der apache. Allerdings weiß ich nicht, wie ich den Speicherverbrauch dort senken kann.

Könnte jemand kurz mal die Konfiguration ansehen und mir vielleicht einen Tipp in die richtige Richtung geben?

Vielen Dank!!

apache, prefork:
Code: 
StartServers         5
MinSpareServers      5
MaxSpareServers     10
ServerLimit        150
MaxClients         150
MaxRequestsPerChild  10000

mysql, zu 90% innodb-tables:
Code: 
key_buffer_size = 32M
table_open_cache = 1024
sort_buffer_size = 8M
net_buffer_length = 16M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
thread_cache = 8
thread_concurrency = 8
max_connections = 150
open_files_limit = 2048
table_cache = 512
myisam_sort_buffer_size = 8M
query_cache_size = 64M
query_cache_limit = 2M
max_heap_table_size = 64M
join_buffer_size = 8M
tmp_table_size = 64M

log_bin=mysql-bin
sync_binlog=1

innodb_buffer_pool_size = 2G
innodb_additional_mem_pool_size = 16M
innodb_thread_concurrency = 16
innodb_log_file_size = 1024M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_support_xa=1
innodb_lock_wait_timeout = 120
innodb_max_dirty_pages_pct = 90
 
Was hast Du gegen den Swap? Du darfst das nicht mit Windows vergleichen. Das System lagert einfach nicht so dringend benötigte Dinge in den Swap aus. Damit ist mehr Platz für wichtige Dinge. Das Swap / Memorymanagment von Linux ist erste Sahne, Du musst Dir also wegen den bisschen Swap nicht den Kopf zerbrechen.

Weiterhin wären doch mal ein paar Daten interessant. Dein Ramverbrauch passt nicht zu Deiner Apache Config. Wenn Du einen solch heftigen Besuch hast, dass 12 GB am RAM verschwinden, ist Deine Apache Config wohl nicht korrekt.

Um die korrekte Config für mySQL zu bekommen, empfehle ich Dir die Sache mal mittels der "primer.sh" zu optimieren. https://launchpad.net/mysql-tuning-primer/+download

Ansonsten wie gesagt, wären ein paar mehr Daten nett ;)

Liebe Grüße aus Leipzig
 
Nur weil man 12 GB Speicher hat, heißt es nicht, dass die Maschine nicht swapt. Warum auch? Es wird i.d.R. Speicher ausgelagert, der schon lange nicht mehr genutzt wurde. Dadurch wird Platz für den HD-Cache geschaffen.
Du darfst Grundsätzlich nicht den ganzen RAM mit Software zu müllen. Lass dem System Luft zum Atmen.

Deine Angaben reichen nicht als vollständige Info. Aber tröste Dich, eine vollständige Aufstellung aller Daten kannst Du eh nicht bringen. Allein schon deshalb, weil sie schneller veralten als Du sie zusammen sammeln kannst.
Bzgl. MySQL: Nutze (und/oder suche vorher die Info von) tuning-primer-script. Mit seiner Aussage kann man mehr Tipps abgeben als mit den reinen Konfig-Daten.
Zu Apache: wichtige Info's wären wie PHP eingesetzt wird. Also mod_php, über FastCGI oder Mischung aus beiden...

huschi.

/edit: Och Mann nööö! Alles umsonst... :(
 
Last edited by a moderator:
Danke schon mal für die Infos. Hatte nur gestern rund 2 GB im swap und auch das Gefühl das mysql dadurch sehr langsam geworden ist.

Hier mal ein Auszug aus top, sortiert nach VIRT

Code: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16173 mysql     20   0 2705m 728m 7020 S    1  6.1  17:21.38 mysqld
11711 wwwrun    20   0  288m  20m 4432 S    0  0.2   0:01.78 httpd2-prefork
12063 wwwrun    20   0  287m  19m 3952 S    2  0.2   0:00.42 httpd2-prefork
12092 wwwrun    20   0  287m  19m 3764 S    0  0.2   0:00.19 httpd2-prefork
12055 wwwrun    20   0  287m  19m 3952 S    0  0.2   0:00.08 httpd2-prefork
12066 wwwrun    20   0  287m  19m 3924 S    0  0.2   0:00.12 httpd2-prefork
12084 wwwrun    20   0  287m  19m 3792 S    2  0.2   0:00.14 httpd2-prefork
12083 wwwrun    20   0  286m  18m 4036 S    0  0.2   0:00.21 httpd2-prefork
11837 wwwrun    20   0  285m  18m 4440 S    2  0.2   0:00.53 httpd2-prefork
12091 wwwrun    20   0  285m  17m 3664 S    0  0.1   0:00.10 httpd2-prefork
12094 wwwrun    20   0  285m  17m 3812 S    0  0.1   0:00.13 httpd2-prefork
12088 wwwrun    20   0  285m  17m 3644 S    0  0.1   0:00.23 httpd2-prefork
12090 wwwrun    20   0  282m  14m 4392 S    0  0.1   0:00.13 httpd2-prefork
12050 wwwrun    20   0  280m  12m 3788 S    0  0.1   0:00.15 httpd2-prefork
12065 wwwrun    20   0  280m  10m 3956 S    0  0.1   0:00.41 httpd2-prefork
11496 wwwrun    20   0  280m  12m 4128 S    0  0.1   0:01.01 httpd2-prefork
11777 wwwrun    20   0  280m  12m 3864 S    0  0.1   0:00.79 httpd2-prefork
11714 wwwrun    20   0  280m  10m 3100 S    0  0.1   0:00.71 httpd2-prefork
12112 wwwrun    20   0  280m  11m 3456 S    0  0.1   0:00.05 httpd2-prefork
11746 wwwrun    20   0  280m  12m 3752 S    0  0.1   0:00.13 httpd2-prefork
11753 wwwrun    20   0  279m  13m 5116 S    0  0.1   0:00.59 httpd2-prefork
12085 wwwrun    20   0  279m  10m 3872 S    0  0.1   0:00.02 httpd2-prefork
11680 wwwrun    20   0  278m  11m 4472 S    0  0.1   0:00.60 httpd2-prefork
11827 wwwrun    20   0  278m  10m 3840 S    0  0.1   0:00.39 httpd2-prefork
11550 wwwrun    20   0  278m  10m 3460 R    0  0.1   0:00.67 httpd2-prefork
12087 wwwrun    20   0  278m 9500 3288 S    0  0.1   0:00.03 httpd2-prefork
12103 wwwrun    20   0  278m 9284 3112 S    0  0.1   0:00.00 httpd2-prefork
12078 wwwrun    20   0  278m 7812 1264 S    0  0.1   0:00.01 httpd2-prefork
12105 wwwrun    20   0  277m 7612 1560 S    0  0.1   0:00.00 httpd2-prefork
12104 wwwrun    20   0  277m 7448 1476 S    0  0.1   0:00.00 httpd2-prefork
12113 wwwrun    20   0  277m 7516 1528 S    0  0.1   0:00.01 httpd2-prefork
12114 wwwrun    20   0  277m 7520 1528 S    1  0.1   0:00.02 httpd2-prefork
15890 root      20   0  277m  12m 6496 S    0  0.1   0:04.16 httpd2-prefork
 1774 root      20   0  184m 1440  972 S    0  0.0   7:26.31 rsyslogd
 1504 root      20   0  105m 1140  936 S    0  0.0   0:09.72 console-kit-dae

Welche Daten sind noch hilfreich?

Hauptanwendung auf dem apache ist php mit Zend AMF Erweiterung als Remote-Zielpunkt für eine Flex-Anwendung.
Eventuell ist Zend AMF verschwenderisch mit RAM...?

Nach meiner Info kann man apache in etwas so viele Client-Prozesse erlauben wie (RAM / REST-Wert) minus Sicherheit, das wären bei mir ja sehr viele, wenn man z.B: mal von 6GB ausgeht, den man apache geben möchte:
6 GB / 20 MB => über 300. Wenn ich mir da den Speicher gerade ansehen bei so wenig Childs würde der Server bei 300 garantiert instabil...oder verstehe ich da was falsch?
 
300 Apache auf 8 Kernen (wovon die Hälfte gethreaded ist) macht 37 Prozesse pro Kern. Plus Kernel, plus MySQL, plus plus plus.
Glaubst Du allen Ernstes, dass das eine gute Idee ist?

Zend_AMF ist doch auch nur eine reine PHP-Anwendung die unter dem Apache läuft. Sicherlich ist Zend nicht gerade als Resourcen-Schonen anzusehen, aber sollte mit der Maschine kein Problem darstellen.
Wie gesagt ist mod_php vs. mod_fcgid noch interessant. Denn die verwalten ihren Speicher unterschiedlich. Gerade bei gleichzeitiger Benutzung kann das gewaltig ausarten.

huschi.
 
Naja, ich sag ja, bei 300 wird er sicher instabil ;-)

Momentan ist die Konfiguration ja bei 150, vielleicht ist das ja auch schon zuviel. Aber was ich bisher bei top beobachtet habe wird dieses Limit im normalen Betrieb nicht erreicht. Aber trotzdem wird der Speicher knapp.

apache2ctl -t -D DUMP_MODULES
Code: 
Loaded Modules:
 core_module (static)
 mpm_prefork_module (static)
 http_module (static)
 so_module (static)
 authz_host_module (shared)
 actions_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authz_groupfile_module (shared)
 authn_file_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 dir_module (shared)
 include_module (shared)
 log_config_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 setenvif_module (shared)
 status_module (shared)
 userdir_module (shared)
 asis_module (shared)
 headers_module (shared)
 imagemap_module (shared)
 ssl_module (shared)
 authz_default_module (shared)
 php5_module (shared)
 rewrite_module (shared)

PHP ist also über mod_php geladen, wenn ich das richtig verstehe...

Sollte ich hier vielleicht noch etwas rausschmeißen?

Danke nochmal für die Hilfestellung!
 
Wie gesagt, fange erst einmal mit der Optimierung von mySQL an. (siehe mein 1. Post). Dort verschwindet auch einiges an RAM.

Es wäre noch interessant, wieviel Besucher so am Tag auf Deine Seite kommen und wie lange die Scriptlaufzeiten sind. Ggf. könnte man die Apacheprozesse schneller beenden. Es kann zum Beispiel zum Problem werden, wenn der Apache zu langsam nach "unten regelt" sondern seine Kinder ewig am Leben erhält.

Um was für eine Art Content handelt es sich denn. An Hand eines Snap von der TOP Ausgabe, kann man nichts optimieren ;)
 
Huschi said:
300 Apache auf 8 Kernen (wovon die Hälfte gethreaded ist) macht 37 Prozesse pro Kern. Plus Kernel, plus MySQL, plus plus plus.
Glaubst Du allen Ernstes, dass das eine gute Idee ist?
Click to expand...

MySQL mal außen vor gelassen, Apache verbringt doch einen guten Teil seiner Zeit mit I/O Operationen, wieso sollten da 40 bzw. 80 Prozesse pro Kern ein Problem sein? Bzw. wäre hier dann nicht in erster Linie die Load Average das entscheidende?

Bei Seiten mit vielen Besuchern bzw. vielen statischen Inhalten und mod_php (also ohne fcgi-Konstrukte oder davor geschaltete Webserver für statische Inhalte, etc.) kommt man um solche Werte nicht herum da sonst die Besucher ja auf freie Prozesse warten müssten - während das System eigentlich noch bei weitem nicht ausgelastet ist.


Ansonsten bleibt natürlich trozdem die Frage an den TE ob/was hier zu optimieren ist, soweit ich sehen kann wurde nirgends ein Problem beschrieben.
 
Dex said:
Ansonsten bleibt natürlich trozdem die Frage an den TE ob/was hier zu optimieren ist,
Click to expand...
Wenn ich mir seinen Ausschnitt aus der my.cnf ansehe, dann ist da Einiges zu optimieren/korrigieren. Aber Huschi wird das an Hand der Ausgabe vom tuning-primer.sh schon erkennen, die my.cnf braucht er dazu ja nicht...

Sorry für den Sarkasmus, aber die offensichtlichen Fehlkonfigurationen in der geposteten my.cnf findet tuning-primer.sh nicht, im Gegenteil, es wird weitere falsche Konfgurationen vorschlagen.

Naja, mir egal, Huschi macht das schon...
 
Hi,

Huschi said:
300 Apache auf 8 Kernen (wovon die Hälfte gethreaded ist) macht 37 Prozesse pro Kern. Plus Kernel, plus MySQL, plus plus plus.
Glaubst Du allen Ernstes, dass das eine gute Idee ist?
Click to expand...

Das ist ein völlig unproblematischer Wert. Ich arbeite beim Loadbalancer eines Kunden mit 1000 Threads pro Kern. Wenn viele Keepalive-Verbindungen benötigt werden, führt an so hohen Werten beim Apache kein Weg vorbei, es sei denn, man benutzt mod_event als MPM (was aber erst sein 2.4 stabil ist).

Ich denke nicht, dass die Speicherauslastung durch den Apache selbst verursacht wird. Da dürfte dann eher mod_php im Spiel sein. Wenn das der Fall ist, würde ich nach Möglichkeit auf FastCGI wechseln. Wenn das nicht möglich ist, und die 300 Prozesse benötigt werden, dann benötigt der Server wohl eine Erweiterung des Arbeitsspeichers.

CU
Tom09
 
Last edited by a moderator:
Da dürfte dann eher mod_php im Spiel sein. Wenn das der Fall ist, würde ich nach Möglichkeit auf FastCGI wechseln.
Click to expand...
Einen Pool an PHP-Prozessen je vHost staendig im Hintergrund zu halten ist ja auch sooooo RAM-sparsam :D

Ich arbeite beim Loadbalancer eines Kunden mit 1000 Threads pro Kern.
Click to expand...
keep-alive wuerde ich an einen entsprechenden Reverse-Proxy (Engine-X, Varnish, ...) auslagern um Probleme mit Apache's Limits und RAM-Verbrauch zu vermeiden.
Als positiver Nebeneffekt kann es die ganzen slow-Attacken (slowloris, slowread) bei geeigneter Konfiguration performanceschonend blockieren.
Aber generell sind zig Tausend Threads kein Problem solange sie nicht jeweils einen dedizierten RAM-Verbrauch ueber paar KB haben.
 
Hallo zusammen!

Erstmal vielen Dank für die interessanten Feedbacks.

Mein Anliegen war hauptsächlich mögliche Optimierungen zu erkennen. Im normalen Betrieb läuft der Server ganz gut, aber es gibt Spitzenzeiten wo die Antwortzeiten quälend langsam werden, da hatte ich erstmal MySQL und Swap im Verdacht. Und dann eben den Apache weil er eventuell die Ursache ist und den RAM frisst.

@Joe User:
Kann gut sein, dass die MySQL-Konfiguration nicht optimal ist, hatte ich ja am Anfang schon angekündigt.
Aber wenn Du offensichtliche Fehler in der Konfiguration entdeckt hast, dann wäre es für mich (und für Mitleser sicher auch) interessant wenn Du hier mal aufzeigst. Danke!

Bin sonst eigentlich auch der Meinung dass die Threads von Apache für die CPU kein Problem sein sollten...die Größenordnung liest man auch in Fachbüchern etc.

@Tom09:
Ein Wechsel auf FastCGI ist nicht so ohne weiteres möglich, ist ein laufendes Produktivsystem und ich muss erstmal die eventuellen Auswirkungen prüfen.
Wie finde ich denn heraus ob mod_php "Schuld" ist bzw. wo kann man dort den Speicherverbrauch kontrollieren/konfigurieren?
 
Auf http://www.rootservice.org/howtos/freebsd/hosting_system.html findest Du meine Default-my.cnf, die seit Jahren auf vielen unterschiedlichen Systemen zum Einsatz kommt. In dieser my.cnf passt Du bitte die Pfade an, setzt die max_connections vorerst auf 50 bis 100 und ergänzt innodb_support_xa=1 wenn Du es benötigst. Dann lässt Du den MySQLd mindestens 48h damit laufen und postest dann die Ausgaben von tuning-primer.sh und mysqltuner.pl. Damit kann man dann weiterarbeiten.

Für Apache findest Du auf http://www.rootservice.org/howtos/freebsd/hosting_system.html ebenfalls eine Beispiel-Config, die Du zwar nicht direkt übernehmen kannst, da Deine Linux-Distro zu viele Anpassungen erfordern würde, aber als grobe Vorlage und Denkanstoss ist sie dennoch brauchbar für Dich.
 
You must log in or register to reply here.

Back
Top