Mysql too many connections
- Thread starter DjTom-i
- Start date
Muss nicht zwangsläufig daran liegen, vielleicht ist die Belastung des Servers einfach gestiegen und er braucht mehr Verbindungen.DjTom-i said:
-> Maximal erlaubte Verbindungen in der my.cnf erhöhen.
Die aktuellen Verbindungen kannst du dir mit dem SQL-Befehl 'SHOW PROCESSLIST' anzeigen lassen (oder einfach in phpMyAdmin als root auf 'Prozesse anzeigen' gehen).
Bei mir ists in /etc/mysql/my.cnf. Ansonsten: find / -name my.cnf
DjTom-i
Member
keine my.cnf
Kann mir einer sagen wie ich gerade rausfinde welche my.cnf gerade in Verwendung ist...
Ich habe nur eine auf dem ganzen Server aber die liegt in einem backup ordner ganz tief vergraben...
Meine mysql läuft allerdings... bis auf die Aussetzer heute morgen.
Komisch! Isch dreh dorsch ;-)
Ps: An die lieben Mods: Bitte ins Mysql Forum verschieben... Danke!
Kann mir einer sagen wie ich gerade rausfinde welche my.cnf gerade in Verwendung ist...
Ich habe nur eine auf dem ganzen Server aber die liegt in einem backup ordner ganz tief vergraben...
Meine mysql läuft allerdings... bis auf die Aussetzer heute morgen.
Komisch! Isch dreh dorsch ;-)
Ps: An die lieben Mods: Bitte ins Mysql Forum verschieben... Danke!
Huschi
Moderator
I.d.R. /etc/my.cnf
Sollte die nicht vorhanden sein, mußt Du in /etc/init.d/mysql nachsehen, wo er eine Config läd.
Aber eine Manipulation an MySQL läßt den fehlerhaften Scripten nur noch mehr Raum, Deinen Server zu blockieren.
Du hast hier entweder ein Fehler im diversen Scripten oder eine Deathlock-Situation in der Datenbank. Denn alle Abfragen die länger als 3 Sekunden hängen sind blockiert.
PS: Beachte bitte Punkt 3 der Boardregeln.
huschi.
Sollte die nicht vorhanden sein, mußt Du in /etc/init.d/mysql nachsehen, wo er eine Config läd.
Aber eine Manipulation an MySQL läßt den fehlerhaften Scripten nur noch mehr Raum, Deinen Server zu blockieren.
Du hast hier entweder ein Fehler im diversen Scripten oder eine Deathlock-Situation in der Datenbank. Denn alle Abfragen die länger als 3 Sekunden hängen sind blockiert.
PS: Beachte bitte Punkt 3 der Boardregeln.
huschi.
DjTom-i
Member
MySQL
zu Punkt 3 der Boardregeln: Sorry!
Ich habe mir leider seit Jahren im Inet Kleinschreibung angewöhnt. Wie du an meinem letzten Post gesehen hast, habe ich es auch "mal wieder" bemerkt.
Nun wieder zurück zum Thema:
Also ich hatte in /home/backup/my.cnf die einzige my.cnf auf dem System.
Hier meine Init.D MySQL
***Verstehe ich daraus richtig, dass er erst in /etc/ nachschaut ob eine my.cnf vorhanden ist und dann wenn er keine findet im basedir, also in diesem Falle in / nach einer my.cnf durchsucht und diese dann verwendet?
Das Problem mit den Prozessen habe ich wahrscheinlich auch im Griff, denn ein Kunde hat ein Script welches erst nach 15 Sekunden die Connection zur DB trennte... da er aber oft um die 200 User und mehr Online hat ist meine DB abgekackt...
Also folgendes muß ich noch wissen:
1. Ist die Aussage die mit *** beginnt richtig?
2. Gibt es einen Befehl oder Trick mit dem ich sehe welche my.cnf gerade verwendet wird?
3. Kennt Ihr ein schönes MySQL Konfigurationstutorial?
zu Punkt 3 der Boardregeln: Sorry!
Ich habe mir leider seit Jahren im Inet Kleinschreibung angewöhnt. Wie du an meinem letzten Post gesehen hast, habe ich es auch "mal wieder" bemerkt.
Nun wieder zurück zum Thema:
Also ich hatte in /home/backup/my.cnf die einzige my.cnf auf dem System.
Hier meine Init.D MySQL
Code:
# If you want to affect other MySQL variables, you should make your changes
# in the /etc/my.cnf, ~/.my.cnf or other MySQL configuration files.
basedir=
# The following variables are only set for letting mysql.server find things.
# Set some defaults
datadir=/var/lib/mysql
pid_file=
if test -z "$basedir"
then
basedir=/
bindir=/usr/bin
else
bindir="$basedir/bin"
fi
PATH=/sbin:/usr/sbin:/bin:/usr/bin:$basedir/bin
export PATH
mode=$1 # start or stop
case `echo "testing\c"`,`echo -n testing` in
*c*,-n*) echo_n= echo_c= ;;
*c*,*) echo_n=-n echo_c= ;;
*) echo_n= echo_c='\c' ;;
esac
parse_arguments() {
for arg do
case "$arg" in
--basedir=*) basedir=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
--datadir=*) datadir=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
--pid-file=*) pid_file=`echo "$arg" | sed -e 's/^[^=]*=//'` ;;
esac
done
}
# Get arguments from the my.cnf file,
# groups [mysqld] [mysql_server] and [mysql.server]
if test -x ./bin/my_print_defaults
then
print_defaults="./bin/my_print_defaults"
elif test -x $bindir/my_print_defaults
then
print_defaults="$bindir/my_print_defaults"
elif test -x $bindir/mysql_print_defaults
then
print_defaults="$bindir/mysql_print_defaults"
else
# Try to find basedir in /etc/my.cnf
conf=/etc/my.cnf
print_defaults=
if test -r $conf
then
subpat='^[^=]*basedir[^=]*=\(.*\)$'
dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf`
for d in $dirs
do
d=`echo $d | sed -e 's/[ ]//g'`
if test -x "$d/bin/my_print_defaults"
then
print_defaults="$d/bin/my_print_defaults"
break
fi
if test -x "$d/bin/mysql_print_defaults"
then
print_defaults="$d/bin/mysql_print_defaults"
break
fi
done
fi
# Hope it's in the PATH ... but I doubt it
test -z "$print_defaults" && print_defaults="my_print_defaults"
fi
#
# Test if someone changed datadir; In this case we should also read the
# default arguments from this directory
#
extra_args=""
if test "$datadir" != "/var/lib/mysql"
then
extra_args="-e $datadir/my.cnf"
fi
parse_arguments `$print_defaults $extra_args mysqld server mysql_server mysql.server`
#
# Set pid file if not given
#
if test -z "$pid_file"
then
pid_file=$datadir/`/bin/hostname`.pid
else
case "$pid_file" in
/* ) ;;
* ) pid_file="$datadir/$pid_file" ;;
esac
fi
# Safeguard (relative paths, core dumps..)
cd $basedir
case "$mode" in
'start')
# Start daemon
if test -x $bindir/mysqld_safe
then
# Give extra arguments to mysqld with the my.cnf file. This script may
# be overwritten at next upgrade.
$bindir/mysqld_safe --datadir=$datadir --pid-file=$pid_file >/dev/null 2>&1 &
# Make lock for RedHat / SuSE
if test -w /var/lock/subsys
then
touch /var/lock/subsys/mysql
fi
else
echo "Can't execute $bindir/mysqld_safe from dir $basedir"
fi
;;
'stop')
# Stop daemon. We use a signal here to avoid having to know the
# root password.
if test -s "$pid_file"
then
mysqld_pid=`cat $pid_file`
echo "Killing mysqld with pid $mysqld_pid"
kill $mysqld_pid
# mysqld should remove the pid_file when it exits, so wait for it.
sleep 1
while [ -s $pid_file -a "$flags" != aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ]
do
[ -z "$flags" ] && echo $echo_n "Wait for mysqld to exit$echo_c" || echo $echo_n ".$echo_c"
flags=a$flags
sleep 1
done
if [ -s $pid_file ]
then echo " gave up waiting!"
elif [ -n "$flags" ]
then echo " done"
fi
# delete lock for RedHat / SuSE
if test -f /var/lock/subsys/mysql
then
rm -f /var/lock/subsys/mysql
fi
else
echo "No mysqld pid file found. Looked for $pid_file."
fi
;;***Verstehe ich daraus richtig, dass er erst in /etc/ nachschaut ob eine my.cnf vorhanden ist und dann wenn er keine findet im basedir, also in diesem Falle in / nach einer my.cnf durchsucht und diese dann verwendet?
Das Problem mit den Prozessen habe ich wahrscheinlich auch im Griff, denn ein Kunde hat ein Script welches erst nach 15 Sekunden die Connection zur DB trennte... da er aber oft um die 200 User und mehr Online hat ist meine DB abgekackt...
Also folgendes muß ich noch wissen:
1. Ist die Aussage die mit *** beginnt richtig?
2. Gibt es einen Befehl oder Trick mit dem ich sehe welche my.cnf gerade verwendet wird?
3. Kennt Ihr ein schönes MySQL Konfigurationstutorial?
Huschi
Moderator
Du brauchst lediglich eine /etc/my.cnf anlegen und die Werte, die Du verändern willst dort eintragen.DjTom-i said:
evtl. steht es in der Commandozeile, die auch im 'ps ax|grep mysql' angezeigt wird. Ansonsten würde ich sagen, er nutzt keine der vorhandenen Configfiles, da er ja keine passende findet.
http://dev.mysql.com/doc/mysql/de/configuring-mysql.html
huschi.
Hm, würde ich nicht allgemein so sagen. Kann ja durchaus sein, dass Scripts hat, die recht lange laufen. Wenn dann die Zugriffszahlen stark steigen, kann es da zu einem Engpass kommen, obwohl die Scripte korrekt laufen. In dem Fall wäre das Erhöhen der maximalen Verbindungen sicherlich nicht falsch.Huschi said:
Natürlich kanns auch an fehlerhaften Scripten liegen, aber wie gesagt, allgemein würd ich das nicht so behaupten.
DjTom-i
Member
Hi
Habe mir heute mal die Prozess List angeschaut und dort sind prozesse die über 16000 sec haben.
Der Entwickler und ich haben ja schon eine Quelle des Übels beseitigt.
Das war so ein böser Block.
Wonach soll ich genau ausschau halten?
Will die Sache nämlich optimal lösen und auch die Scripte optimieren.
Wenn Ihr irgendwelche Logfiles braucht...
Dank im Voraus.
Gruß
Tom-i
Habe mir heute mal die Prozess List angeschaut und dort sind prozesse die über 16000 sec haben.
Der Entwickler und ich haben ja schon eine Quelle des Übels beseitigt.
Das war so ein böser Block.
Wonach soll ich genau ausschau halten?
Will die Sache nämlich optimal lösen und auch die Scripte optimieren.
Wenn Ihr irgendwelche Logfiles braucht...
Dank im Voraus.
Gruß
Tom-i
Huschi
Moderator
Ein 'kill [ID];' hilft erstmal schnell.DjTom-i said:
Logfiles kann man momentan noch nicht gebrauchen. Aber ein gutes Script sollte in irgendein Logfile reinschreiben, wenn ein DB-Zugriff nicht ordnungsgemäß läuft. Zur Not auf STDERR, was unter Apache dann im error_log zu finden ist.
Wichtig: Erst nach dem Kill erfährt das Script, daß etwas nicht funktioniert.
Ansonsten kann man z.B. mit einem einfachen Cron-Script nachsehen lassen, ob wieder eine Connection zu lange hängt und evtl. automatisch gekillt wird.
huschi.
Vielleicht ein Programm, was ständig die MySQL-Verbindung aufrecht erhält? Bspw. mein jabberd2 nutzt MySQL und ist ständig mit dem Server verbunden...Huschi said:Das war auch nicht allgemein gesagt.
Es bezog sich auf die langen Connections aus der o.a. Processlist von bis zu 1658 Sekunden. Das sind fast 28 Minuten. Sorry, aber hier ist definitiv etwas daneben.
Aber gut, den Datenbankusernamen siehts eher nach einem Web-User aus und damit dürftest du dann Recht haben...
