FreeBSD Server Tuning

sanbiber

Well-Known Member
Hallo BSDler,

bei einer FreeBSD-Maschine mit mehreren Jails, mit ZFS und ein paar angebotenen Diensten (Webanwendungen (php, python), http-server, ssh-server, Datenbanken (MySQL, PostgreSQL)) kommt es immer mal wieder zu langen Antwortzeiten (die Hardware ist nicht gerade groß dimensioniert). Mich wuerde interessieren, woran genau das liegt. Sicher bin ich im Lauf der Jahre ueber einige tuning-guides gestolpert (fuer ZFS, fuers Netzwerk, fuer Datenbanken, ...), aber mir kommt das haeufig wie Magie vor: irgendwas laeuft nicht richtig, man schaut sich mal die load an, mal die Memory-Auslastung, mal die swap-Nutzung usw., nimmt nen tuning-guide zur Hand, hoert sich irgendwelche Daumenregeln oder Erfahrungswerte (nichts per se gegen Erfahrungswerte - die sind sehr wertvoll und wichtig!) an stellt hier und da was um und "beobachtet" dann, ob es besser wird ... das ist alles sehr ungenau und ziemlich willkuerlich.

Kennt jemand hier tools, die einem genau bzw. genauer sagen koennen, wo gerade der bottle-neck ist?
Tools, die einem "live" sagen koennen, wo es grad zu Engpaessen kommt, faend ich auch interessant.

Und kennt jemand hier ne gute, aktuelle Uebersicht, wo genau bzw. genauer aufgeschluesselt ist: "wenn es hier hakt, dann schraube hier" ?

Vielen Dank,
sanbiber
 

mr44er

moderater Moderator
Teammitglied
die Hardware ist nicht gerade groß dimensioniert
Mhm. :rolleyes:

Aber im Ernst, das kann man pauschal nie sagen. Das ist oft eine running-Baustelle von neuen Funktionen, die mal haken und sich rumspricht oder jahrelange Erfahrunsgwerte und Umgang.

Klar ist, wenn die Hardware nicht generell dem Einsatzzweck genügt, dann kannst du trotz ausgerupften Haaren, Fehlersuche und Tuning keine Wunder erwarten.
Das eine hängt vom anderen ab und umgekehrt. Du musst hierarchisch draufblicken.
Wenn aus dem Gartenschlauch nix kommt, läufst du rückwärts und suchst den Knick. Am Ende war es aber der zugedrehte Haupthahn. Alle Möglichkeiten in Betracht ziehen und das gibt dann die Erfahrung fürs nächste Mal, weil man 'abklappert'.
 

medV2

Well-Known Member
Zuerst musst du halt mal schauen woran es wirklich hakt. Du könntest eine MonitoringSW wie z.b. Munin einsetzen und dann schauen, wo die peaks sind zu zeiten in denen die Responsetime zu lange ist. Dazu noch irgendwie alle 5Sec oder so top und top -m io rausloggen um zu sehen, was die Last verursacht.

Bei ZFS und Datenbanken hast du hoffentlich die Blocksize auf die der Datenbanken abgestimmt, sonst gibts da schnell probleme und viel zu viel IO.
 

eric81

Well-Known Member
Kann mir nicht vorstellen, dass es so ein Tool gibt.
Ich rate Dir eher dazu, die Tools zu nutzen und zu lernen die FreeBSD zur Analyse bereithält.
Schau mit top nach, ob der Server swapped. ZFS nimmt sich in der Default Einstellung viel RAM.
Das Gemeine ist, dass eben nach einem Neustart alles wie erwartet schnell funktioniert, aber wenn ZFS und die Dienste nach und nach mehr RAM belegen swappt das System und dann wird es hier und da unzumutbar langsam.
Begrenzen kannst Du diesen ZFS-Cache mit z.B. vfs.zfs.arc_max=4g in der /boot/loader.conf.
 

mark05

Well-Known Member
hi

prformance analyse ist ein lngfristiges thema was nicht wirklich mit tools machbar ist welche den ist zustand
wiedergeben , z.b. top oder netstat.

ergo bleibt nur ein monitoring welches entweder mit einem eigenen agent auf der maschine oder via snmp
die messwerte erfasst.

wichtg ist das die messwerte cpu, ram , und hardware IO ( Festplatten , netzwerk etc ) erfasst,
bei einem VM Server sollten host und guests separat erfasst werden.

internet bandbreiten werte erfassen.

somit kommt man um ein monitoring mit munin , naigos , zabbix , xymon nicht vorbei.

nach 4 wochen sollten dann genug messwerte zusammen getragen seinum massnahmen zu ergreifen,


holger
 

turrican

Well-Known Member
Kennt jemand hier tools, die einem genau bzw. genauer sagen koennen, wo gerade der bottle-neck ist?
Tools, die einem "live" sagen koennen, wo es grad zu Engpaessen kommt, faend ich auch interessant.
vmstat, truss und ktrace - siehe deren Manpages bzw Doku im Inet dazu;

Und kennt jemand hier ne gute, aktuelle Uebersicht, wo genau bzw. genauer aufgeschluesselt ist: "wenn es hier hakt, dann schraube hier" ?

Vielleicht hilft dir dieses Pamphlet weiter:

Help, my system is slow
 
Zuletzt bearbeitet von einem Moderator:

sanbiber

Well-Known Member
Danke fuer die Hinweise!

Mir geht es hier im Moment nicht so sehr um konkrete Tuning-Hinweise, sondern um eine umfassendere Sicht auf das Thema. Wie angedeutet, ist mir klar, dass man an sehr vielen Stellen schrauben kann und dass es unterschiedliche Tools gibt, die Teilaspekte anzeigen koennen oder ueber die man Hinweise auf moegliche Probleme bekommen kann. Und auch, dass es kein einfaches Rezept gibt, was man auf alle Maschinen anwenden kann, sondern dass man immer die spezifische workload einer Maschine in Betracht ziehen muss. Und am Ende war oder ist mehr Hardware haeufig die einfachste und schnellste Loesung ...

Ein Traum - und das wollt ich eigentlich herausfinden, ob das wirklich ein Traum ist oder Realitaet - waer ein Tool, was all die Infos der existenten Tools zusammenfuehrt und analysiert und evtl. sogar dann die verbreiteteren Tipps geben kann.

Aber das hilft alles hier bisher auch schon weiter - Danke nochmal!
 

turrican

Well-Known Member
kommt es immer mal wieder zu langen Antwortzeiten
Schau dir mal gezielt an (mit top, iostat, vmstat usw), ob deine Maschine in diesen Situationen nicht swappt wie verrückt - I/O nach swap ist ziemlich "teuer" und läßt Reaktionszeiten ansteigen.

... ein Tool, was all die Infos der existenten Tools zusammenfuehrt und analysiert und evtl. sogar dann die verbreiteteren Tipps geben kann...
Naja, das EINE Tool welches einem auf Knopfdruck ne Auflistung von "da isses lahm und da und da... und das kannst du als Abhilfe dagegen machen" gibt es nicht (zumindest weiss ich keins, das muss also nicht unbedingt was heißen, vllt weiß ein Forenkollege mehr), es wird also auf Spurensuche mit diversen Tools rauslaufen.

Schau dir mal die Seite von Brendan Gregg (FreeBSD Performance Checklist) an, der hat hierzu einiges zusammengetragen;
 
Oben