Dienste sollen DS stärker auslasten

[Schlaefer]

Kann ich irgendwo einstellen, dass gewisse Dienste (z.B. Webstation mit SQL) die DS stärker belasten/auslasten (Speicher und CPU) dürfen. Oder welche Dienste Vorrang haben sollen.
Grund: das CMS auf der DS411+ ist zu langsam und dabei zeigt mir der Resourcenmonitor kaum Speicher- und Prozessorauslastung an.

 

[itari]

Es gibt bei kleinen Linux-Installationen kein Job-Klassenkonzept (Vorrang) und bei den großen Installationen streitet man, ob das überhaupt sinnvoll ist, weil man sich schnell durch virtuelle Machinen (VM) etwas aufsetzen kann.

Den MySQL-Server kann man auch durch geeignete Start-Parameter dazu bringen, mehr RAM zu belegen, aber meist bringt das gar nicht so viel.

Welches CMS setzt denn ein?

Itari

 

[thedude]

Gibt es auf der DS nice?

gruss
dude

 

[Schlaefer]

Drupal 6.2 mit Civicrm 3.4

Kann man PHP auf der DS irgendwie Feuer unter dem Hintern machen? Ich denke, PHP stellt das Hauptproblem dar.
Gibt es ein HowTo für pimp my PHP auf der DS?

 

[Trolli]

Gibt es auf der DS nice?

Es gibt nice als Optware. Frag mich aber nicht, in welchem Paket das drin ist - möglicherweise in den coreutils?

 

[amarthius]

Es gibt nice als Optware. Frag mich aber nicht, in welchem Paket das drin ist - möglicherweise in den coreutils?

Ja ist dort drin.

 

[itari]

Drupal 6.2 mit Civicrm 3.4

Kann man PHP auf der DS irgendwie Feuer unter dem Hintern machen? Ich denke, PHP stellt das Hauptproblem dar.
Gibt es ein HowTo für pimp my PHP auf der DS?

Man kann im DSM einen PHP-Cache einschalten. Alles andere müsste man händisch in die php.ini eintragen (oder vergleichbare Anweisungen in die Skripte aufnehmen).

Um PHP zu pimpen, müsste man erst einmal analysieren, wobei denn die Verzögerungen stattfinden und ob man ihnen durch Maßnahmen begegnen kann.

Grundsätzlich gibt es bei PHP/Datenbank-Anwendungen zwei Problembereiche: einmal die Anzahl der Zugriffe auf Datenbanktabellen (bei Drupal munkelt man, pro Webseitenauslieferung an die 100 DB-Zugriffe) und zum anderen die nach- oder vorgeladenen PHP-Skript-Dateien (include/require), die immer das Dateisystem stark belasten (bei vielen 'gewachsenen' PHP-Paketen ist das manchmal sehr ausgeprägt). Beide Stellen lassen sich kaum durch direktes Tuning verbessern. Allenfalls, dass man auf SSDs umstellt oder Datenbank-Server vom Web-Server maschinell trennt (also 2 DSen).

Itari

 

[jahlives]

Mittels ipkg htop kann man die "niceness" der Prozesse verändern

 

[itari]

Die niceness oder der nice-Value ist eine Variable, die beim Durchrechnen der Priorität für den nächsten Prozess (der Prozesse, die in der Prozess-Warteschlange stehen) eingesetzt wird. Typischerweise entschleunigt man damit rechenintensive Prozesse (sie kommen seltener dran). Interaktive Prozesse (I/O-Calls auf den Kernel und das Warten auf die Antwort) werden durch ihre I/O-Tätigkeit von sich aus beschleunigt. Damit kann man also weder die Zuteilung von CPU-Zeit erzwingen noch mehr RAM erhalten.

Was man braucht, wäre ein Prozess-Scheduler, der auch Gruppen zulässt, wie z.B. der CFS. Gibt es aber wohl auf der DS (noch) nicht.

Itari

 

[Schlaefer]

Naja, ich habe jetzt mal my(-large).cnf ins /etc/ gestellt und zusätzlich ein wenig daran verändert. Bei 1024MB Arbeitsspeicher darfs ruhig ein bisschen grosszügig sein.

Jetzt werde ich noch die *.tpl.php Dateien des gewählten Themes von Drupal von unnötigem php-Ballast befreien. Bei 67 IF Anweisungen (ist das krank) liegt noch einiges drin.

 

[jahlives]

67 if-Anweisungen sind ja noch gar nichts. Auf die Performance drücken meist eher die mysql Abfragen, welche gerade beim CMS Systemen sehr zahlreich und auch sehr umfangreich sind. Ich kann aus eigener Erfahrung gut einschätzen wieviel Performance ein if bei php kostet, da ich mal sehr intensiv mit einem Primscript zu werke ging und es bis zum "geht-nicht-mehr" optimiert habe. Ein if über den Daumen gepeilt bei PHP ein paar tausend ns. Viel mehr als eine ms wirst du wohl ned rauskriegen. Und manchmal kann ein gut platziertes if die Laufzeit eines Codes um Faktoren verkürzen und sinnlose Berechnungen ersparen. Gerade bei Schleifen die tausendfach durchlaufen werden kann ein "gutes" if die Anzahl Durchläufe deutlich reduzieren.
Lange Rede kurzer Sinn: Indem du einfach if einsparst könntest du die Laufzeit u.U. auch verlängern.

 

[Schlaefer]

lösch ... lösch ...

Update: ich habe kurz ein paar Vergleichstests mit Drupal (ohne Änderung an den Templates) gemacht:
- DS 411+: ein spez. Modul aktivieren und wieder deaktivieren benötigt 2 Minuten und 27 Sekunden
- DS 411+: " (ohne my.cnf) " benötigt 2 Minuten und 31 Sekunden
- über gewöhnlichen Hoster: " " benötigt es gerade mal um die 9 Sekunden

Damit ist die Idee, Drupal auf der DS 411+ laufen zu lassen, für mich vom Tisch und über einen Tag arbeit für die Katz.
Ich brauch nen Schnapps und ein Baldrian!

 

[Trolli]

Keine Ahnung, ob das was ändert, aber hast Du mal nachgeschaut, ob die Änderungen in der MySQL-Konfiguration auch wirklich ausgeführt wurden?

Nicht alle Optionen können nämlich über die my.cnf geändert werden. Manches wird auch in der /usr/syno/etc/rc.d/S21mysql.sh festgelegt. Hast Du diese Diskussion dazu schon gefunden?

 

[Schlaefer]

Nein, ich habe nicht nachgeprüft, ob die my.cnf nach dem Neustart wirklich auch beachtet wurde. Wusste nicht wie nachprüfen. Und nach dem Vergleichstest habe ich das ganze eh in die virtuelle Ecke geschmissen.

Jep, diesen Forumsbeitrag habe ich auch gelesen. Ich habe danach auch die S21mysql.sh angeschaut. Aber ich habe kaum Einträge auf die schnelle gesehen, die sich gegenseitig überschrieben hätten. Jedenfalls nicht jene, die ich glaubte massgebend für eine Verschnellerung zu sein.

 

[Trolli]

In phpMyAdmin zum Beispiel kann man sich die aktuelle MySQL-Konfiguration unter "Status" ansehen und analysieren. Da müssten dann auch die geänderten Werte auftauchen.

 

[Schlaefer]

Ich habe die MySQL Einstellungen (über phpMyAdmin: Reiter Variablen) ohne und mit my.cnf Aufruf verglichen, folgende Parameter haben sich positiv verändert:
- key buffer size
- myisam sort buffer size
- query cache size
- read buffer size
- read rnd buffer size
- sort buffer size
- table open cache
- thread cache size
So weit so gut. Aber leider haben diese Veränderungen keinen Einfluss auf die Geschwindigkeit bei einzelnen Aufrufen der HP.
Die CPU Last geht beim einem HP Aufruf von 2 auf maximal 30% und der Speicherverbrauch ändert sich nicht.
Da hats doch noch genug Reserven, aber wie können die für den Webserverdienst nutzbar gemacht werden?

Vielleicht sollte ich einfach von Drupal zu Joomla mit Civicrm wechseln.

Da hilft wohl nur noch beten.