Ewig laufender mySQL Process

A

Azurel

Member
Ich habe einen einzelnen mySQL Process der ewig läuft. Starte ich Server neu, ist er sofort da, kille ich den Process, dann taucht er auch gleich wieder mit einer neuen PID auf. Er verbraucht 10-200% CPU. Wenn ich den Process kill, dann erhalte ich in mysql-error.log diesen Eintrag:

150321 16:14:38 mysqld_safe Number of processes running now: 0
150321 16:14:38 mysqld_safe mysqld restarted
2015-03-21 16:14:38 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2015-03-21 16:14:39 14153 [Note] Plugin 'FEDERATED' is disabled.
2015-03-21 16:14:39 14153 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-03-21 16:14:39 14153 [Note] InnoDB: The InnoDB memory heap is disabled
2015-03-21 16:14:39 14153 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-03-21 16:14:39 14153 [Note] InnoDB: Memory barrier is not used
2015-03-21 16:14:39 14153 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-03-21 16:14:39 14153 [Note] InnoDB: Using Linux native AIO
2015-03-21 16:14:39 14153 [Note] InnoDB: Using CPU crc32 instructions
2015-03-21 16:14:39 14153 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2015-03-21 16:14:39 14153 [Note] InnoDB: Completed initialization of buffer pool
2015-03-21 16:14:39 14153 [Note] InnoDB: Highest supported file format is Barracuda.
2015-03-21 16:14:39 14153 [Note] InnoDB: Log scan progressed past the checkpoint lsn 545863896626
2015-03-21 16:14:39 14153 [Note] InnoDB: Database was not shutdown normally!
2015-03-21 16:14:39 14153 [Note] InnoDB: Starting crash recovery.
2015-03-21 16:14:39 14153 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-03-21 16:14:39 14153 [Note] InnoDB: Restoring possible half-written data pages
2015-03-21 16:14:39 14153 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 545869139456
InnoDB: Doing recovery: scanned up to log sequence number 545872788955
2015-03-21 16:14:39 14153 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2015-03-21 16:14:40 14153 [Note] InnoDB: 128 rollback segment(s) are active.
2015-03-21 16:14:40 14153 [Note] InnoDB: Waiting for purge to start
2015-03-21 16:14:40 14153 [Note] InnoDB: 5.6.23 started; log sequence number 545872788955
2015-03-21 16:14:40 14153 [Note] Event Scheduler: Loaded 0 events
2015-03-21 16:14:40 14153 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.23-log' socket: '/var/lib/mysql/mysql.sock' port: 0 MySQL Community Server (GPL)
Click to expand...

Kann mir dazu irgend jemand was sagen? Wieso läuft ein einzelner mySQL Process ewig? Witzigerweise steht dieser nicht in der Processlist. Da wird mir nichts (ungewöhnliches) angezeigt.

CentOS 6.6 (Final) mit mySQL Server Version: 5.6.23
 
Wenn du nur mysqld und nicht mysqld_safe killst startet mysql_safe den prozess neu. Das ist der ganze Sinn hinter mysql_safe.

Das es nicht in der Prozessliste auftaucht glaube ich nicht.

Code: 
ps auxf | grep mysql

sollte soetwas zeigen wie

Code: 
root      5226  0.0  0.0  19276  1840 ?        S    Mar20   0:00 /bin/bash /usr/bin/mysqld_safe
mysql     6004  0.2  5.4 1833216 555536 ?      Sl   Mar20   4:28  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --open-files-limit=20K --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

Das der Prozess nach einem Serverstart da ist wird wahrscheinlich daran liegen das der Dienst als default eingetragen ist.

Code: 
chkconfig --list mysql
Code: 
mysql                     0:off  1:off  2:on   3:on   4:on   5:on   6:off
 
Last edited by a moderator:
Mit Processlist meinte ich:
http://dev.mysql.com/doc/refman/5.6/en/show-processlist.html

Code: 
mysql> SHOW FULL PROCESSLIST;
+--------+-------+-----------+------+---------+------+-------+-----------------------+
| Id     | User  | Host      | db   | Command | Time | State | Info                  |
+--------+-------+-----------+------+---------+------+-------+-----------------------+
| 178152 | admin | localhost | NULL | Query   |    0 | init  | SHOW FULL PROCESSLIST |
+--------+-------+-----------+------+---------+------+-------+-----------------------+
1 row in set (0.00 sec)
 
Das hat nichts mit den Prozessen auf OS-Ebene zu tun.

PROCESSLIST zeigt nur Datenbankinterne Prozesse. Also welcher DB-Benutzer gerade auf welche DB zugreift und deren Status.
 
Azurel said:
Wieso läuft ein einzelner mySQL Process ewig?
Click to expand...
Weil MySQL ein Dienst ist und irgendein Prozess die eingehenden Client-Requests entgegen nehmen muss?

Alternativ kannst du ja mal etwas mehr Informationen posten. Z.B. den Output _irgendeiner_ Prozessliste, in der dieser Prozess zu sehen ist.
 
@MadMakz
Ich habe leider überhaupt keine Ahnung von was du sprichst. Denn ich sagte in meinem ersten Satz doch:
"Ich habe einen einzelnen mySQL Process der ewig läuft."

Wie kann ich das sagen und dann deiner Meinung nach behaupten, dass er nicht in der OS Processlist steht? Wie soll ich denn auf den Process aufmerksam geworden sein? Das macht doch gar keinen Sinn oder ich sehe den Zusammenhang nicht.

Hier mal ein Screen von htop, den ich eben angefertigt habe. Markiert ist der betreffende Prozess:
http://picload.org/image/igraidp/mysqla.png

Wenn ich dann in mySQL-Shell gehe, mir da die PROCESSLIST (von der ich die ganze Zeit rede) anschaue, dann steht da nichts oder nur normales. Ich frage mich daher warum hier ein mySQL Process dauerhaft läuft und mit soviel CPU. Was macht der?


@elias5000
Ich bezweifle dass ein normaler Datenbank Prozess dafür zuständig ist. Allerdings bin ich da nur Laie und lasse mich gern aufklären. Allerdings möchte ich meinen, dass es auf dem Testserver so einen dauerlaufenden mySQL-Process vorher nicht gab. Hast du denn so was bei dir oder denkst du dir es jetzt nur?
 
Warum taucht dann der Prozess nicht in Post #3 auf, sowie die anderen rund 100 Standardprozesse von Linux?

Dort kann höchstens eine Connection permanent im sleep state stehen. Und das sind meistens Persistente DB Verbindungen oder selten Verbindungsleichen.

Das der Prozess so hoch ausschlägt kann viele Gründe haben. Warum er da sein könnte habe ich bereits ausgeführt.

Was dein htop übrigens zeigt ist wahrscheinlich nur ein Thread von MySQL und keine eigene SQL Instanz. .

strace -p <pid des prozesses>

mit mysqladmin -u root -p -i 1 processlist bekommst du eine fortlaufende processlist womit du evtl. mehr queries findest.

Hast du den gesammten Server neu gestartet oder nur MySQL?
Falls nur letzteres probier mal date -s "`date`" in der Shell.
 
Last edited by a moderator:
MadMakz said:
Warum taucht dann der Prozess nicht in Post #3 auf, sowie die anderen rund 100 Standardprozesse von Linux?
Click to expand...
Wie du schon selbst sagst "PROCESSLIST zeigt nur Datenbankinterne Prozesse". Warum sollten da alle Standardprozesse von Linux darin stehen? Es stehen da andere mySQL Processe drin, ab und an und sehr kurz, wenn ich oft genug die Liste aktualisiere, sehe ich mal was. Aber nichts was dieser eine Process sein könnte.

MadMakz said:
Dort kann höchstens eine Connection permanent im sleep state stehen. Und das sind meistens Persistente DB Verbindungen oder selten Verbindungsleichen.
Click to expand...
Eine Verbindungsleiche baut sich vermutlich nicht automatisch wieder auf, wenn man sie kill macht.

MadMakz said:
Das der Prozess so hoch ausschlägt kann viele Gründe haben. Warum er da sein könnte habe ich bereits ausgeführt.
Click to expand...
Hast du? Dann habe ich den Zusammenhang leider nicht verstanden.

EDIT:

strace gibt mir folgendes unendlich aus:
................
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 1147
fcntl(17, F_SETFL, O_RDWR) = 0
setsockopt(1147, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x132e8c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x132e8c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x132c2a0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
fcntl(17, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 1171
fcntl(17, F_SETFL, O_RDWR) = 0
setsockopt(1171, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x132e8c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x132e8c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x132c2a0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
fcntl(17, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 651
fcntl(17, F_SETFL, O_RDWR) = 0
setsockopt(651, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x132e8c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x132e8c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x132c2a0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
fcntl(17, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 1147
fcntl(17, F_SETFL, O_RDWR) = 0
setsockopt(1147, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x132e8c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x132e8c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x132c2a0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
fcntl(17, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 651
fcntl(17, F_SETFL, O_RDWR) = 0
setsockopt(651, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x132e8c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x132e8c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x132c2a0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
fcntl(17, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
accept(17, {sa_family=AF_FILE, NULL}, [2]) = 651
...........
Click to expand...
 
Last edited by a moderator:
Mh, ja, da scheint MySQL gerne zu nörgeln. Sollte aber nicht 100% Auslastung bringen.

Machen wir es mal anders

Code: 
timeout 1m strace -f -c -p <pid des prozesses>
(Dauert 1ne Minute)
So können wir hoffentlich sehen welche Calls die CPU besetzen.
Evtl. auch in variation mit/ohne -f weil -f auch Child-Threads mit einbezieht.

Am Ende des Tages wird es aber wie so oft wieder was ganz einfaches sein woran ich mal wieder nicht denke.
 
Last edited by a moderator:
MadMakz said:
Hast du den gesammten Server neu gestartet oder nur MySQL?
Click to expand...
Ich habe eben auch den Server mal neu gestartet.

MadMakz said:
mit mysqladmin -u root -p -i 1 processlist
bekommst du eine fortlaufende processlist womit du evtl. mehr queries findest.
Click to expand...
Ich habe das jetzt leider erst nach dem Server restart gemacht. Er zeigt jetzt normal in der mysql Shell von psa einen Process an der lange läuft. Die Anzeige gab es vorher nicht.

Code: 
mysql> SHOW FULL PROCESSLIST;
+-------+-------+-----------+------+---------+------+-------+-----------------------+
| Id    | User  | Host      | db   | Command | Time | State | Info                  |
+-------+-------+-----------+------+---------+------+-------+-----------------------+
|   134 | admin | localhost | psa  | Sleep   |  634 |       | NULL                  |
|  3605 | admin | localhost | psa  | Sleep   |   72 |       | NULL                  |
| 20333 | admin | localhost | NULL | Query   |    0 | init  | SHOW FULL PROCESSLIST |
+-------+-------+-----------+------+---------+------+-------+-----------------------+
3 rows in set (0.00 sec)

Ich habe das jetzt nochmal nach paar Minuten gemacht und einem Plesk Update:
Code: 
> SHOW FULL PROCESSLIST;
+------+-------+-----------+------+---------+------+-------+-----------------------+
| Id   | User  | Host      | db   | Command | Time | State | Info                  |
+------+-------+-----------+------+---------+------+-------+-----------------------+
|  328 | admin | localhost | psa  | Sleep   |   56 |       | NULL                  |
| 8110 | admin | localhost | NULL | Query   |    0 | init  | SHOW FULL PROCESSLIST |
+------+-------+-----------+------+---------+------+-------+-----------------------+
2 rows in set (0.00 sec)
In TOP steht der Process aber immernoch mit >4min Minuten drin, aber nicht in der Processlist hier.


MadMakz said:
Falls nur letzteres probier mal date -s "`date`" in der Shell.
Click to expand...
Das gibt mir
# date -s "`date`"
Mon Mar 23 12:50:44 CET 2015
Click to expand...
Du beziehst dich da sicher eher auf:
# /etc/init.d/ntpd stop
# date -s "`date`"
# /etc/init.d/ntpd start
Click to expand...


Ich habe auch mal dies von dir ausprobiert:
timeout 1m strace -f -c -p <pid des prozesses>
Click to expand...

Ergebnisse:
Code: 
# timeout 1m strace -f -c -p 5873
Process 5873 attached with 30 threads - interrupt to quit
Process 10499 attached (waiting for parent)
Process 10499 resumed (parent 5873 ready)
Process 10502 attached (waiting for parent)
Process 10502 resumed (parent 5873 ready)
Process 10503 attached (waiting for parent)
Process 10503 resumed (parent 5873 ready)
Process 10505 attached (waiting for parent)
Process 10505 resumed (parent 5873 ready)
Process 10537 attached (waiting for parent)
Process 10537 resumed (parent 5873 ready)
Process 10540 attached (waiting for parent)
Process 10540 resumed (parent 5873 ready)
Process 10629 attached (waiting for parent)
Process 10629 resumed (parent 5873 ready)
Process 10640 attached (waiting for parent)
Process 10640 resumed (parent 5873 ready)
Process 10656 attached (waiting for parent)
Process 10656 resumed (parent 5873 ready)
Process 5873 detached
Process 5880 detached
Process 5881 detached
Process 5882 detached
Process 5883 detached
Process 5884 detached
Process 5885 detached
Process 5886 detached
Process 5887 detached
Process 5888 detached
Process 5889 detached
Process 5891 detached
Process 5892 detached
Process 5893 detached
Process 5894 detached
Process 5895 detached
Process 5896 detached
Process 5897 detached
Process 5898 detached
Process 5899 detached
Process 5900 detached
Process 5901 detached
Process 5902 detached
Process 6428 detached
Process 6432 detached
Process 6525 detached
Process 7434 detached
Process 8447 detached
Process 8448 detached
Process 8998 detached
Process 10499 detached
Process 10502 detached
Process 10503 detached
Process 10505 detached
Process 10537 detached
Process 10540 detached
Process 10629 detached
Process 10640 detached
Process 10656 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 43.67  357.223601      112511      3175           io_getevents
 36.74  300.549511       29766     10097      1477 futex
  8.46   69.218473      581668       119           select
  5.67   46.369254       41699      1112           poll
  1.87   15.278414          22    693743           read
  1.43   11.661919          23    514736           lseek
  1.02    8.349623          26    326256           pread
  0.81    6.618995      945571         7         5 restart_syscall
  0.09    0.758261        2916       260           fsync
  0.09    0.748626          20     37497           gettimeofday
  0.04    0.303792          71      4299           pwrite
  0.03    0.207070          21     10016           clock_gettime
  0.02    0.191698          74      2578           io_submit
  0.02    0.161302          20      7891       797 recvfrom
  0.02    0.131280          35      3796           sendto
  0.01    0.107369          48      2230           write
  0.00    0.039757          76       526           madvise
  0.00    0.019726          21       948           fcntl
  0.00    0.018605          29       639           mprotect
  0.00    0.015217          22       682           sched_yield
  0.00    0.013317          21       629         9 access
  0.00    0.013312          44       301           shutdown
  0.00    0.011557          37       316           accept
  0.00    0.010241          16       632       316 setsockopt
  0.00    0.007318          22       331           close
  0.00    0.002177          14       157         5 lstat
  0.00    0.001787          38        47           open
  0.00    0.001637         117        14           unlink
  0.00    0.001000         111         9           clone
  0.00    0.000323           9        38           getcwd
  0.00    0.000263          53         5         5 readlink
  0.00    0.000000           0        18           mmap
  0.00    0.000000           0         5           munmap
  0.00    0.000000           0         9           set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00  818.035425               1623118      2614 total

Ohne "-f"
Code: 
# timeout 1m strace -c -p 5873
Process 5873 attached - interrupt to quit
Process 5873 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.82    3.049377        5842       522           poll
  0.12    0.003567           4       998           futex
  0.04    0.001183           1      1569           fcntl
  0.02    0.000528           1       523           accept
  0.01    0.000317           1       523       523 setsockopt
  0.00    0.000000           0         1           restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00    3.054972                  4136       523 total
Damit kann ich selbst jetzt leider wenig anfangen. ;)

Der Process springt von 10% bis hoch zu 200% der CPU. Er verbleibt nicht in einem Bereich.

Könnte auch an den kaputten Datenbankfiles und MySQLs Selbstheilungskräften liegen...
Click to expand...
Ich bin schon alle Datenbanken durch gegangen und habe REPAIR für alle Tabelle ausgeführt, ohne ein Problem bisher.
 
Azurel said:
Ich bin schon alle Datenbanken durch gegangen und habe REPAIR für alle Tabelle ausgeführt, ohne ein Problem bisher.
Click to expand...
Dein Logauzug aus dem ersten Post sagt etwas Anderes.

Bezüglich strace: Zeig mal bitte Deine vollständige, unverfälschte my.cnf
 
Mein erster Post sagt da was anderes? Beziehst du dich auf das Zitat? Ich habe einen mysql Process per "kill" abgewürgt. Natürlich repariert er das dann. ;)
Das hat mit meiner Aussage aber nichts zu tun.

Meine my.cnf schaut so aus:
[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
#bind-address = 127.0.0.1
skip-networking

ft_min_word_len=1
ft_stopword_file = ""

## - bedeutet, dass dies bereits der 'Default' Wert ist

max_connections = 151
##thread_stack = 256K
##query_cache_limit = 1M
query_cache_size = 256M
innodb_buffer_pool_size = 256M
key_buffer_size = 2048M
join_buffer_size = 2M
##sort_buffer_size = 2M
thread_cache_size = 16
table_open_cache = 2048
table_definition_cache = 2048
low_priority_updates = 1
slow_query_log = 1
expire_logs_days = 7
slow_query_log_file = /var/log/mysql-slow.log
log_error = /var/log/mysql-error.log
long_query_time = 2

#140321he
innodb_flush_log_at_trx_commit = 2

[mysqldump]
quick
quote-names
max_allowed_packet = 32M


[isamchk]
key_buffer_size = 256M


[myisamchk]
key_buffer_size = 256M


[mysqld_safe]
log-error = /var/log/mysql-error.log
pid-file = /var/run/mysqld/mysqld.pid
Click to expand...
 
date -s "`date`" hat etwas mit "leap second" zu tun. Manchmal kann es vorkommen das die Uhr falsch tickt und eine 61. Sekunde produziert. Manche Anwendungen kommen damit nicht zurrecht. (Was auch OK ist denn 61 Sekunden/Min sind ja eh falsch)

Mit dem Kommando reinintalisiert man die Uhr.

Mir scheint die IO Zeit und die Socket-Fehler (recvfrom) etwas hoch. Das spricht umso mehr für einen Defekt. Über 1m bekomme ich bei mir dort 0 Fehler.

Rein spekulativ. Schau dir mal die SMART werte deiner Festplatte an, im dümmsten Fall könnten es defekte Sektoren in genau dem Bereich sein wo die DB's liegen.


Ein SHOW STATUS; in mysql wäre vielleicht auch noch gut. Und mal in der /var/log/mysql-slow.log vorbeischauen.
 
Last edited by a moderator:
Bezüglich SMART, dass kann meine HDD scheinbar nicht?
# smartctl -a /dev/sda
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-504.8.1.el6.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model: centos60-x86_64-he-vmtempl-0
Serial Number: *******
Firmware Version: F.9XE9K4
User Capacity: 914,828,034,048 bytes [914 GB]
Sector Size: 512 bytes logical/physical
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 5
ATA Standard is: ATA/ATAPI-5 T13 1321D revision 1
Local Time is: Mon Mar 23 14:50:40 2015 CET
SMART support is: Unavailable - device lacks SMART capability.
Click to expand...
 
Wird vermutlich ein vServer sein.

Dann wird es /dev/vda sein.
Code: 
lsblk -o name,mountpoint
Da wird SMART dann aber nicht großartig mehr zeigen.
 
Das ist Richtig aber an dem Punkt auch nicht weiter Wichtig außer das sich dann der Anbieter darum kümmern müsste wenn alles andere auszuschließen ist was bis jetzt nocht nicht erwiesen ist.

Wenn der Anbieter ein Rescue/Livesystem ISO anbietet kann man aber vorab ein Filesystemcheck selber machen. Auf "Handfestes" springt ein Support für gewöhnlich auch schneller an.

Vorerst wäre aber noch wenigstens
MadMakz said:
...
Ein SHOW STATUS; in mysql wäre vielleicht auch noch gut. Und mal in der /var/log/mysql-slow.log vorbeischauen.
Click to expand...
zu prüfen.
 
You must log in or register to reply here.
Back
Top