FreeBSD reagiert sehr langsam

A

alex27

Well-Known Member
Also seit heute reagiert mein Webserver auf dem FreeBSD 8.0-STABLE läuft sehr langsam.

CPU: 1.2% user, 0.0% nice, 3.4% system, 0.0% interrupt, 95.4% idle
Mem: 239M Active, 186M Inact, 128M Wired, 112M Buf, 2954M Free
Swap: 8192M Total, 8192M Free

load averages: 0.26, 0.29, 0.17

Das sieht für mich alles sehr gut aus, und trotzdem reagiert der Apache sehr sehr langsam das öffnen von Dateien auf dem Server dauert und selbst ein einfaches w und dann enter dauert 2 Sekunden.

Ich bin ein wenig ratlos, wo das Problem liegen könnte und hoffe das hier jemand ein paar gute Ideen hat.
 
Da würde ich doch eher auf ein Netzwerkproblem tippen. Was hat sich denn seit gestern geändert?
 
Ein zweiter Server der am gleichen Router angeschlossen ist, hat keinerlei Probleme.

Was neu ist, ist ein Script das Videos bearbeitet. Das Script lief zu dem Zeitpunkt als ich die Server Daten hier gepostet habe. Das deaktivieren von dem Script hat auch nichts verändert, jedoch seit einem Reboot ist momentan alles in Ordnung.

Das Script habe ich noch nicht wieder gestartet. Ich bin jetzt am Überlegen wenn durch das Script evtl. die Auslastung der Festplatte hoch gewesen ist, dann würde das erklären warum das System so langsam reagiert hat aber dann hätte doch auch der Load und die CPU Auslastung höher sein müssen.

Oder liege ich da Falsch?
 
Kommt darauf an, was das Skript macht. Je nach Operation liefert die Platte halt nicht genug Daten um die CPU nennenswert zu beschäftigen.
 
Hmm, weisst Du denn wie man sehen kann wie sehr die Festplatte ausgelastet ist, dann wüsste ich ja, ob es daran liegt.
 
Danke für die Antworten, werde mal mit iostat und / oder gstat schauen. Sieht beides gut aus.

Die maxnodes könnten es natürlich auch sein, ich weiss zwar wie ich sie in der sysctl.conf setzen kann aber wie kann ich denn sehen wie der momentane Wert ist und wieviele in Gebrauch sind.
 
Hi,

sysctl vfs.numvnodes zeigt den aktuellen Stand.

Mit sysctl kern.maxvnodes erhöhst Du diese.

Schaue mal in man tuning, sollte da alles drin stehen.


Grüße
Kai


PS: wenn dies der Fall ist, müsstest Du bei top viele Prozesse im ufs State sehen
 
Zuletzt bearbeitet:
Sieht so aus als liegt es an den maxnodes.

Die sind auf der Standard Einstellung von 100000, vfs.numvnodes: 96328 ist der momentane Wert und zur Zeit ist nichts los auf dem Server plus ich habe ein paar Sachen disabled.

Wie hoch kann man den Wert denn problemlos setzen ?
 
Wow, das ist mächtig, wenn ich mein Notebook als Orientierungspunkt nehme.

Ich würde in so einem Fall einfach mal maxvnodes verzehnfachen. Ich frage mich bloß gerade worum es sich dabei überhaupt handelt.

Die Zahl der vom vfs bereitgestellten Dateien? Was müsste dann auf dem Rechner laufen, damit solche Zahlen herauskommen? Eine obskure Datenbank, die für jede Tabellenzeile eine eigene Datei anlegt?
 
Auf dem Server läuft ein Content Management Script das in der Tat auf eine Datenbank zugreift.

In der Datenbank sind grosse Mengen von Bildern und wenn neue Bilder hochgeladen werden, dann werden auch automatisch Thumbnails erstellt usw.
 
11.13.3 Virtual Memory
11.13.3.1 kern.maxvnodes

A vnode is the internal representation of a file or directory. So increasing the number of vnodes available to the operating system cuts down on disk I/O. Normally this is handled by the operating system and does not need to be changed. In some cases where disk I/O is a bottleneck and the system is running out of vnodes, this setting will need to be increased. The amount of inactive and free RAM will need to be taken into account.

To see the current number of vnodes in use:

# sysctl vfs.numvnodes
vfs.numvnodes: 91349

To see the maximum vnodes:

# sysctl kern.maxvnodes
kern.maxvnodes: 100000

If the current vnode usage is near the maximum, increasing kern.maxvnodes by a value of 1,000 is probably a good idea. Keep an eye on the number of vfs.numvnodes. If it climbs up to the maximum again, kern.maxvnodes will need to be increased further. A shift in your memory usage as reported by top(1) should be visible. More memory should be active.


Grüße
Kai
 
Nun, dann habe ich ja gar nicht schlecht geraten. Da Schritt für Schritt 1000 draufzupacken, kann ich aber nicht nachvollziehen. Ich würde die Zahl zumindest mal verdoppeln.
 
Kamikaze schrieb:
Wow, das ist mächtig, wenn ich mein Notebook als Orientierungspunkt nehme.

Ich würde in so einem Fall einfach mal maxvnodes verzehnfachen. Ich frage mich bloß gerade worum es sich dabei überhaupt handelt.

Die Zahl der vom vfs bereitgestellten Dateien? Was müsste dann auf dem Rechner laufen, damit solche Zahlen herauskommen? Eine obskure Datenbank, die für jede Tabellenzeile eine eigene Datei anlegt?
Zum Vergrößern anklicken....

Genau wie gesagt, viele Thumbnail Berechnungen z.B. ;-)
 
Ich habe es jetzt mal auf 200k erhöht und werde es mal beobachten :) Ich denke mal das es daran liegt denn das IO Bottleneck würde ja die ganze Problematik erklären.
 
Ich habe mal einen kleinen Stresstest gestartet und dem CMS etwas zu tun gegeben und siehe da:

vfs.numvnodes: 123381

und keinerlei Verzögerung irgendwelcher andere Requests und auch der Load ist noch immer eher niedrig.
 
Vnodes belegen Kernelspeicher. Auf i386 sollte man mit ihnen also also sparsam sein, da die ganze Plattform sehr am zu niedrigen Kernelspeicher krankt. Unter amd64 gilt aber ein klares "viel hilft viel", spricht selbst wenn es nun gut läuft, einfach noch mal die Hälfte oben rauf. Dann ist da auf jeden Fall genug, auch in kritischen Situationen. Außerdem solltest du - sofern du UFS2 einsetzt - vfs.ufs.dirhash_maxmem drastisch erhöhen. Am besten 128 Megabyte oder sogar noch mehr, Verzeichniszugriffe werden deutlich schneller und gerade wenn viele Dateien auf dem Dateisystem liegen, kann ein großer Dirhash-Puffer wahre Wunder wirken.
 
Also ich habe die Maxnodes jetzt auf 250000 gesetzt. Als ich dem CMS mehr zu tun gegeben habe als es normal der Fall ist bin ich auf 200000 Nodes gekommen, von daher sollte ich mit 250000 auf der sicheren Seite sein. Hoffe ich mal.

Der Server ist leider nicht X64, sondern ein Dual Xeon I386. Die Festplatte nutzt UFS.

vm.kmem_size: 335544320
vm.kmem_size_max: 335544320

Momentan scheint alles gut zu laufen. Das Listing der Directories dauert in der Tat recht lange und etwas mit find suchen zu wollen ist zwecklos.
 
Wie kann man denn sehen, was genau die nodes nutzt ?

Die Anzahl der genutzten Nodes steigt und steigt, ich reboote den Server jetzt einmal täglich damit es nicht über 300.000 geht.

Es werden immer mehr auch wenn das besagte CMS nicht läuft-
 
Das klingt so als würde irgend ein Prozess immer mehr Dateien öffnen und nicht mehr schließen.

Du könntest einfach mal nach und nach die Prozesse einzeln abschießen, bis irgendwann die Zahl der Nodes schlagartig sinkt, dann hast du den Übeltäter identifiziert.

Das ist halt ziemlich unangenehm auf einem Produktivsystem.
 
Ich kenne mich damit leider (noch) nicht aus, aber wäre das nicht der perfekte Einsatzzweck für Dtrace?
 
Ich dachte mir ich versuche es einfach mal mit lsof und da ich denke das es evtl. mit der Anzahl der offenen Tabellen zusammehängt habe ich dann

lsof | grep "mysql" | wc -l

versucht und habe aber nur 1340 als Resultat bekommen. Bei

lsof | wc -l

ist das Resultat 5743 jedoch habe ich bereits kurz nach dem Reboot bereits 73766 Nodes in Benutzung.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben