connects dauern z.T. sehr lange, warum?

connects dauern z.T. sehr lange, warum?

am 03.04.2006 22:15:21 von Michael Pichler

Hallo,

Ich hab folgendes Problem mit einem Mysql-Server:

4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
Datenbank Server extrem lange.
Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.

Ich hab bereits mehrfach geprüft, ob zu diesem Zeiten
irgendwelche Cronjobs laufen, nix, auch keine System-Jobs.
Weder auf dem einen noch auf dem anderen Server.

Es gehen auch keine vermehrten Abfragen ein, die Zahl der
Queries/Sekunde bleibt unverändert.
Auch Speicher ist genügend vorhanden, kein Swappen, nix.
Auch die CPU-Last bleibt in diesem Zeitraum unverändert auf
niedrigem Niveau.

Mysql ist in der Version 4.1.10a Max.
OS ist SuSE 9.3.

Wodurch kann es verursacht werden, dass connects so extrem lange dauern
und dann z.T. mit einem timeout abbrechen.
Welche Parameter/Variablen könnte ich verändern, bzw. wie kann ich mysql
veranlassen mir mehr Informationen zu geben?

Bin für jeden Tipp dankbar!

Gruß

Michael Pichler


Start-Parameter:
/usr/sbin/mysqld \
--bootstrap \
--skip-innodb \
--skip-bdb \
--skip-grant-tables \
--user=mysql \
--pid-file=/var/lib/mysql/mysqld.pid \
--socket=/var/lib/mysql/mysql.sock \
--datadir=/var/lib/mysql \
--log-slow-queries=/var/log/mysql-slow.log \
--log-long-format


my.cnf:

[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 1024M
max_allowed_packet = 16M
table_cache = 1024
sort_buffer_size = 8M
net_buffer_length = 1M
myisam_sort_buffer_size = 128M
thread_cache_size = 8
query_cache_size = 128M
thread_concurrency = 4
max_connections = 200
net_read_timeout = 10
tmp_table_size = 134217728
wait_timeout = 120
ft_min_word_len = 2
ft_stopword_file =
server-id = 1

[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 1024M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
ft_min_word_len = 2
ft_stopword_file =

[mysqlhotcopy]
interactive-timeout

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 00:18:03 von stefan hoffmann

tach Micahel,

Michael Pichler schrieb:
> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
> Datenbank Server extrem lange.
Von remote PCs? Klingt nach einem Netzwerkproblem.

> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.
Lass mal tcpdump laufen, schalte dein Interface in promiscuous mode.


mfG
--> stefan <--

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 02:37:31 von Sven Paulus

Michael Pichler wrote:
> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
> Datenbank Server extrem lange.
> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.

Eventuell ein DNS-Problem (Server laedt zu diesem Zeitpunkt ewig
viele Zonen neu und kann keine Queries beantworten oder so)? Oder
machen die Netzwerker zu diesem Zeitpunkt irgendwelche Spielereien?

Hast Du einfach mal probiert, was passiert, wenn du zu diesen Zeiten
manuell versuchst (z.B. mittels telnet) auf den MySQL-Port zu
connecten?

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 08:27:24 von Michael Pichler

Sven Paulus schrieb:
> Michael Pichler wrote:
>> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
>> Datenbank Server extrem lange.
>> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
>> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.
>
> Eventuell ein DNS-Problem (Server laedt zu diesem Zeitpunkt ewig
> viele Zonen neu und kann keine Queries beantworten oder so)? Oder
> machen die Netzwerker zu diesem Zeitpunkt irgendwelche Spielereien?
>
> Hast Du einfach mal probiert, was passiert, wenn du zu diesen Zeiten
> manuell versuchst (z.B. mittels telnet) auf den MySQL-Port zu
> connecten?

hallo,

danke für die Antworten.
Der Server hat 2 Netzwerkschnittstellen. Das Propblem tritt leider bei
beiden auf.
Auch ein Connect direkt von der Shell mit dem mysql client klappt zu
diesen Zeiten nicht.

Am Netzwerk dürfte es also eigentlich nicht liegen.

Gruß
Michael

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 08:49:58 von Axel Schwenke

Sven Paulus wrote:
> Michael Pichler wrote:
>> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
>> Datenbank Server extrem lange.
>> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
>> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.
>
> Eventuell ein DNS-Problem (Server laedt zu diesem Zeitpunkt ewig
> viele Zonen neu und kann keine Queries beantworten oder so)?

Das wäre auch meine Vermutung. Defaultmäßig macht MySQL beim Connect
ein DNS-Lookup nach dem Hostnamen des Clients (um per IP *und* Hostname
in den Permission-Tabellen suchen zu können).

Ich hatte mal ein Problem der selben Art, als zwei Dinge zusammen
gekommen sind:

1. ein cronjob machte regelmäßig FLUSH HOSTS auf die Datenbank
2. nscd lief nicht

Unter diesen Bedingungen dauerten Connects dann mal mehrere 10
Sekunden, was bei ~200 Connects/s tödlich war.


Michael, welches Betriebssystem? Läuft auf der MySQL-Maschine nscd?
Wie ist das DNS organisiert? Wie lang ist "extrem lang"?


XL

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 10:18:59 von Michael Pichler

> Sven Paulus wrote:
>> Michael Pichler wrote:
>>> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
>>> Datenbank Server extrem lange.
>>> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
>>> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.
>> Eventuell ein DNS-Problem (Server laedt zu diesem Zeitpunkt ewig
>> viele Zonen neu und kann keine Queries beantworten oder so)?
>
> Das wäre auch meine Vermutung. Defaultmäßig macht MySQL beim Connect
> ein DNS-Lookup nach dem Hostnamen des Clients (um per IP *und* Hostname
> in den Permission-Tabellen suchen zu können).
>
> Ich hatte mal ein Problem der selben Art, als zwei Dinge zusammen
> gekommen sind:
>
> 1. ein cronjob machte regelmäßig FLUSH HOSTS auf die Datenbank
> 2. nscd lief nicht
>
> Unter diesen Bedingungen dauerten Connects dann mal mehrere 10
> Sekunden, was bei ~200 Connects/s tödlich war.
>
>
> Michael, welches Betriebssystem? Läuft auf der MySQL-Maschine nscd?
> Wie ist das DNS organisiert? Wie lang ist "extrem lang"?
>
>
> XL

Hallo,

als OS läuft SuSE 9.3, der nscd ist aktiv.

Wegen der Rechte benötige ich eigentlich kein Name Resolving, da der
SQL-Server anwendungsbedingt sowieso von überall her erreichbar sein
muss. Kann man das abschalten?

Ein flush Hosts wird auch nicht durchgeführt.
Die Status Anzeige sagt, dass seit dem letzten Start, vor 5 Tagen, nur
ein Flush Befehl durchgeführt wurde.

Vielleicht würde es auch helfen, eine Art Debug Modus einzuschalten.
Wie und wo kann man das?
Die beiden Logs, die bisher geführt werden (/var/lib/mysqld.log und
/var/lib/mysqld.log.1) bleiben leer bis auf Meldungen dass der Service
gestartet bzw beendet wurde (bei einem manuellen Neustart von mysql).

vielen Dank & Gruß
Michael

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 11:34:45 von Michael Pichler

Axel Schwenke schrieb:
>[...]
> Wie ist das DNS organisiert? Wie lang ist "extrem lang"?
>
>
> XL

Auf dem Server läuft kein DNS-Server.
Zum Auflösen von Namen werden die Nameserver des Hosters verwendet, bei
dem der Server steht.

"sehr lange" bedeutet 5 bis 20 Sekunden, so dass zum Teil der client mit
einem Timeout abbricht.

Gruß
Michael

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 12:17:04 von Sven Paulus

Michael Pichler wrote:
> Auf dem Server läuft kein DNS-Server.
> Zum Auflösen von Namen werden die Nameserver des Hosters verwendet, be=
i=20
> dem der Server steht.

Aber genau dies kann ja das Problem sein: Kannst Du sicherstellen,
dass dieser DNS-Server permanent verfuegbar ist? Und nicht zeitweise
sehr lange fuer seine Antworten braucht, denn eine Zeitspanne ...

> "sehr lange" bedeutet 5 bis 20 Sekunden, so dass zum Teil der client mit=
=20
> einem Timeout abbricht.

.... in dieser Groessenordnung kann ich mir durchaus schon durch DNS
verursacht vorstellen, z.B. wenn bei dem Hoster die authoritativen=20
und die rekursiven DNS-Dienste auf der gleichen Serverinstanz laufen
und er wirklich regelmaessig komplette Zone-Reloads macht.

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 12:19:21 von Michael Pichler

Michael Pichler schrieb:
>[...]
>
> 4x am Tag, genau alle 6 Stunden dauert ein Connect zu dem
> Datenbank Server extrem lange.
> Immer genau um 00:00 Uhr, um 06:00 Uhr, um 12:00 Uhr und um 18:00 Uhr.
> Der Spuk dauert dann 2 bis 5 Minuten und ist dann wieder vorbei.
>
> Ich hab bereits mehrfach geprüft, ob zu diesem Zeiten
> irgendwelche Cronjobs laufen, nix, auch keine System-Jobs.
> Weder auf dem einen noch auf dem anderen Server.

Auf Grund der Anregung mit dem DNS habe ich auf dem Server jetzt einen
Nameserver installiert. Es gibt nur die localhost Zone und diverse
Forwarder. Ausserdem hab ich den locahost als ersten Nameserver in der
Netzwerkkonfiguration eingetragen. Seit dem ist das Problem behoben.

Ich vermute also, dass der Nameserver, der vorher als Standard verwendet
wurde, genau zu diesen Zeiten sehr verzögert geantwortet hat.

Seltsam finde ich, dass scheinbar der nscd, der ja bereits vorher auf
dem System lief, nicht verwendet wurde.

Vielen Dank für eure Hilfe!

Gruß
Michael

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 12:55:45 von Axel Schwenke

Michael Pichler wrote:
> Axel Schwenke schrieb:
>>[...]
>> Wie ist das DNS organisiert? Wie lang ist "extrem lang"?
>>
>>
>> XL
>
> Auf dem Server läuft kein DNS-Server.
> Zum Auflösen von Namen werden die Nameserver des Hosters verwendet, bei
> dem der Server steht.

Hmm. Das ist suboptimal.

Ich sehe auch gerade, daß nscd auf SuSE defaultmäßig keine Hostnamen
cached. Ich würde sagen, schalte das mal an (/etc/nscd.conf) und schau
ob das Problem dann weg ist. Besser wäre es, einen lokalen DNS-Cache
laufen zu lassen.

Du kannst die Namensauflösung in MySQL per --skip-name-resolve auch
ganz abschalten. Davon würde ich aber abraten. Noch mehr abraten würde
ich davon, einen MySQL-Server uneingeschränkt im Internet verfügbar zu
machen. Das Protokoll ist praktisch Klartext (aber zumindest das
Paßwort wird verschlüsselt übertragen).

Du hast die Wahl, per SSL verschlüsselte Verbindungen zu benutzen (das
ist etwas tricky, weil du die Zertifikate erzeugen mußt) oder eine dir
passende Tunnel- oder VPN-Lösung zu verwenden.


XL

Re: connects dauern z.T. sehr lange, warum?

am 04.04.2006 13:11:28 von Michael Pichler

Axel Schwenke schrieb:
> Michael Pichler wrote:
>> Axel Schwenke schrieb:
>>> [...]
>>> Wie ist das DNS organisiert? Wie lang ist "extrem lang"?
>>>
>>>
>>> XL
>> Auf dem Server läuft kein DNS-Server.
>> Zum Auflösen von Namen werden die Nameserver des Hosters verwendet, bei
>> dem der Server steht.
>
> Hmm. Das ist suboptimal.
>
> Ich sehe auch gerade, daß nscd auf SuSE defaultmäßig keine Hostnamen
> cached. Ich würde sagen, schalte das mal an (/etc/nscd.conf) und schau
> ob das Problem dann weg ist. Besser wäre es, einen lokalen DNS-Cache
> laufen zu lassen.

Hab jetzt einen lokalen NS installiert. Problem ist seit dem behoben.
Dass SuSE dem nscd das Cachen von Hostnamen per Standard untersagt find
ich schon sehr merkwürdig.

> Du kannst die Namensauflösung in MySQL per --skip-name-resolve auch
> ganz abschalten. Davon würde ich aber abraten. Noch mehr abraten würde
> ich davon, einen MySQL-Server uneingeschränkt im Internet verfügbar zu
> machen. Das Protokoll ist praktisch Klartext (aber zumindest das
> Paßwort wird verschlüsselt übertragen).

Das geht leider auf Grund der Anwendung nicht anders.

> Du hast die Wahl, per SSL verschlüsselte Verbindungen zu benutzen (das
> ist etwas tricky, weil du die Zertifikate erzeugen mußt) oder eine dir
> passende Tunnel- oder VPN-Lösung zu verwenden.

Die Rechte der Benutzer sind so gesetzt, dass die "sensiblen" Daten nur
von einer bestimmten IP/Benutzer abfragbar sind. Diese private (10.xxx)
IP ist per Crosslink angebunden. So wirds wenigstens ein bisschen sicher.

vielen Dank für die Hilfe

Gruß
Michael



> XL