System Ressourcen erreichen den schwarzen Bereich - numfile!

Hallo!
Die Einstellungen werden über die mySQL Konfigurationsdatei (my.cnf) geregelt. Nach einer Änderung den mySQL Server einmal durchstarten. Allerdings sollte der Server nach einer Änderungen erst mal 48 Stunden laufen, um aussagekräftige Werte zu erhalten.

Hallo,
genau dies habe ich getan. Nur scheint es nicht angenommen zu werden?

Hier mal meine my.cnf:

Code:
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "/var/lib/mysql/my.cnf" to set server-specific options or
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
[mysqld]
set-variable=local-infile=0
#
# * Basic Settings
#
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
#
# For compatibility to other Debian packages that still use
# libmysqlclient10 and libmysqlclient12.
old_passwords	= 1
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
# bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 16M
max_allowed_packet	= 16M
thread_stack		= 128K
#
# * Query Cache Configuration
#
query_cache_limit	= 1048576
query_cache_size        = 16777216
query_cache_type        = 1
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log		= /var/log/mysql.log
#log		= /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log-slow-queries	= /var/log/mysql/mysql-slow.log
#
# The following can be used as easy to replay backup logs or for replication.
#server-id		= 1
log-bin			= /var/log/mysql/mysql-bin.log
expire-logs-days	= 20
max_binlog_size         = 104857600
#binlog-do-db		= include_database_name
#binlog-ignore-db	= include_database_name
#
# * BerkeleyDB
#
# According to an MySQL employee the use of BerkeleyDB is now discouraged
# and support for it will probably cease in the next versions.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# If you want to enable SSL support (recommended) read the manual or my
# HOWTO in /usr/share/doc/mysql-server/SSL-MINI-HOWTO.txt.gz
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the ndbd storage daemons,
# not from the ndb_mgmd management daemon.
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1

# Slow Query Log - Enable Logging of Slow Queries
log-slow-queries = /var/log/mysql-slow-queries.log
 
Ich werd einfach nicht schlau drauß. Auch keine Ahnung, warum mir jetzt apache, python und httpsd "um die Ohren fliegen".

Code:
root@www:~# lsof -n|grep -oE '^[a-z]+'|sort|uniq -c|sort -n
      6 init
      8 grep
      8 logger
      8 splogger
      8 uniq
     15 bash
     16 sort
     19 lsof
     22 xinetd
     25 syslogd
     27 sftp
     28 drwebd
     29 su
     31 rotatelog
     32 named
     39 mailmanct
     48 cron
     52 courierlo
     56 qmail
     64 couriertc
     97 ossec
    108 imapd
    111 spamd
    112 couriertl
    117 sshd
    148 mysqld
    255 httpsd
    288 python
    727 apache
    813 java

Die Werte sind doch viel zu hoch? Was tun?
 
Besucher wegschicken, Dienste beenden, größeren bzw. richtigen Server mieten. Nicht unbedingt in dieser Reihenfolge.

Ach, herrlich diese Antworten...
Ist doch nicht schwer zu verstehen, dass meine Frage darauf abziehlt an dem bestehenden System Veränderungen vorzunehmen, so dass das vorliegende Problem gelöst werden kann?

Grundlegend ist es einfach nicht normal, dass numfile ständig das hardlimit erreicht. Dies liegt, soweit ich es herausgefunden habe, an der Java VM. Jedoch warum diese "unnütze" Prozesse/Dateien öffnet und nicht wieder schließt oder einfach Dateien generell nicht schließt ist doch die Frage. Für alle dies betreffende relevante Antworten bin ich euch dankbar.
 
Ist doch nicht schwer zu verstehen, dass meine Frage darauf abziehlt an dem bestehenden System Veränderungen vorzunehmen, so dass das vorliegende Problem gelöst werden kann?
Ich habe hier einen VW Käfer von 1980 und will 200 km/h auf der Autobahn fahren. Aber ich will unbedingt den Käfer behalten...

Mach dir doch einfach klar, dass du nicht alles haben kannst und Kompromisse eingehen musst. Wenn du den Virtual-Server behalten willst, bleiben ja noch 2 der genannten Möglichkeiten übrig.

Die Anzahl der offenen Dateien (oder nennen wir es korrekterweise Dateideskriptoren) steigt i. d. R. fast linear mit der Anzahl der Benutzer. Es wird nämlich für jeden Benutzer eine Verbindung benötigt und eventuell noch weitere Dateien geöffnet, z. B. um eine Konfiguration zu lesen oder eine History zu schreiben (ich schrieb jetzt bewusst nicht Log). Und da bei Linux alles eine Datei ist, kannst du dir die Folgen ausmalen.
 
Ich habe hier einen VW Käfer von 1980 und will 200 km/h auf der Autobahn fahren. Aber ich will unbedingt den Käfer behalten...

Mit div. Umbauten am Käfer lässt sich dieses Vorhaben in die Praxis umsetzen...

Mach dir doch einfach klar, dass du nicht alles haben kannst und Kompromisse eingehen musst. Wenn du den Virtual-Server behalten willst, bleiben ja noch 2 der genannten Möglichkeiten übrig.

Ich würde ja gerne Kompromisse eingehen wollen, da ich den VS gerne behalten möchte, darum Frage ich doch nach Lösungswegen.

Die Anzahl der offenen Dateien (oder nennen wir es korrekterweise Dateideskriptoren) steigt i. d. R. fast linear mit der Anzahl der Benutzer. Es wird nämlich für jeden Benutzer eine Verbindung benötigt und eventuell noch weitere Dateien geöffnet, z. B. um eine Konfiguration zu lesen oder eine History zu schreiben (ich schrieb jetzt bewusst nicht Log). Und da bei Linux alles eine Datei ist, kannst du dir die Folgen ausmalen.

Es ist mir schon klar, dass eine neue Verbindung ein Socket öffnet/benötigt. Das Problem in diesem Falle ist, dass es anscheinend viel zu viele sind. Die Höhe von numfile steht in keinem Verhältnis zu den Verbindungen von und zu openfire - dies haben auch die Entwickler bestätigt, nur haben diese keine Idee, warum sich meine Java VM so "seltsam" verhält.

Da stellt sich die Frage, wie bekomme ich das Problem in den Griff?

- Eine Möglichkeit ist, Java zu debuggen. Davon habe ich leider keinen Plan und bis jetzt ist noch keiner mit hilfreichen Tips aus dieser Richtung an mich herangetreten, bzw. konnte es.

- Eine andere Möglichkeit wäre, das System zu entschlacken, bzw. in irgendeiner Art und Weise stabieler zu gestalten. (Hierbei sollten aber Apache, Qmail, Imap, MySQL weiterhin laufen.)

Z.B. ist die Ausgabe "288 python" doch viel zu hoch, dafür, dass ich keine Python-Skript o.Ä. verwende - oder?
 
- Eine Möglichkeit ist, Java zu debuggen.
Das kannst Du IMHO auch vergessen. Wenn das entsprechende Java-Programm auf viele Klassen zu greift, müssen diese ja auch geladen werden. Die entsprechenden jar-Files brauchen ebenfalls alle file descriptoren. Wahrscheinlich ist es keine gute Idee, große Java-Programme auf einem vServer laufen zu lassen.

Z.B. ist die Ausgabe "288 python" doch viel zu hoch, dafür, dass ich keine Python-Skript o.Ä. verwende - oder?
Dann schau mal mit lsof nach, welche Prozess-ID sich dahinter den Python-Prozessen verbirgt. Ein "ps -efH" verrät Dir dann auch schnell, welcher Dienst intern Python-Scripte einsetzt.
 
Back
Top