Auslastung zu hoch (Neuer Thread )

[BeNe]

Für was dieses Script wenn es doch monit gibt ?
Das kann doch das auch alles + noch mehr... aber OK!

@Menki
wegen den PHP-Prozessen, bringt dieser Croneintrag was ?

Code:

09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm

ist aus der PHP5 cron.

Greez BeNe

[menki]

ich habe dieses jetzt in die cron eingefügt...mal abwarten was sich tut....werde weiter berichten.

MENKI

[ZooL]

(03-11-2009 07:25 PM)BeNe Wrote:  Für was dieses Script wenn es doch monit gibt ?
Das kann doch das auch alles + noch mehr... aber OK!

Greez BeNe

naja aber z.B bei menki sind 1338 accounts angelegt.. und da monit drüber rasseln lassen kostet doch dann auch leistung am gewissen punkten denke ich mir.. also einfaches script denke nicht das da was gegen einzuwenden ist und wenn doch...ihr müsst es nicht benutzen

[BeNe]

Quote:naja aber z.B bei menki sind 1338 accounts angelegt.. und da monit drüber rasseln lassen kostet doch dann auch leistung

Macht eigentlich nix anderes als dein Script.
Aber eine alterntive ist immer gut ;-)

Greez BeNe

[menki]

ich habe jetzt festgestellt das auch dann wenn ich die überflüssigen php5 prozesse kille trotzdem der ram voll wird. nach einer bestimmten ziet wird der server ziemlich träge. ich schätze er verliert 20% leistung dadurch aber da er so leistungsstark ist hält er ziemlich lange aus.

@lucan

hast du diese problem irgendwie in den griff kriegen können?

ich könnte ja noch php version von dotdeb installen aber dann kann ich nicht mehr zurück da neuere version oder geht das irgendwie? ich schiebe die schuld auf lenny....irgendeine webserver software php5 oder so macht diese probleme...da die probleme mit fcgid und mit fastcgi aufgetretten sind kann es an diesen beschleuniger nicht liegen.

MENKI

[Lucan]

Bei mir hat der wechsel von fcgid auf fastcgi wunder bewirkt, sowie das korigieren vom Cron.

Meine Ram auslastung kam seit den änderungen nicht mehr über 50%
Die beiden Tage davor bis zu 98%

Wobei die beiden Tage auch etwas besser besucht waren (Wochenende halt)
Kann dir also ne richtige Antwort ob das mein Problem gelöst hat erst in nen paar Tagen geben.


Ebenfalls musste ich die Configs von fastcgi anpassen, da die scheinbar zerschossen waren.
Evtl. bei dir auch mal Prüfen (muss bei mir beim update von RC 7 zur Stable aufgetreten sein)

Verwende auf dem Server keine .dotdeb Versionen.


Apache ist bei mir mit KeepAlive auf ON,
Maxkeepaliverequest ist auf 10
KeepAliveTimeout auf 3
Und verwendet wird prefork als mpm.

Werde da aber nachdem ich das ganze auf den Settings getestet hab mal auf worker wechseln und dort dann weiter beobachten.



Nen wechsel von den dotdeb files wieder zurück dürfte glaube ich nicht so einfach sein, ausser evtl dotdeb in die sources.list aufnehmen, updaten und ggf. wieder die packete purgen, dotdeb source aus der sources.list packen und wieder die gewünschten pakete installieren, wobei das wohl nicht ohne Probleme verlaufen würde.



Grüße

[WuChEn]

(03-12-2009 02:01 AM)menki Wrote:  ich schiebe die schuld auf lenny....irgendeine webserver software php5 oder so macht diese probleme...da die probleme mit fcgid und mit fastcgi aufgetretten sind kann es an diesen beschleuniger nicht liegen.

MENKI

Kann ich nur zustimmen, auch mit fastcgi füllt sich der RAM immer mehr.

Gruß WU

[Lucan]

Überprüft mal die ganzen Settings von Fastcgi, ob da alles richtig ist, bei mir waren manche variablen auch nicht gesetzt.

Dabei daran denken die config im working Ordner auch zu überschreiben.

[menki]

wie es aussieht habe ich mein ram problem in der griff bekommen.
ich fand im englischen forum den link zu diesem finetuning howto:

http://www.isp-control.net/documentation...ces_system

die mysql einstellungen spielen eine grosse rolle in diesem problem. was mich aber am meisten beunruhigt ist diese äusserung in derm fine tuning howto:

Code:

-idle-timeout 300 \
-singleThreshold 100

ermöglicht das absterben eines fastcgi prozesses nach dem die website ausgeliefert wurde. da dieses standardmässig nicht aktiv ist bleiben viele php5-cgi prozesse als leichen über.
seitdem ich diese einstellung in meiner fastcgi config vorgenommen habe BLEIBT KEIN EINZIGER php5 prozess als leiche im system über. dadurch gibts auch kein ram problem mehr. diese option MUSS als standard in ispcp rein! da fcgid als wrapper auf die fastcgi 2.4.6 zugreift gelten auch die selben probleme für fcgid.....

ausserdem setzte ich in der apache.conf:

ThreadStackSize 4000000

ich werde meine server weiter beobachten und ich werde hier posten wenn ich noch eine verbesserung finde.

MENKI

[WuChEn]

Habe nun auch mal die Einstellung "-singleThreshold 100" auch aktiviert, und werd das mal im Auge behalten.

Gruß WU