Weil der Hosteurope-Kundendienst mir gerade nicht weiterhelfen kann, weil außerstande, das Problem nachzuvollziehen, hoffe ich, dass vielleicht einer unserer lieben IT'ler im Forum noch eine Idee hat.
Ihr habt es vermutlich alle schon mitbekommen: Der Server läuft völlig normal, ohne Auffälligkeiten, dann, von einem Augenblick auf den anderen, bricht die Performance ein. Statische Webseiten lassen sich weiterhin aufrufen, aber das Forum, das auf MySQL-Basis läuft, kann keine Seiten mehr aufbauen.
Wartet man ca. 4-5 Minuten, ist die Seite dann hereingeladen, die typische Meldung am Seitenfuß sieht dann so aus: "Seite erstellt in 290.029 Sekunden mit 13 Abfragen." Danach läuft wieder alles normal, mit den üblichen Zugriffszeiten von 0,2 Sekunden. Dieser Spuk wiederholt sich vier, fünf Mal pro Stunde, immer aus heiterem Himmel, so dass an einen normalen Forenbetrieb nicht zu denken ist, und das zur besucherreichsten Zeit des Jahres.
Das unangekündigte Auftreten macht den Fehler schwer reproduzierbar, trotzdem bekomme ich im Fünf-Minuten-Takt Alarm-Mails, die so aussehen:
Server: mail.gottfabrik.de.
Server health parameter "Services > MySQL CPU usage" changed its status from "green" to "red".
top - 23:22:20 up 1 day, 8:06, 0 users, load average: 1.40, 1.26, 0.82
Tasks: 228 total, 2 running, 226 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.1 us, 3.0 sy, 6.2 ni, 87.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16777216 total, 3860868 used, 12916348 free, 0 buffers
KiB Swap: 8388608 total, 92260 used, 8296348 free. 2752308 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
604 mysql 20 0 2295680 92416 5328 S 94.0 0.6 102:54.83 mysqld
16898 popuser 20 0 17208 1796 1064 R 31.3 0.0 0:00.53 imapd
16903 root 20 0 19952 1408 944 R 15.7 0.0 0:00.08 top
1 root 20 0 33324 1716 1032 S 0.0 0.0 0:05.64 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/1+
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/12+
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
5 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
6 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
7 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 nfsiod/124+
179 root 20 0 19424 400 396 S 0.0 0.0 0:00.32 upstart-ud+
198 root 20 0 49212 712 708 S 0.0 0.0 0:00.05 systemd-ud+
214 root 20 0 316656 5960 4068 S 0.0 0.0 0:01.82 smbd
268 root 20 0 308704 2344 776 S 0.0 0.0 0:00.00 smbd
271 root 20 0 316656 2712 832 S 0.0 0.0 0:01.34 smbd
342 syslog 20 0 184384 8652 828 S 0.0 0.1 0:28.26 rsyslogd
388 root 20 0 15472 324 320 S 0.0 0.0 0:00.34 upstart-so+
390 root 20 0 15224 316 312 S 0.0 0.0 0:00.35 upstart-fi+
407 root 20 0 231396 1656 1276 S 0.0 0.0 0:14.57 nmbd
542 root 20 0 274520 18632 17700 S 0.0 0.1 0:08.97 sw-engine
573 root 20 0 23600 980 764 S 0.0 0.0 0:00.88 cron
653 root 20 0 177660 1476 1200 S 0.0 0.0 0:18.76 monit
680 root 20 0 14940 916 816 S 0.0 0.0 0:01.48 xinetd
759 root 20 0 4288 352 348 S 0.0 0.0 0:00.00 courierlog+
760 root 20 0 25952 832 764 S 0.0 0.0 0:00.04 authdaemond
763 root 20 0 34512 1560 1296 S 0.0 0.0 0:00.78 authdaemond
764 root 20 0 34512 1560 1296 S 0.0 0.0 0:00.76 authdaemond
765 root 20 0 34512 1552 1288 S 0.0 0.0 0:00.84 authdaemond
766 root 20 0 34512 1600 1308 S 0.0 0.0 0:00.79 authdaemond
767 root 20 0 34512 1560 1296 S 0.0 0.0 0:00.83 authdaemond
791 root 20 0 4288 416 352 S 0.0 0.0 0:00.46 courierlog+
792 root 20 0 12116 864 768 S 0.0 0.0 0:01.05 couriertcpd
822 root 20 0 4288 432 348 S 0.0 0.0 0:00.01 courierlog+
823 root 20 0 12116 864 768 S 0.0 0.0 0:00.04 couriertcpd
862 root 20 0 4288 436 356 S 0.0 0.0 0:00.00 courierlog+
864 root 20 0 12116 848 768 S 0.0 0.0 0:00.00 couriertcpd
905 root 20 0 4288 276 272 S 0.0 0.0 0:00.00 courierlog+
906 root 20 0 12116 752 748 S 0.0 0.0 0:00.00 couriertcpd
953 bind 20 0 247616 14768 2328 S 0.0 0.1 0:07.93 named
1039 postfix 20 0 402616 1844 1124 S 0.0 0.0 0:30.51 psa-pc-rem+
1073 root 20 0 61328 2512 2376 S 0.0 0.0 0:05.42 sshd
1316 root 20 0 25288 1508 1352 S 0.0 0.0 1:03.58 master
1330 postfix 20 0 27520 1368 1276 S 0.0 0.0 0:00.43 qmgr
1333 postfix 20 0 27520 1648 1424 S 0.0 0.0 0:43.36 qmgr
1461 root 20 0 372700 2572 428 S 0.0 0.0 0:00.02 sw-engine-+
1597 root 20 0 31376 388 196 S 0.0 0.0 0:00.00 sw-cp-serv+
1598 sw-cp-s+ 20 0 31916 2204 1680 S 0.0 0.0 0:00.09 sw-cp-serv+
2759 root 20 0 286440 13708 5744 S 0.0 0.1 0:30.21 sw-engine
2821 root 20 0 561876 2636 920 S 0.0 0.0 4:12.09 sw-collectd
3009 root 20 0 12732 672 668 S 0.0 0.0 0:00.00 getty
3015 root 20 0 12732 676 672 S 0.0 0.0 0:00.00 getty
3914 postfix 20 0 40384 2388 1972 S 0.0 0.0 0:02.10 tlsmgr
8473 popuser 20 0 143632 57596 2952 S 0.0 0.3 2:52.37 spamd child
10568 postfix 20 0 27352 1640 1328 S 0.0 0.0 0:00.06 pickup
15985 www-data 30 10 504684 44820 21292 S 0.0 0.3 0:02.46 /usr/sbin/+
16049 www-data 30 10 504380 42020 18760 S 0.0 0.3 0:02.62 /usr/sbin/+
16063 www-data 30 10 508964 45064 21608 S 0.0 0.3 0:01.38 /usr/sbin/+
16064 www-data 30 10 505180 43636 19816 S 0.0 0.3 0:01.02 /usr/sbin/+
16066 www-data 30 10 496744 25500 8140 S 0.0 0.2 0:00.68 /usr/sbin/+
16067 www-data 30 10 499056 40176 16804 S 0.0 0.2 0:00.61 /usr/sbin/+
16116 www-data 30 10 495736 25068 7308 S 0.0 0.1 0:00.18 /usr/sbin/+
16118 www-data 30 10 495236 34048 14420 S 0.0 0.2 0:00.45 /usr/sbin/+
16119 www-data 30 10 492928 23912 6764 S 0.0 0.1 0:00.17 /usr/sbin/+
16135 www-data 30 10 492808 23140 6012 S 0.0 0.1 0:00.12 /usr/sbin/+
16139 www-data 30 10 492852 23316 6256 S 0.0 0.1 0:00.12 /usr/sbin/+
16141 www-data 30 10 492784 22964 5936 S 0.0 0.1 0:00.10 /usr/sbin/+
16143 www-data 30 10 492808 23140 6012 S 0.0 0.1 0:00.13 /usr/sbin/+
16144 www-data 30 10 504656 42300 18888 S 0.0 0.3 0:01.11 /usr/sbin/+
16147 www-data 30 10 498560 25408 8272 S 0.0 0.2 0:00.27 /usr/sbin/+
16148 www-data 30 10 496528 24748 7560 S 0.0 0.1 0:00.40 /usr/sbin/+
16150 www-data 30 10 498640 25456 8228 S 0.0 0.2 0:00.32 /usr/sbin/+
16151 www-data 30 10 499328 39780 18292 S 0.0 0.2 0:00.66 /usr/sbin/+
16161 www-data 30 10 497384 35260 15492 S 0.0 0.2 0:01.07 /usr/sbin/+
16164 www-data 30 10 496520 24792 7616 S 0.0 0.1 0:00.34 /usr/sbin/+
16167 www-data 30 10 493204 24160 6836 S 0.0 0.1 0:00.32 /usr/sbin/+
16189 www-data 30 10 496504 24764 7408 S 0.0 0.1 0:00.37 /usr/sbin/+
16194 www-data 30 10 492992 23700 6532 S 0.0 0.1 0:00.24 /usr/sbin/+
16197 www-data 30 10 496512 24844 7476 S 0.0 0.1 0:00.33 /usr/sbin/+
16201 www-data 30 10 496568 24268 7076 S 0.0 0.1 0:00.29 /usr/sbin/+
16205 www-data 30 10 492876 23136 6084 S 0.0 0.1 0:00.11 /usr/sbin/+
16206 www-data 30 10 496756 37744 16672 S 0.0 0.2 0:00.62 /usr/sbin/+
16207 www-data 30 10 496728 24860 7612 S 0.0 0.1 0:00.34 /usr/sbin/+
16208 www-data 30 10 494948 24116 7040 S 0.0 0.1 0:00.12 /usr/sbin/+
16209 www-data 30 10 501252 37968 15928 S 0.0 0.2 0:00.79 /usr/sbin/+
16222 www-data 30 10 496748 24856 7340 S 0.0 0.1 0:00.30 /usr/sbin/+
16227 www-data 30 10 492852 23256 6208 S 0.0 0.1 0:00.11 /usr/sbin/+
16232 www-data 30 10 492876 23124 6072 S 0.0 0.1 0:00.12 /usr/sbin/+
16234 www-data 30 10 492808 23008 5944 S 0.0 0.1 0:00.09 /usr/sbin/+
16235 www-data 30 10 492816 23088 6016 S 0.0 0.1 0:00.11 /usr/sbin/+
16237 www-data 30 10 494948 24096 7032 S 0.0 0.1 0:00.12 /usr/sbin/+
16238 www-data 30 10 492808 22900 5880 S 0.0 0.1 0:00.08 /usr/sbin/+
16245 www-data 30 10 492808 23036 5960 S 0.0 0.1 0:00.09 /usr/sbin/+
16248 www-data 30 10 494856 24208 7104 S 0.0 0.1 0:00.12 /usr/sbin/+
16249 www-data 30 10 499400 26584 8556 S 0.0 0.2 0:00.40 /usr/sbin/+
16263 www-data 30 10 492852 23276 6216 S 0.0 0.1 0:00.11 /usr/sbin/+
16266 www-data 30 10 492876 23216 6148 S 0.0 0.1 0:00.12 /usr/sbin/+
16269 www-data 30 10 494924 24076 7020 S 0.0 0.1 0:00.13 /usr/sbin/+
16271 www-data 30 10 492852 23260 6212 S 0.0 0.1 0:00.11 /usr/sbin/+
16274 www-data 30 10 492852 23104 6056 S 0.0 0.1 0:00.15 /usr/sbin/+
16280 www-data 30 10 492892 23412 6324 S 0.0 0.1 0:00.15 /usr/sbin/+
16283 www-data 30 10 492928 22560 5588 S 0.0 0.1 0:00.12 /usr/sbin/+
16287 www-data 30 10 496716 24496 7168 S 0.0 0.1 0:00.26 /usr/sbin/+
16291 www-data 30 10 494924 24204 7132 S 0.0 0.1 0:00.11 /usr/sbin/+
16292 www-data 30 10 492852 23264 6216 S 0.0 0.1 0:00.11 /usr/sbin/+
16299 www-data 30 10 495008 24276 7184 S 0.0 0.1 0:00.14 /usr/sbin/+
16300 www-data 30 10 492852 23108 6064 S 0.0 0.1 0:00.11 /usr/sbin/+
16302 www-data 30 10 494924 24036 6988 S 0.0 0.1 0:00.11 /usr/sbin/+
16304 www-data 30 10 496488 24868 7720 S 0.0 0.1 0:00.32 /usr/sbin/+
16305 www-data 30 10 502588 40900 17516 S 0.0 0.2 0:00.77 /usr/sbin/+
16310 www-data 30 10 492808 23020 5944 S 0.0 0.1 0:00.10 /usr/sbin/+
16341 www-data 30 10 494924 24120 7056 S 0.0 0.1 0:00.13 /usr/sbin/+
16342 www-data 30 10 493204 24224 6908 S 0.0 0.1 0:00.30 /usr/sbin/+
16377 www-data 30 10 492936 23328 6260 S 0.0 0.1 0:00.14 /usr/sbin/+
16403 www-data 30 10 494924 24252 7188 S 0.0 0.1 0:00.11 /usr/sbin/+
16427 www-data 30 10 495280 25152 7820 S 0.0 0.1 0:00.34 /usr/sbin/+
16431 www-data 30 10 494948 24128 7060 S 0.0 0.1 0:00.11 /usr/sbin/+
16439 www-data 30 10 499116 33504 15872 S 0.0 0.2 0:00.53 /usr/sbin/+
16443 www-data 30 10 494940 24048 6996 S 0.0 0.1 0:00.11 /usr/sbin/+
16451 www-data 30 10 492852 22044 5132 S 0.0 0.1 0:00.08 /usr/sbin/+
16599 www-data 30 10 492852 21976 5064 S 0.0 0.1 0:00.07 /usr/sbin/+
16601 www-data 30 10 496748 23656 6416 S 0.0 0.1 0:00.12 /usr/sbin/+
16602 www-data 30 10 492852 21976 5064 S 0.0 0.1 0:00.07 /usr/sbin/+
16604 www-data 30 10 496988 23776 6308 S 0.0 0.1 0:00.16 /usr/sbin/+
16605 www-data 30 10 492808 21868 4948 S 0.0 0.1 0:00.06 /usr/sbin/+
16606 www-data 30 10 496712 23704 6444 S 0.0 0.1 0:00.16 /usr/sbin/+
16608 www-data 30 10 493128 23132 6000 S 0.0 0.1 0:00.10 /usr/sbin/+
16617 www-data 30 10 495256 24392 7176 S 0.0 0.1 0:00.14 /usr/sbin/+
16623 www-data 30 10 492852 22032 5120 S 0.0 0.1 0:00.07 /usr/sbin/+
16624 www-data 30 10 496696 23600 6356 S 0.0 0.1 0:00.13 /usr/sbin/+
16629 www-data 30 10 492856 23096 6028 S 0.0 0.1 0:00.09 /usr/sbin/+
16631 www-data 30 10 500880 28712 8972 S 0.0 0.2 0:00.66 /usr/sbin/+
16632 www-data 30 10 493128 23204 6060 S 0.0 0.1 0:00.09 /usr/sbin/+
16634 www-data 30 10 496328 23504 6396 S 0.0 0.1 0:00.09 /usr/sbin/+
16635 www-data 30 10 498748 34296 14700 S 0.0 0.2 0:00.52 /usr/sbin/+
16637 www-data 30 10 492856 23096 6028 S 0.0 0.1 0:00.10 /usr/sbin/+
16639 www-data 30 10 496464 23632 6476 S 0.0 0.1 0:00.10 /usr/sbin/+
16640 www-data 30 10 492852 22032 5120 S 0.0 0.1 0:00.06 /usr/sbin/+
16643 www-data 30 10 492808 23260 6152 S 0.0 0.1 0:00.09 /usr/sbin/+
16644 www-data 30 10 492852 22036 5124 S 0.0 0.1 0:00.06 /usr/sbin/+
16645 www-data 30 10 496984 23988 6496 S 0.0 0.1 0:00.15 /usr/sbin/+
16646 www-data 30 10 492856 23088 6020 S 0.0 0.1 0:00.11 /usr/sbin/+
16653 www-data 30 10 499640 39340 17300 S 0.0 0.2 0:01.10 /usr/sbin/+
16655 www-data 30 10 492936 22296 5324 S 0.0 0.1 0:00.11 /usr/sbin/+
16656 www-data 30 10 496696 23596 6356 S 0.0 0.1 0:00.16 /usr/sbin/+
16657 www-data 30 10 499360 25376 7392 S 0.0 0.2 0:00.28 /usr/sbin/+
16659 www-data 30 10 501104 35828 13964 S 0.0 0.2 0:00.96 /usr/sbin/+
16660 www-data 30 10 496696 23604 6364 S 0.0 0.1 0:00.14 /usr/sbin/+
16664 www-data 30 10 492856 23088 6020 S 0.0 0.1 0:00.11 /usr/sbin/+
16668 www-data 30 10 496784 37476 16428 S 0.0 0.2 0:00.52 /usr/sbin/+
16669 www-data 30 10 499360 25340 7360 S 0.0 0.2 0:00.19 /usr/sbin/+
16671 www-data 30 10 510124 48016 19440 S 0.0 0.3 0:02.00 /usr/sbin/+
16672 www-data 30 10 496328 23596 6464 S 0.0 0.1 0:00.10 /usr/sbin/+
16675 www-data 30 10 496328 23592 6460 S 0.0 0.1 0:00.10 /usr/sbin/+
16676 www-data 30 10 493128 23236 6092 S 0.0 0.1 0:00.10 /usr/sbin/+
16678 www-data 30 10 493128 23180 6036 S 0.0 0.1 0:00.10 /usr/sbin/+
16685 www-data 30 10 502372 41228 19976 S 0.0 0.2 0:01.53 /usr/sbin/+
16686 www-data 30 10 492852 22036 5124 S 0.0 0.1 0:00.07 /usr/sbin/+
16688 www-data 30 10 492856 23084 6016 S 0.0 0.1 0:00.10 /usr/sbin/+
16690 www-data 30 10 492852 21976 5064 S 0.0 0.1 0:00.06 /usr/sbin/+
16692 www-data 30 10 492852 22028 5116 S 0.0 0.1 0:00.06 /usr/sbin/+
16695 www-data 30 10 499040 27332 9584 S 0.0 0.2 0:00.34 /usr/sbin/+
16699 www-data 30 10 500940 36484 16660 S 0.0 0.2 0:01.28 /usr/sbin/+
16700 www-data 30 10 496748 23800 6348 S 0.0 0.1 0:00.15 /usr/sbin/+
16701 www-data 30 10 492876 21984 5068 S 0.0 0.1 0:00.07 /usr/sbin/+
16728 www-data 30 10 501140 28172 8188 S 0.0 0.2 0:00.68 /usr/sbin/+
16738 www-data 30 10 495008 23784 6716 S 0.0 0.1 0:00.26 /usr/sbin/+
16739 www-data 30 10 495008 24416 7308 S 0.0 0.1 0:00.17 /usr/sbin/+
16836 www-data 30 10 492868 22072 5148 S 0.0 0.1 0:00.07 /usr/sbin/+
16837 www-data 30 10 498788 24600 7336 S 0.0 0.1 0:00.14 /usr/sbin/+
16838 www-data 30 10 492876 21980 5064 S 0.0 0.1 0:00.06 /usr/sbin/+
16843 www-data 30 10 492808 21952 5036 S 0.0 0.1 0:00.05 /usr/sbin/+
16846 www-data 30 10 498516 26628 7200 S 0.0 0.2 0:00.64 /usr/sbin/+
16852 www-data 30 10 492852 22032 5120 S 0.0 0.1 0:00.09 /usr/sbin/+
16856 www-data 30 10 492264 20232 3688 S 0.0 0.1 0:00.07 /usr/sbin/+
16857 root 20 0 99676 4148 3144 S 0.0 0.0 0:00.08 sshd
16858 sshd 20 0 62748 1564 800 S 0.0 0.0 0:00.02 sshd
16859 www-data 30 10 492924 22836 5868 S 0.0 0.1 0:00.09 /usr/sbin/+
16860 www-data 30 10 492264 20188 3656 S 0.0 0.1 0:00.04 /usr/sbin/+
16861 www-data 30 10 497012 23952 6372 S 0.0 0.1 0:00.16 /usr/sbin/+
16863 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
16864 www-data 30 10 495204 31720 12152 S 0.0 0.2 0:00.40 /usr/sbin/+
16865 www-data 30 10 496748 23812 6360 S 0.0 0.1 0:00.17 /usr/sbin/+
16866 www-data 30 10 492032 17472 1232 S 0.0 0.1 0:00.00 /usr/sbin/+
16868 popuser 20 0 15024 1440 936 S 0.0 0.0 0:00.04 imapd
16869 popuser 20 0 16244 2720 936 S 0.0 0.0 0:00.19 imapd
16870 popuser 20 0 14724 1132 912 S 0.0 0.0 0:00.01 imapd
16871 popuser 20 0 14724 1164 912 S 0.0 0.0 0:00.01 imapd
16872 popuser 20 0 15432 1924 936 S 0.0 0.0 0:00.10 imapd
16873 popuser 20 0 14724 1144 908 S 0.0 0.0 0:00.01 imapd
16874 popuser 20 0 14856 1320 936 S 0.0 0.0 0:00.02 imapd
16875 popuser 20 0 14724 1204 932 S 0.0 0.0 0:00.01 imapd
16877 root 20 0 12920 2288 1780 S 0.0 0.0 0:00.04 couriertls
16879 popuser 20 0 14724 1160 908 S 0.0 0.0 0:00.01 imapd
16880 root 20 0 12920 2288 1780 S 0.0 0.0 0:00.05 couriertls
16883 root 20 0 12920 2292 1780 S 0.0 0.0 0:00.05 couriertls
16887 root 20 0 12920 2296 1784 S 0.0 0.0 0:00.05 couriertls
16889 root 20 0 12920 2288 1780 S 0.0 0.0 0:00.05 couriertls
16891 root 20 0 12920 2292 1784 S 0.0 0.0 0:00.05 couriertls
16892 root 20 0 12920 2292 1784 S 0.0 0.0 0:00.05 couriertls
16893 root 20 0 12920 2288 1780 S 0.0 0.0 0:00.06 couriertls
16894 root 20 0 12920 2292 1780 S 0.0 0.0 0:00.05 couriertls
16895 popuser 20 0 14724 1128 908 S 0.0 0.0 0:00.01 imapd
16897 root 20 0 12920 2292 1780 S 0.0 0.0 0:00.04 couriertls
16900 root 20 0 12920 2296 1784 S 0.0 0.0 0:00.06 couriertls
21445 root 20 0 131712 25668 2316 S 0.0 0.2 0:51.92 /usr/sbin/+
25327 root 30 10 491984 33292 17080 S 0.0 0.2 0:39.80 /usr/sbin/+
25330 www-data 30 10 164052 9696 452 S 0.0 0.1 0:00.71 /usr/sbin/+
Server: mail.gottfabrik.de.
Server health parameter "Services > Apache CPU usage" changed its status from "yellow" to "red".
Server health parameter "Services > MySQL CPU usage" changed its status from "red" to "green".
top - 18:22:12 up 1 day, 3:06, 0 users, load average: 0.36, 0.77, 0.97
Tasks: 125 total, 2 running, 122 sleeping, 0 stopped, 1 zombie
%Cpu(s): 3.2 us, 3.1 sy, 6.4 ni, 87.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16777216 total, 3464468 used, 13312748 free, 0 buffers
KiB Swap: 8388608 total, 105808 used, 8282800 free. 2752080 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20016 www-data 30 10 494704 24232 7196 R 11.5 0.1 0:03.37 /usr/sbin/+
20830 www-data 30 10 496096 30232 9812 S 11.5 0.2 0:00.55 /usr/sbin/+
20848 root 20 0 19816 1320 944 R 11.5 0.0 0:00.05 top
1 root 20 0 33324 2048 1364 S 0.0 0.0 0:05.11 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/1+
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/12+
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
5 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
6 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
7 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rpciod/124+
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 nfsiod/124+
179 root 20 0 19424 552 548 S 0.0 0.0 0:00.32 upstart-ud+
198 root 20 0 49212 728 724 S 0.0 0.0 0:00.05 systemd-ud+
214 root 20 0 316656 6544 4652 S 0.0 0.0 0:01.61 smbd
268 root 20 0 308704 2344 776 S 0.0 0.0 0:00.00 smbd
271 root 20 0 316656 2712 832 S 0.0 0.0 0:01.13 smbd
342 syslog 20 0 184188 7016 920 S 0.0 0.0 0:23.90 rsyslogd
388 root 20 0 15472 460 456 S 0.0 0.0 0:00.34 upstart-so+
390 root 20 0 15224 452 448 S 0.0 0.0 0:00.35 upstart-fi+
407 root 20 0 231396 1656 1276 S 0.0 0.0 0:12.49 nmbd
542 root 20 0 274520 19264 18332 S 0.0 0.1 0:07.76 sw-engine
573 root 20 0 23600 980 764 S 0.0 0.0 0:00.76 cron
604 mysql 20 0 2289212 77652 7992 S 0.0 0.5 75:12.04 mysqld
653 root 20 0 177660 1832 1568 S 0.0 0.0 0:15.95 monit
680 root 20 0 14940 916 816 S 0.0 0.0 0:01.07 xinetd
759 root 20 0 4288 352 348 S 0.0 0.0 0:00.00 courierlog+
760 root 20 0 25952 1160 1092 S 0.0 0.0 0:00.04 authdaemond
763 root 20 0 34512 1656 1392 S 0.0 0.0 0:00.56 authdaemond
764 root 20 0 34512 1664 1400 S 0.0 0.0 0:00.62 authdaemond
765 root 20 0 34512 1656 1392 S 0.0 0.0 0:00.63 authdaemond
766 root 20 0 34512 1704 1412 S 0.0 0.0 0:00.63 authdaemond
767 root 20 0 34512 1664 1400 S 0.0 0.0 0:00.64 authdaemond
791 root 20 0 4288 416 352 S 0.0 0.0 0:00.35 courierlog+
792 root 20 0 12116 864 768 S 0.0 0.0 0:00.80 couriertcpd
822 root 20 0 4288 436 352 S 0.0 0.0 0:00.01 courierlog+
823 root 20 0 12116 864 768 S 0.0 0.0 0:00.03 couriertcpd
862 root 20 0 4288 276 272 S 0.0 0.0 0:00.00 courierlog+
864 root 20 0 12116 752 748 S 0.0 0.0 0:00.00 couriertcpd
905 root 20 0 4288 276 272 S 0.0 0.0 0:00.00 courierlog+
906 root 20 0 12116 752 748 S 0.0 0.0 0:00.00 couriertcpd
953 bind 20 0 247616 14432 2328 S 0.0 0.1 0:07.27 named
1039 postfix 20 0 402616 1824 1136 S 0.0 0.0 0:26.40 psa-pc-rem+
1073 root 20 0 61328 2512 2376 S 0.0 0.0 0:03.83 sshd
1316 root 20 0 25288 1512 1356 S 0.0 0.0 0:53.90 master
1330 postfix 20 0 27520 1368 1276 S 0.0 0.0 0:00.37 qmgr
1333 postfix 20 0 27520 1648 1424 S 0.0 0.0 0:36.73 qmgr
1461 root 20 0 372700 2572 428 S 0.0 0.0 0:00.01 sw-engine-+
1597 root 20 0 31376 392 200 S 0.0 0.0 0:00.00 sw-cp-serv+
1598 sw-cp-s+ 20 0 31916 1596 1248 S 0.0 0.0 0:00.04 sw-cp-serv+
2759 root 20 0 286440 13808 5864 S 0.0 0.1 0:25.84 sw-engine
2821 root 20 0 561876 2644 920 S 0.0 0.0 3:23.94 sw-collectd
3009 root 20 0 12732 672 668 S 0.0 0.0 0:00.00 getty
3015 root 20 0 12732 676 672 S 0.0 0.0 0:00.00 getty
3914 postfix 20 0 40384 2792 2376 S 0.0 0.0 0:01.80 tlsmgr
8473 popuser 20 0 142312 55660 2876 S 0.0 0.3 0:54.03 spamd child
10190 popuser 20 0 16288 2832 960 S 0.0 0.0 0:18.34 imapd
10192 root 20 0 12920 2308 1796 S 0.0 0.0 0:00.10 couriertls
10977 www-data 30 10 511736 41612 11324 S 0.0 0.2 1:00.01 /usr/sbin/+
19709 postfix 20 0 27352 1640 1328 S 0.0 0.0 0:00.01 pickup
20370 www-data 30 10 501724 39060 18424 S 0.0 0.2 0:04.01 /usr/sbin/+
20384 www-data 30 10 499060 28528 10656 S 0.0 0.2 0:02.17 /usr/sbin/+
20518 www-data 30 10 496508 34652 13928 S 0.0 0.2 0:00.70 /usr/sbin/+
20527 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20529 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20530 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20532 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20534 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20536 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20537 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20540 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20541 www-data 30 10 492032 17456 1216 S 0.0 0.1 0:00.00 /usr/sbin/+
20617 www-data 30 10 504428 40940 17820 S 0.0 0.2 0:02.38 /usr/sbin/+
20674 postfix 20 0 27352 1540 1244 S 0.0 0.0 0:00.00 anvil
20676 postfix 20 0 27496 2116 1664 S 0.0 0.0 0:00.02 trivial-re+
20717 www-data 30 10 506004 41308 16652 S 0.0 0.2 0:03.25 /usr/sbin/+
20796 www-data 30 10 499416 27028 8936 S 0.0 0.2 0:00.53 /usr/sbin/+
20798 www-data 30 10 492264 18568 2128 S 0.0 0.1 0:00.01 /usr/sbin/+
20799 www-data 30 10 492400 20492 3740 S 0.0 0.1 0:00.08 /usr/sbin/+
20800 www-data 30 10 496440 24436 7152 S 0.0 0.1 0:00.28 /usr/sbin/+
20802 www-data 30 10 501876 38656 16096 S 0.0 0.2 0:01.01 /usr/sbin/+
20803 www-data 30 10 504044 36620 13768 S 0.0 0.2 0:00.78 /usr/sbin/+
20804 www-data 30 10 496516 32708 11976 S 0.0 0.2 0:00.56 /usr/sbin/+
20805 www-data 30 10 498544 26412 9072 S 0.0 0.2 0:00.50 /usr/sbin/+
20806 www-data 30 10 492072 18320 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20808 www-data 30 10 492256 19504 3004 S 0.0 0.1 0:00.02 /usr/sbin/+
20809 www-data 30 10 492072 18320 2048 S 0.0 0.1 0:00.00 /usr/sbin/+
20812 www-data 30 10 492072 18320 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20817 www-data 30 10 492072 18320 2048 S 0.0 0.1 0:00.00 /usr/sbin/+
20818 www-data 30 10 492072 18320 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20819 www-data 30 10 492072 18324 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20820 www-data 30 10 492072 18328 2052 S 0.0 0.1 0:00.00 /usr/sbin/+
20821 www-data 30 10 496708 24820 7580 S 0.0 0.1 0:00.18 /usr/sbin/+
20822 www-data 30 10 492272 18688 2148 S 0.0 0.1 0:00.03 /usr/sbin/+
20823 www-data 30 10 0 0 0 Z 0.0 0.0 0:00.07 /usr/sbin/+
20825 www-data 30 10 492072 18324 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20826 www-data 30 10 492072 18320 2044 S 0.0 0.1 0:00.01 /usr/sbin/+
20827 www-data 30 10 497136 31320 9876 S 0.0 0.2 0:00.50 /usr/sbin/+
20828 www-data 30 10 492072 18324 2048 S 0.0 0.1 0:00.01 /usr/sbin/+
20829 www-data 30 10 492072 18316 2044 S 0.0 0.1 0:00.01 /usr/sbin/+
20831 www-data 30 10 492072 18328 2052 S 0.0 0.1 0:00.00 /usr/sbin/+
20841 root 20 0 99676 4140 3144 S 0.0 0.0 0:00.09 sshd
20842 sshd 20 0 62752 1556 800 S 0.0 0.0 0:00.02 sshd
21445 root 20 0 131712 25664 2316 S 0.0 0.2 0:42.41 /usr/sbin/+
28767 root 30 10 491984 33292 17080 S 0.0 0.2 1:24.24 /usr/sbin/+
28770 www-data 30 10 164064 9860 612 S 0.0 0.1 0:01.97 /usr/sbin/+
bzw. die dazugenhörigen Entwarnungen. Betroffen sind immer die Apache- und die MySQL-CPU-Auslastung. Der Hosteurope-Support vermutete, dass der Server Opfer eines Angriffs geworden ist. Gegen einen DDOS-Angriff spricht in meinen Augen, dass der Server selbst immer noch antwortet, Mails und statische Seiten problemlos funktionieren, nur die MySQL-Datenbanken nicht mehr antworten. Ich habe versucht, das Problem zu recherchieren, finde aber keine Hinweise auf Angreifer, die gezielt MySQL zum Absturz bringen.
Ist jemandem von euch schon mal so etwas untergekommen? Es fällt zeitlich ziemlich genau mit dem Abschluss geplanter Wartungsarbeiten zusammen, wobei ich nicht weiß, was genau dort gemacht worden ist. Ich habe die Serverpakete aktualisiert und in der Forensoftware den Overhead aus den Tabellen gelöscht, was jedoch keinen Effekt nach sich gezogen hätte. Die mangelnde Reproduzierbarkeit macht es nicht leichter, aber unser Forum ist im Moment ein gutes Drittel der Zeit nicht erreichbar, und ich würde viel lieber einen Nano schreiben, als mich damit rumschlagen zu müssen.
Hast du Statistiken zu Aufrufen? Also wie viele in einem gewissen Zeitraum? Vor allem im Bereich MySQL? Laut meinem Freund kann es sein, dass nur MySQL gezielt angegriffen wird.
Auf welcher MySQL-Version läuft das Forum? Kannst du hier oder per Mail mir bitte alle möglichen Statistiken zukommen lassen, die dir zur Verfügung stehen?
Die Eckdaten unseres Servers:
Ubuntu 14.04LTS
Apache 2.4.7-1ubuntu4.13
MySQL 5.5.53-0ubuntu0.14.04.1
Ich schicke dir gleich alles nochmal per Mail. Logfiles suche ich gerade.
Danke!
Weitere Idee: Vielleicht sind die Indices in der Datenbank kaputt. Ggf. neu generieren lassen und schauen, ob das hilft? Suchabfragen dauern definitiv zu lange und ähm vielleicht sollten die - falls möglich - für Gäste erstmal ausgeschaltet werden?
Hi,
würde in eine ähnliche Kerbe schlagen wie meine Vorrednerin. Im PHPMYAdmin (sofern installiert) mal gucken, ob irgendeine Tabelle nicht mehr in Ordnung ist, alle mal reparieren/optimieren lassen.
Ich hatte mal das Problem, dass der Server lahmgelegt wurde, weil das Limit der MAX_USER_CONNECTIONS erreicht wurde. Du kannst dir im PHPMyAdmin unter Prozesse ansehen, wie viele laufen (vor allem, wenn der Server anfängt zu hinken wird's interessant).
Gruß
Maja, hast du das Forum in den Wartungsmodus gesetzt?
Zitat von: Aryana am 02. November 2016, 19:22:15
Maja, hast du das Forum in den Wartungsmodus gesetzt?
Ja. Ich habe einmal alle Foreneinstellungen resettet, falls das Forum Schuld ist.
Ergo nun mal abwarten, wie es reagiert? Hatte dir noch eine Mail geschickt.
Ich habe gerade ein bisschen auf dem Server rumgewühlt und dabei diese Graphiken gefunden, die zeigen, wie sich die CPU-Auslastung durch MySQL entwickelt - die erste Graphik zeigt den Verlauf des heutigen Tages, die zweite den Wochenverlauf. Man sieht, wie die Spitzen ab Freitag plötzlich hochgehen.
Was interessant ist: Während ich in den Einstellungen war, ist das Forum wieder abgeschmiert - aber ein paar Minuten
nachdem die MySQL-Werte so hoch waren. Während mein Browser minutenlang auf den Webseitenaufbau wartete (und das, wohlgemerkt, während das Forum im Wartungsmodus war, also praktisch keinerlei MySQL-Aktivität generierte), waren laut Plesk die Ressourcenwerte im grünen Bereich.
Ich habe das Forum jetzt auf "Output Compression" gestellt, was es vorher nicht war, und hoffe, dass das vielleicht hilft. Ansonsten sehen alle Tabellen normal aus - und ich denke auch, wenn die zerschossen wären, müsste das Forum andauernd streiken und nicht nur im Brunfttakt eines Goldhamsterweibchens.
Dafür habe ich einen neuen Verdächtigen ausgemacht und tagge einmal das liebe
@RockSheep. Sie hat auf unserem Server Webspace, und als ich mich wunderte, warum das Paket in der Übersicht knatschrot angezeigt wurde, ist mir aufgefallen, dass sie ein Gigabyte Webspace zur Verfügung hat, aber 32 GB belegt (was mehr als zehn Prozent unseres Servers entspricht und größer ist als der gesamte Tintenzirkel). Könnt ihr mal schauen, was da los ist, und ob ihr einen Ressourcenfresser am Start habt? Danke!
[Dateianhang durch Administrator gelöscht]
So, noch ein bisschen tiefer gewühlt ...
Die Schweizer sind sehr wahrscheinlich unschuldig an dem MySQL-Problem, dafür ist ihre Datenbank viel zu klein. Aber eine Bitte
@RockSheep: Würdet ihr ein paar von euren Backups löschen? Ihr speichert seit März jeden Tag zweimal euren gesamten Webspace ab - und seid inzwischen bei über 30GB Backups angekommen ... :rofl:
Hoffentlich letzter Beitrag für jetzt (weil ich Hunger habe und heute noch schreiben muss - stattdessen bin ich seit heute Nachmittag mit dem Server zugange): Ist jemandem nach Ausführung des Repair-Scripts und der Umstellung auf komprimierte Ausgabe noch ein Ausfall untergekommen? Bei mir läuft gerade alles so, wie es soll.
Bislang ist es friedlich.
Bislang kein Problem, mein Freund wirft nochmal einen Blick in die Log-Files. Ich habe aber als User gerade das Gefühl, es läuft flüssiger. Selbst als in den Zeiten, wo es in den letzten Tagen lief.
Ich hatte gerade nochmal 45 Sekunden für einen Seitenaufbau. Die CPU-Werte waren dabei durchgehend unauffällig.
Eine Graphik habe ich noch. Das ist die CPU-Auslastung durch Apache im Verlauf der vergangenen Woche.
[Dateianhang durch Administrator gelöscht]
Okay, ich nochmal. Ich habe einen Verdacht. Ich habe mir gerade die Statstiken der letzten Woche rausgesucht. Alle CPU-Verbräuche schnellen ab Freitag, dem Tag nach Abschluss der Wartungsarbeiten, in die Höhe:
- Verbrauch durch MySWL
- Verbrauch durch Apache
- Verbrauch durch Emails
Jeweils bei gleichbleibendem RAM-Verbrauch. Alle diese Werte sind Prozentangaben. Was ist, wenn sich die absoluten Werte nicht verändert haben, aber die Gesamtmenge der zur Verfügnug stehenden CPU sich plötzlich reduziert hat? Woran sehe ich, wie viel CPU meinem virtuellen Server tatsächlich zur Verfügung steht (Anzahl der Kerne, Taktfrequenz)?
@Maja: Ich geb das gern weiter an
@Umizu, die den Space eigentlich von mir übernommen hat für die Vereinswebseite. Aber soviel ich weiss, sind wir inzwischen umgezogen, also könnte das dort eigentlich weg. Ich schreib sie mal an.
Ansonsten kommt mir bezüglich dem Problem auch nicht mehr in den Sinn, als schon gesagt wurde. :/
Ich hatte meinen Mann auch nochmal gefragt, und falls es doch weitere Ausfälle gibt, hätte er noch ein paar Ideen.
Deshalb überlasse ich ihm mal das Wort:
Hallo Maja ;D
ich bin zwar kein Datenbank-Admin, habe aber ein bisschen Erfahrung mit MySQL. Eigentlich scheue ich solche Ferndiagnosen wie der Teufel das Weihwasser.
In deinen Postings habe ich bisher nichts gelesen davon, dass du die Datenbank auf langsam bzw. sehr lang laufende Abfragen gecheckt hast (Stichwort: slow queries). Solche Abfragen können die DB eine Weile auslasten und lange Antwortzeiten verursachen.
Sofern du die Datenbank nicht sowieso schon daraufhin untersucht hast, würde ich mir die mal ansehen und erst dann Vermutungen über eventuell fehlende Indices anstellen. Neben den Möglichkeiten, die MySQL m.W. selbst bereitstellt, gibt es sonst noch das Programm innotop, mit dem man sich slow queries auflisten lassen kann, ähnlich wie man sich mit top die Prozesse auflisten lassen kann.
Der Nachteil daran ist allerdings, dass man das Loggen der Slow Queries erst einschalten muss und die Logs demzufolge erst ab dem Zeitpunkt erst zur Verfügung hat (nützt also erst etwas, wenn so etwas erneut auftritt).
Wegen des Verbrauchs durch E-Mails: Sofern der Mail-Server eine Verbindung zu derselben Datenbank braucht (z.B. für Anmeldedaten), kann das ebenfalls da mit reinspielen.
@Maja wegen des Seitenausfalls.
Wenn ich es aus den Grafiken richtig herausgelesen habe geht zuerst die SQL-Auslastung hoch und kurz danach Webseite unter Apache in die Knie. Wenn ich damit recht habe ist zu 90% die Ursache auf der SQL Basis zu suchen.
Grund dafür ist, dass es zu viele, zu komplexe oder zu unstrukturierte Anfragen an die Datenbank gibt. Dadurch werden dann Ressourcen an lange abfragen oder große Ergebnismengen gebunden. SQL frisst also immer mehr Speicher und CPU-Leistung - Die Seite wird langsamer. Dann ist die Datenbanbk fertig und übergibt die Daten an den Apache zur Weiterverarbeitung und dann ist der Apache überlastet und das Forum geht in die Knie bis Apache alles verarbeitet hat und dann geht wieder alles.
Ich kenne dieses Szenario all zu gut aus meiner Arbeit mit Datenbanken und schlecht ausgebildeten Informatikern, welche auf meine Datenbanken losgelassen wurden und die Parallelen sind frappierend.
Für mich sieht das deshalb nach unautorisierten Zugriffe über Apache auf die Datenbank aus oder nach sehr schlechtem Code. Da ich dafür aber kein Experte bin denke ich Rocketsheep könnte dir da evtl. besser weiter helfen. Evtl. bereit auch jemand Daten für eine andere Anwendung/Auswertung auf und produziert damit ungewollt zu hohe Last? Auch das ist passiert als schlecht ausgebildete Informatiker meine AS2 für den Shareppoint ausquetschen wollten und mit der DB2 nicht zurecht kamen...
@cryphos Wenn es nur unautorisierte Zugriffe auf die Datenbank wären, hätte sich nicht auch der CPU-Verbrauch durch den Mailserver vervielfacht. Außerdem müsste sich das auch in einem insgesamt gestiegenen RAM-Verbrauch niederschlagen, weil diese Zugriffe RAM kosten.
Das von dir geschilderte Szenario passt mE auch nicht zum Verhalten des Forums, das nicht peu à peu langsamer wird, sondern eine Viertelstunde völlig normal läuft, um dann schlagartig wegzuknacken - und dann auf einen Schlag wieder da zu sein, als wäre nichts gewesen.
Ich habe diverse Datenbanken auf meinem Server, die einzige von nennenswerter Größe ist der Tintenzirkel. Woran sehe ich, ob ein Script von außen versucht, auf meine Datenbanken zuzugreifen?
Zitat von: Maja am 02. November 2016, 20:43:34
Ich habe diverse Datenbanken auf meinem Server, die einzige von nennenswerter Größe ist der Tintenzirkel. Woran sehe ich, ob ein Script von außen versucht, auf meine Datenbanken zuzugreifen?
Rocketsheep ist da besser geeignet als ich, bei Intrusion dedection bin ich echt nur ein Laie. Ich kann dir nur sagen was ich machen würde. das wäre die Datenbank beobachten und alle Anfragen protokollieren lassen. Dann würde ich die raus suchen die besonders lange dauern oder besonders große Speicherlast erzeugen. Habe ich da ein paar Kandidaten ausgemacht würde ich zum einen prüfen wer stellt diese Anfragen und zum anderen welche Tabellen werden abgefragt.
Dann würde ich die abgefragten Tabellen unter Audit stellen um genau zu ermitteln wer da wann was wie abfragt und ich würde prüfen unter welchen Umständen der anfragende User diese Mörderanfragen stellt. Ist der User dir unbekannt, dann ist es wohl sicher ein Externer. ist dir der User bekannt und z.B. dein Standarduser für Datenbankanfragen, dann wird es kniffliger. Dann musst du prüfen unter welchen Umständen die Anfragen erstellt wurden. dazu musst du dann die Apache Protokolle via Zeitstempel mit den SQL Protokollen abgleichen. Ich musste das zwei mal im leben manuell durchführen und bin nicht Firm darin. Sicher gibt es da bessere Lösungen als alles manuell durchzugehen. Aber wie gesagt, Rocketsheep müsste sich da wesentlich besser als ich auskennen.
Zum Vergleich: Dies ist die CPU-Auslastung durch meinen Mailserver von letztem Dienstag bis heute. Das absolute Mailaufkommen hat sich nicht verändert in der Zeit, und ich denke nicht, dass Anfragen an meine MySQL-Datenbanken einen Einfluss auf den CPU-Verbrauch durch den Mailserver haben dürften, und umgekehrt. Deswegen vermute ich wirklich einen Rückgang der absoluten CPU-Leistung.
Diesen Verdacht habe ich jetzt auch (mit den Graphiken zur Illustration) an den HE-Kundendienst weitergeleitet.
[Dateianhang durch Administrator gelöscht]
@Maja in den Logfiles steht nichts auffälliges. Aber im Moment scheint es wieder ganz gut zu laufen? :hmmm: Ich habe in der letzten Zeit keine Ausfälle mehr bemerkt.
Es läuft im Moment rund, aber die CPU-Auslastung des Servers ist immer noch insgesamt deutlich höher als sonst. Üblicherweise lag unsere CPU-Usage immer im 10%-Bereich, jetzt dümpelt sie bei 40-50% rum. Ich hoffe, der Kundendienst kann meinen Ausführungen folgen - nach den Graphiken, die ich eingereicht habe, sollte das Problem jetzt zumindest nachvollziehbar sein.
Gerade ist z.B. MySQL niedrig, aber der Apache krallt sich 40% - das ist also nicht so, dass erst MySQL hochgeht und dann der Apache nachzieht, der macht das gerade von sich aus.
@Maja Nutzt du Joomla für irgendeine deiner Seiten?
Wenn ja, angeblich werden gerade massive Attacken auf unsichere Joomlaversionen gefahren und es wird deshalb geraten das neuste Update aufzuspielen, dass die dafür verantwortlichen Lücken schließt.
Zitat von: cryphos am 02. November 2016, 21:28:38
@Maja Nutzt du Joomla für irgendeine deiner Seiten?
Wenn ja, angeblich werden gerade massive Attacken auf unsichere Joomlaversionen gefahren und es wird deshalb geraten das neuste Update aufzuspielen, dass die dafür verantwortlichen Lücken schließt.
Nein, meine Webseiten sind alle handgeschrieben, als Forensoftware nutze ich Serendipity, und das Forum läuft auf SMF. Die Tintenzirkler, die ihren Webspace über mich laufen lassen, benutzen Wordpress und Drupal.
Hallo Maja!
Wenn du wissen willst, ob von außerhalb mehr Zugriffe kommen als sonst, dann müsstest du eigentlich eine passende Statistik über phpMyAdmin (oder welches Administrationstool du auch immer verwendest) abrufen können. So etwas wie "Top Zugriffe auf URLs" und auch von welcher Location diese gemacht wurden. Nur für den Fall, dass du einen Angriff von außen noch für eine Möglichkeit hältst.
Ansonsten ist mir aufgefallen, dass zeitweise die NaNo-Counter in den Signaturen sehr lange zum Laden brauchen. Teils pro Counter 700ms bis 1sek. Hab das mit Firefox im Entwicklertool unter Netzwerk beobachtet, konnte es aber in den letzten 10 Minuten nicht mehr rekonstruieren. Wie genau funktioniert denn das mit dem Countern? Werden da Daten in einem bestimmten Intervall abgefragt und die restliche Zeit über gechached?
Nur noch mal eine Wasserstandsmeldung: Seitdem Du das Forum aus dem Wartungsmodus zurückgeholt hast, hatte ich keine ungewöhnlichen Ladezeiten mehr.
Da ich vermutlich wieder bis in die Frühe auf sein werde und dann entsprechend morgen den halben Tag verschlafen: Wenn ihr seht, dass das Forum wieder rumschneckt, und ich bin nicht online, seid ihr so lieb und meldet es hier? Danke!
Ganz simple Frage: passen CPU-Verbrauche mit Anzahl der Seitenabrufe pro Zeiteinheit zusammen? Was wurde gerade aufgerufen, wenn es hakt? Suchen kosten mehr als einfache Anfragen. Unseren kleinen Filkshop hat mal Google geDDoSt - da hatten wir eine Spiertrap gebaut, auf die Google immer mehr Bot losließ, weil die von diesen gesehene Seitentiefe so riesig war. Oder die andere Truppe, die sämtliche Podcasts auf HTML-Inhalte spiderte. Die MP3 und MP4 Dateien wohlgemerkt...
Was sind die /usr/sbin/.... Prozesse, die durch den Nutzer www-data laufen? Da hängt da eine ganze Menge dieser Prozesse in Deinem ersten Post. Und wenn die i/o-Ressourcen binden (beispielsweise das Dateisystem blockieren), dann hängen auch alle anderen Prozesse.
Hinsichtlich MySQL kannst Du ja mal schauen, wie die Parametrisierung ist. Da gibt es immer wieder mal Optimierungspotential.
https://bugs.launchpad.net/mysql-tuning-primer (https://bugs.launchpad.net/mysql-tuning-primer)
Schick' mir mal Apache-Zugriffs-Logs, die /etc/mysqld/my.cnf und /var/log/mysql* zu (Mailadresse ist ja bekannt).
Die "Output Compression" ist zwar sinnvoll weil sie Netzkapazität schont, kostet aber ein wenig mehr an CPU. Dürfte aber nichts am aktuellen Problem änden.
Du bist auf einem virtuellen Server (HostEurope macht ja nur noch solche)? Da bin ich auch immer wieder gebissen worden. Für alles, von dem ich irgendwie abhänge, will ich inzwischen eigene Physik haben. Denn wenn "der Nachbar" ein i/o- oder CPU-Problem hat, dann knirscht's auch bei mir, ohne dass ich genauer sehen kann, was kaputt ist, und ohne dass ich da etwas 'dran ändern kann. Auf der Physik habe ich dann eigene VMs - aber da kann ich dann je sehen, welche gerade was macht (und das dann auch abstellen).
(https://www.wyae.de/tmp/vm_usage.png)
Wie stellst Du anderen Webspace zur Verfügung? Da kann dann auch mal 'was querschießen (meist unbeabsichtigt). Wenn sich da beispielsweise Backup-MySQLdumps zu überholen versuchen...
Hallo Volker,
zum Titenzirkel passen die CPU-Verbrauche nicht. Die sind im ganz normalen Bereich - in den letzten Tagen haben sie natürlich angezogen, weil der Nano gestartet ist, aber nicht dramatisch, nicht sprunghaft, und nicht auf einen Schlag am Freitag.
Ich habe zwei Tintenzirklern über Plesk Hosting-Pakete mit einem GB Webspace eingerichtet. Beide haben da auch Datenbanken am Laufen, aber ich habe mir das heute angeschaut, und es sieht auf den ersten Blick alles normal aus, und die Datenbanken sind ziemlich klein; die einzige DB von nennenswerter Größe ist die des Tintenzirkelforums. Ich habe aber noch nicht rausgefunden, wo man sich in PHPMyAdmin die Statistiken anzeigen kann; die Punkte "Status" und "Processes", die ich in einer Dokumentation gefunden habe, gibt es bei mir jedenfalls nicht.
Die Logfiles habe ich dir gerade geschickt, vielleicht wirst du ja schlau draus (und ich hoffe, ich habe die richtigen Dateien erwischt).
Hosteurope bietet auch dedizierte Server an, aber nicht in meiner Preisklasse ...
Moin!
Zitat von: Maja am 03. November 2016, 01:01:05
Ich habe zwei Tintenzirklern über Plesk Hosting-Pakete mit einem GB Webspace eingerichtet. Beide haben da auch Datenbanken am Laufen,
Das bedeutet, dass Du die nicht einfach unterscheiden kannst. Alle virtuellen Instanzen laufen auf/im selben Daemon. Dann hat "apache" oder "mysql" halt Last - Du siehst aber nicht, welche der Domians/Unterpakete gerade Stress machen.
Zitat von: Maja am 03. November 2016, 01:01:05
Ich habe aber noch nicht rausgefunden, wo man sich in PHPMyAdmin die Statistiken anzeigen kann; die Punkte "Status" und "Processes", die ich in einer Dokumentation gefunden habe, gibt es bei mir jedenfalls nicht.
Bei Problemen: per SSH einloggen, und über "nmon" und "pstree -pau" mal schauen, was da so akut 'rumspinnt. Konntest Du herausfinden, was da so an "/usr/sbin..." Prozessen läuft? Könnten mysqld oder apache sein - oder halt irgendetwas anderes.
Zitat von: Maja am 03. November 2016, 01:01:05
Hosteurope bietet auch dedizierte Server an, aber nicht in meiner Preisklasse ...
Es gibt auch andere Anbieter. Allerdings sind die "Dedicated" Server meist extrem nackt - egal bei welchem Provider. Da muss man dann eigentlich alles selber machen. Dafür pfuschen dann weder Provider noch andere Kunden bei einem 'rein.
Eine andere Idee: hast Du die Apache/Mysql Prozesse seit Freitag schon mal durchgestartet? So für den Fall, dass da irgendetwas hängt.
nmon: command not found
pstree -pau
init,1
|-/usr/sbin/apach,12400 -k start
| |-/usr/sbin/apach,12403,www-data -k start
| |-/usr/sbin/apach,13456,www-data -k start
| |-/usr/sbin/apach,13555,www-data -k start
| |-/usr/sbin/apach,13556,www-data -k start
| |-/usr/sbin/apach,13560,www-data -k start
| |-/usr/sbin/apach,13859,www-data -k start
| |-/usr/sbin/apach,13995,www-data -k start
| `-/usr/sbin/apach,13996,www-data -k start
|-/usr/sbin/spamd,6081
| `-spamd child,7043,popuser
|-courierlogger,759 -name=courier-authdaemon-pid=/var/run/courier-authdaemo
| `-authdaemond,760
| |-authdaemond,763
| |-authdaemond,764
| |-authdaemond,765
| |-authdaemond,766
| `-authdaemond,767
|-courierlogger,791 -name=imapd -pid=/var/run/imapd.pid -start-name=courier
| `-couriertcpd,792 -address=0 -maxprocs=40 -maxperip=40 -nodnslookup...
| |-imapd,5276,popuser Maildir
| |-imapd,5286,popuser Maildir
| |-imapd,7786,popuser Maildir
| |-imapd,7791,popuser Maildir
| |-imapd,13640,popuser Maildir
| |-imapd,13643,popuser Maildir
| |-imapd,13646,popuser Maildir
| |-imapd,13649,popuser Maildir
| |-imapd,13652,popuser Maildir
| |-imapd,13655,popuser Maildir
| |-imapd,13658,popuser Maildir
| |-imapd,13661,popuser Maildir
| |-imapd,13662,popuser Maildir
| |-imapd,13663,popuser Maildir
| |-imapd,16392,popuser Maildir
| |-imapd,25514,popuser Maildir
| |-imapd,25517,popuser Maildir
| |-imapd,25520,popuser Maildir
| `-imapd,29011,popuser Maildir
|-courierlogger,822 -name=imapd-ssl -pid=/var/run/imapd-ssl.pid -start-name
| `-couriertcpd,823 -address=0 -maxprocs=40 -maxperip=40 -nodnslookup...
|-courierlogger,862 -name=pop3d -pid=/var/run/pop3d.pid -start-name=courier
| `-couriertcpd,864 -address=0 -maxprocs=40 -maxperip=40 -nodnslookup...
|-courierlogger,905 -name=pop3d-ssl -pid=/var/run/pop3d-ssl.pid -start-name
| `-couriertcpd,906 -address=0 -maxprocs=40 -maxperip=40 -nodnslookup...
|-couriertls,5300 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,5301 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,7793 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,7795 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13642 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13645 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13648 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13651 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13654 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13657 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13660 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13667 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13668 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,13669 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,16394 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,25516 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,25519 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,25522 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-couriertls,29015 -statusfd=7 -printx509=9 -localfd=5 -tcpd -server
|-cron,573
| `-cron,17300
| `-sh,17301 -c...
| `-sh,17302 -c...
| `-run-parts,17303 --report /etc/cron.daily
| `-50plesk-daily,17304 /etc/cron.daily/50plesk-daily
| `-sw-engine,17305 -c /opt/psa/admin/conf/php.ini...
| `-sw-engine,12496 -c ...
| `-web_statistic_e,12499
| `-awstats.pl,13928 ...
|-getty,3009 38400 console
|-getty,3015 38400 tty2
|-(kthreadd/124021,2)
| |-(khelper/124021,3)
| |-(nfsiod/124021,28)
| |-(rpciod/124021/0,4)
| |-(rpciod/124021/1,5)
| |-(rpciod/124021/1,14)
| |-(rpciod/124021/1,15)
| |-(rpciod/124021/1,16)
| |-(rpciod/124021/1,17)
| |-(rpciod/124021/1,18)
| |-(rpciod/124021/1,19)
| |-(rpciod/124021/1,20)
| |-(rpciod/124021/1,21)
| |-(rpciod/124021/1,22)
| |-(rpciod/124021/1,23)
| |-(rpciod/124021/2,6)
| |-(rpciod/124021/2,24)
| |-(rpciod/124021/2,25)
| |-(rpciod/124021/2,26)
| |-(rpciod/124021/2,27)
| |-(rpciod/124021/3,7)
| |-(rpciod/124021/4,8)
| |-(rpciod/124021/5,9)
| |-(rpciod/124021/6,10)
| |-(rpciod/124021/7,11)
| |-(rpciod/124021/8,12)
| `-(rpciod/124021/9,13)
|-master,1316
| |-pickup,9066,postfix -l -t fifo -u -c
| |-proxymap,14014,postfix -t unix -u
| |-qmgr,1330,postfix -l -t unix -u
| |-qmgr,1333,postfix -l -t fifo -u
| |-smtpd,14013,postfix -n smtp -t inet -u -c -o stress= -s 2
| `-tlsmgr,3914,postfix -l -t unix -u -c
|-monit,653 -Ic/opt/psa/etc/modules/watchdog/moni
| `-{monit},658
|-mysqld,604,mysql
| |-{mysqld},616
| |-{mysqld},617
| |-{mysqld},618
| |-{mysqld},619
| |-{mysqld},620
| |-{mysqld},621
| |-{mysqld},622
| |-{mysqld},623
| |-{mysqld},624
| |-{mysqld},625
| |-{mysqld},629
| |-{mysqld},630
| |-{mysqld},631
| |-{mysqld},632
| |-{mysqld},641
| |-{mysqld},1192
| |-{mysqld},21829
| |-{mysqld},21888
| |-{mysqld},31039
| |-{mysqld},7322
| |-{mysqld},18578
| |-{mysqld},23822
| |-{mysqld},23825
| |-{mysqld},13524
| |-{mysqld},13525
| |-{mysqld},13584
| |-{mysqld},13586
| `-{mysqld},13588
|-named,953,bind -t /var/named/run-root -c /etc/named.conf -u bind -n 2
| |-{named},954
| |-{named},955
| |-{named},956
| `-{named},957
|-nmbd,407 -D
|-psa-pc-remote,1039,postfix -p inet:12768@127.0.0.1
| |-{psa-pc-remote},1040
| |-{psa-pc-remote},1041
| |-{psa-pc-remote},1042
| |-{psa-pc-remote},1044
| |-{psa-pc-remote},1045
| `-{psa-pc-remote},1046
|-rsyslogd,342,syslog
| |-{rsyslogd},356
| `-{rsyslogd},357
|-smbd,214 -F
| |-smbd,268 -F
| `-smbd,271 -F
|-sshd,1073 -D
| `-sshd,24821
| `-bash,24839
| `-pstree,14015 -pau
|-sw-collectd,2821 -C /etc/sw-collectd/collectd.conf -P/var/run/sw-collectd.
| |-{sw-collectd},2823
| |-{sw-collectd},2824
| |-{sw-collectd},2825
| |-{sw-collectd},2826
| |-{sw-collectd},2827
| `-{sw-collectd},2828
|-sw-cp-serverd,1597
| `-sw-cp-serverd,1598,sw-cp-server
|-sw-engine,542 -c /opt/psa/admin/conf/php.ini/opt/psa/admin/bin/modules/wat
|-sw-engine,2759 -c /opt/psa/admin/conf/php.ini/usr/lib/plesk-9.0/psa-health-
|-sw-engine-fpm,9164
|-systemd-udevd,198 --daemon
|-upstart-file-br,390 --daemon
|-upstart-socket-,388 --daemon
|-upstart-udev-br,179 --daemon
`-xinetd,680 -dontfork -pidfile /var/run/xinetd.pid -stayalive
ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 33324 2292 ? Ss Oct28 0:15 init
root 2 0.0 0.0 0 0 ? S Oct28 0:00 [kthreadd/12402
root 3 0.0 0.0 0 0 ? S Oct28 0:00 [khelper/124021
root 4 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 5 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 6 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 7 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 8 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 9 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 10 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 11 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 12 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 13 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 14 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 15 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 16 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 17 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 18 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 19 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 20 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 21 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 22 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 23 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 24 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 25 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 26 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 27 0.0 0.0 0 0 ? S Oct28 0:00 [rpciod/124021/
root 28 0.0 0.0 0 0 ? S Oct28 0:00 [nfsiod/124021]
root 179 0.0 0.0 19424 576 ? S Oct28 0:00 upstart-udev-br
root 198 0.0 0.0 49212 700 ? Ss Oct28 0:00 /lib/systemd/sy
root 214 0.0 0.0 316656 4312 ? Ss Oct28 0:06 smbd -F
root 268 0.0 0.0 308704 2044 ? S Oct28 0:00 smbd -F
root 271 0.0 0.0 316656 2468 ? S Oct28 0:05 smbd -F
syslog 342 0.0 0.1 184576 19788 ? Ssl Oct28 2:07 rsyslogd
root 388 0.0 0.0 15472 620 ? S Oct28 0:00 upstart-socket-
root 390 0.0 0.0 15224 616 ? S Oct28 0:00 upstart-file-br
root 407 0.0 0.0 231396 1380 ? Ss Oct28 0:58 nmbd -D
root 542 0.0 0.0 274520 9164 ? Ss Oct28 0:34 /usr/bin/sw-eng
root 573 0.0 0.0 23600 964 ? Ss Oct28 0:03 cron
mysql 604 7.7 0.5 2301992 91908 ? Ssl Oct28 614:45 /usr/sbin/mysql
root 653 0.0 0.0 177660 1424 ? Ssl Oct28 1:16 /opt/psa/admin/
root 680 0.0 0.0 14940 888 ? Ss Oct28 0:03 /usr/sbin/xinet
root 759 0.0 0.0 4288 408 ? S Oct28 0:00 /usr/sbin/couri
root 760 0.0 0.0 25952 752 ? S Oct28 0:00 /usr/lib/courie
root 763 0.0 0.0 34512 1532 ? S Oct28 0:04 /usr/lib/courie
root 764 0.0 0.0 34512 1628 ? S Oct28 0:04 /usr/lib/courie
root 765 0.0 0.0 34512 1576 ? S Oct28 0:04 /usr/lib/courie
root 766 0.0 0.0 34512 1620 ? S Oct28 0:04 /usr/lib/courie
root 767 0.0 0.0 34512 1576 ? S Oct28 0:04 /usr/lib/courie
root 791 0.0 0.0 4288 416 ? S Oct28 0:02 /usr/sbin/couri
root 792 0.0 0.0 12116 760 ? S Oct28 0:05 /usr/lib/courie
root 822 0.0 0.0 4288 412 ? S Oct28 0:00 /usr/sbin/couri
root 823 0.0 0.0 12116 740 ? S Oct28 0:00 /usr/lib/courie
root 862 0.0 0.0 4288 412 ? S Oct28 0:00 /usr/sbin/couri
root 864 0.0 0.0 12116 736 ? S Oct28 0:00 /usr/lib/courie
root 905 0.0 0.0 4288 408 ? S Oct28 0:00 /usr/sbin/couri
root 906 0.0 0.0 12116 740 ? S Oct28 0:00 /usr/lib/courie
bind 953 0.0 0.1 247616 20044 ? Ssl Oct29 0:37 /usr/sbin/named
postfix 1039 0.0 0.0 402616 1908 ? Ssl Oct28 2:52 /usr/lib/plesk-
root 1073 0.0 0.0 61328 2504 ? Ss Oct29 0:33 /usr/sbin/sshd
root 1316 0.0 0.0 25288 1508 ? Ss Oct28 4:23 /usr/lib/postfi
postfix 1330 0.0 0.0 27520 1584 ? S Oct28 0:01 qmgr -l -t unix
postfix 1333 0.0 0.0 27520 1688 ? S Oct28 3:01 qmgr -l -t fifo
root 1597 0.0 0.0 31376 464 ? Ss Oct28 0:00 sw-cp-server: m
sw-cp-s+ 1598 0.0 0.0 32336 2588 ? S Oct28 0:03 sw-cp-server: w
root 2759 0.0 0.0 286696 12000 ? S Oct28 2:02 /usr/bin/sw-eng
root 2821 0.2 0.0 561876 2744 ? Ssl Oct28 22:55 /usr/sbin/sw-co
root 3009 0.0 0.0 12732 672 tty1 Ss+ Oct28 0:00 /sbin/getty 384
root 3015 0.0 0.0 12732 676 tty2 Ss+ Oct28 0:00 /sbin/getty 384
postfix 3914 0.0 0.0 40384 2364 ? S Oct28 0:16 tlsmgr -l -t un
popuser 7786 1.0 0.0 19636 6172 ? S Nov02 1:49 /usr/bin/imapd
popuser 7791 0.2 0.0 16264 2824 ? S Nov02 0:24 /usr/bin/imapd
root 7793 0.0 0.0 12920 2304 ? S Nov02 0:00 couriertls -sta
root 7795 0.0 0.0 12920 2304 ? S Nov02 0:00 couriertls -sta
postfix 9066 0.0 0.0 27352 1636 ? S 01:14 0:00 pickup -l -t fi
root 9164 0.0 0.0 372704 6584 ? Ss Nov02 0:00 sw-engine-fpm:
root 12400 0.2 0.1 491984 33296 ? Ss 01:26 0:03 /usr/sbin/apach
www-data 12403 0.0 0.0 164064 9864 ? S 01:26 0:00 /usr/sbin/apach
popuser 13640 0.1 0.0 17272 1844 ? S 01:39 0:00 /usr/bin/imapd
root 13642 0.0 0.0 12920 2296 ? S 01:39 0:00 couriertls -sta
popuser 13643 0.0 0.0 16812 1300 ? S 01:39 0:00 /usr/bin/imapd
root 13645 0.0 0.0 12920 2296 ? S 01:39 0:00 couriertls -sta
popuser 13646 0.4 0.0 19332 3796 ? S 01:39 0:02 /usr/bin/imapd
root 13648 0.0 0.0 12920 2304 ? S 01:39 0:00 couriertls -sta
popuser 13649 0.2 0.0 18012 2592 ? S 01:39 0:01 /usr/bin/imapd
root 13651 0.0 0.0 12920 2292 ? S 01:39 0:00 couriertls -sta
popuser 13652 0.0 0.0 17040 1568 ? S 01:39 0:00 /usr/bin/imapd
root 13654 0.0 0.0 12920 2300 ? S 01:39 0:00 couriertls -sta
popuser 13655 0.0 0.0 16812 1340 ? S 01:39 0:00 /usr/bin/imapd
root 13657 0.0 0.0 12920 2300 ? S 01:39 0:00 couriertls -sta
popuser 13658 0.0 0.0 16812 1328 ? S 01:39 0:00 /usr/bin/imapd
root 13660 0.0 0.0 12920 2296 ? S 01:39 0:00 couriertls -sta
popuser 13661 0.0 0.0 16812 1292 ? S 01:40 0:00 /usr/bin/imapd
popuser 13662 0.0 0.0 16916 1400 ? S 01:40 0:00 /usr/bin/imapd
popuser 13663 0.0 0.0 16812 1352 ? S 01:40 0:00 /usr/bin/imapd
root 13667 0.0 0.0 12920 2300 ? S 01:40 0:00 couriertls -sta
root 13668 0.0 0.0 12920 2300 ? S 01:40 0:00 couriertls -sta
root 13669 0.0 0.0 12920 2296 ? S 01:40 0:00 couriertls -sta
postfix 14016 0.0 0.0 27352 1536 ? S 01:43 0:00 anvil -l -t uni
www-data 14341 0.5 0.1 498492 26808 ? S 01:44 0:01 /usr/sbin/apach
www-data 14355 1.9 0.2 504384 43276 ? S 01:44 0:04 /usr/sbin/apach
root 14461 4.6 0.3 131896 60884 ? Ss 01:44 0:09 /usr/sbin/spamd
popuser 14462 1.1 0.3 136712 66240 ? S 01:45 0:02 spamd child
www-data 14504 1.0 0.2 502044 40440 ? S 01:45 0:01 /usr/sbin/apach
www-data 14508 1.5 0.2 498792 37684 ? S 01:45 0:02 /usr/sbin/apach
www-data 14555 1.6 0.2 504692 43192 ? S 01:45 0:02 /usr/sbin/apach
popuser 14609 4.9 0.0 17308 1840 ? S 01:47 0:03 /usr/bin/imapd
root 14611 0.4 0.0 12920 2300 ? S 01:47 0:00 couriertls -sta
www-data 14639 2.0 0.2 496476 36316 ? R 01:47 0:00 /usr/sbin/apach
www-data 14641 0.6 0.1 498784 25460 ? S 01:47 0:00 /usr/sbin/apach
root 14656 0.6 0.0 100892 4216 ? Ss 01:48 0:00 sshd: root@pts/
root 14667 1.7 0.0 19536 3468 pts/1 Ss 01:48 0:00 -bash
root 14681 0.2 0.0 62672 3112 ? Ss 01:48 0:00 sshd: [accepted
sshd 14682 0.0 0.0 62672 1408 ? S 01:48 0:00 sshd: [net]
www-data 14692 0.0 0.1 492016 17272 ? S 01:48 0:00 /usr/sbin/apach
root 14693 0.0 0.0 15512 1140 pts/1 R+ 01:48 0:00 ps aux
popuser 16392 0.2 0.0 15344 1952 ? S 00:31 0:11 /usr/bin/imapd
root 16394 0.0 0.0 12920 2304 ? S 00:31 0:00 couriertls -sta
popuser 25514 1.1 0.0 19640 6224 ? S Nov02 6:40 /usr/bin/imapd
root 25516 0.0 0.0 12920 2300 ? S Nov02 0:00 couriertls -sta
popuser 25517 0.0 0.0 14840 1372 ? S Nov02 0:09 /usr/bin/imapd
root 25519 0.0 0.0 12920 2300 ? S Nov02 0:00 couriertls -sta
popuser 25520 0.2 0.0 16268 2892 ? S Nov02 1:24 /usr/bin/imapd
root 25522 0.0 0.0 12920 2300 ? S Nov02 0:00 couriertls -sta
popuser 29011 1.2 0.0 17584 2208 ? S Nov02 7:10 /usr/bin/imapd
root 29015 0.0 0.0 12920 2316 ? S Nov02 0:01 couriertls -sta
Ich habe den Server am Freitag neu gestartet, als die Probleme losgingen, aber die Ressourcen waren sofort wieder im Keller, deswegen habe ich es nicht wiederholt.
Guten Morgen,
Ich bin gerade mit dem Tablet online, hab mich eben ein wenig durch das Romanboard im Nanobereich gewuehlt und hatte dort einige Male nacheinander eine "webseite nicht verfuegbar"-Fehlermeldung. Nach Neu laden kam die gewünschte Seite aber dann sehr schnell hoch, hierLadezeiten sind absolut in Ordnung, nur diese Fehlermeldungen irritieren. Keine Ahnung, ob derer Server noch Schluckauf hat oder ob es an meiner Uraltmoehre von Tablet liegt.
Akut ist da nicht wirklich Auffälliges dabei.
Wenn man wissen will, was an Programmen gerade MySQL nutzt, dann kann man das auf der Shell abfragen mit
netstat -pan | fgrep ':3306 '
oder
ss -pan | fgrep ':3306 '
je nachdem, was gerade installiert ist (ss für SocketStatistics ist eine zwar kurze und naheliegende aber IMHO nur mäßig geschmackvolle Abkürzung)
Um 8.23 hing das Forum wieder. (Es kann sein, dass es noch länger war. Ich glaube, ich hatte irgendwann neu geladen.)
ZitatSeite erstellt in 44.575 Sekunden mit 19 Abfragen.
Als ich das dann hier melden wollte, passierte es nochmal.
ZitatSeite erstellt in 256.497 Sekunden mit 22 Abfragen.
ZitatSeite erstellt in 27.779 Sekunden mit 12 Abfragen.
Das sieht zwar im Vergleich zu Tigermöhres Zahl harmlos aus, aber hat trotzdem ungewöhnlich lang gedauert.
Sollte das bei mir nochmal passieren, editiere ich die neue Zahl auch hier rein.
Gerade beim antworten wollen bei den Hardcorlern:
ZitatSeite erstellt in 32.418 Sekunden mit 14 Abfragen.
Für so wenige Abfragen definitiv zu lange.
Zeitgleich mit Eluin bei mir auch:
Zitat50.981 Sekunden mit 19 Abfragen.
Hatte es auch gerade wieder:
ZitatSeite erstellt in 43.516 Sekunden mit 11 Abfragen.
ZitatSeite erstellt in 91.382 Sekunden mit 13 Abfragen.
Ich bin jetzt wach und seh es wieder selbst. Danke für die Meldungen!
Vom HE Kundendienst habe ich noch nichts wieder gehört.
Welche Prozesse laufen gerade? Denn da hakte es wieder...
Nach einem Telefonat mit
@Volker habe ich gerade die Signaturen für das gesamte Forum deaktiviert, um ausschließen zu können, dass unser Nanowrimo-Counter für die Zusammenbrüche verantwortlich ist. Eure Signaturen sind alle noch auf dem Server abgespeichert und lassen sich per Knopfdruck wieder aktivieren, wenn die Zusammenbrüche jetzt weitergehen.
Läuft der Server ab jetzt rund, herzlichen Glückwunsch: Dann haben wir den Schuldigen.
Da ich jetzt unten bin und esse, wäre es lieb, wenn ihr mir auffällige Ladezeiten der nächsten Stunde melden könntet. Danke!
@Maja, was ist mit den Teamcountern? Sollen wir die auch erst einmal entfernen? Nur zur Sicherheit?
Zitat von: Sprotte am 03. November 2016, 21:14:24
@Maja, was ist mit den Teamcountern? Sollen wir die auch erst einmal entfernen? Nur zur Sicherheit?
Die Teamcounter sind aus Sicht unseres Servers nur kleine Bildchen, die über das <img>-Tag eingebunden werden. Vor allem werden sie nur dann abgerufen, wenn jemand genau die Seite in dem Thread aufruft, in der diese Bilder gezeigt werden - anders als die Counter, die zum einen die Ausführung eines Scripts auf unserem Server erfordern, zum anderen in jedem einzelnen Beitrag der jeweiligen Mitglieder angezeigt werden. Und wir haben dieses Jahr nochmal ein Dutzend Teilnehmer mehr als im vergangenen Jahr, das kann also tatsächlich einen Unterschied machen.
Ich schaue jetzt, ob sich die CPU-Last schon sichtbar verändert hat, rechne aber nicht mit klaren Ergebnissen vor morgen - dafür sind die Ausfälle immer zu unvorhersehbar aufgetreten.
21:39 Seite erstellt in 219.892 Sekunden mit 15 Abfragen.
21:48 Seite erstellt in 538.619 Sekunden mit 14 Abfragen.
Seite erstellt in 490.382 Sekunden mit 14 Abfragen.
ZitatSeite erstellt in 181.595 Sekunden mit 13 Abfragen.
Ich glaube, die Counter können wir damit ausschließen. :-\
Eben hatte ich auch so einen Riesenbatzen wie Sprotte und Shin, den habe ich aber vergessen zu kopieren.
Zitat von: Miezekatzemaus am 03. November 2016, 21:49:56
ZitatSeite erstellt in 181.595 Sekunden mit 13 Abfragen.
Ich glaube, die Counter können wir damit ausschließen. :-\
Eben hatte ich auch so einen Riesenbatzen wie Sprotte und Shin, den habe ich aber vergessen zu kopieren.
Hier das gleiche, Forum brauchte ca. 5 Minuten zum Laden.
Ich denke, damit sollte die Unschuld unserer Counter erwiesen sein. Ich habe die Signaturen jetzt wieder eingeschaltet.
Ebenso,
aber mir ist gerade aufgefallen, dass ich seit Tagen keine Emails mehr mit Threadbenachrichtigungen erhalten habe. Sind die während des NaNo's ausgeschaltet (weil überwältigend viele) oder könnte da was nicht stimmen?
Bei mir war das Gleiche, und dann hat das Forum gar nicht mehr geladen. Ich bekam eine Error-Meldung wegen Zeitüberschreitung beim Laden, dauerte insgesamt gute 10 Minuten. Ich habe währenddessen auf anderen Seiten gesurft, aber daran kann es ja wohl kaum liegen.
So war es bei mir ebenfalls. :schuldig:
Zitat von: Maubel am 03. November 2016, 21:56:30
aber mir ist gerade aufgefallen, dass ich seit Tagen keine Emails mehr mit Threadbenachrichtigungen erhalten habe. Sind die während des NaNo's ausgeschaltet (weil überwältigend viele) oder könnte da was nicht stimmen?
Nein, mit denen ist eigentlich alles in Ordnung. Der Server verschickt die Mails ordnungsgemäß, da habe ich gerade nachgeschaut, und es kommen auch keine Bouncenachrichten. Ich hoffe, wir sind nicht wieder auf irgendwelchen Sperrlisten gelandet ...
@Volker Da ich gerade am Rechner war, während der Server abgerauscht ist, habe ich top ausgeführt, um zu sehen, ob Prozesse als wartend aufgeführt sind. Das nicht, aber MySQL verbrauchte mal smakkelig 102% CPU-Power.
top - 22:05:31 up 6 days, 7:49, 1 user, load average: 1.75, 1.64, 2.14
Tasks: 213 total, 1 running, 212 sleeping, 0 stopped, 0 zombie
%Cpu(s): 24.0 us, 2.5 sy, 1.0 ni, 72.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16777216 total, 12266380 used, 4510836 free, 0 buffers
KiB Swap: 8388608 total, 120472 used, 8268136 free. 11291036 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
604 mysql 20 0 2302188 98492 5244 S 102.0 0.6 726:37.88 /usr/sbin/mysqld
20119 root 20 0 19952 1676 1068 R 1.6 0.0 0:00.63 top
20177 www-data 30 10 494276 21132 4576 S 1.3 0.1 0:00.04 /usr/sbin/apache2 -k start
18869 www-data 30 10 501824 41668 20936 S 1.0 0.2 0:05.64 /usr/sbin/apache2 -k start
19495 www-data 30 10 498588 35680 14996 S 0.7 0.2 0:02.40 /usr/sbin/apache2 -k start
19588 www-data 30 10 498284 27468 10364 S 0.7 0.2 0:01.84 /usr/sbin/apache2 -k start
19777 www-data 30 10 504396 40604 17620 S 0.7 0.2 0:01.65 /usr/sbin/apache2 -k start
19936 www-data 30 10 499032 28232 10384 S 0.7 0.2 0:01.36 /usr/sbin/apache2 -k start
20170 www-data 30 10 494624 21276 4660 S 0.7 0.1 0:00.09 /usr/sbin/apache2 -k start
18921 www-data 30 10 498520 25872 8612 S 0.3 0.2 0:03.62 /usr/sbin/apache2 -k start
19911 www-data 30 10 494624 22656 5972 S 0.3 0.1 0:00.61 /usr/sbin/apache2 -k start
20038 www-data 30 10 494632 21428 4784 S 0.3 0.1 0:00.21 /usr/sbin/apache2 -k start
20130 www-data 30 10 494632 21412 4780 S 0.3 0.1 0:00.16 /usr/sbin/apache2 -k start
32716 root 30 10 491984 33296 17080 S 0.3 0.2 0:44.98 /usr/sbin/apache2 -k start
1 root 20 0 33324 2292 1320 S 0.0 0.0 0:17.81 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kthreadd/124021]
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [khelper/124021]
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/0]
5 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
6 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/2]
7 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/3]
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/4]
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/5]
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/6]
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/7]
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/8]
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/9]
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/1]
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/2]
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/2]
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/2]
27 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rpciod/124021/2]
28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [nfsiod/124021]
179 root 20 0 19424 576 488 S 0.0 0.0 0:00.42 upstart-udev-bridge --daemon
198 root 20 0 49212 700 696 S 0.0 0.0 0:00.05 /lib/systemd/systemd-udevd --daemon
214 root 20 0 316656 2652 2412 S 0.0 0.0 0:07.26 smbd -F
268 root 20 0 308704 576 484 S 0.0 0.0 0:00.00 smbd -F
271 root 20 0 316656 796 592 S 0.0 0.0 0:06.13 smbd -F
Wenn es das nächste mal hängt, mache ich ss -pan | fgrep ':3306 ' - den Befehl konnte ich nur erst wieder nachsehen, als der Server wieder lief ...
EDIT
Während der nächsten Downtime abgefragt:
root@lvps92-51-133-22:~# ss -pan | fgrep ':3306 '
tcp LISTEN 0 0 *:3306 *:* users:(("mysqld",604,10))
tcp LISTEN 0 0 *:3306 *:* users:(("mysqld",604,10))
Oh Mann, Maja. Ich will dich einfach mal eben knuddeln, dass du neben dem NaNo jetzt auch noch das hakelige Forum an der Backe hast. Danke, dass du dich darum kümmerst. :knuddel: Und danke an alle, die helfen.
Zitat von: Maja am 03. November 2016, 22:18:59
%Cpu(s): 24.0 us, 2.5 sy, 1.0 ni, 72.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
604 mysql 20 0 2302188 98492 5244 S 102.0 0.6 726:37.88 /usr/sbin/mysqld
Du hast den "M"-vServer mit 4 vCores? Das würde dann erklären, warum MySQL (auf 1 vCore) voll ausgelastet ist, der Server (mit 4 vCores) aber nur zu 1/4
MySQL muss da optimiert werden. Hast Du Dir die Ausgaben von dem Skript mal angeschaut, den ich Dir zugesandt habe?
Die Einstellungen müssten dann in /etc/mysql/my.cnf gemacht und MySQL neu gestartet werden.
Was Du auch noch machen kannst, wäre die möglichen Locks 'rauszunehmen bzw. die Aufgaben besser zu verteilen - jeweils im [mysqld] Abschnitt
max_connections = 500
innodb_flush_log_at_trx_commit = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_thread_concurrency = 8
Es kann einfach sein, dass das Forum nun an die Grenzen der klassischen Default-Einstellungen stößt - und dann das Forum schlicht auf die Datenbank warten muss. Dann müssen die Buffer und Entkopplungen optimiert/vergrößert werden.
Zitat von: Volker am 04. November 2016, 00:00:32
Du hast den "M"-vServer mit 4 vCores? Das würde dann erklären, warum MySQL (auf 1 vCore) voll ausgelastet ist, der Server (mit 4 vCores) aber nur zu 1/4
Ich habe den "Expert"-Server, ein Modell, das es so nicht mehr gibt, seit sie die Servermodelle umgestellt haben. Sollen sein 8 GB RAM, 4 vCores (CPU-Kerne à 1.500 Gigaherz). Das kann also hinkommen mit deiner Einschätzung.
ZitatMySQL muss da optimiert werden. Hast Du Dir die Ausgaben von dem Skript mal angeschaut, den ich Dir zugesandt habe?
Die Einstellungen müssten dann in /etc/mysql/my.cnf gemacht und MySQL neu gestartet werden.
Bei mir ist irgendwie nichts angekommen, kannst du mir das nochmal schicken?
Ich überlege allerdings, nach dem Nano auf das nächstgrößere Servermodell umzuziehen, weil ich das Gefühl habe, wir könnten auch ein bisschen mehr Performance durchaus verkraften.
https://code.launchpad.net/mysql-tuning-primer (https://code.launchpad.net/mysql-tuning-primer) oder auch (etwas rauhbeiniger, aber aktueller) http://mysqltuner.com/ (http://mysqltuner.com/)
Zitat von: Pandorah am 03. November 2016, 22:36:09
Oh Mann, Maja. Ich will dich einfach mal eben knuddeln, dass du neben dem NaNo jetzt auch noch das hakelige Forum an der Backe hast. Danke, dass du dich darum kümmerst. :knuddel: Und danke an alle, die helfen.
Da häng ich mich einfach mal mit dran. Danke... :knuddel:
Dito, es ist absolut bemerkenswert, was du hier für die schreibende Zunft leistest. Danke dafür.
Zitat von: Volker am 04. November 2016, 00:57:19
https://code.launchpad.net/mysql-tuning-primer (https://code.launchpad.net/mysql-tuning-primer) oder auch (etwas rauhbeiniger, aber aktueller) http://mysqltuner.com/ (http://mysqltuner.com/)
Oder etwas näher, falls nicht schon ausgeführt: Simple Machines Forum Software hat ein eigenes Auswertungstool für sowas: status.php. Entweder schon dabei oder von deren Seite zu erhalten. Wenn etwas von der Konfiguration her sehr aus dem Rahmen fällt, zeigt es das an. Genauso, wenn es unnatürlich viele offene Verbindungen hat und ähnliche Informationen oder wenn einzelne Teile auffällig oft aufgerufen werden (wie es bei einem defekten Script der Fall wäre).
Das kann eventuell einen Blick wert sein. Aber das volle Ergebnis davon würde ich nicht öffentlich machen, weil es Details zur SQL Konfiguration erhält. Zusammen mit den anderen Angaben im Thread wird das Forum langsam angreifbar.
Von den Ressourcen glaube ich weniger, dass dieses Forum an die natürlichen Grenzen kommt. Es hat zwar viele Benutzer, aber so Foren sind für tausende ausgelegt, nicht für dutzende. Vor allem wäre es im Fall einer Ressourcenauslastung ein gradueller Zuwachs, welcher mit der Zahl der Benutzer skaliert. Das ist hier nicht der Fall, hier sind es unnatürliche Spikes in unregelmäßigen Abständen.
Ui, hübsch. Gibt zwar nicht alles, aber schon mal ein paar Hinweise.
Was ich bei meinem kleinen Forum und im Vergleich zum TiZi gesehen habe (beide liefen mit der Standard-Konfig in /etc/mysql/my.cnf):
kannst Du die Caches deutlich aufblasen? Hier jeweils das 10fache der Default-Einstellungen:
#
# * Query Cache Configuration
#
query_cache_limit = 10M
query_cache_size = 160M
max_heap_table_size = 640M
tmp_table_size = 640M
Und das Erhöhen der MaxClients nicht vergessen!
Zitat von: Maja am 03. November 2016, 21:55:52
Ich denke, damit sollte die Unschuld unserer Counter erwiesen sein. Ich habe die Signaturen jetzt wieder eingeschaltet.
Na da bin ich ja froh. Wobei die nur eine SQLite-Datenbank nutzen, um die Wortzahl zu cachen. Ich denke mal im Notfall könnte man das Script noch so erweitern, dass es die Bilder zwischenspeichert und einfach nur lädt, wenn es aufgerufen wird. (Dabei wird nicht sehr viel bei der Erstellung gemacht...)
Kann man die Festplattenaktivität zu diesem Zeitpunkt auch bestimmen? Wenn da viel los ist, oder vielleicht ein Schaden vorliegt, könnte es auch zu längeren Zeiten kommen (letzteres sofern ein RAID-System vorliegt).
Da sich der Thread beruhigt hat:
- Ist das Problem gelöst?
- Wurde etwas an den Konfigs geändert? Wenn ja: was?
Just gerade eben:
Zitat30.449 Sekunden mit 14 Abfragen
Zumindest aber nicht so wahnsinnig lang wie bei manch anderen hier schon.
Bei mir hat es eben 153 Sekunden gedauert.
Ich habe nicht auf die Sekunden geschaut (mach ich das nächste Mal, wenn ich dran denke), aber es war über eine Minute.
Bei mir hat es gestern und vorgestern andauernd geschneckt, nachdem es endlich geladen hatte, habe ich nicht mehr auf die Sekunden geachtet. Aber es hat ziemlich gedauert. :-\
Erst einmal ein dickes Danke an Maja, dass sie sich neben dem NaNo auch noch hiermit herum schlägt :knuddel:. Damit vermelde ich dann auch, dass ich gestern und überhaupt am Wochenende starke Verbindungsprobleme hatte und teilweise so lange warten musste, dass der Browser die Füße hoch gelegt hat und meinte, ich soll mir die Seite halt selbst malen. Heute früh das gleiche Spiel, aber seit etwa sieben Uhr läuft es bei mir sehr stabil :)
Als ich gestern eine Suche ausgeführt habe, haben bei mir auch die anderen Seiten bestimmt über eine Minute nicht geladen.
Hier hat's gerade mal wieder ziemlich geschneckt.
Dito. Aber jetzt läuft es wieder.
ZitatSeite erstellt in 502.378 Sekunden mit 15 Abfragen.
Unread-Themen aktualisiert.
Hier auch. Es dauerte 2x nacheinander je mindestens 5 Minuten, bis irgendwas passierte.
Ich hatte ebenfalls gerade mehrfach lange Ladehemmungen... :gähn:
Hier jetzt auch wieder. Fast zwei Minuten, dann "Webseite nicht erreichbar". Nach neuladen war sie dann da.
Bei mir war es ebenfalls gerade extrem:
ZitatSeite erstellt in 812.877 Sekunden mit 26 Abfragen.
Ja, hier war das auch: Seite nicht erreichbar.
Gerade hatte ich beim Laden der ungelesene Beiträge 120.58 Sekunden mit 14 Abfragen.
Gestern Abend dauerte es manchmal auch arg lange oder meldete mir, dass die Seite nicht erreichbar ist – wobei ich da mit mobilem Netz in der Bahn unterwegs war und es auch daran gelegen haben könnte :-\
Gott sei Dank, bei mir lief alles wie gewohnt.
Grüßle
Leon
Gerade wieder: Seite nicht erreichbar, dann doch wieder.
Ich habe auch immer wieder Probleme, weil die Seite ewig braucht, bevor sie sich aufbaut. :seufz:
Bei mir gerade:
Seite erstellt in 34.717 Sekunden mit 14 Abfragen.
Ich hake mich mal mit ein, so'n bisschen verstehe ich ja auch was von der Technik ;)
Zu allererst fällt natürlich die enorme CPU-Last auf, die das MySQL verursacht. Ich bin zwar tendenziell eher Programmierer als Netzwerkadmin, aber wenn eine so hohe Last verursacht wird, gehe ich mal davon aus, dass das Loadbalancing nicht vernünftig funktioniert oder falsch bzw. gar nicht konfiguriert ist.
@Maja: Weißt du, ob du da einen Cluster an Datenbanken hast oder ob das tatsächlich nur eine einzige ist, auf die alle Anfragen losgeballert werden? Das würde nämlich auch die langen Ladezeiten bei den Suchen erklären.
Auf dem Apache scheint ja alles in Ordnung zu sein, von daher kann man die Anwendung selbst auf jeden Fall schon mal ausschließen.
Für mich sieht es im Augenblick schlichtweg so aus, dass die Datenbank einfach an ihre Grenzen stößt, da ich vermute, dass die Suchindizes nicht optimal sind und er daher einfach bei jeder Anfrage die Datenbank so lange durchwühlt, bis er das Ergebnis gefunden hat. Das betrifft dann natürlich auch die normalen Inhalte des Zirkels, da diese genauso abgefragt werden. Und man muss ehrlich sein: So wenige Inhalte haben wir hier wirklich nicht :D
Edit: Und wenn HostEurope nicht so zuverlässig ist bzw. sich kein Mensch meldet, empfehle ich dir einen Umzug zu Strato. Die sind etwas günstiger und haben bei allen Datenbanken standardmäßig SSDs (sau schnelle Festplatten) verbaut. Tut halt dann einmal weh, weil du die Domain umziehen musst, aber danach wirds schön. Ich selbst war lange Zeit Strato-Kunde und auch mit dem Service echt zufrieden.
Nur zur Info, was der Spaß kosten würde: https://www.strato.de/hosting/ (https://www.strato.de/hosting/)
Zitat von: Big Kahuna am 08. November 2016, 21:10:19
Weißt du, ob du da einen Cluster an Datenbanken hast oder ob das tatsächlich nur eine einzige ist, auf die alle Anfragen losgeballert werden?
Das ist eine einzelne, dediziert betriebene MySQL-Datenbank auf einem Root-vServer, auf dem auch der Apache läuft. Ich vermute mal, dass die den gut überbucht haben.
Zitat von: Big Kahuna am 08. November 2016, 21:10:19
Edit: Und wenn HostEurope nicht so zuverlässig ist bzw. sich kein Mensch meldet, empfehle ich dir einen Umzug zu Strato. Die sind etwas günstiger und haben bei allen Datenbanken standardmäßig SSDs (sau schnelle Festplatten) verbaut.
Ohauerha - das kann ich gar nicht bestätigen. Die haben ihre vServer nicht wirklich im Griff: alle paar Wochen grätscht denen der Host weg auf dem die vServer laufen. Und nur in 1/3 der Fälle merken die das selber. Und in allen in denen ich die Kunden-Technikhotline anrufe, dann werde ich vertröstet und die müssten erst ein Ticket ins Rechenzentrum aufmachen. Dann kommen über die Folgewoche ca. alle 2 Tage Nachrichten, dass sie es aufgrund des ach so akuten Stresses sich akut gerade um meinen gemeldeten und vom Helpdesk verifizierten Totalausfall nicht 'drum kümmern können. Und dann nach so 1-2 Wochen stellen sie fest, dass doch alles okay aussieht (der Server kommt meist so nach 10-120 Minuten wieder).
Nicht angekündigte Reboots sind ähnlich häufig. Auch nachträglich gibt es keine Info - erst recht nicht von denen selber. Aber auch nicht auf Nachfrage, weshalb da etwas rebootet wurde. Die Anregung, dann zumindest Bescheid zu geben (um dann z.B. Funktionstests des Servers machen zu können oder noch Services nachzustarten) sind zwar auf- aber nicht angenommen worden.
Ich hatte jetzt 2 vServer auf unterschiedlichen Hosts in Betreuung. Beide sind immer wieder sporadisch am Stottern. Gerade Filesystem-Access tritt immer wieder massiv auf die Bremse. So mehrere Sekunden lange Hänger über mehrere Stunden. Typisches Phänomen wenn Virtuzzo massiv überbucht wird. Wenn man richtig und fundiert meckert, dann wird man auf einen anderen Host geschoben, der nicht ganz so überbucht ist. Aber erst dann - und man muss den Server neu aufsetzen.
Strato ist meiner Erfahrung nach von den Features her in den jeweiligen Preisklassen eher unten denn Mittelfeld, hinsichtlich Überbuchung/Unzuverlässigkeit leider Marktführer - und besonders bitter: von Betrieb, Administration und technischer Kundenbetreuung her kenne ich aktuell leider mit Abstand nichts schlechteres am Markt.
:nöö:
Ein vServer dort ist bereits gekündigt und wird abgeschaltet. Für den anderen bereite ich die Migration gerade vor. Good Riddance.
Bei OVH (und deren Billigmarken Kimsufi / Isgenug) hatte ich Hardware - zwar sonst kein Support, aber Probleme haben die immer selber im Monitoring gesehen und die Behebung selber gestartet bevor ich auch nur anrufen konnte - dabei kam relativ okay jemanden ans Telefon und das dann in kompetent ("Kollege ist gerade im RZ und tauscht an Ihrem Server die Festplatte").
Bei Hetzner (auch Hardware) habe ich ebenfalls nur gute Erfahrung. Sehr kompetenter Support schnell am Telefon. Wartungszeiten werden angekündigt, wenn auch nur der Hauch einer Gefahr einer Beeinträchtigung besteht.
Ultravps hostet vServer auf Hetzner-Hardware, ist eine sehr kleine Bude mit sehr kleinen vServern für extrem kleines Geld (mein vServer kostet da noch 2,-/Monat) - und hat direkten Admin-Support gefühlt 24/7.
Netcup hat ebenfalls billige vServer, ist aber ein wenig größer und die Server immer mal wieder unter Last. Also nichts für größere Ansprüche (zumindest nicht bei den kleinen vServern). Der Support ist okay, passt.
Bei anderen Anbietern habe ich keine aktuellen Erfahrungen. Web-Hostingpakete habe ich auch schon seit Jahren nicht mehr. Immer nur (v)Server - da kann aber muss man auch alles selber machen.
Zitat von: Volker am 09. November 2016, 00:06:54
Ohauerha - das kann ich gar nicht bestätigen. Die haben ihre vServer nicht wirklich im Griff: alle paar Wochen grätscht denen der Host weg auf dem die vServer laufen. Und nur in 1/3 der Fälle merken die das selber. Und in allen in denen ich die Kunden-Technikhotline anrufe, dann werde ich vertröstet und die müssten erst ein Ticket ins Rechenzentrum aufmachen. Dann kommen über die Folgewoche ca. alle 2 Tage Nachrichten, dass sie es aufgrund des ach so akuten Stresses sich akut gerade um meinen gemeldeten und vom Helpdesk verifizierten Totalausfall nicht 'drum kümmern können. Und dann nach so 1-2 Wochen stellen sie fest, dass doch alles okay aussieht (der Server kommt meist so nach 10-120 Minuten wieder).
Nicht angekündigte Reboots sind ähnlich häufig. Auch nachträglich gibt es keine Info - erst recht nicht von denen selber. Aber auch nicht auf Nachfrage, weshalb da etwas rebootet wurde. Die Anregung, dann zumindest Bescheid zu geben (um dann z.B. Funktionstests des Servers machen zu können oder noch Services nachzustarten) sind zwar auf- aber nicht angenommen worden.
Ich hatte jetzt 2 vServer auf unterschiedlichen Hosts in Betreuung. Beide sind immer wieder sporadisch am Stottern. Gerade Filesystem-Access tritt immer wieder massiv auf die Bremse. So mehrere Sekunden lange Hänger über mehrere Stunden. Typisches Phänomen wenn Virtuzzo massiv überbucht wird. Wenn man richtig und fundiert meckert, dann wird man auf einen anderen Host geschoben, der nicht ganz so überbucht ist. Aber erst dann - und man muss den Server neu aufsetzen.
Strato ist meiner Erfahrung nach von den Features her in den jeweiligen Preisklassen eher unten denn Mittelfeld, hinsichtlich Überbuchung/Unzuverlässigkeit leider Marktführer - und besonders bitter: von Betrieb, Administration und technischer Kundenbetreuung her kenne ich aktuell leider mit Abstand nichts schlechteres am Markt.
:nöö:
Okay, dann haben wir da wohl gänzlich unterschiedliche Erfahrungen gemacht ???
Aber wenn es tatsächlich nur eine einzelne Datenbank ist, ist das Problem naheliegend. Da müsste man evtl. mal noch 1-2 neue Knoten dazu schalten.
Zitat von: Volker am 09. November 2016, 00:06:54
Bei Hetzner (auch Hardware) habe ich ebenfalls nur gute Erfahrung. Sehr kompetenter Support schnell am Telefon. Wartungszeiten werden angekündigt, wenn auch nur der Hauch einer Gefahr einer Beeinträchtigung besteht.
Kann ich zustimmen. Wir haben alles von uns dort liegen und sind seit mehreren Jahren sehr zufrieden.
Ich würde auf die Suche tippen. Habe gerade vorhin versucht einen Begriff global zu suchen und danach war die Seite komplett tot. Eine Minute später hat es wieder funktioniert. Checkt mal die Auslastung bei einem simplen Suchbegriff quer über alle Foren.
Okay, das von Prometheus kann ich so unterschreiben. Hab mit zwei Tabs gearbeitet, in einem davon hatte ich geschaut ob ich irgendwo bereits eins meiner Bücher erwähnt hatte (ich bin vergesslich), im anderen hatte ich diesen Thread auf.
Suche ausgelöst, dann hier im vorher geladenen Thread die Beiträge gelesen und tatsächlich, das Forum war gerade weg.
/Edit:
Verdacht: Wir haben ja auch das Problem, dass bei besonders stark verschachtelten Unterforen manchmal die Pfade abgeschnitten werden. Eventuell hängt sich eine globale Suche daran auf?
So, es sieht aus, als hätte Hosteurope das Problem endlich in den Griff bekommen. Im KIS melden sie noch, was hier schon längst spekuliert wurde und ja auch meine Vermutung war: Dass nicht mein Virtual Server die Probleme hatte, sondern das ganze Wirtssystem befallen war und einfach zu wenig Ressourcen für die einzelnen Systeme übrig war:
ZitatDerzeit kommt es auf dem Wirtssystem, auf dem Ihr Virtual Server betrieben wird, zu einer ungewöhnlich hohen Last, so dass die Arbeitsgeschwindigkeit geringer als erwartet sein kann. Wir analysieren noch die Ursachen dessen, was leider längere Zeit benötigt. In der Zwischenzeit arbeiten wir daran, eine möglichst hohe Performance sicher zu stellen.
Sie vermelden auch einen Ausfall von 09.11.2016 00:00 bis 10.11.2016 23:59, und der Server war gerade kurzfristig komplett offline. Nachdem er aber gerade wieder gestartet wurde, sehenem meine Ressourcen endlich wieder so aus, wie sie sollten - mit einer CPU-Last deutlich unter zehn Prozent. Ich hänge mal zwei Graphiken an, wie die Auslastung durch Apache und MySQL seitdem aussieht.
Der Kundendienst ist also tatsächlich an der Sache drangeblieben. Nur an ihrer Kommunikation müssen sie echt arbeiten. Ich muss jetzt sehen, ob ich auf die Dauer bei Hosteurope bleiben will. Ich bin mit dem Tintenzirkel seit 2003 dort und eigentlich immer sehr zufrieden gewesen. Allerdings überlege ich, auf einen leistungsfähigeren Server aufzurüsten.
[Dateianhang durch Administrator gelöscht]
Oh, wäre das fein, wenn sie wirklich die Wurzel besiegt haben! Bislang finde ich das Forum turboflott. :vibes:
Danke fürs Dranbleiben und Durchbeißen, Maja! (Und die Info über die Wartungsarbeiten via FB.)
Ich weiß nicht, ob das schon besorgniserregend lang ist, aber ich hatte eben 45.085 Sekunden mit 14 Abfragen, was mir lang vorkam. Irgendwann heute Mittag hatte ich das schonmal so ähnlich, da habe ich dann allerdings nicht auf die Sekundenzahl geachtet.
Ich hatte heute drei Ressourcenalarmmails, und die CPU-Werte sind wieder da, wo sie vor zwei Wochen waren. Kundendienst ist informiert, ich hoffe, die bekommen das jetzt schneller (und dauerhaft!) in den Griff, sonst muss ich wirklich umziehen.
Dumme Frage... aber hast du immer noch das gleiche Serverpaket wie 2003? Sind ja sowieso nur virtuelle Server.
Ich hatte mir 2009 ein Paket geholt und wollte bei mir 2014 ein Nachfolgesystem aufziehen. Bin dann drauf gekommen, dass ein "neuer Server" mittlerweile für den gleichen Preis die vierfachen Ressourcen geboten hat. Ich hab den dann einfach virtuell upgraden lassen und nicht mehr bezahlt.
Hier hat's gerade mal wieder erbärmlich geschneckt.
Zitat von: Prometheus am 09. November 2016, 20:27:24
Ich würde auf die Suche tippen. Habe gerade vorhin versucht einen Begriff global zu suchen und danach war die Seite komplett tot. Eine Minute später hat es wieder funktioniert. Checkt mal die Auslastung bei einem simplen Suchbegriff quer über alle Foren.
Das kann man reproduzieren. Eben diese Seite in 0.178 Sekunden aufgebaut. Dann suche gestartet (die gerade mal 13 Ergebnisse zurücklieferte), die Suche brauchte 208 Sekunden und ein kurz danach gestarteter Reloaf dieser Seite 179.944 Sekunden mit 21 Abfragen - und Aryanas Meldung fiel auch in diesen Zeitraum.
Würde mich sehr wundern, wenn es da keinen Zusammenhang gibt. Ich würde an deiner Stelle die Suche mal für 2-3 Tage abklemmen und schauen was passiert.
WARUM die Suche das ganze Forum lahmlegt, ist dann ne andere Frage. Da sind vermutlich einige Indizes im Eimer oder die Such-Abfragen der Forensoftware sind einfach schlecht bzw nicht für so eine Datenmenge ausgelegt.
Nachtrag aus dem SMF-Manual:
ZitatIf you are going to enable search, and are not or cannot use Sphinx, use a Large Custom Index
SMF's custom index works by taking a hash of every available word, and then building an index of which words point to which messages. 'Small' means this is a 16 bit hash, 'Moderate' is 24 and 'Large' is a 32 bit hash. 'Large' is thus only two bytes larger per record than small is, plus an additional number of records based on the average number of unique words per post you have - which is not going to be a significant increase. The speed improvement you get for the additional ~40% space usage is well worth it.
Hast du einen Search-Index und steht der auf "Large"?
Zitat von: Prometheus am 16. November 2016, 09:01:42
Dumme Frage... aber hast du immer noch das gleiche Serverpaket wie 2003? Sind ja sowieso nur virtuelle Server.
Ich hatte mir 2009 ein Paket geholt und wollte bei mir 2014 ein Nachfolgesystem aufziehen. Bin dann drauf gekommen, dass ein "neuer Server" mittlerweile für den gleichen Preis die vierfachen Ressourcen geboten hat. Ich hab den dann einfach virtuell upgraden lassen und nicht mehr bezahlt.
Nein, 2003 hatte ich nur ein hundsnormales Webpack. Der Tintenzirkel ist gewachsen und gewachsen und ich habe entsprechen aufgesrüstet. 2011 habe ich den ersten (kleineren) Virtual Server bekommen und bin dann 2014 auf den aktuellen Server gewachselt, mit einem damals aktuellen Angebot. Ich überlege im Moment, nochmal aufzurüsten, weil ich für etwas mehr Geld mal wieder deutlich mehr Leistung bekomme, entsprechend den Entwicklungen am Hardwaremarkt. Früher waren Speicherplatz und Traffic ein Thema, heute spricht da ja keiner mehr von (mit Platz kann ich euch totschmeißen), aber RAM und CPU sind halt so eine Sache.
Zitat von: Kaeptn am 16. November 2016, 09:55:24
Zitat von: Prometheus am 09. November 2016, 20:27:24
Ich würde auf die Suche tippen. Habe gerade vorhin versucht einen Begriff global zu suchen und danach war die Seite komplett tot. Eine Minute später hat es wieder funktioniert. Checkt mal die Auslastung bei einem simplen Suchbegriff quer über alle Foren.
Das kann man reproduzieren. Eben diese Seite in 0.178 Sekunden aufgebaut. Dann suche gestartet (die gerade mal 13 Ergebnisse zurücklieferte), die Suche brauchte 208 Sekunden und ein kurz danach gestarteter Reloaf dieser Seite 179.944 Sekunden mit 21 Abfragen - und Aryanas Meldung fiel auch in diesen Zeitraum.
Würde mich sehr wundern, wenn es da keinen Zusammenhang gibt. Ich würde an deiner Stelle die Suche mal für 2-3 Tage abklemmen und schauen was passiert.
WARUM die Suche das ganze Forum lahmlegt, ist dann ne andere Frage. Da sind vermutlich einige Indizes im Eimer oder die Such-Abfragen der Forensoftware sind einfach schlecht bzw nicht für so eine Datenmenge ausgelegt.
Nachtrag aus dem SMF-Manual:
ZitatIf you are going to enable search, and are not or cannot use Sphinx, use a Large Custom Index
SMF's custom index works by taking a hash of every available word, and then building an index of which words point to which messages. 'Small' means this is a 16 bit hash, 'Moderate' is 24 and 'Large' is a 32 bit hash. 'Large' is thus only two bytes larger per record than small is, plus an additional number of records based on the average number of unique words per post you have - which is not going to be a significant increase. The speed improvement you get for the additional ~40% space usage is well worth it.
Hast du einen Search-Index und steht der auf "Large"?
Die Suche legt den Server nicht lahm. Ich kann anhand der Serverdaten sehen, dass schlagartig die CPU-Aufnahme sämtlicher Programme hochschnellt und dann da auch bleibt, und das, ohne dass sich etwas am Forum verändert hatte. Die Suche hat immer schon lang gedauert, und ich habe mich jetzt nach dem Suchindex umgeschaut - ich hatte bislang noch keinen, und ich lege jetzt einen benutzerdefinierten Index an (den allgemeinen kann ich nicht nehmen, weil wir keine Längenbegrenzung für Beiträge haben). Ich hoffe, dass sich damit die Suche beschleunigen lässt.
Mit dem aktuellen Problem hat das aber nichts zu tun. Der HE-Kundendienst hat heute, wieder, am Server rumgeschraubt, und die Werte sind wieder alle im normalen Bereich. Letztes Mal haben sie mir geschrieben, es wäre ein Hardwareproblem gewesen, allerdings sind die Lags ja nach einer Woche wieder aufgetreten. Ich hoffe, dass die Lösung diesmal dauerhaft ist.
ZitatIch kann anhand der Serverdaten sehen, dass schlagartig die CPU-Aufnahme sämtlicher Programme hochschnellt und dann da auch bleibt, und das, ohne dass sich etwas am Forum verändert hatte.
Verstehe nicht ganz, was du mit "verändern" meinst. Nur nochmal zur Klarstellung mein Versuchsaufbau:
Wenn ich mehrere Tintenzirkel-Browsertabs öffne und in einem eine Suche starte und in allen anderen beliebige Beiträge anzuzeigen versuche, hängen diese Tabs so lange, bis die Suche beendet ist . Das gilt auch, wenn ich den Tintenzirkel in einem zweiten Browser öffne und dort einen Beitrag lade, hängt also nicht mit der Browser-Session zusammen.
Übirgens: Die Suche ist deutlich schneller geworden, immer noch 25 Sekunden aber gegenüber 208 sind das ja Welten.
Zitat von: Kaeptn am 16. November 2016, 19:38:56
Verstehe nicht ganz, was du mit "verändern" meinst.
Ich meinte, dass das Problem schlagartig auftritt, unabhängig davon, was gerade im Forum passiert, und ohne dass ich Änderungen an Forensoftware oder Datenbank vorgenommen hätte. Und auch, ohne dass jemand die Forensuche bemüht hätte - das war einer meiner ersten Verdächtigen, eben weil ich weiß, dass sie temporär das System ausbremsen kann. Aber ich habe um drei Uhr in der Nacht allein, ohne Gäste oder auch nur Bots, in einem laggenden Forum gesessen, dessen Seiten minutenlang zum Reinladen brauchten. Und, wenn die Suche schuld wäre, hätte sich das Problem über einen längeren Zeitraum aufgebaut, statt von einem Tag auf den anderen einzusetzen und umgekehrt auch von einem Moment auf den anderen wieder zu verschwinden, nachdem die HE-Techniker das System neu gestartet hatten.
Zitat von: Kaeptn am 16. November 2016, 19:38:56
Übirgens: Die Suche ist deutlich schneller geworden, immer noch 25 Sekunden aber gegenüber 208 sind das ja Welten.
Am Search Index kann das nicht liegen. Der ist nämlich noch in Arbeit und steht gerade bei 56%, das wird noch ein Weilchen dauern, ehe der für Suchanfragen genutzt werden kann. Ich hoffe aber, dass danach die Suche wirklich schneller ablaufen wird.
So, ab jetzt kann über den neuen Suchindex gesucht werden. Er hat anderthalb GB, und das Forum hat den ganzen Tag dran gerechnet, aber dafür fluppen die Suchabfragen jetzt nur so - "Seite erstellt in 0.052 Sekunden mit 26 Abfragen." Danke
@Kaeptn für den Tipp!
Wow, das ist ja wirklich super schnell! Vielen Dank! :vibes:
Zitat von: Maja am 16. November 2016, 20:05:27
Und auch, ohne dass jemand die Forensuche bemüht hätte - das war einer meiner ersten Verdächtigen, eben weil ich weiß, dass sie temporär das System ausbremsen kann. Aber ich habe um drei Uhr in der Nacht allein, ohne Gäste oder auch nur Bots, in einem laggenden Forum gesessen, dessen Seiten minutenlang zum Reinladen brauchten.
Ok, das ist dann eindeutig was anderes. Na immerhin fluppen die Suchen nun, gern geschehen.
Ich wusste echt nicht, dass der Suchindex existiert. Zehn Jahre SMF, und man learnt immer noch was Neues dazu.
Zitat von: Maja am 17. November 2016, 14:46:25
Ich wusste echt nicht, dass der Suchindex existiert. Zehn Jahre SMF, und man learnt immer noch was Neues dazu.
Das hab ich aber auch schon ziemlich am Anfang vom Thread (http://forum.tintenzirkel.de/index.php?topic=20175.msg917926#msg917926) gemeint ::) Vermutlich hab ich mich nicht klar genug ausgedrückt. :hmmm:
Zitat von: Eluin am 17. November 2016, 16:44:13
Zitat von: Maja am 17. November 2016, 14:46:25
Ich wusste echt nicht, dass der Suchindex existiert. Zehn Jahre SMF, und man learnt immer noch was Neues dazu.
Das hab ich aber auch schon ziemlich am Anfang vom Thread (http://forum.tintenzirkel.de/index.php?topic=20175.msg917926#msg917926) gemeint ::) Vermutlich hab ich mich nicht klar genug ausgedrückt. :hmmm:
Manchmal muss man mir was mehrmals sagen, bis es ankommt. ;)
Kein Problem ;D Ich habe mich auch nicht sonderlich klar ausgedrückt ::) Bin froh, dass es jetzt läuft :jau:
In den frühen Morgenstunden (jetzt und etwa seit einer Viertelstunde) traten bei mir leider wieder Ladeprobleme auf und es dauerte lange, bis die Seite hoch lud bzw. konnte teilweise gar nicht hoch geladen werden.
Zitat von: Blaurot am 09. Januar 2017, 05:34:03
In den frühen Morgenstunden (jetzt und etwa seit einer Viertelstunde) traten bei mir leider wieder Ladeprobleme auf und es dauerte lange, bis die Seite hoch lud bzw. konnte teilweise gar nicht hoch geladen werden.
Ich kenne das schon lange. Es ist jeden Tag zwischen ca. 05:15 und 05:30 so. Ich bekomme das täglich mit, weil ich zu der Uhrzeit immer Feierabend mache und immer noch kurz online gehe, weil ich es immer wieder vergesse. Da es wirklich jeden Tag so ist, bin ich von einem täglichen Update des Servers oder sonstigem mir fremden Technik-Gednös ausgegangen. ;)
Ja, ich meine, das auch schon mal gelesen zu haben. Ich weiß zwar auch nicht, wie der Vorgang heißt, aber (lasst mich lügen) HostEurope macht in der Zeit irgendwas, was zur Verlangsamung führt.
Backup? Snapshot?
Backup. Jeden Morgen um fünf. Das ist die Zeit, wo meistens am wenigsten los ist und der Admin ins Bett gehen muss, und der Ausfall des Forums wegen des Backups ist imemr ein guter Grund, Rechner und mich runterzufahren.