Apache memory error

Joe User said:
Nein. Das Limit für Shared Memory Segments liegt bei 32MB, Dein Prozess will aber mehr reservieren und wird deshalb abgeschossen.
Du solltest Deinem Prozess beibringen mehrere Segments < 32 MB zu reservieren...
Click to expand...


@themonk
Ich gehe mal davon aus, dass du weißt was du tust und hast deinen Server vorher auch schon komplett gesichert.

Nur ein Vorschlag: Was du auch mal ausprobieren könntest, sind folgende Befehle als Nutzer root auf dem Server auszuführen:

cat /proc/sys/kernel/shmmax
18446744073692774399

Diesen Wert habe ich als Rückgabewert von meinem Server erhalten und für die folgenden Befehle auch weiterhin übernommen.

echo 18446744073692774399 > /proc/sys/kernel/shmmax

sysctl -w kernel.shmmax=18446744073692774399

echo "kernel.shmmax=18446744073692774399" >> /etc/sysctl.conf

sysctl -p

Die Werte sollten dann in etwa wie folgt aussehen:

ipcs -lm

------ Gemeinsamer Speicher: Grenzen --------
max number of segments = 4096
max seg size (kbytes) = 18014398509465599
max total shared memory (kbytes) = 18014398442373116
min seg size (bytes) = 1
 
@Joe User mit root meinst du den Admin von meinem vServer oder meinen Anbieter? Da ich den vServer selber betreue bin ich quasi der Root. Sonst hätte ich die Frage hier nicht stellen müssern und hätte meinen root gefragt :).

@andreas0 das was du schreibst könnte eine Lösung sein. Zumindest wurde etwas ähnliches auch hier beschrieben. Allerdings muss ich gestehen, dass mir das etwas zu riskant ist, da ich nicht genau weiß was der Befehl macht. Also er erhöht den maximalen Shared Memory aber, ob das eine gute Idee ist weiß ich nicht :).

Ich glaub der Fehler liegt an dem verwendeten OpCache und PHP-FastCGI. In diesem Zusammenhang habe ich Lösungen gefunden die entweder empfehlen statt fcgi php-fpm zu verwenden oder den OpCache abzuschalten.
Wie hier zu lesen ist funktioniert der Cache bei PHP auf Shared-Hosting-Servern nicht richtig, sondern nur auf Dedicated-Servern. Ab PHP 7 scheint es wohl wieder zu funktionieren.
Was glaub ich bei mir aktuell ganz gut läuft ist den OpCache auf 32MB zu beschränken. Somit habe ich zwar nicht die Standart 64MB aber besser 32MB als das ganze abzuschalten :)
 
PHP-Friends said:
Wie schon dein Vorposter sagte:

Code: 
cat /proc/user_beancounters
Click to expand...

Es ist tatsächlich ein Virtuozzo vServern.
Die Werte sind folgende. Denke die oberen sind die wichtigen:
PHP: 
uid  resource                     held              maxheld              barrier                limit              failcnt
     1212:  kmemsize                 46869410             50274304            196636764            217374182                   19
            lockedpages                     0                    0                 1840                 1840                    0
            privvmpages                555376               561712              4096000              4096000                    0
            shmpages                   149617               149617               262144               262144                  963
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                       139                  180                 1000                 1000                    0
            physpages                  867785               879533              1024000              1024000                    0
            vmguarpages                     0                    0              1024000           2147483647                    0
            oomguarpages               285407               291889              1024000           2147483647                    0
            numtcpsock                     39                   41                 1000                 1000                    0
....
 
@themonk
Wenn ich deinen Auszug user_beancounters richtig interpretiere, so wurden dir nur ca. 4GB zugesichert. Und alles was darüber angefordert wird, wird vom System einfach abgelehnt oder wird im Swap ausgelagert.
 
Alle anderen haben einen failcnt von 0.

Das der Wert oft überschritten wurde habe ich auch gesehen. Habe auch vermutet, dass ich wohl den RAM irgendwo ausgereizt habe. Aber was genau bedeutet das nun für mich?

Habe in diesem Zusammenhang jetzt nur gelesen, dass einige, wie ich schon erwähnt habe, den OpCache oder FastCGI deaktiviert haben oder beim Hoster um einen höheren shmpages gebettelt haben.

==Edit==
@andreas0 4GB stehen mir ja auch zu. Oder bedeutet dies, dass ich keine dynamischen 4GB habe?
 
themonk said:
==Edit==
@andreas0 4GB stehen mir ja auch zu. Oder bedeutet dies, dass ich keine dynamischen 4GB habe?
Click to expand...

Ich interpretiere es so, dass dir die ersten 4GB laut dem Auszug user_beancounters gegeben wurden, aber alles darüber nicht. Also, keine weiteren 4GB, so dass du am Ende 8GB RAM hättest.
 
themonk said:
Aber was genau bedeutet das nun für mich?
Click to expand...

Du liest aber schon, was andere schreiben, oder...?

Joe User said:
Dein root sollte also erstmal alle (ich betone ALLE) auf dem System vorhandene Konfigurationen sorgfältig überprüfen (sollte er ohnehin regelmässig tun). Danach das System auf das absolut Nötigste zusammenschrumpfen und wenn das Problem dann immernoch besteht, geht es los mit strace und anderen Debuggern das System systematisch abzuklappern. Wenn auch das nicht hilft, sollten bereits genug Infos für das Abklappern diverser Bugzillas vorhanden sein. Bleibt auch dies ohne Erfolg, dann kann man noch die Mailinglisten durchsuchen und letztendlich einen Bugreport vefassen.
Click to expand...
 
andreas0 said:
Ich interpretiere es so, dass dir die ersten 4GB laut dem Auszug user_beancounters gegeben wurden, aber alles darüber nicht. Also, keine weiteren 4GB, so dass du am Ende 8GB RAM hättest.
Click to expand...

Also keinen dynamischen 4GB? Und egal wieviel Platz auf dem Server ist mehr als 4GB bekomme ich nie?

Was mir noch gerade aufgefallen ist. Bei meinem alten Server mit "nur" 2 GB RAM habe ich bei shmpages ein Limit von 9223372036854775807 und somit auch failcnt von 0.

Ich würden den shmpages jetzt so interpretieren das ich aktuell keinen zusätzlichen RAM bekomme (oder nur sehr wenig) und auf dem alten Server mit dem Wert 9223372036854775807 "unendlich" nutzen konnte. Ist das richtig?



nexus said:
Du liest aber schon, was andere schreiben, oder...?
Click to expand...

Ja selbstverständlich. Habe das System erst vor knapp 2 Wochen neu installiert. Wüsste daher ehrlich gesagt nicht was ich an den Konfigurationen prüfen sollte oder worauf ich achten müsste.
 
themonk said:
Also keinen dynamischen 4GB? Und egal wieviel Platz auf dem Server ist mehr als 4GB bekomme ich nie?
Click to expand...

Wenn du free -m eingibst, was du ja schon weiter vorher schon mal gemacht hattest, und du nur 4000 MB angezeigt bekommst, so ist dies auch deine maximale Grüße deines RAM´s. Mehr bekommst du dann auch nicht, auch wenn du ihn versuchst anzufordern.
 
Nochmal zum Mitmeisseln:

RAM ist nicht Dein Problem!



@Andreas0
Bitte keine offensichtlichen Bullshit-Vorschläge, es gibt nur sehr wenige Systeme die grössere als 128MB shared Memory Segments benötigen und das sind definitiv keine VMs, denn innerhalb von VMs ist deren Aufgaben kaum realisierbar. Darüberhinaus ist "unbegrenzter" Shared Memory ein schönes Mittel zum (Self-)DoS. Und innerhalb VMs ist Shared Memory auch noch ein generelles Sicherheitsproblem.

Ein shmmax von 134217728 ist also völlig ausreichend und zusammen mit einem shmall von 32768 auch auf nahezu allen Systemen noch uneingeschränkt für (Self-)DoS geeignet.

Unabhängig davon, wird der OP auf seinem System kaum Einfluss auf den Kernel nehmen können...
 
Joe User said:
... Und innerhalb VMs ist Shared Memory auch noch ein generelles Sicherheitsproblem.
Click to expand...

Könntest du bitte dieses Sicherheitsproblem mal näher erläutern und wann macht sich dieses Sicherheitsproblem bemerkbar?
 
Mich persönlich wundert es auch dass der Apache soviele Shared Memory Pages braucht. Imho werden die entweder für Libraries genutzt die in mehreren Prozessen gemappt sind, oder aber wenn ich viele Threads habe die die gleichen Pages nutzen (afaik sind Linux pthreads eigentlich nichts anderes als vollwertige Prozesse die mit Shared Memory Pages untereinander den gleichen Speicher nutzen).

Seis drum, ich würde erstmal in /proc/ graben und sehen ob wirklich ein Prozess (der Apache) sehr viele Shared Memory Pages nutzt. Danach würd ich ihn mit Apache Bench etwas stressen und sehen ob er dann (weil er neue Threads öffnet) signifikant mehr Shared Memory Pages braucht.

Wenn damit die Herkunft des Fehlers nachvollziehbar geklärt wäre würde ich entweder die max. Threads des Apachen einschränken, oder das MPM-Modul ändern (z.B. Prefork, Worker oder Event).

Siehe: http://www.liquidweb.com/kb/apache-mpms-explained/

Thomas

PS: Oder was ich an deiner Stelle noch eher vorschlagen würde: Hol dir bei PHP-Friends, netcup (oder einigen anderen) einen KVM vServer und spar dir den ganzen Virtuozzo-Beancounters Ärger. Heute die shmpages, morgen die privvmpages und übermorgen die Inodes... Überraschungen die es bei KVM nicht gibt!
 
Joe User said:
Nochmal zum Mitmeisseln:

RAM ist nicht Dein Problem!
Click to expand...

Habe jetzt OPcache wieder auf 64 gesetzt und bis auf Apache und MySQL soweit alle Service beendet. Der Fehler bleibt. Somit vermute ich das der Fehler nur in der Config von MySQL, Apache oder dem System liegen kann.

Was vielleicht noch wichtig ist. Zu dem Zeitpunkt wo der 500 Fehler kommt läuft ein PHP Skript über einen Cronjob welches eine etwas längere Ausführungszeit hat. Das Skript läuft durch und nur Aufrufe über den Browser (fcgi) machen ab und zu Probleme. Da der RAM ausreichend ist und auch die CPU keine Probleme macht ist die Laufzeit des Skripts, denke ich, nicht das Problem.
 
ThomasChr said:
Mich persönlich wundert es auch dass der Apache soviele Shared Memory Pages braucht.
Click to expand...
Der OP nutzt beispielsweise mod_fcgid um PHP einzubinden und somit ist Apache dann der vermeintliche (aber nicht der wahre) Verursacher.

Ein Grund mehr endlich PHP-FPM zu verwenden.
 
andreas0 said:
Könntest du bitte dieses Sicherheitsproblem mal näher erläutern und wann macht sich dieses Sicherheitsproblem bemerkbar?
Click to expand...

Ein mögliches Szenario:
Da Shared Memory, wie der Name ja schon sagt, von mehreren Diensten/Programmen gemeinsam genutzt wird, kann es passieren, daß Anwendung A nach Beendigung seiner Arbeit den Speicher nicht ordnungsgemäß löscht und dann Anwendung B die noch im Shared Memory liegenden Daten 'weiterverarbeiten' könnte.
 
andreas0 said:
Könntest du bitte dieses Sicherheitsproblem mal näher erläutern und wann macht sich dieses Sicherheitsproblem bemerkbar?
Click to expand...

Für eine entsprechend weitreichende Abhandlung zum Memorymanagement in Hardware und Software ist hier weder die Zeit noch der geeignete Ort. Dafür reicht nichtmal ein durchschnittliches IT-Studium aus...

Du kannst aber gerne nach den seit Ewigkeiten allgemein bekannten Sicherheitsrisiken und -lücken googlen und Dich anhand dieses Materials weiter in die Problematik einarbeiten. Plane ruhig ein paar Jahre ein, Du wirst sie, wie jeder andere auch, benötigen.
 
You must log in or register to reply here.
Back
Top