Aktive Verbindungen & TCP-Verbindungen

[Thomas Barth]

Hallo,
ich sehe auf einer Master-Datenbank z.B. 10 aktive Verbindungen (netstat
-atupe). Wenn ich mir die TCP-Verbindungen dazu anzeigen lasse (lsof -i
:3306), sehe ich jede aktive Verbindung in _jedem_ LISTEN-Node mit dem
Status ESTABLISHED aufgefï¿œhrt. So werden mir wegen dieser Wiederholungen
mindestens 100 TCP-Verbindungen angezeigt. Warum werden auf diese Weise
die TCP-Verbindungen multipliziert? Muss das so sein? Gibt es dazu ein
Limit?

Gruￜ, Thomas

[Axel Schwenke]

Thomas Barth <txb...@web.de> wrote:
> ich sehe auf einer Master-Datenbank z.B. 10 aktive Verbindungen (netstat
> -atupe).

MySQL-Verbindungen l��t man sich mit SHOW PROCESSLIST anzeigen.

> Wenn ich mir die TCP-Verbindungen dazu anzeigen lasse (lsof -i
>:3306), sehe ich jede aktive Verbindung in _jedem_ LISTEN-Node mit dem

> Status ESTABLISHED aufgef�hrt. So werden mir wegen dieser Wiederholungen
> mindestens 100 TCP-Verbindungen angezeigt.

Aha

> Warum werden auf diese Weise
> die TCP-Verbindungen multipliziert? Muss das so sein? Gibt es dazu ein
> Limit?

Gegenfrage: wo ist deine MySQL-Frage? Was hat MySQL damit zu tun, wie
lsof offene TCP-Verbindungen anzeigt?


XL

[Thomas Barth]

Am 02.04.2013 15:52, schrieb Axel Schwenke:

> Gegenfrage: wo ist deine MySQL-Frage? Was hat MySQL damit zu tun, wie
> lsof offene TCP-Verbindungen anzeigt?

Wo ich meine Fragen stelle, �berlasse mal sch�n mir. Und wenn du keine
Freude daran hast, Fragen zielgerichtet zu beantworten, dann lasse es
doch einfach ganz ;-)

Gru�, Thomas

[Thomas 'PointedEars' Lahn]

Thomas Barth wrote:

> Am 02.04.2013 15:52, schrieb Axel Schwenke:
>> Gegenfrage: wo ist deine MySQL-Frage? Was hat MySQL damit zu tun, wie
>> lsof offene TCP-Verbindungen anzeigt?
>

> Wo ich meine Fragen stelle, überlasse mal schön mir. Und wenn du keine

> Freude daran hast, Fragen zielgerichtet zu beantworten, dann lasse es
> doch einfach ganz ;-)

Sonst geht's Dir noch gut?

<http://www.tty1.net/smart-questions_de.html>

--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Thomas Barth]

Am 02.04.2013 17:25, schrieb Thomas 'PointedEars' Lahn:

>> Wo ich meine Fragen stelle, überlasse mal schön mir. Und wenn du keine
>> Freude daran hast, Fragen zielgerichtet zu beantworten, dann lasse es
>> doch einfach ganz ;-)
>
> Sonst geht's Dir noch gut?

Was war an dem, was ich geschrieben habe, nicht zu verstehen? Also noch
einmal, warum produziert MySQL diesen Mist? Wenn ich mich z.B. n-mal per
ssh einlogge, dann habe ich n aktive SSH-Verbindungen, aber n x 2
TCP-Verbindungen. Da würde ich vermuten, dass es sich jeweils um einen
Kontroll- und um einen Datenkanal handelt. Also ist dieses interessante
Thema durchaus MySQL spezifisch und passt daher in diese Gruppe. Jemand
da, der ein bisschen Ahnung hat oder habe ich es hier nur mit Hohlköpfen
zu tun? :-)

Gruß, Thomas

[Thomas 'PointedEars' Lahn]

*PLONK*

F'up2 poster

[Helmut Hullen]

Hallo, Thomas,

Du meintest am 02.04.13:

> Am 02.04.2013 17:25, schrieb Thomas 'PointedEars' Lahn:

[...]

>> Sonst geht's Dir noch gut?

> Was war an dem, was ich geschrieben habe, nicht zu verstehen?

Thomas scheint sich zu langweilen und macht hier ab und zu den Aushilfs-
Hausmeister.

Viele Gruesse!
Helmut

[Stefan Froehlich]

On Tue, 02 Apr 2013 15:19:29 Thomas Barth wrote:
> ich sehe auf einer Master-Datenbank z.B. 10 aktive Verbindungen (netstat
> -atupe). Wenn ich mir die TCP-Verbindungen dazu anzeigen lasse (lsof -i
> :3306), sehe ich jede aktive Verbindung in _jedem_ LISTEN-Node mit dem

> Status ESTABLISHED aufgeführt. So werden mir wegen dieser Wiederholungen

> mindestens 100 TCP-Verbindungen angezeigt. Warum werden auf diese Weise
> die TCP-Verbindungen multipliziert? Muss das so sein?

Nein, muss es nicht - aus dem simplen Grund, dass das hier nicht
nachvollziehbar ist: pro Verbindung kommt genau ein Eintrag mit ESTABLISHED
bei der Ausgabe von lsof -i. Weshalb, kann ich Dir auch nicht sagen - aber
Du solltest jedenfalls hoeflicher zu Alex sein, er versteht hier mit
Abstand am meisten von MySQL.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - der rasantste Quatsch seit Konrad Zuse.
(Sloganizer)

[Claus Reibenstein]

Stefan Froehlich schrieb:

> Du solltest jedenfalls hoeflicher zu Alex sein, [...]

Zu wem? ;-)

Gruￜ
Claus

[Stefan Froehlich]

On Wed, 03 Apr 2013 08:17:34 Claus Reibenstein wrote:
> > Du solltest jedenfalls hoeflicher zu Alex sein, [...]

> Zu wem? ;-)

Alex, Axel... Hauptsache Italien.

Servus,
Stefan, Legastheniker

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Komfort ohne Grenzen - Stefan: tüfteln, welch kultiviertes Verlieben!
(Sloganizer)

[Axel Schwenke]

Thomas Barth <txb...@web.de> wrote:
>
> Was war an dem, was ich geschrieben habe, nicht zu verstehen?

Die Stelle, wo du implizierst, das h�tte etwas mit MySQL zu tun.

> Also noch einmal, warum produziert MySQL diesen Mist?

Tut es nicht.

> Da w�rde ich vermuten, dass es sich jeweils um einen

> Kontroll- und um einen Datenkanal handelt.

Du solltest dich mehr an Fakten halten anstatt haltlose Vermutungen
anzustellen. Eine MySQL-Verbindung ist genau eine (1) TCP-Verbindung.
Wenn �berhaupt (es gibt auch noch named pipes und shared memory als
Verbindungsoption).

Eine TCP-Verbindung wiederum ist ein Quadrupel
(Host1-Adresse, Host1-Port, Host2-Adresse, Host2-Port)

wobei Host1 und Host2 noch austauschbar sind, weil TCP ja immer
bidirektional ist. Wenn lsof dir jetzt mehrere Zeilen pro Tupel
ausspuckt, dann ist das genau *kein* MySQL-Problem.


XL

[Axel Schwenke]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
> On Wed, 03 Apr 2013 08:17:34 Claus Reibenstein wrote:
>> > Du solltest jedenfalls hoeflicher zu Alex sein, [...]
>
>> Zu wem? ;-)
>
> Alex, Axel... Hauptsache Italien.

LOL

[Thomas Barth]

Am 03.04.2013 11:05, schrieb Axel Schwenke:
> Thomas Barth <txb...@web.de> wrote:
>>
>> Was war an dem, was ich geschrieben habe, nicht zu verstehen?
>

> Die Stelle, wo du implizierst, das hätte etwas mit MySQL zu tun.

>
>> Also noch einmal, warum produziert MySQL diesen Mist?
>
> Tut es nicht.
>

>> Da würde ich vermuten, dass es sich jeweils um einen

>> Kontroll- und um einen Datenkanal handelt.
>
> Du solltest dich mehr an Fakten halten anstatt haltlose Vermutungen
> anzustellen. Eine MySQL-Verbindung ist genau eine (1) TCP-Verbindung.

> Wenn überhaupt (es gibt auch noch named pipes und shared memory als
> Verbindungsoption).

Gerade habe ich gesehen, dass zwei Replikatoren eines Kunden von mir 62
aktive Verbindungen hielten, dadurch kamen über 5600 TCP-Verbindungen
zustande. Warum wird in jedem LISTEN-Node (also mit eigener PID) jede
genehmigte Verbindung wiederholt mit dem selben Zielport? Das ergibt für
mich keinen Sinn. Aber wenn das so sein muss und kein Problem für das
System darstellt, KANN ich damit leben! Verstehen würde ich es aber
trotzdem gerne. Fakt ist, dass ich bei SSH-Verbindungen immer nur zwei
TCP-Verbindungen sehe mit zwei unterschiedlichen Zielports. DAS finde
ich noch verständlich!

Gruß, Thomas

[Axel Schwenke]

Thomas Barth <txb...@web.de> wrote:
>
> Gerade habe ich gesehen, dass zwei Replikatoren eines Kunden von mir 62

> aktive Verbindungen hielten, dadurch kamen �ber 5600 TCP-Verbindungen
> zustande.

Glaube ich nicht. Zeigen!

Au�erdem: was sind "Replikatoren"? MySQL-Replikation offensichtlich
nicht, denn da hat ein Slave genau eine Verbindung zum Master.

> Warum wird in jedem LISTEN-Node (also mit eigener PID) jede
> genehmigte Verbindung wiederholt mit dem selben Zielport?

Was nennst du "LISTEN-Node"?

Ein Socket im Status LISTEN ist nicht verbunden. Das ist ein Endpunkt,
der eine neue Verbindung akzeptiert.

Allerdings haben alle Verbindungen, die vom Client initiiert werden
(bei MySQL immer) zwangsweise alle die gleiche Portnummer und meist
auch die gleiche IP-Adresse am serverseitigen Ende. Und es gibt immer
auch einen Endpunkt mit dieser Adresse+Portnummer im LISTEN Modus.
Technisch sind alle diese Endpunkte Sockets (vergleichbar Filehandles)
- und sie sind vollkommen unabh�ngig voneinander.

Eine Verbindung hat man erst durch die Angabe des anderen Endpunkts
(auf der Client-Seite). [server:3306 - client:50000] w�re z.B. eine
TCP-Verbindung. [client:50000 - server:3306] ist die gleiche
Verbindung, nur in der Gegenrichtung. Es gibt bei TCP *immer* beide
Richtungen, zumindest wenn die Verbindung erstmal aufgebaut ist.
Deswegen sind beide Varianten gleichwertig und meinen die gleiche
Verbindung. Typischerweise zeigen die Tools immer das lokale Ende
als erstes. Z.B. netstat w�rde die gleiche Verbindung auf dem Server
genau anders herum anzeigen als auf dem Client.

Es kann schon rein technisch keine zweite TCP-Verbindung geben, die
auch [server:3306 - client:50000] oder [client:50000 - server:3306]
hei�t. Bzw. wenn das Tupel ein weiteres Mal auftaucht - z.B. in der
Ausgabe von lsof - dann meint es die *gleiche* Verbindung.

> Fakt ist, dass ich bei SSH-Verbindungen immer nur zwei
> TCP-Verbindungen sehe mit zwei unterschiedlichen Zielports. DAS finde

> ich noch verst�ndlich!

Ich verstehe nicht, was du meinst. *Ich* sehe in der Ausgabe von lsof
die *gleiche* SSH Verbindung zweimal:

zeta2:~# netstat -at | grep ssh
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 zeta2.xl.local:ssh beta.xl.local:53450 ESTABLISHED
tcp6 0 0 [::]:ssh [::]:* LISTEN

Das ist genau eine Verbindung. Plus zwei Sockets (einer IPv4,
einer IPv6), die weitere Verbindungen akzeptieren.

zeta2:~# lsof -i :22
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 3566 root 3u IPv6 5832 TCP *:ssh (LISTEN)
sshd 3566 root 4u IPv4 5834 TCP *:ssh (LISTEN)
sshd 9717 root 3u IPv4 11707115 TCP zeta2.xl.local:ssh->beta.xl.local:53450 (ESTABLISHED)
sshd 9719 schwenke 3u IPv4 11707115 TCP zeta2.xl.local:ssh->beta.xl.local:53450 (ESTABLISHED)

Beta ist meine Workstation, von der aus ich die SSH-Verbindung zu
Zeta2 (meinem Server) aufgebaut habe. Der Socket wird serverseitig
von zwei(!) sshd Prozessen aufgehalten. Einer (9717) l�uft als root.
Das ist der sshd Proze�, der die neu aufgemachte Verbindung vom sshd
Master (3566) bekommen hat. Aus Sicherheitsg�nden (Privilege Separation)
forkt der ein Kind (9719) das dann meine user-id annimmt:

zeta2:~# ps -fax
PID TTY STAT TIME COMMAND
...
3566 ? Ss 0:28 /usr/sbin/sshd
9917 ? Ss 0:00 \_ sshd: schwenke [priv]
9919 ? S 0:00 \_ sshd: schwenke@pts/2
9920 pts/2 Ss 0:00 \_ -bash
...

lsof kann also Verbindungen mehrfach anzeigen, aber nur dann, wenn
sie von mehreren Prozessen gleichzeitig offen gehalten werden.
Bei MySQL kann das aber nicht passieren. Denn der MySQL-Server ist
genau 1 (ein) Proze�.

Mein Fazit: was immer du siehst, sind *nicht* 5600 TCP-Verbindungen
f�r 62 offene MySQL-Verbindungen.


XL

PS: <seufz> im n�chsten Leben werde ich dann wohl doch Professor
und halte Vorlesungen "UNIX und Netzwerke"

PPS: kanonische Leseempfehlung:
W. Richard Stevens: "Unix Network Programming"