Mysql prozess verschwindet und taucht wieder auf? load time über 50(!)

Wodka · May 20, 2011

Hi leute,

ich bin am verzweifeln, ich hab schon überall nach geschaut, niemand hat dieses problem:

seit 2 tagen habe ich die übelste load time 20-90 und ich denke es liegt daran dass mysql prozess gekillt(?) und wieder hinzugefügt wird.
sehr seltsam, es taucht auf und verschwindet wieder, beim verschwinden wird cpu wieder freigesetzt.

ohne mysql prozess:
MOD: Bilder bitte immer als Anhang posten. Danke!

mit mysql prozess:
MOD: Bilder bitte immer als Anhang posten. Danke!

CPU und Ram ist eigentlich nicht überlastet, aber die load time ist sehr hoch.

Was ich auch bemerkt hab seit einigen wochen steigt der TIME+ wert von mysql weiter und weiter, hatte da mal einen wert von über 60000 stunden drin, bis ich schließlich restartet hab

ps aux

gibt mir bestimmt über 100 apache prozesse an und über 30 root prozesse

apache2.conf

Code:

Timeout 20
KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 2

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          240
    MaxRequestsPerChild   8000
</IfModule>

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients        240
    MinSpareThreads      25
    MaxSpareThreads      75 
    ThreadsPerChild      25
    MaxRequestsPerChild   8000
</IfModule>

my.cnf

Code:

[mysqld]
skip-external-locking
key_buffer        = 540M
sort_buffer_size        = 512K
read_buffer_size        = 3M
read_rnd_buffer_size    = 4M
join_buffer_size       = 3M
thread_stack        = 128K
thread_cache_size    = 200
myisam-recover        = BACKUP
innodb_buffer_pool_size = 10M
max_connections        = 235
low_priority_updates   = 1
long_query_time         = 1
table_cache            = 1024
max_allowed_packet      = 32M
tmp_table_size          = 512M
max_heap_table_size     = 512M
thread_concurrency     = 4
skip-locking
query_cache_limit       = 1M
query_cache_size        = 80M

[isamchk]
key_buffer        = 64M

ich weiß nicht mehr weiter

Joe User · May 21, 2011

Zunächst mal taucht der mysqld in beiden Screenshots auf. Dann ist die my.cnf für die 4GB RAM völlig überdimensioniert. Und zudem taucht da auch noch ein Ressourcen fressender Tomcat auf. Zuletzt fehlen schlicht die restlichen ~280-300 Prozesse um auch nur ansatzweise die Glaskugel auspacken zu können...

Wodka · May 21, 2011

das tomcat war mit plesk dabei, komisch ich dachte hätte es gelöscht.
nun ist es endgültig weg via apt-get remove tomcat4 und tomcat5.5

my.cnf ist eigentlich ganz in ordnung?
wo sollte ich da was runterschrauben?

übrigens, ich hab gerade entdeckt das die I/O waits (%wa) in der prozessliste sehr hoch gehen kann, bis 80% fast.
disk writes sind schon etwas viele aber das es so plötzlich auftritt ist komisch.
Swap wird auch überhaupt nicht benutzt.

free

Code:

             total       used       free     shared    buffers     cached
Mem:       4152596    1928560    2224036          0     139144     655480
-/+ buffers/cache:    1133936    3018660
Swap:      4000144          0    4000144

ab und an steht das manchmal so da:

Code:

Cpu(s):  8.0%us,  1.0%sy,  0.0%ni, 40.1%id, 50.6%wa,  0.0%hi,  0.2%si,  0.0%st

d.h cpu und ram sind absolute entlastet dennoch sehr hohe load time.

Spin-Doc · May 21, 2011

Wird aktuell ein evtl. vorhandenes RAID neu synchronisiert?

Code:

# cat /proc/mdstat

Wodka · May 21, 2011

der support hat nun endlich geschrieben nach guten 3 tagen.
ich hab ihnen die situation erklärt mit den high I/O waits und es kam nun herraus, dass es wirklich ein HDD Schaden war.

fazit: wenig CPU & Ram verbrauch aber dennoch hoher load time -> etwas mit der Disk stimmt nicht

d4f · May 21, 2011

In deinem Fall scheinbar schon, aber meist bedeuted es schlichtwegs dass die Festplatte nicht mit dem Lesen/Schreiben (also meist dem Positionieren) nachkommt, was oft bei hoher Datenbank-Belastung der Fall ist.
(Was es ja eigentlich auch hier bedeutet

)

Joe User · May 21, 2011

Wodka said:
my.cnf ist eigentlich ganz in ordnung?

Nein, die ist mit Verlaub Müll.

Wodka said:
wo sollte ich da was runterschrauben?

Nahezu Alles. Dazu poste bitte die komplette my.cnf, benenne uns möglichst genau die Anzahl und die verwendeten WebApps der VHosts, sowie die jeweils durchschnittlichen Hits/Tag.
Zusätzlich führst Du nach einer Uptime des MySQLd von mindestens 48h die folgenden beiden Scripts als root aus und postest die unverfälschten Ausgaben:
https://github.com/rackerhacker/MySQLTuner-perl/raw/master/mysqltuner.pl
http://www.day32.com/MySQL/tuning-primer.sh

Wodka · May 22, 2011

Also grade ist der server down, die wechseln die HDD

ganze my.cnf

Code:

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.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

[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
#
# 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		= 540M
sort_buffer_size        = 512K
read_buffer_size        = 3M
read_rnd_buffer_size    = 4M
join_buffer_size       = 3M
thread_stack		= 128K
thread_cache_size	= 200
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover		= BACKUP
innodb_buffer_pool_size = 10M
max_connections        = 235
#max_write_lock_count    = 1
low_priority_updates   = 1
long_query_time         = 1
#log_slow_queries        = /var/log/mysql/log-slow-queries.log
table_cache            = 1024
max_allowed_packet      = 32M
tmp_table_size          = 512M
max_heap_table_size     = 512M
thread_concurrency     = 4
skip-locking
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 80M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#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
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id		= 1
#log_bin			= /var/log/mysql/mysql-bin.log
#expire_logs_days	= 10
#max_binlog_size         = 100M
#binlog_do_db		= include_database_name
#binlog_ignore_db	= include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
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!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

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

[isamchk]
key_buffer		= 64M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

Besucher ca. 40.000
views ca. 100.000

sobald der server wieder geht poste ich tuning-premier ausgabe

virtual2 · May 22, 2011

Ich denke in deinem Fall ist eine größer dimensionierte Hardware von nöten.

Mein Vorschlag: Miete einen zweiten Server mit SSD auf welchem du den MySQL Server betreibst und die Connection via SSH tunnelst.

IP-Projects.de · May 23, 2011

Zunächst:

Wie sieht es mit iotop aus? Mit iotop siehst du, welche Prozesse wirklich aktuell IOs generieren und in welcher Menge.

In deinem Fall scheinbar schon, aber meist bedeuted es schlichtwegs dass die Festplatte nicht mit dem Lesen/Schreiben (also meist dem Positionieren) nachkommt, was oft bei hoher Datenbank-Belastung der Fall ist.
(Was es ja eigentlich auch hier bedeutet )

Resultiert daraus nicht auch, dass die Zugriffszahlen auf die Webseite enorm gestiegen sein müssten? (Frage an den Thread Ersteller - sind die Zugriffe exorbitant gestiegen?) So wie ich das sehe handelt es sich um einen normalen Webserver, nicht um ein reines Datenbank Management. Im Grunde müsste die Apache Last bzw. die Last der PHP Prozesse ja in gewisser Weise proportional zu der Datenbankbelastung stehen, es sei denn es werden Prozesse gestartet, die eine Endlosschleife an Datenbankabfragen generieren.

der support hat nun endlich geschrieben nach guten 3 tagen.
ich hab ihnen die situation erklärt mit den high I/O waits und es kam nun herraus, dass es wirklich ein HDD Schaden war.

ok, wäre interessant ob es danach wieder besser wird.

Besucher ca. 40.000
views ca. 100.000

Das sollten normale Festplatten noch gerade so ab können. Wir betreiben für einen Kunden eine Shoplösung, bei der permanent 500 - 700 aktive Besucher auf einem Magentoshop unterwegs sind. Magento ist ja bekanntlich nicht unbedingt das ressourcenschonenste Shopsystem. Das System ist mit 2 normalen SATA Festplatten im RAID 1 ausgestattet (3Ware RAID Controller) und hat einen Load von 0,7 - 1,5.

Wodka · May 23, 2011

virtual2 said:
Ich denke in deinem Fall ist eine größer dimensionierte Hardware von nöten.

Mein Vorschlag: Miete einen zweiten Server mit SSD auf welchem du den MySQL Server betreibst und die Connection via SSH tunnelst.

findest du?

eigentlich reicht es noch so.
An die RAM grenze kommt es nicht und cpu ist auch nicht zu belastet.

IP-Projects.de said:
Zunächst:

Wie sieht es mit iotop aus? Mit iotop siehst du, welche Prozesse wirklich aktuell IOs generieren und in welcher Menge.

hat sich ja erledigt, die Platte war im Eimer.
aber hier ist die aktuelle iotop ausgabe, von der neuen disk:

Code:

  246 be/3 root        0.00 B/s   57.60 K/s  0.00 % 93.69 % [jbd2/sda4-8]
32643 be/4 mysql       0.00 B/s   46.08 K/s  0.00 %  0.11 % mysqld --based~ck --port=3306
 1204 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1205 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1551 be/4 mysql       0.00 B/s    3.84 K/s  0.00 %  0.00 % mysqld --based~ck --port=3306
 1184 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1269 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1412 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1339 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1344 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
  336 be/4 mysql       0.00 B/s 1524.56 K/s  0.00 %  0.00 % mysqld --based~ck --port=3306
 1511 be/4 www-data    0.00 B/s   30.72 K/s  0.00 %  0.00 % apache2 -k start
  882 be/4 mysql       0.00 B/s    0.00 B/s  0.00 %  0.00 % mysqld --based~ck --port=3306
 1526 be/4 www-data    0.00 B/s    7.68 K/s  0.00 %  0.00 % apache2 -k start
 1528 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1512 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
 1527 be/4 www-data    0.00 B/s    3.84 K/s  0.00 %  0.00 % apache2 -k start
23552 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % couriertcpd -a~/pop3d Maildir
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init [2]
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    4 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]

ich hab genau den höhsten Wert der bei mysql gemessen wurde rauskopiert.
der taucht so alle 10 Sekunden auf denke ich

IP-Projects.de said:
(Frage an den Thread Ersteller - sind die Zugriffe exorbitant gestiegen?) So wie ich das sehe handelt es sich um einen normalen Webserver, nicht um ein reines Datenbank Management. Im Grunde müsste die Apache Last bzw. die Last der PHP Prozesse ja in gewisser Weise proportional zu der Datenbankbelastung stehen, es sei denn es werden Prozesse gestartet, die eine Endlosschleife an Datenbankabfragen generieren.

die Zugriffsrate ist daher sehr hoch angestiegen, da der Server sehr Lahm geworden ist, load times von 20-90

Ich denke die Suchanfragen auf der Seite generieren die dicken fetten Festplatten I/O, da die Platte nicht mehr hinterher kam stieg die load time.

Zusätzlich schlich sich bei der reinstallation von apache ein neuer Fehler ein und der Support hat die RAM auch gewechselt.

IP-Projects.de said:
ok, wäre interessant ob es danach wieder besser wird.

ja klar, also die seite läuft nun seit 3-4 h wieder recht gut.

IP-Projects.de said:
Das sollten normale Festplatten noch gerade so ab können. Wir betreiben für einen Kunden eine Shoplösung, bei der permanent 500 - 700 aktive Besucher auf einem Magentoshop unterwegs sind. Magento ist ja bekanntlich nicht unbedingt das ressourcenschonenste Shopsystem. Das System ist mit 2 normalen SATA Festplatten im RAID 1 ausgestattet (3Ware RAID Controller) und hat einen Load von 0,7 - 1,5.

Vll lag es noch daran, dass die RAM auch noch glaube ich einen fehler hatte, aber im grunde genommen war wirklich nur die Platte schuld.

Wodka · May 23, 2011

ha! das ist zu geil.
Server läuft nun seit gut 4 Stunden bis vor kurzem keinerlei Probleme.
load time 0,5-1
Doch nun fängt der spaß wieder von vorne an?!
I/O waits (%wa) steigt wieder auf 30-80% hoch und load time wieder 7-20

Das haben die ja toll hingekriegt die Platte auszutauschen.
Wo kann da der Fehler sein?? vor 5 Tagen war da absolute nichts mit der Platte, lief alles prima.

:/

Joe User · May 23, 2011

Liefere bitte erstmal die von mir in meinen beiden vorigen Posts angeforderten Infos, damit wir endlich unsere Glaskugeln genauer befragen können...

Wodka · May 24, 2011

here we go:

tuning-primer.sh

Code:

        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.1.49-3 x86_64

Uptime = 0 days 5 hrs 1 min 40 sec
Avg. qps = 123
Total Questions = 1796098
Threads Connected = 39

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 1.000000 sec.
You have 686 out of 1796123 that take longer than 1.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.1/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 200
Current threads_cached = 156
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 235
Current threads_connected = 78
Historic max_used_connections = 132
The number of used connections is 56% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 2 M
Current InnoDB data space = 2 M
Current InnoDB buffer pool free = 34 %
Current innodb_buffer_pool_size = 10 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 1.99 G
Configured Max Per-thread Buffers : 2.45 G
Configured Max Global Buffers : 632 M
Configured Max Memory Limit : 3.06 G
Physical Memory : 3.87 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 9 M
Current key_buffer_size = 540 M
Key cache miss rate is 1 : 20
Key buffer free ratio = 80 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 80 M
Current query_cache_used = 26 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 33.04 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 512 K
Current read_rnd_buffer_size = 4 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 3.00 M
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT
Current open_files_limit = 4341 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 2048 tables
Current table_definition_cache = 1024 tables
You have a total of 440 tables
You have 528 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 512 M
Current tmp_table_size = 512 M
Of 22465 temp tables, 19% were created on disk
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 3 M
Current table scan ratio = 425 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 24
You may benefit from selective use of InnoDB.
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

mysqltuner.pl

Code:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.49-3
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 48M (Tables: 249)
[--] Data in InnoDB tables: 2M (Tables: 168)
[!!] Total fragmented tables: 171

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 5h 6m 18s (1M q [123.390 qps], 87K conn, TX: 8B, RX: 139M)
[--] Reads / Writes: 78% / 22%
[--] Total buffers: 1.1G global + 10.7M per thread (235 max threads)
[!!] Maximum possible memory usage: 3.6G (92% of installed RAM)
[OK] Slow queries: 0% (8K/1M)
[OK] Highest usage of available connections: 56% (132/235)
[OK] Key buffer size / total MyISAM indexes: 540.0M/9.3M
[OK] Key buffer hit rate: 95.1% (63M cached / 3M reads)
[OK] Query cache efficiency: 60.9% (841K cached / 1M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (49 temp sorts / 14K sorts)
[OK] Temporary tables created on disk: 20% (5K on disk / 28K total)
[OK] Thread cache hit rate: 99% (132 created / 87K connections)
[!!] Table cache hit rate: 0% (527 open / 105K opened)
[OK] Open file limit used: 14% (631/4K)
[!!] Table locks acquired immediately: 92%
[OK] InnoDB data size / buffer pool: 2.7M/10.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
    Optimize queries and/or use InnoDB to reduce lock wait
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    table_cache (> 2048)

und dann nochmal iotop
Da sind 1-2 prozesse die jede 2-5 sekunde 99% schlucken: jbd2/sda3-8

Code:

  246 be/3 root        0.00 B/s   48.40 K/s  0.00 % 99.99 % [jbd2/sda4-8]
  661 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [jbd2/sda3-8]
 4386 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 4408 be/4 www-data    0.00 B/s    7.45 K/s  0.00 %  0.00 % apache2 -k start
 4410 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 4424 be/4 www-data    0.00 B/s    7.45 K/s  0.00 %  0.00 % apache2 -k start
 4496 be/4 www-data    0.00 B/s   18.61 K/s  0.00 %  0.00 % apache2 -k start
 4507 be/4 mysql       0.00 B/s    9.26 M/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
 4614 be/4 www-data    0.00 B/s    7.45 K/s  0.00 %  0.00 % apache2 -k start
 4625 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 4641 be/4 www-data    0.00 B/s   11.17 K/s  0.00 %  0.00 % apache2 -k start
 4888 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
27495 be/4 mysql       0.00 B/s    0.00 B/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
27633 be/4 mysql       0.00 B/s   11.17 K/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
 3209 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 3295 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 3365 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 3496 be/4 www-data    0.00 B/s   11.17 K/s  0.00 %  0.00 % apache2 -k start
 1624 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 4369 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
14057 be/4 mysql       0.00 B/s    0.00 B/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
14061 be/4 mysql       0.00 B/s   11.17 K/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
14062 be/4 mysql       0.00 B/s    0.00 B/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
32512 be/4 mysql       0.00 B/s    0.00 B/s  0.00 %  0.00 % mysqld --basedir=/u~qld.sock --port=3306
 4399 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
 3917 be/4 www-data    0.00 B/s    7.45 K/s  0.00 %  0.00 % apache2 -k start
 3926 be/4 www-data    0.00 B/s    7.45 K/s  0.00 %  0.00 % apache2 -k start
 4083 be/4 www-data    0.00 B/s    3.72 K/s  0.00 %  0.00 % apache2 -k start
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init [2]
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    4 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]

Mysql prozess verschwindet und taucht wieder auf? load time über 50(!)

Wodka

New Member

Attachments

Joe User

Zentrum der Macht

Wodka

New Member

Spin-Doc

Registered User

Wodka

New Member

d4f

Kaffee? Wo?

Joe User

Zentrum der Macht

Wodka

New Member

virtual2

Registered User

IP-Projects.de

Active Member

Wodka

New Member

Wodka

New Member

Joe User

Zentrum der Macht

Wodka

New Member

We value your privacy