MySQL 4.0.24 (OpenBSD port) und Errcode 9 bzw. 17

Hallo zusammen,

vor kurzem trat der Fehler "Can't create/write to file
'/tmp/#sql_52d8_0.MYI' (Errcode: 17)" bei manchen SQL-Statements auf
und es wurde kein Ergebnis zurückgegeben.
Die Datei war in "/tmp" mit 0 Bytes angelegt. Die Rechte waren korrekt
eingestellt.

Im Endeffekt waren es vier solcher Dateien im temporären Verzeichnis.
Nachdem diese gelöscht waren hat alles wieder funktioniert und zwar
ganz ohne Probleme.

Davor oder währenddessen sind außerdem Errcodes 9 und "Bad file
descriptor" aufgetreten. Das hört sich nach einer bekannten
Einschränkung von OpenBSD an bezüglich der erlaubten offenen Dateien.
Allerdings wurde diese Grenze über den "open_files_limit"-Parameter
von MySQL bereits auf 1772 (die Grenze von OpenBSD) angehoben.

Ich bin jetzt etwas ratlos wodurch der Fehler tatsächlich ausgelöst
werden konnte. Wenn tatsächlich zu viele Dateien offen waren kann es
doch nicht sein dass ich einfach die vier temporären Dateien löschen
kann und dann keine Probleme mehr auftreten.
Außerdem kann ich die Grenze der maximal erlaubten offenen Dateien
nicht beliebig anheben.

Wie kann man also dem Fehlergrund auf die Spur kommen?

Viele Grüße,
Glenn Kusardi

Re: MySQL 4.0.24 (OpenBSD port) und Errcode 9 bzw. 17

"Glenn Kusardi" wrote:

> vor kurzem trat der Fehler "Can't create/write to file
> '/tmp/#sql_52d8_0.MYI' (Errcode: 17)" bei manchen SQL-Statements auf
> und es wurde kein Ergebnis zurückgegeben.
> Die Datei war in "/tmp" mit 0 Bytes angelegt. Die Rechte waren korrekt
> eingestellt.

Hmm. MySQL auf Linux sagt:

~ $perror 17
OS error code 17: File exists

Allerdings müssen die (errno) Fehlercodes nicht mit denen von OpenBSD
übereinstimmen. Was sagt denn dein 'perror' dazu?

> Im Endeffekt waren es vier solcher Dateien im temporären Verzeichnis.
> Nachdem diese gelöscht waren hat alles wieder funktioniert und zwar
> ganz ohne Probleme.

Das würde zu obiger Meldung passen. Die Frage bleibt: warum bekommen
mehrere temporäre Files den gleichen Filenamen? IIRC codiert MySQL die
Thread-ID und einen Zähler pro Thread in den Namen. Eventuell gibt es
ja Probleme aus der Thread-Ecke (AFAIK eines der Probleme mit *BSD)

> Davor oder währenddessen sind außerdem Errcodes 9 und "Bad file
> descriptor" aufgetreten. Das hört sich nach einer bekannten
> Einschränkung von OpenBSD an bezüglich der erlaubten offenen Dateien.
> Allerdings wurde diese Grenze über den "open_files_limit"-Parameter
> von MySQL bereits auf 1772 (die Grenze von OpenBSD) angehoben.

Das wäre trivial zu überprüfen. SHOW STATUS LIKE 'Open_files' zeigt
dir, wieviele Filedescriptoren mysqld geöffnet hält.

> Wie kann man also dem Fehlergrund auf die Spur kommen?

Wenn du einen reproduzierbaren Testfall hast, reporte einen Bug auf
http://bugs.mysql.com


XL

Re: MySQL 4.0.24 (OpenBSD port) und Errcode 9 bzw. 17

Axel Schwenke wrote:

> Allerdings müssen die (errno) Fehlercodes nicht mit denen von OpenBSD
> übereinstimmen. Was sagt denn dein 'perror' dazu?

Ebenfalls "file exists".

> Das würde zu obiger Meldung passen. Die Frage bleibt: warum bekommen
> mehrere temporäre Files den gleichen Filenamen? IIRC codiert MySQL die
> Thread-ID und einen Zähler pro Thread in den Namen. Eventuell gibt es
> ja Probleme aus der Thread-Ecke (AFAIK eines der Probleme mit *BSD)

Aber das kann nicht das einzige Problem sein, denn: Wenn es so wäre,
dass MySQL einfach nur doppelte Dateinamen für temporäre Daten
verteilt, dann müssten doch bereits angelegte Dateien trotzdem
ordnungsgemäß gelöscht werden.

> > Einschränkung von OpenBSD an bezüglich der erlaubten offenen Dateie=
n
> > Allerdings wurde diese Grenze über den "open_files_limit"-Parameter
> > von MySQL bereits auf 1772 (die Grenze von OpenBSD) angehoben.
> Das wäre trivial zu überprüfen. SHOW STATUS LIKE 'Open_files' zeigt
> dir, wieviele Filedescriptoren mysqld geöffnet hält.

Beim nächsten Auftreten des Fehlers werde ich das im Auge behalten.
Aber eigentlich schließe ich das aus.

> Wenn du einen reproduzierbaren Testfall hast, reporte einen Bug auf
> http://bugs.mysql.com

Leider nicht, das Problem tritt sporadisch auf und ohne ersichtliche
Fehlerursache. Im Moment läuft ein Überwachungsskript das prüft ob
der Fehler auftritt. Das ist aber natürlich keine Lösung.

Gibt es irgendwelche MySQL-Hacker die bei sowas helfen können, gerne
auch kommerzielle Anbieter von Beratungsleistungen (aber nicht MySQL AB
bei denen man einen MySQL Berater nicht unter 1 Manntag bekommt und sie
eigentlich gleich das Serverkomplettberatungspaket verkaufen wollen).

Viele Grüße,
Glenn

Re: MySQL 4.0.24 (OpenBSD port) und Errcode 9 bzw. 17

Hi,
ich hatte das gleiche problem mit OpenBSD 3.8...
MySQL sagt "this error should never happen" ;) - grossartige
Hilfe.

Naja, ich habe die login.conf um

[snip]
_mysql:\
:datasize=infinity:\
:maxproc=infinity:\
:openfiles-cur=2048:\
:openfiles-max=8192:\
:stacksize-cur=8M:\
:localcipher=blowfish,8:\
:tc=default:
[snip]

erweitert


ausserdem in sysctl.conf

[snip]
kern.maxfiles=16384
kern.somaxconn=256
[snip]

geschrieben.

Seitdem verhält sich die Kiste stabil.
Mein ander Webserver unter FreBSD 6.0 läuft wie gelutsch und
zeigt selbst unter Vollauslastung keinerlei Probleme.
Deswegen wir der OpenBSD webserver nach FreeBSD portiert und Ruhe ist.

Beste Grüße

Tim


Glenn Kusardi schrieb:
> Axel Schwenke wrote:
>
> Leider nicht, das Problem tritt sporadisch auf und ohne ersichtliche
> Fehlerursache. Im Moment läuft ein Überwachungsskript das prüft ob
> der Fehler auftritt. Das ist aber natürlich keine Lösung.
>
> Gibt es irgendwelche MySQL-Hacker die bei sowas helfen können, gerne
> auch kommerzielle Anbieter von Beratungsleistungen (aber nicht MySQL AB
> bei denen man einen MySQL Berater nicht unter 1 Manntag bekommt und sie
> eigentlich gleich das Serverkomplettberatungspaket verkaufen wollen).
>
> Viele Grüße,
> Glenn
>

Re: MySQL 4.0.24 (OpenBSD port) und Errcode 9 bzw. 17

Tim Maass wrote:

> :openfiles-cur=3D2048:\
> :openfiles-max=3D8192:\
> kern.maxfiles=3D16384
> Seitdem verhält sich die Kiste stabil.

Das war auch meine erste Überlegung, dass es daran liegt.

Aber als das Problem vor Kurzem wieder aufgetreten ist, hat SHOW STATUS
in der MySQL Konsole beim Wert für open_files nur ~25 angezeigt. Das
ist weit weg von jeder Beschränkung, auch unter OpenBSD.

Das würde die Vermutung entkräften dass es daran liegt, dass MySQL
nicht genug Dateien öffnen kann.

Viele Grüße,
Glenn