mysqld 100% CPU Auslastung "Pagecleaner"

P

p0se

Member
Hallo,

ich habe ein Problem mit meinem vServer bei dem mir ja vielleicht jemand helfen kann.

Ein paar Eckdaten

Strato vServer
‪Ubuntu 16.04.4 LTS‬
Plesk Onyx Version 17.5.3 Update #45
Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz (2 core(s))
4 GB Ram
MySQL Version 5.7.21

In unregelmäßigen Abständen geht der Prozess "mysqld" auf 100% CPU Auslastung.
Dadurch fängt der Server an zu hängen, Websiten sind nicht mehr erreichbar eMails werden nicht mehr Versand. Er ist also extrem ausgelastet.

Dieser zustand bleibt ca. 5-10 Minuten bestehen. Danach ist alles wieder ok.

Um die unregelmäßigen Zeiten zu verdeutlichen hier mal ein Monitoring von März.

Code: 
02.03.2018	15:06
02.03.2018	15:30
08.03.2018	03:03
10.03.2018	00:20
10.03.2018	19:59
13.03.2018	02:01
13.03.2018	16:07
16.03.2018	13:16
18.03.2018	01:33
27.03.2018	03:10
27.03.2018	14:47
28.03.2018	16:02
28.03.2018	16:14

Auf dem Server laufen ein paar Wordpress und Shopware Instanzen die aber relativ wenig Traffic erzeugen.

In meinen Augen könnte der Fehler durch die MySQL Funktion "Pagecleaner" kommen. Hier mal ein Auszug aus dem Error Log.

Code: 
2018-04-08T01:37:09.686592Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5753ms. The settings might not be optimal. (flushed=3 and evicted=0, during the time.)
2018-04-08T02:13:33.002151Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5153ms. The settings might not be optimal. (flushed=5 and evicted=0, during the time.)
2018-04-08T02:18:32.369050Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4304ms. The settings might not be optimal. (flushed=5 and evicted=0, during the time.)
2018-04-08T02:19:09.164872Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5794ms. The settings might not be optimal. (flushed=3 and evicted=0, during the time.)
2018-04-08T02:20:17.572992Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 13404ms. The settings might not be optimal. (flushed=8 and evicted=0, during the time.)
2018-04-08T02:20:33.334415Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6761ms. The settings might not be optimal. (flushed=38 and evicted=0, during the time.)
2018-04-08T02:23:12.938463Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5060ms. The settings might not be optimal. (flushed=15 and evicted=0, during the time.)
2018-04-08T03:00:32.490424Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 29512ms. The settings might not be optimal. (flushed=5 and evicted=0, during the time.)
2018-04-08T03:55:20.914833Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5379ms. The settings might not be optimal. (flushed=11 and evicted=0, during the time.)
2018-04-08T06:00:07.555096Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4054ms. The settings might not be optimal. (flushed=10 and evicted=0, during the time.)
2018-04-08T08:00:23.032378Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 18776ms. The settings might not be optimal. (flushed=5 and evicted=0, during the time.)
2018-04-08T13:59:20.453746Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5403ms. The settings might not be optimal. (flushed=14 and evicted=0, during the time.)

Den Error finde ich täglich ca. 50 mal im Log.

Laut google wäre ein Lösungsansatz "innodb_lru_scan_depth" vom Standardwert 1024 auf 256 zu setzen.

Ich denke aber auch das ich recht viele nicht optimale Einträge in meiner Datenbank habe wodurch der Fehler entsteht.

Leider bin ich im Thema SQL nicht ganz so fit :/

Hat jemand einen Lösungsansatz oder ne Idee wie ich am besten verfahren soll?
 
Wenn Du nicht in der Konfig der DB "was völlig zerlegt hast" oder eine komplett "merkwürdigen" Workload fährst - klingt das eher danach, als ob das unter der VM liegende Storage nicht ausreichend flott wäre.

Siehe auch die Beschreibung unter https://stackoverflow.com/a/41155396
 
An den Datenbanken habe ich nicht wirklich etwas gemacht.
Ich benutze größtenteils Plesk für die Verwaltung wenn möglich.

Hier mal die Ausgabe der Schreib und Lesezeiten
Code: 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

Code: 
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 12,1365 s, 88,5 MB/s

Sieht in meinen Augen erstmal ok aus?!
 
Du solltest auch überprüfen, ob deine Wordpress-Instanzen viel über ihre Plugins verbraten, das Plugin P3 oder WP Performance Profiler hilft da ab und an.

Und für shopware gilt dasselbe:
https://developers.shopware.com/developers-guide/debugging/

Und schon mal geschaut mit Monitoring des MySQL und anderen Diensten und Hardware (bswp. mit Munin, Nagios, Icinga) wann der Flaschenhals passiert?
 
Last edited by a moderator:
Ist das Strato Storage. Manchmal genehmigt sich das sekundenlange Auszeiten:
https://serversupportforum.de/threads/performance-strato-vserver.54276/

Geh zu einem Anbieter wo du sicher sein kannst dass das Storage auch liefert. Netcup, PHP-Friends, IP-Projects, Hetzner ...

Theoretisch ist wohl HostEurope auch ok.

Wenn du magst kann ich dir einen netcup Server zur Verfügung stellen und du kannst mit dem mal testen.
 
Last edited by a moderator:
@Joe User

Ausgabe MySQL tuner

Code: 
 >>  MySQLTuner 1.7.9 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.7.21-0ubuntu0.16.04.1
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/log/mysql/error.log(2K)
[OK] Log file /var/log/mysql/error.log exists
[OK] Log file /var/log/mysql/error.log is readable.
[OK] Log file /var/log/mysql/error.log is not empty
[OK] Log file /var/log/mysql/error.log is smaller than 32 Mb
[OK] /var/log/mysql/error.log doesn't contain any warning.
[!!] /var/log/mysql/error.log contains 1 error(s).
[--] 0 start(s) detected in /var/log/mysql/error.log
[--] 0 shutdown(s) detected in /var/log/mysql/error.log

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in InnoDB tables: 131M (Tables: 1127)
[--] Data in MyISAM tables: 91K (Tables: 40)
[OK] Total fragmented tables: 0

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] User 'conta@%' hasn't specific host restriction.
[!!] User 'nextcloud_n@%' hasn't specific host restriction.
[!!] User 'vp_shop_u@%' hasn't specific host restriction.
[!!] User 'vp_usr@%' hasn't specific host restriction.
[!!] User 'wordpress_2@%' hasn't specific host restriction.
[!!] User 'wordpress_4@%' hasn't specific host restriction.
[!!] User 'wordpress_d@%' hasn't specific host restriction.
[!!] User 'xibo_u@%' hasn't specific host restriction.
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 8d 13h 19m 10s (3M q [4.615 qps], 97K conn, TX: 12G, RX: 1G)
[--] Reads / Writes: 91% / 9%
[--] Binary logging is disabled
[--] Physical Memory     : 4.0G
[--] Max MySQL memory    : 390.2M
[--] Other process memory: 969.8M
[--] Total buffers: 192.0M global + 1.3M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 214.3M (5.23% of installed RAM)
[OK] Maximum possible memory usage: 390.2M (9.53% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/3M)
[OK] Highest usage of available connections: 11% (17/151)
[OK] Aborted connections: 2.54%  (2469/97144)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 298K sorts)
[!!] Joins performed without indexes: 37079
[!!] Temporary tables created on disk: 52% (203K on disk / 384K total)
[OK] Thread cache hit rate: 99% (314 created / 97K connections)
[!!] Table cache hit rate: 0% (512 open / 889K opened)
[OK] Open file limit used: 0% (0/102K)
[OK] Table locks acquired immediately: 100% (3K immediate / 3K locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 72B
[--] Sys schema is installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (3M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/129.0K
[!!] Read Key buffer hit rate: 93.1% (1K cached / 133 reads)
[OK] Write Key buffer hit rate: 100.0% (5 cached / 5 writes)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 128.0M/131.6M
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.99% (109838205 hits/ 109848315 total)
[!!] InnoDB Write Log efficiency: 79.92% (1169865 hits/ 1463882 total)
[OK] InnoDB log waits: 0.00% (0 waits / 294017 writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is disabled.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- RocksDB Metrics ---------------------------------------------------------------------------
[--] RocksDB is disabled.

-------- Spider Metrics ----------------------------------------------------------------------------
[--] Spider is disabled.

-------- Connect Metrics ---------------------------------------------------------------------------
[--] Connect is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: ROW
[--] XA support enabled: ON
[--] Semi synchronous replication Master: Not Activated
[--] Semi synchronous replication Slave: Not Activated
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Control error line(s) into /var/log/mysql/error.log file
    Restrict Host for user@% to user@SpecificDNSorIp
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    This is MyISAM only table_cache scalability problem, InnoDB not affected.
    See more details here: https://bugs.mysql.com/bug.php?id=49177
    This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
    Beware that open_files_limit (102400) variable
    should be greater than table_open_cache (512)
    Read this before changing innodb_log_file_size and/or innodb_log_files_in_group: http://bit.ly/2wgkDvS
Variables to adjust:
    join_buffer_size (> 512.0K, or always use indexes with joins)
    tmp_table_size (> 32M)
    max_heap_table_size (> 32M)
    table_open_cache (> 512)
    innodb_buffer_pool_size (>= 131M) if possible.
    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.



@GwenDragon

Ich habe mal P3 (Plugin Performance Profiler) über eine Wordpress Installation laufen lassen. Die unterscheiden sich alle nicht so sehr.

Code: 
WordPress Plugin Profile Report
===========================================
Report date: 11. April 2018
Theme name: unknown
Pages browsed: 16
Avg. load time: 0.0001 sec
Number of plugins: 1
Plugin impact: 289655.24% of load time
Avg. plugin time: 0.1770 sec
Avg. core time: 0.0001 sec
Avg. theme time: 0.0000 sec
Avg. mem usage: 4.50 MB
Avg. ticks: 5
Avg. db queries : 82.00
Margin of error : -0.1770 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.1770 sec - 100.00%

Aktuell habe ich nur ein Monitoring zum schauen ob Webseiten erreichbar sind. Vermutlich muss ich da mal was machen....



@ThomasChr

ich glaube in diesem Fall liegt es nicht an Strato da ich ja auch selber sehen kann wie sehr der mysqld Prozess ausgelastet ist.

Wenn ich nicht mehr weiter weiß würde ich dein Angebot aber gerne mal zum testen annehmen.
 
Ob die 100% Auslastung was mit den Errors zu tun haben wäre interessant.
Theoretisch könnte die CPU natürlich in einer Busy Loop auf die Platten warten. Das würde 100% Auslastung durchaus erklären.
100% Auslastung kann auch "waiting for disk" sein. Eine CPU die auf die Disk wartet ist zwar 100% am warten auf die Disk - wenn aber andere Arbeit kommt kann diese CPU diese trotzdem übernehmen. Das ist nicht immer ganz so einfach :-)

Mach doch mal ein "vmstat 1" während es ausgelastet ist, dann weiß man genaueres.

Die Fehlermeldung im Log bedeutet übrigens dass es zuviele geänderte Daten gibt. Jede Sekunde will er geänderte Daten auf die Platten schreiben, braucht dafür aber oftmals länger. Manchmal 29 Sekunden.

Das scheint mir ein Problem mit dem Storage von Strato zu sein. Das gleiche mit dem ich zu kämpfen hatte.
 
Aber er glaubt doch nicht, daß es am Storage liegt.

Auch wenn Logfiles, Du und andere das Gegenteil behaupten.
 
p0se said:
Hier mal die Ausgabe der Schreib und Lesezeiten
Code: 
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

Code: 
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 12,1365 s, 88,5 MB/s

Sieht in meinen Augen erstmal ok aus?!
Click to expand...

Wenn man das Gefühl hat, dass das Plattensystem eventuell Probleme machen könnte, so gibt es auch noch das Tool ioping, dessen Ausgabe z.B. mit dem Befehl "ioping -c 50 -A -D ." wie folgt aussieht und aus meiner Sicht viel aussagekräftiger in Bezug des IO´s ist.

--- . (ext4 /dev/xvda2) ioping statistics ---
49 requests completed in 9.19 ms, 196 KiB read, 5.33 k iops, 20.8 MiB/s
generated 50 requests in 49.0 s, 200 KiB, 1 iops, 4.08 KiB/s
min/avg/max/mdev = 151.0 us / 187.5 us / 297.2 us / 31.0 us

Diesen Auszug habe ich auf einen virtuellen Server mit ganz normalen Festplatten im RAID 10 Verbund beim Providers IP-Projects, den ich auch nur sehr empfehlen kann, erstellt.
 
Habe IP-Projects bei meinen obigen Empfehlungen gleich mal nachgetragen. Von denen hört man auch nur gutes!
Mea culpa fürs vergessen!

@p0se: Ich kann dich durchaus verstehen. Nur denk ich dass der 100% Beweis schwierig wird.
Ich habs aber schon daran gemerkt dass ein einfacher „ls“ auf der Shell mannchmal ein paar Sekunden gedauert hat!
 
Tipp: Aktiviere doch das Slow Query Log. Je nachdem mit 1, 5 oder 10 Sekunden.

Wenn da einfache Querys die deutlich schneller sind auftauchen weißt du dass zu dem Zeitpunkt entweder Ram, CPU oder IO nicht verfügbar war. Und das ist dann ein Fehler des Providers.

Bin gespannt was rauskommt!
 
@andreas0

Code: 
ioping -c 50 -A -D .
4 KiB from . (vzfs /dev/vzfs): request=1 time=311 us
4 KiB from . (vzfs /dev/vzfs): request=2 time=374 us
4 KiB from . (vzfs /dev/vzfs): request=3 time=2.17 ms
4 KiB from . (vzfs /dev/vzfs): request=4 time=433 us
4 KiB from . (vzfs /dev/vzfs): request=5 time=391 us
4 KiB from . (vzfs /dev/vzfs): request=6 time=318 us
4 KiB from . (vzfs /dev/vzfs): request=7 time=437 us
4 KiB from . (vzfs /dev/vzfs): request=8 time=392 us
4 KiB from . (vzfs /dev/vzfs): request=9 time=480 us
4 KiB from . (vzfs /dev/vzfs): request=10 time=631 us
4 KiB from . (vzfs /dev/vzfs): request=11 time=2.60 ms
4 KiB from . (vzfs /dev/vzfs): request=12 time=3.16 ms
4 KiB from . (vzfs /dev/vzfs): request=13 time=275 us
4 KiB from . (vzfs /dev/vzfs): request=14 time=362 us
4 KiB from . (vzfs /dev/vzfs): request=15 time=521 us
4 KiB from . (vzfs /dev/vzfs): request=16 time=362 us
4 KiB from . (vzfs /dev/vzfs): request=17 time=4.57 ms
4 KiB from . (vzfs /dev/vzfs): request=18 time=945 us
4 KiB from . (vzfs /dev/vzfs): request=19 time=145 us
4 KiB from . (vzfs /dev/vzfs): request=20 time=339 us
4 KiB from . (vzfs /dev/vzfs): request=21 time=285 us
4 KiB from . (vzfs /dev/vzfs): request=22 time=2.85 ms
4 KiB from . (vzfs /dev/vzfs): request=23 time=571 us
4 KiB from . (vzfs /dev/vzfs): request=24 time=338 us
4 KiB from . (vzfs /dev/vzfs): request=25 time=884 us
4 KiB from . (vzfs /dev/vzfs): request=26 time=285 us
4 KiB from . (vzfs /dev/vzfs): request=27 time=353 us
4 KiB from . (vzfs /dev/vzfs): request=28 time=390 us
4 KiB from . (vzfs /dev/vzfs): request=29 time=411 us
4 KiB from . (vzfs /dev/vzfs): request=30 time=265 us
4 KiB from . (vzfs /dev/vzfs): request=31 time=379 us
4 KiB from . (vzfs /dev/vzfs): request=32 time=477 us
4 KiB from . (vzfs /dev/vzfs): request=33 time=268 us
4 KiB from . (vzfs /dev/vzfs): request=34 time=384 us
4 KiB from . (vzfs /dev/vzfs): request=35 time=369 us
4 KiB from . (vzfs /dev/vzfs): request=36 time=4.04 ms
4 KiB from . (vzfs /dev/vzfs): request=37 time=272 us
4 KiB from . (vzfs /dev/vzfs): request=38 time=345 us
4 KiB from . (vzfs /dev/vzfs): request=39 time=312 us
4 KiB from . (vzfs /dev/vzfs): request=40 time=158 us
4 KiB from . (vzfs /dev/vzfs): request=41 time=173 us
4 KiB from . (vzfs /dev/vzfs): request=42 time=409 us
4 KiB from . (vzfs /dev/vzfs): request=43 time=201 us
4 KiB from . (vzfs /dev/vzfs): request=44 time=1.14 ms
4 KiB from . (vzfs /dev/vzfs): request=45 time=324 us
4 KiB from . (vzfs /dev/vzfs): request=46 time=670 us
4 KiB from . (vzfs /dev/vzfs): request=47 time=452 us
4 KiB from . (vzfs /dev/vzfs): request=48 time=566 us
4 KiB from . (vzfs /dev/vzfs): request=49 time=184 us
4 KiB from . (vzfs /dev/vzfs): request=50 time=333 us

--- . (vzfs /dev/vzfs) ioping statistics ---
50 requests completed in 49.0 s, 1.34 k iops, 5.23 MiB/s
min/avg/max/mdev = 145 us / 746 us / 4.57 ms / 979 us

@ThomasChr

ich wollte gerade den Slow Query Log aktivieren....irgendwas mache ich doch hier falsch?!

Und zwar unter /etc/mysql/mysql.conf.d/mysqld.cnf

Dort habe ich

Code: 
#log_slow_queries       = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes

auskommentiert und den Dienst mysql neugestartet. Damit habe ich dann wohl den MySQL Dienst abgeschossen.

Code: 
ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000] [2002] No such file or directory

Additionally, an exception has occurred while trying to report this error: Zend_Exception
No entry is registered for key 'translate' (Abstract.php:144)

Search for related Knowledge Base articles
ERROR: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] No such file or directory' in /opt/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php:129 Stack trace: #0 /opt/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:dbname=ps...', 'admin', '$AES-128-CBC$RO...', Array) #1 /opt/psa/admin/externals/Zend/Db/Adapter/Pdo/Mysql.php(111): Zend_Db_Adapter_Pdo_Abstract->_connect() #2 /opt/psa/admin/externals/Zend/Db/Adapter/Abstract.php(460): Zend_Db_Adapter_Pdo_Mysql->_connect() #3 /opt/psa/admin/externals/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('select param, v...', Array) #4 /opt/psa/admin/plib/Db/Adapter/Pdo/Mysql.php(30): Zend_Db_Adapter_Pdo_Abstract->query('select param, v...', Array) #5 /opt/psa/admin/plib/db.php(36): Db_Adapter_Pdo_Mysql->query('select param, v...') #6 /opt/psa/admin/plib/db.php(212): db_query('select param, v...', false) #7 /opt/psa/admin/plib/Plesk/Mode.php(439): get_param('disable_provisi...') #8 /opt/psa/admin (Abstract.php:144)

Search for related Knowledge Base articles

jemand ne Idee?


Zum Thema Anbieter wechseln.

Ich zahle bei Strato 8€ im Monat.
Dafür bekomme ich einen vServer und vor allem Plesk Onyx in der Web Host Edition.
Welches auch für Kunden gut nutzbar ist.

Ich habe bisher noch keinen Anbieter gefunden der ein vergleichbares Angebot liefert.
Sollte es wirklich am Storage vom Strato liegen wird mir auf lange Sicht natürlich nichts anderes Übrig bleiben aber 8€ ist schon ne krasse Ansage wie ich finde.
 
Last edited by a moderator:
Zu dem mysql-Fehler kann ich auf Anhieb nichts sagen. Scheint mir irgendein Plesk-Zeugs zu sein. Die Config hast du richtig geändert.
Hier das ioping bei einem vServer von netcup:
Code: 
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=1 time=179 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=2 time=340 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=3 time=354 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=4 time=282 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=5 time=302 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=6 time=320 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=7 time=371 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=8 time=312 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=9 time=313 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=10 time=309 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=11 time=437 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=12 time=353 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=13 time=307 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=14 time=297 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=15 time=403 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=16 time=386 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=17 time=328 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=18 time=417 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=19 time=1.22 ms
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=20 time=335 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=21 time=350 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=22 time=293 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=23 time=333 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=24 time=270 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=25 time=331 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=26 time=432 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=27 time=344 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=28 time=375 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=29 time=288 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=30 time=300 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=31 time=285 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=32 time=430 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=33 time=333 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=34 time=307 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=35 time=292 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=36 time=352 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=37 time=292 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=38 time=282 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=39 time=318 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=40 time=444 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=41 time=320 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=42 time=278 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=43 time=318 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=44 time=296 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=45 time=293 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=46 time=325 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=47 time=307 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=48 time=284 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=49 time=494 us
4 KiB from . (ext4 /dev/mapper/server--vg-root): request=50 time=320 us
Nur einmal ein Ausreißer mit über einer 1 ms. Strato sieht da schon schlechter aus (zweimal >4 ms) aber noch nicht wirklich tragisch imho.
 
Naja ich musste den Slow Query Log wieder deaktivieren da sonst alle Webseiten die auf dem Server sind nicht mehr erreichbar sind sobald ich ihn aktiviere....
 
You must log in or register to reply here.
Back
Top