INET/inet_error: send errno = 10054

[Robert Dollinger]

Guten Morgen!

Nachdem ich ausgiebig gegoogelt und Dokumentation gelesen habe, bin ich leider noch immer nicht weiter, da die Antworten auf diese Fehlermeldung von Netzwerkproblemen bis hin zur korrupten DB lauten. Vielleicht kann mir hier trotzdem jemand weiterhelfen. Meine DB hat folgende Einstellungen:

Firebird 1.5.2.4731

SuperServer

Page Size: 8192
Sql Dialect: 3
Sweep Interval: 0
ODS Version: 10.1
Forced Writes: Yes
Read Only: False
Buffers:
Pages: 2048
KB: 16384

Die Größe der DB varriert zwischen 50 MB bis hin zu 300 MB, abhängig vom Betrieb. Diese DB wird in einer Lösung zur Automatisierung der Produktionsprozesse in der Industrie eingestezt. Die Folge dieses Fehlers ist fatal, da alle Programme die Verbindung zur DB verlieren, und somit neugestartet werden müssen. Was natürlich im Produktionsbetrieb in der Industrie nicht nachvollziehbar ist.

Was ich dazu sagen muss der Fehler tritt nich bei allen Kunden auf. Deshalb ist das Problem um so misterioser und auch nicht auffindbar.

Kann Windows das Problem sein? Ich glaube nicht, da ich bei einem Kunden mit Windows 2000 Server keine Schwierigkeiten habe, aber bei einem anderen schon. Wiederum ein anderer hat Windows 2003 Server und der hat auch Probleme.

Danke für die Hilfe
Robert

[Heiko Luettge]

Hallo Robert,
<p>
10054 "connection reset by peer"<p>
Also Netzprobleme.
In der 1.5.3 sind ein paar Fehler behoben worden,
vielleicht ist es ja einer ?.
<p>
Heik

[Frank Schlottmann-Goedde]

Moin,

> Guten Morgen!
>
> Nachdem ich ausgiebig gegoogelt und Dokumentation gelesen habe, bin
> ich leider noch immer nicht weiter, da die Antworten auf diese
> Fehlermeldung von Netzwerkproblemen bis hin zur korrupten DB lauten.
> Vielleicht kann mir hier trotzdem jemand weiterhelfen. Meine DB hat
> folgende Einstellungen:
>
> Firebird 1.5.2.4731
>
> SuperServer

Classic wäre zunächst einmal ein workaround, da stirbt immer nur ein client.

> Page Size: 8192 Sql Dialect: 3 Sweep Interval: 0 ODS Version: 10.1
> Forced Writes: Yes Read Only: False Buffers: Pages: 2048 KB: 16384
> Was natürlich im
> Produktionsbetrieb in der Industrie nicht nachvollziehbar ist.

s.o. eventuell hilft ein redesign, so dass die Applikation nach einer Verbindungstrennung die Verbindung zum Server neu aufbaut.

Wird denn der Server (via guardian) neu gestartet?

> Was ich dazu sagen muss der Fehler tritt nich bei allen Kunden auf.
> Deshalb ist das Problem um so misterioser und auch nicht auffindbar.

Deutet auch auf Netzwerkprobleme und/oder events in Kombination mit Firewalls hin. Oder auf eine defekte Netzwerkkarte, Hub, Switch etc. pp.

> Kann Windows das Problem sein?

:-) Wir verwenden als DB-Server nur Linux-Maschinen, aber ich glaube nicht, dass es in diesem Fall an Windows liegt.

(na hoffentlich wird das irgendwie lesbar formatiert,
ich hasse webforen :-) )

Frank
--
Fascinating creatures, phoenixes, they can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets.
- J.K. Rowlin

[Robert Dollinger]

Hallo an alle,

inzwischen schon einmal Danke!!!!

Werde jetzt die Classic Variante aus reinem Interesse versuchen. Ziel sollte es aber sein mit dem Superserver auszukommen.

Die Applikationen bauen die Verbindung bereits neu auf, nachdem sie sie verloren haben. Ich möchte das Problem aber an der Basis lösen.

Ihr glücklichen ich bin leider auf Windows angewiesen :-(

Ciao
Rober

[Robert Dollinger]

Bin leider noch nicht wirklich weitergekommen mit der Lösung des Problems. Ich habe jetzt allerdings einen anderen Verdacht:

Im Buch von Helen Borrie steht unter "Firebird Limits", dass die "maximum connected clients" bei TCP/IP theorethisch 1024 sind. Allerdings hat sie als Anmerkung dazugeschrieben, dass dies viel vom Rechner abhaengt und sie gibt als "practical guideline" 150 clients bei einem Superserver an.

So, der Rechner wo die DB laeuft ist ein P4 2,6 Ghz mit 1,5 GB Ram und Raid 1. Das Maximum an verbundenen Clients sind 234.

Könnte also sein das Firebird, bzw. der Rechner es nicht mehr schafft diese 234 Verbindungen zu verarbeiten und somit einfach den Firebird-Dienst neustartet.

Vielen Dank für die Hilfe

Rober

[Thomas Steinmaurer]

Hallo Robert,
<br>
mir ist jemand bekannt, der auch bei nur einem Kunden ein ziemliches Problem, vor allem mit dem 10054er Fehler hat. Ab und zu so ein Eintrag kann womöglich vernachläßigt werden, weil z.B. ein einfaches Abschießen einer Anwendung, ohne dabei die DB-Verbindung ordentlich zu schließen, diesen Log-Eintrag ebenfalls nach sich ziehen kann.
<br>
Es könnten durchaus Netzwerkprobleme sein, vor allem wenn es sich um nur einen Problemkunden handelt, aber hier dann gleich die komplette Netzwerkinfrastruktur (Switch, Hub, ...) auszuwechseln, ohne dabei eine Erfolgsgarantie zu haben, ist doch eher problematisch. Ich würde einmal versuchen am Server ein Tool <b>IBConSvc</b> zu installieren. http://www.ibphoenix.com/downloads/ibconsvcl.zip. Das hilft Dir vielleicht herauszufinden, ob es ein bestimmter Client ist, der Probleme macht. Dieses Tool wurde für InterBase entwickelt, und man muss eine kleine Änderung (Delphi-Source ist dabei) machen, damit dieses Tool das Fenster-Handle des Firebird-Servers findet, damit auch tatsächlich Einträge in firebird.log gemacht werden. Probier das einfach einmal aus.
<br>
Thoma

[Heiko Luettge]

Hallo Robert,<p>
ob der Server tatsächlich neustartet, siehst du ja im Log.
<p>
Beim Umstieg auf Classic, dass die Buffer (hier 16kB) für jede Verbindung, also jeden Client allokiert (argz, was für ein blödes Wort ) werden.
<p>
Heik

[Gerhard Behnke]

Hallo Robert,

wir hatten ein ähnliches bzw. gleiches Problem, was definitiv mit der Anzahl der Verbindungen zusammenhing. Wir haben einige Zeit benötigt um heruaszufinden warum der Server crashed. Im Logfile war nichts zu sehen. WIr haben dann festgestellt, dass mit zunehmender Anzahl vonn Verbindungen der Speicherbedarf über 2GByte steigt, was normalerweise die Obergrenze für einen 32 Bit Windowsserver (auch Linux!) ist.Dieses hat zur Folge, dass der Server crashed ohne einen erkennbaren Eintrag im Log-File.
Man kann diese Grenze durch einen entsprechenden Eintrag in der System ini auf 3 GByte erhöhen.
Ich würde Dir empfehlen auf Classic umzusteigen, hier hat jeder Prozess 2 GByte und sei es durch swappen, zur Verfügung.
Sollte es Performance Probleme geben, spendiere noch etwas RAM (würde ich bei der Anzahl von CLients sowieso machen) und Du kannst sicher sein, Deine Probleme sind gelöst.
Unser DB ist cirk. 15 GByte und wir haben cirk. 250 Connections bei einer sehr großen Anzahl von Transaktionen.

Gruß

Gerhar

[Gerhard Behnke]

Eines habe ich noch vergessen:

Wir haben sehr umfangreiche Tests durchgeführt um heruaszufinden, ob Linux gegenüber Windows Server 2003 die bessere Wahl ist.
Zumindest für unsere Anwendung:

DB irk. 15 GByte
cirk. 250 Clients
pro Tag werden cirk. 8000 Dokumente gespeichert
jedes Speichern führt zu einer Aktualisierung der Dokumentenüberischt eines jeden ! Clients

Ergebniss:
Bei manchen Zugriffen war Linux schneller bei anderen wiederum Windows. Schneller heißt aber nicht signifikant schneller !
Unterm Strich heißt das:
Wer was am besten mag und bezahlen kann, ist sowohl mit Linux als auch W2003 gleichermaßen gut beraten

Gruß
Gerhar

[Robert Dollinger]

Inzwischen schon einmal Danke an alle.
Ich werde jetzt als Lösungsansätze folgendes versuchen:

- die Anzahl Clients veringern
- dem Kunden raten mehr Ram einzubauen
- IBConSvc habe ich bereits installiert, mal schauen was sich damit
alles analysieren laesst.

Auf Classic-Server werde ich inzwischen nicht wechseln.

Nochmals Danke, wenn ich das Problem geloest habe werde ich es natuerlich hier auch posten

[Robert Dollinger]

So das Problem scheint gelöst zu sein. Der Rechner war total überfordert. Mit einem neuem Rechner gibt es mittlerweile keine Probleme mehr. Danke nochmals für die Hilfe