Netzwerkanalyse, Fehlersuche, Testberichte
Home / News
Netzwerkanalyse
Grundlagen
Verkabelung
Erste Schritte
Baselining
Let's sniff
Tools
Auswerten/Filtern
Typische Probleme 1
Typische Probleme 2
Sicherheit
Bücher
Tutorials
Cacti
DSL einrichten
DynDNS einrichten
m0n0wall | pfSense
Nmap
VirtualBox
Wireshark
Forum
Shop
FAQ
Know How
Testberichte
Hardware-DB
Events
Netzwerklexikon
Links / Service
Suche
Kontakt
Impressum
Feedback
Sitemap
Partner
Unser Partner für
SSL Zertifikate
ist Checkdomain GmbH.
Netzwerktechnik Forum

Forum Netzwerktechnik (Archiv)

Kategorie Netzwerktechnik - Forum Netzwerke einrichten

 
Daten- /Datenbankserver und 15 Clients - Zugriffszeit

geschrieben am 03.05.2007 um 11:13 von apollon

Guten Tag,

ich habe ein Problem mit einem Netzwerk.

In diesem Netz befinden sich 15 Clients die mit einem Programm arbeiten, das auf eine Datenbank von ca. 3,17 GB und Daten (hauptsächlich Bilder und Tabellen) von ca 37 GB zugreift. Die Daten sind den einzelnen Kunden zugeteilt. werden also nur bei dem passendem Kunden geladen.

Von dem Programm werden keine externen Programme benutzt.

Die Datenbank ist eine FastObjects Datenbank.

Im Netz gibt es kein Internet und keine Domain DHCP ist zwar an aber die Rechner haben statische IPs. Der Server ist ein Win2000 Server.
Das Netz läuft auf 1 Gbit. Der Zugriff auf die Daten geht zeitweiße sehr langsam.

Hab mir schon die Tutorials zu wireshark und die Problemlösungen durchgelesen :)
aber könnt ihr mir sagen wo ich da ansetzen soll?

MfG
 

geschrieben am 03.05.2007 um 11:28 von bewa

Re: Daten- /Datenbankserver und 15 Clients - Zugriffszeit

Moin.

"apollon" wrote:

Der Zugriff auf die Daten geht zeitweiße sehr langsam.

Hab mir schon die Tutorials zu wireshark und die Problemlösungen durchgelesen :)
aber könnt ihr mir sagen wo ich da ansetzen soll?


"Zeitweise" bedeutet, ab und zu läuft der Server auch mit der gewünschten Geschwindigkeit?
Gleich mit Wireshark und Co. drauf los zu suchen, ist in den meisten Fällen sinnlos, außer man findet zufällig irgendeinen relativ offensichtlichen Fehler (falsch konfigurierte Paketfilter etc.).

Zunächst wäre mal interessant:

- Wieviele Clients greifen dann ungefähr zu? Einer? 50%? Alle?
- Wie sieht die Server-Last aus, wenn es gefühlt langsam läuft? (CPU-Last, I/O-Durchsatz)
- Wie stark ist das Netz "beschäftigt"? (Netzdurchsatz)
- Welches Protokoll wird von der Anwendung verwendet? UDP/TCP/SCTP/Ganzwasanderes oder auch mehrere davon?

Der mit Abstand wichtigste Ansatz ist dabei also: Was macht die Anwendung überhaupt (mit welchen Protokollen)? Dann kann man überlegen, was anders sein könnte, wenn es langsamer wird. Entweder systematisch durch alle OSI-Layer, was aber bei komplexen Setups Tage, oder Wochen in Anspruch nehmen kann, oder aber hoffentlich gezielt, indem man den Soll-Zustand mit dem Ist-Zustand während der Störungen abgleicht.
 

geschrieben am 03.05.2007 um 11:57 von apollon

Moin :)

Quote:
- Wieviele Clients greifen dann ungefähr zu? Einer? 50%? Alle?


Die Clients schwanken. Online sind sie alle und auch alle im Programm.
Gearbeitet wird meistens an 7-8 Rechner gleichzeitig. Das Programm nutzt im Ruhezustand kein Netz.
Wenn abends nach Feierabend die Clients weniger werden an denen gearbeitet wird kann es trotzdem noch zu verzögerungen kommen. Das Programm wirkt aber insgesamt schneller in der Datenbeschaffung.

Quote:
- Wie sieht die Server-Last aus, wenn es gefühlt langsam läuft? (CPU-Last, I/O-Durchsatz)


CPU-Last:
0%-4% im Ruhezustand
bei Zugriffen gehts auf 13%-20% hoch.

I/O Durchsatz.
Kannst du mir mal nen Tipp geben wie ich das am besten Grafisch darstellen kann?

Mit der Systemauslastung hab ich die gesendeten Daten mal angezeigt im Zugrif liegt die ganze Sache dann bei 80%.
Im normalen Betrieb weiß ichs leider nicht.

Quote:
- Wie stark ist das Netz "beschäftigt"? (Netzdurchsatz)


Sicher (am besten) am Server messen?/!
Mit Wireshark? oder auch durchsatz der Karte. Die Clients kommunizieren nicht untereinander. Jedenfalls nicht vom User gefordert.

Quote:
- Welches Protokoll wird von der Anwendung verwendet? UDP/TCP/SCTP/Ganzwasanderes oder auch mehrere davon?


Ich tippe auf TCP.
Werd mal schaun mit was diese Datenbank arbeitet.

Danke schonmal

MfG
 

geschrieben am 04.05.2007 um 13:06 von bewa

Moin.

"apollon" wrote:

CPU-Last:
0%-4% im Ruhezustand
bei Zugriffen gehts auf 13%-20% hoch.


Das ist nicht der Rede wert. Selbst mit einzelnen Spitzen ist es im Normalfall dann nicht "gefühlt" langsam.

Quote:
I/O Durchsatz.
Kannst du mir mal nen Tipp geben wie ich das am besten Grafisch darstellen kann?


Gemeint waren die Plattenzugriffe. Wenn es für das RAID oder worauf auch immer eure Datenbank liegt kein eigenes Tool gibt, mit dem man kontinuierlich die Auslastung verfolgen kann, bleibt die universelle Möglichkeit unter Windows Servern (ab 2000):
Start -> Ausführen -> Perfmon.msc (Steckt auch irgendwo im Menü, aber damit geht es am schnellsten.)
Damit kannst du fast alle "üblichen", allgemeinen Leistungsparameter abfragen die jedes Server-OS kennt. Die Auswertemöglichkeiten sind beschränkt, Bedienung und Darstellung finde ich unterirdisch schlecht - aber es ist ein Bordmittel und kostenlos dabei... Mit der rechten Maustaste in die Grafik klicken, dann kannst du "Leistungsindikatoren" hinzufügen. Die sind jeweils unter den zugehörigen Objekten gruppiert, z.B. CPU oder auch TCP-Verbindungen. Auf Knopfdruck gibt es für viele immerhin eine Erklärung... Wie immer am besten nicht zu viele auf einmal anzeigen sonst kann das kein Mensch mehr lesen.

Quote:
Mit der Systemauslastung hab ich die gesendeten Daten mal angezeigt im Zugrif liegt die ganze Sache dann bei 80%.


Was hast du dir da genau anzeigen lassen und womit? 80% Auslastung ist heftig, das entspricht bei Anwendungen die prinzipbedingt Lastschwankungen haben eigentlich schon voller Auslastung!

Quote:
Quote:
- Wie stark ist das Netz "beschäftigt"? (Netzdurchsatz)


Sicher (am besten) am Server messen?/!


Gemeint war die Netzwerkauslastung des Servers bzw. der Netzwerkkarte.
Entweder direkt am Server (mittels Perfmon, TCPDump/Wireshark oder einem anderen Tool), oder im Idealfall an einem Hub bzw. an einem SPAN/Monitor-Port durch einen anderen Rechner. Vorteil des separaten Rechners: Das Messergebnis wird nicht verfälscht, weil die Messung nicht auf dem Rechner läuft. So pingelig muss man aber eigentlich erst werden, wenn es an das Finetuning oder spezielle Problemstellungen geht.

Quote:

Quote:
- Welches Protokoll wird von der Anwendung verwendet? UDP/TCP/SCTP/Ganzwasanderes oder auch mehrere davon?


Ich tippe auf TCP.
Werd mal schaun mit was diese Datenbank arbeitet.


Wenn es nicht auf Anhieb in der Doku zu finden ist, kann man das Spielchen auch umdrehen, und mit Wireshark schauen, was verwendet wird. Das ist aber unter Umständen mühseliger. Außerdem hilft es enorm, sich vor dem Messen zu überlegen, WAS man überhaupt messen oder untersuchen möchte - klingt anfangs albern, aber das spart eine Menge unnötiger Arbeit wenn man es einmal verinnerlicht hat.

Solltest du dir sicher sein, das TCP Schuld hat kannst du natürlich auch einfach eine Weile einen Mitschnitt laufen lassen, bis du einen "problematischen" Zeitraum aufgenommen hast und diesen dann zunächst mal auf die üblichen Verdächtigen (viele Duplikate Acks, Retransmissions, usw.) abklopfen.
 

geschrieben am 16.05.2007 um 15:09 von Kami

hm... könnte das vielleicht nicht auch an den Festplatten des Servers liegen?

nur eine reine Vermutung
 

geschrieben am 16.05.2007 um 19:25 von apollon

also ich hab mir die ganze sache nochmal genau angeschaut.
kann da nich immer arbeiten.

erstmal werden bei 7 clients die speicher von 256 mb auf 512 mb erweitert.
danach muss ich wohl auf den vorhandenen win2k3 rechnern sp4 drauf schieben.

das sollte zumindest die kisten mal schneller machen. danach werd ich mal mit wireshark das netz aufs korn nehmen.

danke aber schonmal für die tipps
 

[ Dieses Thema im Live-Forum aufrufen ]

Sie befinden sich im Archiv des Forums.
Zum Forum

Archiv erstellt mit phpBB2HTML 0.1 - Foren in statisches HTML umwandeln © 2006 Mirko Kulpa

 

 
© 2004-2015, network lab - we make your net work - Netzwerkforum
aktualisiert am 16.12.2017