mikrocontroller.net

Forum: PC Hard- und Software vServer-Kernellog läuft ständig voll


Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat jemand Ahnung von vServern? Bei mir läuft ständig /var/log/kern.log 
voll mit Dingen, die ich zum ersten Mal sehe. Alle paar Minuten kommen 
neue kryptische Zeilen dazu. Wie gehe ich systematisch vor, um das 
Problem zu finden?
Dec 30 13:40:59 myserver kernel: [4193690.744629]  do_page_fault+0x22/0x30
Dec 30 13:40:59 myserver kernel: [4193690.746940] RAX: 0000000000000001 RBX: 000000000306b280 RCX: 00007fffd83b4770
Dec 30 13:40:59 myserver kernel: [4193690.749019] R13: 0000000003071100 R14: 0000000000000001 R15: 0000000000000117
Dec 30 13:40:59 myserver kernel: [4193690.756363] [ 8355]     0  8355    46158      237      26       4       74             0 systemd
Dec 30 13:40:59 myserver kernel: [4193690.757535] [ 8691]     0  8691    11908       37      27       3       95             0 rpcbind
Dec 30 13:41:00 myserver kernel: [4193690.761724] [ 8758]     0  8758    22430        1      43       3      238             0 saslauthd
Dec 30 13:41:00 myserver kernel: [4193690.766216] [ 9308]     0  9308   296885     4969      71      21     1028             0 node /root/.pm2
Dec 30 13:41:00 myserver kernel: [4193690.767538] [ 5301]     0  5301     8820     1170      20       3        0             0 systemd-journal
Dec 30 13:41:00 myserver kernel: [4193690.769919] [11155]     0 11155   247266     4001      57      17        0             0 npm
Dec 30 13:41:04 myserver kernel: [4193694.994678] CPU: 5 PID: 12495 Comm: mysqld Tainted: G           O    4.13.4-1-pve #1
Dec 30 13:41:04 myserver kernel: [4193694.997200]  dump_header+0x97/0x225
Dec 30 13:41:04 myserver kernel: [4193694.999712]  mem_cgroup_out_of_memory+0x4b/0x80
Dec 30 13:41:04 myserver kernel: [4193695.002221]  mm_fault_error+0x8f/0x190
Dec 30 13:41:04 myserver kernel: [4193695.004667] RIP: 0033:0x7f975a74eab8
Dec 30 13:41:04 myserver kernel: [4193695.008076] R13: 00007f9757b65040 R14: 0000000000000020 R15: 0000000001e238b0
Dec 30 13:41:04 myserver kernel: [4193695.025057] [12455]     0 12455    16381      179      36       3        0         -1000 sshd
Dec 30 13:41:25 myserver kernel: [4193715.832183] R13: 00007f974f2cdde0 R14: 00007f9752259000 R15: 0000000000000100
Dec 30 13:43:21 myserver kernel: [4193831.923744] CPU: 5 PID: 8355 Comm: systemd Tainted: G           O    4.13.4-1-pve #1
Dec 30 13:43:21 myserver kernel: [4193831.925607]  dump_stack+0x63/0x8b
Dec 30 13:43:21 myserver kernel: [4193831.927462]  oom_kill_process+0x208/0x410
Dec 30 13:43:21 myserver kernel: [4193831.929317]  mem_cgroup_oom_synchronize+0x31e/0x340
Dec 30 13:43:21 myserver kernel: [4193831.931158]  mm_fault_error+0x8f/0x190
Dec 30 13:43:21 myserver kernel: [4193831.932971]  page_fault+0x28/0x30
Dec 30 13:43:21 myserver kernel: [4193831.934706] RAX: 0000000000000001 RBX: 000055983415c7d0 RCX: 00007f42c410b9d3
Dec 30 13:43:21 myserver kernel: [4193831.937954] memory: usage 813240kB, limit 819200kB, failcnt 1777024222
Dec 30 13:43:21 myserver kernel: [4193831.953499] [12455]     0 12455    16381      179      36       3        0         -1000 sshd
Dec 30 13:43:21 myserver kernel: [4193831.955208] [13104]     0 13104   219982     3276      51      16        0             0 npm
Dec 30 13:43:21 myserver kernel: [4193831.957502] [15127]     0 15127    14780       77      31       3        0             0 sshd
Dec 30 13:43:38 myserver kernel: [4193849.351376] kmem: usage 16144kB, limit 9007199254740988kB, failcnt 0
Dec 30 13:43:38 myserver kernel: [4193849.362629] [ 9158]     0  9158   231716     5883     106      19      312             0 PM2 v2.8.0: God
Dec 30 13:43:38 myserver kernel: [4193849.364537] [ 5301]     0  5301     8820     1174      20       3        0             0 systemd-journal
Dec 30 13:44:58 myserver kernel: [4193929.624026] Hardware name: Supermicro Super Server/X10SDV-4C-TLN2F, BIOS 1.1b 07/13/2016
Dec 30 13:44:58 myserver kernel: [4193929.625877]  dump_header+0x97/0x225
Dec 30 13:44:58 myserver kernel: [4193929.627725]  out_of_memory+0x11d/0x4c0
Dec 30 13:44:58 myserver kernel: [4193929.629565]  ? get_mem_cgroup_from_mm+0x90/0x90
Dec 30 13:44:58 myserver kernel: [4193929.631410]  __do_page_fault+0x4ad/0x4e0
Dec 30 13:44:58 myserver kernel: [4193929.633216] RIP: 0033:0x7f2844e8464a
Dec 30 13:44:58 myserver kernel: [4193929.656273] [17919]     0 17919     5949       42      14       3        0             0 mysqladmin
Dec 30 13:46:42 myserver kernel: [4194033.196932] CPU: 5 PID: 19629 Comm: npm Tainted: G           O    4.13.4-1-pve #1
Dec 30 13:46:42 myserver kernel: [4194033.200024]  ? mem_cgroup_scan_tasks+0xc4/0xf0
Dec 30 13:46:42 myserver kernel: [4194033.203111]  ? get_mem_cgroup_from_mm+0x90/0x90
Dec 30 13:46:42 myserver kernel: [4194033.206093]  page_fault+0x28/0x30
Dec 30 13:46:42 myserver kernel: [4194033.208684] RBP: 00007fff0cd42550 R08: 00000000000002e0 R09: 0000000000000000
Dec 30 13:46:42 myserver kernel: [4194033.217444] [ 8691]     0  8691    11908       37      27       3       95             0 rpcbind
Dec 30 13:46:42 myserver kernel: [4194033.218708] [ 8697]     0  8697     7242       27      20       3       43             0 cron
Dec 30 13:46:42 myserver kernel: [4194033.220118] [ 8758]     0  8758    22430        1      43       3      238             0 saslauthd
Dec 30 13:46:42 myserver kernel: [4194033.221425] [ 8809]     0  8809     3929        0      13       3       39             0 agetty
Dec 30 13:46:42 myserver kernel: [4194033.223257] [ 8876]     0  8876     3765        2      13       3       49             0 xinetd
Dec 30 13:46:42 myserver kernel: [4194033.232163] [23315]     0 23315     5872       30      14       3        0             0 sshd
Dec 30 13:46:42 myserver kernel: [4194033.233302] Memory cgroup out of memory: Kill process 16866 (node /usr/share) score 67 or sacrifice child
Dec 30 13:46:43 myserver kernel: [4194034.717393] RBP: 00007ffc4a308eb0 R08: 00007ffc4a308c20 R09: c4464a735670447b
Dec 30 13:46:43 myserver kernel: [4194034.723956] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Dec 30 13:46:43 myserver kernel: [4194034.728136] [ 8758]     0  8758    22430        1      43       3      238             0 saslauthd
Dec 30 13:46:43 myserver kernel: [4194034.730051] [ 8810]     0  8810     3929        0      13       3       39             0 agetty
Dec 30 13:46:43 myserver kernel: [4194034.733194] [10072]     0 10072   306088     7012      79      31        0             0 postmon-mta: ma
Dec 30 13:46:43 myserver kernel: [4194034.735050] [16866]     0 16866   262226    21032     127      84        0             0 node /usr/share
Dec 30 13:46:43 myserver kernel: [4194034.737369] [23555]   110 23555    16717      181      34       3        0             0 sshd

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du nutzt zu viel RAM: "Memory cgroup out of memory".

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vmstat sagt
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  3  13748 271168      0 299176    2    2  4039   175    1    1 15  7 68 10
 1  2  13748 271304      0 299176    0    0 115584   452 1688 11970  4 12 69 15
 0  0  13748 271304      0 299176    0    0 118004    92 1736 11675  3 14 78  4
 0  0  13748 271228      0 299176    0    0 103360   144 1355 11716  3  8 87  2
 0  0  13748 271192      0 299176    0    0 103988   740 1811 12945  3  9 69 19
 0  0  13748 271316      0 299176    0    0 108948   288 1276 11583  2  8 86  4
 0  1  13748 271280      0 299176    0    0 73668   800 2007 12404  1 14 66 19
 1  2  13748 271280      0 299176    0    0 103736   376 1674 13134  1 10 67 21
 0  0  13748 271276      0 299176    0    0 114488   344 1804 13530  1 11 83  5
 0  0  13748 271276      0 299176    0    0 119536    32 1305 11919  0  8 91  0
 0  3  13748 271344      0 299176    0    0 87364   344 1514 11853  1 11 81  7

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> vmstat sagt

Nix wesentliches, aber Du hast verdammt viel I/O (Lesen von Disk, bi).
Ein Buff von 0 sehe ich eigentlich nur in Out-of-memory Situationen, 
weil da der Kernel alle Puffer frei gibt.

Der Webserver kann eventuell zuviele MySQL Verbindungen aufreissen, aber 
da müsste man deutlich mehr über Deine Config wissen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Ein Buff von 0 sehe ich eigentlich nur in Out-of-memory Situationen,
> weil da der Kernel alle Puffer frei gibt.

Genau das passiert hier ja auch. Der Kernel wirft Prozesse ab, weil 
Speicher knapp. Da wär eine Prozessliste mit Speicherbelegung nützlich.

: Bearbeitet durch User
Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den bi ist mir auch schon aufgefallen. Das geht aber auch dann 
nicht weg, auch wenn ich apache2, mysqld, spamassassin, dovecot, postfix 
und amavis beende (das ist eigentlich auch alles, wofür ich den Server 
brauche).
cat /proc/meminfo
MemTotal:        1048576 kB
MemFree:          290036 kB
MemAvailable:     290036 kB
Buffers:               0 kB
Cached:           298016 kB
SwapCached:            0 kB
Active:           510308 kB
Inactive:         177788 kB
Active(anon):     303220 kB
Inactive(anon):   119400 kB
Active(file):     207088 kB
Inactive(file):    58388 kB
Unevictable:           0 kB
Mlocked:           60844 kB
SwapTotal:        524288 kB
SwapFree:         510536 kB
Dirty:              1428 kB
Writeback:             0 kB
AnonPages:       4496712 kB
Mapped:           956744 kB
Shmem:           2554352 kB
Slab:               0 kB
SReclaimable:          0 kB
SUnreclaim:            0 kB
KernelStack:       37056 kB
PageTables:       141348 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    18514580 kB
Committed_AS:   24206632 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1732304 kB
DirectMap2M:    31717376 kB
DirectMap1G:     2097152 kB
free
             total       used       free     shared    buffers     cached
Mem:       1048576     733736     314840          0          0     290288
-/+ buffers/cache:     443448     605128
Swap:       524288      13752     510536

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  30248  2632 ?        Ss   Dec24 145:12 /sbin/init
root        90  0.0  0.1  17184  1704 ?        S    Dec24   0:49 upstart-udev-bridge --daemon
root        98  0.0  0.1  21216  1940 ?        Ss   Dec24   0:00 /sbin/udevd --daemon
root       179  0.0  0.1  15000  1428 ?        S    Dec24   0:49 upstart-socket-bridge --daemon
root      1859  0.0  0.1  18992  1968 ?        Ss   Dec24   0:00 /sbin/rpcbind -w
root      1913  0.0  0.1  14596  1524 tty2     Ss+  Dec24   0:00 /sbin/getty -8 38400 tty2
bind      1968  0.0  4.8 274700 50588 ?        Ssl  Dec24   0:21 /usr/sbin/named -u bind
root      2007  0.0  0.5 120600  6156 ?        Sl   Dec24   0:40 /usr/sbin/rsyslogd -c5
root      2054  0.0  0.1  57648  1408 ?        Ss   Dec24   0:00 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
root      2055  0.0  0.0  57648    52 ?        S    Dec24   0:00 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
root      2086  0.0  0.1  49964  1996 ?        Ss   Dec24   0:00 /usr/sbin/sshd
root      2118  0.0  0.1  19584  1512 ?        Ss   Dec24   0:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root      2200  0.0  0.1  18900  1756 ?        Ss   Dec24   0:03 /usr/sbin/cron
root      3073  0.0  0.2  21672  2168 ?        Ss   Dec24   0:04 /usr/sbin/dovecot -c /etc/dovecot/dovecot.conf
dovecot   3095  0.0  0.1  13068  1452 ?        S    Dec24   0:01 dovecot/anvil
root      3096  0.0  0.1  13196  1592 ?        S    Dec24   0:01 dovecot/log
nobody    3100  0.0  0.2 132916  2180 ?        Sl   Dec24   0:11 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
root      3116  0.0  0.8 295816  8512 ?        Ss   Dec24   0:09 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
www-data  3117  0.0  0.6 295816  7284 ?        S    Dec24   0:00 php-fpm: pool www
www-data  3118  0.0  0.6 295816  7256 ?        S    Dec24   0:00 php-fpm: pool www
root      3215  0.0  0.2  37908  2756 ?        Ss   Dec24   0:05 /usr/lib/postfix/master
postfix   3227  0.0  0.2  59596  2988 ?        S    Dec24   0:00 qmgr -l -t fifo -u
root      3249  0.0  0.2  32792  2860 ?        Ss   Dec24   0:17 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:110
root      3322  0.0  0.8 165512  8804 ?        Sl   Dec24   3:38 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock
root      3324  0.0  0.1  22320  1760 ?        S    Dec24   0:35 /usr/lib/gamin/gam_server
root      3359  0.0  0.1  14596  1756 console  Ss+  Dec24   0:00 /sbin/getty -8 38400 console
root      3362  0.0  0.1  14596  1736 tty1     Ss+  Dec24   0:00 /sbin/getty -8 38400 tty1
postfix   3472  0.0  0.2  42652  2444 ?        S    Dec24   0:00 tlsmgr -l -t unix -u -c
www-data  5088  0.0  1.0 175744 11320 ?        S    01:56   0:00 /usr/sbin/fcgi-pm -k start
www-data  5089  0.0  1.1 176920 11796 ?        S    01:56   0:00 /usr/sbin/apache2 -k start
amavis   11630  0.0 10.6 234568 111508 ?       Ss   12:01   0:01 /usr/sbin/amavisd-new (master)
amavis   11633  0.0 11.2 246872 117676 ?       S    12:01   0:00 /usr/sbin/amavisd-new (ch3-avail)
root     14607  0.0  0.2   9380  2632 ?        S    12:09   0:00 /bin/sh /usr/bin/mysqld_safe
mysql    15031  0.0  2.0 151076 21296 ?        Sl   12:09   0:03 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/
root     15032  0.0  0.1   4108  1444 ?        S    12:09   0:00 logger -t mysqld -p daemon.error
root     16867  0.0  7.5 153488 78652 ?        Ss   12:30   0:03 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -d --pidfile=/var/r
root     16878  0.0  7.1 153488 74836 ?        S    12:30   0:00 spamd child
root     16879  0.0  7.1 153488 74836 ?        S    12:30   0:00 spamd child
dovenull 17570  0.0  0.4  24288  4888 ?        S    12:40   0:00 dovecot/imap-login
dovenull 17572  0.0  0.4  24292  4500 ?        S    12:40   0:00 dovecot/imap-login
vmail    17575  0.0  0.4  37944  4748 ?        S    12:40   0:00 dovecot/imap
vmail    17576  0.0  0.4  37976  4944 ?        S    12:40   0:00 dovecot/imap
postfix  23980  0.0  0.3  39976  3896 ?        S    14:14   0:00 pickup -l -t fifo -u -c
root     25010  0.0  0.3  23572  4180 ?        S    Dec29   0:00 dovecot/config
web12    25437  0.0  4.3 298416 45336 ?        S    14:38   0:02 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client0/web12/web:/var/www/clients/
dovenull 26138  0.0  0.4  24288  4452 ?        S    14:49   0:00 dovecot/imap-login
root     26140  0.0  0.1  19280  1548 ?        S    14:49   0:00 dovecot/ssl-params
dovenull 26141  0.0  0.4  24288  4628 ?        S    14:49   0:00 dovecot/imap-login
vmail    26145  0.0  0.5  39336  5524 ?        S    14:49   0:00 dovecot/imap
vmail    26146  0.0  0.4  37964  4484 ?        S    14:49   0:00 dovecot/imap
www-data 26232  0.0  2.2 389544 24000 ?        S    14:50   0:00 /usr/sbin/apache2 -k start
web13    26281  0.0  3.1 293264 32824 ?        S    14:51   0:01 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client0:/var/www/example.com:/var/w
www-data 26339  0.0  2.3 389708 24308 ?        S    14:52   0:00 /usr/sbin/apache2 -k start
www-data 26397  0.0  2.2 389380 23880 ?        S    14:53   0:00 /usr/sbin/apache2 -k start
www-data 26433  0.0  2.3 389556 24136 ?        S    14:53   0:00 /usr/sbin/apache2 -k start
root     26942  0.0  0.5  71304  5348 ?        Rs   15:01   0:00 sshd: root@pts/4
root     26946  0.0  0.3  17952  3208 pts/4    Ss   15:01   0:00 -bash
web12    27278  0.0  4.3 299984 45660 ?        S    15:06   0:00 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client0/web12/web:/var/www/clients/
web12    27287  0.0  3.9 297392 41152 ?        S    15:06   0:00 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client0/web12/web:/var/www/clients/
web12    27288  0.0  4.2 298688 44368 ?        S    15:06   0:00 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client0/web12/web:/var/www/clients/
www-data 27313  0.0  2.1 389068 23040 ?        S    15:07   0:00 /usr/sbin/apache2 -k start
root     27332  0.0  0.1  14596  1844 ?        Ss   15:07   0:00 /sbin/getty -8 38400 tty3
root     27334  0.0  0.1  14596  1776 ?        Ss   15:07   0:00 /sbin/getty -8 38400 tty4
root     27336  0.0  0.1  15328  1916 pts/4    R+   15:07   0:00 ps aux
root     27491  0.0  3.4 387644 36408 ?        Ss   Dec29   0:01 /usr/sbin/apache2 -k start
root     30825  0.0  0.0  21212   600 ?        S    00:08   0:00 /sbin/udevd --daemon
root     30826  0.0  0.0  21212   600 ?        S    00:08   0:00 /sbin/udevd --daemon

Autor: TestX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist das zufällig ein billigteil das nur 1gb MAX hat und wesentlich 
weniger "garantierten" speicher und shared kernel ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TestX schrieb:
> ist das zufällig ein billigteil das nur 1gb MAX hat und wesentlich
> weniger "garantierten" speicher und shared kernel ?

Sieht schwer danach aus. Zu wenig Server für zu viel Aufgaben.

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist doch aber noch freier Speicher übrig. Und der Cache könnte im 
Notfall auch verkleinert werden.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fällt auf, das du deutlich weniger swap space als Hauptspeicher 
hast, was sehr ungünstig ist:

Oliver V. schrieb:
> SwapTotal:        524288 kB
> SwapFree:         510536 kB

swapTotal sollte mindestens die Grösse des installierten RAM erreichen.
Als Abhilfe würde ich mehr RAM und mehr swap space vorschlagen. 
Ausserdem macht sich dovecot (und php-cgi) doch recht breit, es wäre 
eine Überlegung wert, das mal ein wenig runterzustutzen.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Mir fällt auf, das du deutlich weniger swap space als Hauptspeicher
> hast, was sehr ungünstig ist:

Hab ich bei Servern(!) eigentlich immer so. Die sollen arbeiten, nicht 
swappen. Wenn ein Server bös auf den Swapspace geht, dann hat man zu 
wenig RAM oder die Services gehen zu grosszügig damit um.

Stark swappende Services ergeben eigentlich nur Sinn, wenn sich das über 
den Tag verschiebt. Also sowas wie Services A+B tagsüber und C+D nachts.

Hier gibts zu viel Services mit zu viel davon genutztem oder nutzbarem 
Speicher. Beispielweise einen spamd mit maximal 5 Prozessen. Die 
verabschieden sich zwar nach einer Weile - aber Gnade der Kiste, wenn 
mal alle 5 zusammen kommen. Wenn nicht grad ein mittleres Unternehmen 
mit versorgt wird, dann reicht eigentlich einer.

PS: Mein Heimserverlein mit 3GB RAM läuft völlig ohne Swapspace.

: Bearbeitet durch User
Autor: Oliver V. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das ist die RAM-Nutzung laut Verwaltungspanel meines Anbieters.
Ich kann jetzt keine Knappheit erkennen, wenn ich ehrlich bin. Ich 
dachte auch immer, dass ein RAM-knappes Linux zuerst den Cache 
verkleinert, swappt und erst dann meckert.

Die Peaks kommen vom täglichen Backup.

spamd habe ich jetzt mal auf 1 child limitiert. Danke für den Tipp. Bin 
für mehr Tipps dankbar.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die reale Speicherbelegung ist schon mit einem physischen Server 
schwierig genug zu bewerten. Statistiken aus "ps" und dem Management 
geben nur grobe Hinweise, erst recht bei grober Zeitauflösung.

Hier kommt hinzu, dass es sich hier um einen virtuellen Server handelt. 
Manche Virtualisierungstechnik simuliert dabei eine formal streng 
getrennte Maschine, andere hingegen nutzen einen gemeinsamen Kernel 
(z.B. Virtuozzo). Das verkompliziert Speicheranalysen u.U. beträchtlich, 
weil man sich da eigentlich wie in Platos Höhle vorkommt.

Aber das sind natürlich alles nur Ratespiele. Wenn das Problem auch 
auftritt, wenn so circa überhaupt nichts läuft ...

Oliver V. schrieb:
> auch wenn ich apache2, mysqld, spamassassin, dovecot, postfix
> und amavis beende

... dann wirds komplizierter und vielleicht weiss der Anbieter des 
Servers dazu beizutragen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Such mal in den Logs die Zeilen der Art
  Memory cgroup out of memory: Kill process ... (...)
raus. Also was immer wieder abgeschossen wird, ob sich ein Muster 
zeigt. Das obige "node /usr/share" sagt mir nichts.

: Bearbeitet durch User
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Die sollen arbeiten, nicht
> swappen. Wenn ein Server bös auf den Swapspace geht, dann hat man zu
> wenig RAM oder die Services gehen zu grosszügig damit um.

Der Meinung bin ich prinzipiell natürlich auch - nichts geht über 
physischen RAM, wobei meine Linuxbox auch mit 1GB gut klarkommt, sie 
aber auch nicht so viel zu tun hat (Apache, Samba, netatalk, CUPS, ein 
wenig postgresql und irgendwelche anderen Dinge, die mir gerade 
entfallen sind :-P). Aber wenns so knapp wird, sorgt swapspace 
wenigstens dafür, das da nicht dauernd Kernel Exceptions kommen - die 
sollten die grosse Ausnahme sein.

Oliver V. schrieb:
> Das ist die RAM-Nutzung laut Verwaltungspanel meines Anbieters

Das ist natürlich gemittelt und in den Peaks könnten schon mal 100% drin 
sein, die wir nicht sehen. Dein syslog sagt jedenfalls, das da immer 
wieder zu wenig Speicher ist.
Anbei mal die Speichersituation meiner Box über die letzte Woche.

: Bearbeitet durch User
Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man irgendwie rauskriegen, welcher Prozess da so viel Speicher 
anfordert? Das müssen ja mit einem Schlag mehr als 300 MB sein, denn so 
viel ist zur Zeit frei und das Log wird voller und voller. Alle paar 
Minuten oder Sekunden ein Eintrag. Das Komische ist: Alles 
funktioniert.....

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
300 MB + Cache, der zu opfern wäre + Swap, der irgendwie immer leer ist.

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Kann man irgendwie rauskriegen, welcher Prozess da so viel Speicher
> anfordert?

Das wäre vielleicht eine Hilfe:
Beitrag "Re: vServer-Kernellog läuft ständig voll"

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, sorry, überlesen.
Dec 30 17:25:25 myserver kernel: [4207155.917035] Memory cgroup out of memory: Kill process 5117 (node /usr/share) score 69 or sacrifice child
Dec 30 17:51:44 myserver kernel: [4208734.790055] Memory cgroup out of memory: Kill process 27331 (node /usr/share) score 50 or sacrifice child
Dec 30 17:51:46 myserver kernel: [4208737.021524] Memory cgroup out of memory: Kill process 31868 (mysqld) score 80 or sacrifice child
Dec 30 17:59:14 myserver kernel: [4209184.828698] Memory cgroup out of memory: Kill process 31878 (node /usr/share) score 45 or sacrifice child
Dec 30 17:59:17 myserver kernel: [4209188.700699] Memory cgroup out of memory: Kill process 13189 (mysqld) score 80 or sacrifice child
Dec 30 18:46:51 myserver kernel: [4212042.228739] Memory cgroup out of memory: Kill process 6715 (node /usr/share) score 66 or sacrifice child
Dec 30 18:51:55 myserver kernel: [4212346.525603] Memory cgroup out of memory: Kill process 20449 (node /usr/share) score 66 or sacrifice child
Dec 30 19:04:51 myserver kernel: [4213122.474568] Memory cgroup out of memory: Kill process 12130 (node /usr/share) score 67 or sacrifice child
Dec 30 19:23:32 myserver kernel: [4214243.424181] Memory cgroup out of memory: Kill process 11577 (node /usr/share) score 67 or sacrifice child
Dec 30 19:26:38 myserver kernel: [4214429.486930] Memory cgroup out of memory: Kill process 23878 (mysqld) score 79 or sacrifice child
Dec 30 19:32:02 myserver kernel: [4214753.218824] Memory cgroup out of memory: Kill process 23918 (node /usr/share) score 67 or sacrifice child

Also entweder mysqld oder /usr/share.
MySQL ist schon ziemlich eingedampft und mit dem MySQLTuner bearbeitet 
worden. So viel braucht der nicht mehr.
Was /usr/share ist, keine Ahnung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Derjenige der abgeschossen wird, muss nicht derjenige sein, der den 
meisten Speicher hat oder will. Mir sind die Regeln dafür aber nicht 
bekannt.

Beim MySQL sollte man es aber merken. Wer nutzt den? PHP? Dann könnte 
dessen Log was dazu vermelden.

: Bearbeitet durch User
Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MySQL wird von PHP genutzt, ja, aber eher selten. Da läuft kein Forum 
oder Shop oder sowas. Der Mailkram benutzt es, glaube ich, auch.
In den anderen Logs finde ich keine Probleme. Nicht einmal in dem von 
MySQL!?

Was mich aber auch stutzig macht, ist der konstant hohe "load average" 
von fast 10 auf dem Server. Manchmal sogar mehr.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Prozesse werden willkürlich raus geschossen, es muß nicht unbedingt 
an Mysqld liegen, ich hatte mal beim VServer das Problem das der kmem zu 
klein war gibt in etwa die gleichen Fehler wen der Server nicht komplett 
abschmiert.

Schau mal mit:
cat /proc/user_beancounters

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's hier nicht.

cat: /proc/user_beancounters: No such file or directory

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es eine Möglichkeit, herauszufinden, welcher Prozess diese hohen 
io/bi-Werte verursacht, die vmstat anzeigt?
Ich glaube, dass diese beiden Symptome zusammen hängen.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Was /usr/share ist, keine Ahnung.
Du hast das 'node' davor übersehen. Scheint irgendeine Node.js Anwendung 
zu sein.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Oliver V. schrieb:
>
> Dec 30 19:32:02 myserver kernel: [4214753.218824] Memory cgroup out of 
> memory: Kill process 23918 (node /usr/share) score 67 or sacrifice 
> child
>
> Also entweder mysqld oder /usr/share.
> MySQL ist schon ziemlich eingedampft und mit dem MySQLTuner bearbeitet
> worden. So viel braucht der nicht mehr.
> Was /usr/share ist, keine Ahnung.

"/usr/share" ist ein Verzeichnis auf Deinem Linux-System. Mit "node" ist 
möglicherweise ein Programm aus dem Amateurfunkbereich gemeint, das 
früher im Paket "node" und heute in dem Paket "ax25-node" enthalten sein 
soll. Du als Admin dieses Systems solltest wissen, was da installiert 
ist, was dort läuft, warum es läuft, wer das benötigt und wie es 
gestartet wird.  ;-)

Und bevor diese Diskussion "Out of memory" -- "Nein" -- "Doch" -- "Das 
kann aber nicht sein" -- "Ooooh" noch weiter geführt wird: doch, das ist 
so, und es steht ganz eindeutig in den Kernellogs. Ganz offensichtlich 
gibt es eine Control Group, und das für diese Control Group 
konfigurierte Speicherlimit ist nun einmal erschöpft, und darum tut der 
OOM-Killer seinen Job.

Da es sich um eine Control Group handelt -- also: ein Feature von 
modernen Linux-Kernels, mit dem unter anderem die Ressourcen und die 
Priorisierung einzelner Prozesse oder Prozessgruppen limitiert werden 
können (ähnlich wie einst mit ulimits, nur viel weiter gehend) -- ist es 
wenig zielführend, das mit Werkzeugen zu betrachten, die den 
Ressourcenverbrauch des Gesamtsystems und seiner Prozesse anzeigen. 
Zielführender ist es, zunächst festzustellen, welcher Control Group die 
betreffenden Prozesse zugeordnet, und wie deren Ressourcenlimits 
konfiguriert sind. Die dazu nötigen Informationen findest Du unter 
/sys/fs/cgroup, unter /proc/<pid>/cgroup, und mit den Programmen des 
Pakets "cgroup-tools". HTH, YMMV.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
K. J. schrieb:
> Die Prozesse werden willkürlich raus geschossen,

Nein, das war früher mal so. Darüber haben sich die FreeBSD-Jungs dann 
so lange lustig gemacht, bis unter Linux der OOM-Killer eingeführt 
wurde, der nach nicht ganz trivialen, aber durchaus sinnvollen Kriterien 
herauszufinden versucht, welchen Prozeß das System am ehesten 
verschmerzen kann -- hat IIRC mit Benutzung, Priorität und so weiter zu 
tun -- und diesen erschießt.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Gibt es eine Möglichkeit, herauszufinden, welcher Prozess diese hohen
> io/bi-Werte verursacht, die vmstat anzeigt?

Das Programm iotop(8) aus dem Paket "iotop".

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, also /sys/fs/cgroup ist schon einmal ein leeres Verzeichnis.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Ok, also /sys/fs/cgroup ist schon einmal ein leeres Verzeichnis.

Was genau ist denn das für ein Debian, und wie wird es virtualisiert?

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit iotop habe ich kein Glück. :/
iotop
Traceback (most recent call last):
  File "/usr/sbin/iotop", line 16, in <module>
    main()
  File "/usr/lib/python2.7/dist-packages/iotop/ui.py", line 571, in main
    main_loop()
  File "/usr/lib/python2.7/dist-packages/iotop/ui.py", line 561, in <lambda>
    main_loop = lambda: run_iotop(options)
  File "/usr/lib/python2.7/dist-packages/iotop/ui.py", line 465, in run_iotop
    return curses.wrapper(run_iotop_window, options)
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "/usr/lib/python2.7/dist-packages/iotop/ui.py", line 455, in run_iotop_window
    taskstats_connection = TaskStatsNetlink(options)
  File "/usr/lib/python2.7/dist-packages/iotop/data.py", line 146, in __init__
    self.family_id = controller.get_family_id('TASKSTATS')
  File "/usr/lib/python2.7/dist-packages/iotop/genetlink.py", line 69, in get_family_id
    m = GeNlMessage.recv(self.conn)
  File "/usr/lib/python2.7/dist-packages/iotop/genetlink.py", line 51, in recv
    msg = conn.recv()
  File "/usr/lib/python2.7/dist-packages/iotop/netlink.py", line 229, in recv
    raise err
OSError: Netlink error: No such file or directory (2)

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Mit "node" ist
> möglicherweise ein Programm aus dem Amateurfunkbereich gemeint, das
> früher im Paket "node" und heute in dem Paket "ax25-node" enthalten sein
> soll.

Ne, das ist schon Node.js, zumal im obigen log auch npm (node package 
manager) und PM2 (Advanced Node.js process manager) auftauchen.

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist alles, was "node" im Namen hat:
locate node
/etc/amavis/conf.d/05-node_id
/lib/udev/create_static_nodes
/usr/include/python2.7/node.h
/usr/lib/perl/5.14.2/CORE/regnodes.h
/usr/lib/ruby/1.8/rexml/node.rb
/usr/lib/ruby/1.8/rexml/light/node.rb
/usr/lib/ruby/1.8/yaml/basenode.rb
/usr/lib/ruby/1.8/yaml/yamlnode.rb
/usr/lib/ruby/1.9.1/psych/nodes
/usr/lib/ruby/1.9.1/psych/nodes.rb
/usr/lib/ruby/1.9.1/psych/nodes/alias.rb
/usr/lib/ruby/1.9.1/psych/nodes/document.rb
/usr/lib/ruby/1.9.1/psych/nodes/mapping.rb
/usr/lib/ruby/1.9.1/psych/nodes/node.rb
/usr/lib/ruby/1.9.1/psych/nodes/scalar.rb
/usr/lib/ruby/1.9.1/psych/nodes/sequence.rb
/usr/lib/ruby/1.9.1/psych/nodes/stream.rb
/usr/lib/ruby/1.9.1/rexml/node.rb
/usr/lib/ruby/1.9.1/rexml/light/node.rb
/usr/lib/ruby/1.9.1/syck/basenode.rb
/usr/lib/ruby/1.9.1/syck/yamlnode.rb
/usr/share/keymaps/i386/qwerty/et-nodeadkeys.kmap.gz
/usr/share/keymaps/i386/qwertz/de-latin1-nodeadkeys.kmap.gz
/usr/share/keymaps/i386/qwertz/mac-usb-de-latin1-nodeadkeys.kmap.gz
/usr/share/keymaps/mac/mac-de-latin1-nodeadkeys.kmap.gz
/usr/share/man/man3/getipnodebyaddr.3.gz
/usr/share/man/man3/getipnodebyname.3.gz
/usr/share/man/man3/lh_node_stats.3ssl.gz
/usr/share/man/man3/lh_node_stats_bio.3ssl.gz
/usr/share/man/man3/lh_node_usage_stats.3ssl.gz
/usr/share/man/man3/lh_node_usage_stats_bio.3ssl.gz
/usr/share/mysql/ndb-config-2-node.ini
/usr/share/snmp/mib2c-data/details-node.m2i
/usr/share/snmp/mib2c-data/m2c_setup_node.m2i
/usr/share/snmp/mib2c-data/node-get.m2i
/usr/share/snmp/mib2c-data/node-set.m2i
/usr/share/snmp/mib2c-data/node-storage.m2i
/usr/share/snmp/mib2c-data/node-validate.m2i
/usr/share/snmp/mib2c-data/node-varbind-validate.m2i

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Virtualisiert wird laut Anbieter mit "LXC".

Autor: Donni Donis (donnidonis)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Du brauchst einfach mehr Ressourcen, ganz einfach. Wenn du dir das nicht 
leisten kannst, musst du halt weniger drauf laufen lassen. Die 
LogMeldungen sind doch eindeutig.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Das ist alles, was "node" im Namen hat:

Such eventuell mal nach PM2.
Hier mal ein paar Zeilen aus Deinem Log:
Dec 30 13:41:00 myserver kernel: [4193690.766216] [ 9308]     0  9308   296885     4969      71      21     1028             0 node /root/.pm2
Dec 30 13:41:00 myserver kernel: [4193690.769919] [11155]     0 11155   247266     4001      57      17        0             0 npm
Dec 30 13:43:21 myserver kernel: [4193831.955208] [13104]     0 13104   219982     3276      51      16        0             0 npm
Dec 30 13:43:38 myserver kernel: [4193849.362629] [ 9158]     0  9158   231716     5883     106      19      312             0 PM2 v2.8.0: God
Dec 30 13:46:42 myserver kernel: [4194033.196932] CPU: 5 PID: 19629 Comm: npm Tainted: G           O    4.13.4-1-pve #1
Dec 30 13:46:43 myserver kernel: [4194034.735050] [16866]     0 16866   262226    21032     127      84        0             0 node /usr/share

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
locate pm2
/usr/bin/rpm2cpio
/usr/share/doc/libgpm2
/usr/share/doc/rpm2cpio
/usr/share/doc/libgpm2/changelog.Debian.gz
/usr/share/doc/libgpm2/changelog.gz
/usr/share/doc/libgpm2/copyright
/usr/share/doc/rpm2cpio/changelog.Debian.gz
/usr/share/doc/rpm2cpio/changelog.gz
/usr/share/doc/rpm2cpio/copyright
/usr/share/man/man8/rpm2cpio.8.gz
/usr/share/vim/vim73/syntax/xpm2.vim
/var/lib/dpkg/info/libgpm2:amd64.list
/var/lib/dpkg/info/libgpm2:amd64.md5sums
/var/lib/dpkg/info/libgpm2:amd64.postinst
/var/lib/dpkg/info/libgpm2:amd64.postrm
/var/lib/dpkg/info/libgpm2:amd64.shlibs
/var/lib/dpkg/info/rpm2cpio.list
/var/lib/dpkg/info/rpm2cpio.md5sums
/var/www/clients/client0/web12/tmp/sess_1dpvb9tq6eubpm2436o7kfbsp0
/var/www/clients/client0/web12/tmp/sess_26psf8hfucol0qq115erhkppm2
/var/www/clients/client0/web12/tmp/sess_coop3gq8mpm2282dmnpaiikn92
/var/www/clients/client0/web13/tmp/sess_uj7req4dpddcopp8o9l6539pm2

Das mit den knappen Ressourcen glaube ich nicht. Mittlerweile ist der 
Cache auf über 650 MB angewachsen. Das wäre nicht der Fall, wenn der 
Platz tatsächlich gebraucht werden würde.
Es sei denn, natürlich, ein Prozess fordert auf ein Mal eine irrsinnige 
Menge (1-2 GB) an. Da gebe ich euch Recht. Aber so etwas habe ich bisher 
nicht gefunden.

Autor: TestX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guck mal ob es root.pm2 gibt wie in den logs..

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cat /root/.pm2
cat: /root/.pm2: No such file or directory

In den Dateien unter /proc/*/cgroup sind zumindest keine Zahlenwerte 
eingetragen, die irgendwelche Limits suggerieren könnten. Ich habe daran 
auch nie etwas verstellt. Ist alles mehr oder weniger Standard (bis eben 
auf die kleinen Tweaks seitdem ich das Problem bemerkt habe).

Leider ist es ein Stochern im Nebel. Anfrage beim Anbieter läuft 
parallel, aber wegen Wochenende und Feiertagen wird das etwas dauern.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Mit iotop habe ich kein Glück. :/

Ok, die Fehlermeldung unter Ubuntu 16.04 LTS ist da eindeutiger... Du 
mußt das Programm als root ausführen ("sudo iotop").

Autor: Daniel Abrecht (daniel-a)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Virtualisiert wird laut Anbieter mit "LXC".

Wow, das würde ich mich nicht trauen. Bei einem eigenen Server finde ich 
LXC ja ganz praktisch, aber fremden auf container zugriff zu geben wäre 
mir etwas zu riskant. Welcher Anbieter ist das?

Autor: Oliver V. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Habe ich versucht. Gleiche Meldung.

Meine Vermutung ist momentan:

memory: usage 817004kB, limit 819200kB, failcnt 1777024222
memory+swap: usage 1228800kB, limit 1228800kB, failcnt 7939462527

Also Limits von 800MB und 1200MB. Ich habe aber mehr RAM (1GB) und 
nochmal 500MB Swap, die der vServer auch zu belegen versucht.
Der Anbieter hat wahrscheinlich ein falsches Limit gesetzt bzw. einfach 
vergessen, das korrekte Limit einzustellen. Nämlich auf den Wert des 
bestellten RAMs und RAM+SWAP.
Mal schauen, was die sagen.

Autor: guest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Welcher Anbieter ist das?

Keine Ahnung, die verwendete Software scheint jedenfalls Proxmox zu sei:
https://www.proxmox.com
Proxmox VE ist eine leistungsstarke und leichtgewichtige Open Source Server-Virtualisierungssoftware, optimiert für Leistung und Benutzerfreundlichkeit. Für maximale Flexibilität haben wir zwei Virtualisierungstechnologien unter einer Managementoberfläche vereint: Kernel-based Virtual Machine (KVM) und Container-Virtualisierung mit Linux Container (LXC).

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Virtualisiert wird laut Anbieter mit "LXC".

Spannend. ;-)

Was mir übrigens gerade beim neuen 'Drüberschauen noch auffällt: nach 
der von Dir geposteten Ausgabe von "free -t" (im Post [1] ganz unten) 
swappt die Büchse schon, und nach der von Dir in [2] geposteten Ausgabe 
von "ps aux" sind in Summa schon 98,2 % des Arbeitsspeichers belegt. 
Auch dieses "usage 817004kB, limit 819200kB" aus [3] weist deutlich 
darauf hin, daß diese Kiste völlig am Ende ist.

In [3] erwähnst Du, daß Du für 1 GB RAM bezahlst, und natürlich solltest 
Du dann auch erwarten können, 1 GB RAM zu bekommen. Aber selbst wenn die 
Kiste den gebuchten Arbeitsspeicher hätte, wäre das Ganze immer noch 
allzu Spitz auf Knopf genäht. Wenn Du mit Deinem Hoster redest, solltest 
Du lieber ein komplettes Gigabyte dazu buchen, dann hast Du auch genug 
Reserve, wenn Du größere E-Mails oder Deine Webseite mehr Aufmerksamkeit 
bekommt.

Um temporär über die Feiertage wieder etwas Luft zu bekommen, würde ich 
jetzt zunächst den größten Ressourcenfresser Amavis sowie eventuell auch 
Spamassassin deaktivieren, oder die Anzahl der Apache- und PHP-Prozesse 
beschränken. Oder schlimmstenfalls eine Swapdatei anlegen und einbinden, 
damit die Maschine etwas mehr Swapspace hat -- das ist aber wirklich die 
dreckigste aller dreckigen Lösungen. YMMV.

[1] Beitrag "Re: vServer-Kernellog läuft ständig voll"
[2] Beitrag "Re: vServer-Kernellog läuft ständig voll"
[3] Beitrag "Re: vServer-Kernellog läuft ständig voll"

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin am Überlegen, ob ich das Caching deaktiviere... und wie. 
Zumindest mal für ein Experiment. Mit jeder meiner Optimierungen wächst 
der Cache.

Autor: EinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du bei einem Anbieter mit Discounter im Namen? Da hatte ich die 
letzten Tage die selben Probleme und bin mit der selben Konfiguration zu 
einem anderen Anbieter gewechselt, der keine solchen Probleme macht.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> [Dinge]

Ach so, am Rande bemerkt: um den Ressourcenverbrauch von UNIX-Systemen 
über längere Zeiträume zu überwachen, gibt es den altbekannten "System 
Activity Reporter" (SAR) im Paket "sysstat". Eins der Programme liest in 
regelmäßigen Intervallen die Performancecounter des Systems aus, 
speichert die Zustände und setzt die Counter zurück. Die gespeicherten 
Zustände können dann mit den anderen Programmen ausgelesen und in 
verschiedenen Formaten -- tabellarisch, JSON, CSV, XML -- ausgegeben 
werden. Nach einem konfigurierbaren Zeitraum, normalerweise sieben Tage, 
werden die gespeicherten Daten gelöscht.

So hnlich arbeitet collectd, das kenne ich aber nur vom Hörensagen. SAR 
hat dabei den Vorteil, daß ich ihn seit Ewigkeiten kenne und er auch für 
andere UNIXe als Linux, etwa AIX, Solaris, HPUX und FreeBSD verfügbar 
ist. So kann ich dasselbe Werkzeug und dieselben Skripte für den ganzen 
Zoo nutzen. Der Nachteil von SAR ist allerdings, daß er eben nur Daten 
sammelt und ausgibt, für die Visualisierung muß man sich entweder selbst 
etwas schreiben oder auf etwas wie GNUplot, pyxplot, Flot oder jqPlot 
ausweichen.

Für einen professionellen Betrieb geht natürlich nichts über ein 
"richtiges" Monitoring, etwa mit Icinga, Zabbix, Shinken, Cacti, oder 
für verclusterte und verteilte Umgebungen so etwas wie Ganglia. Solche 
Systeme sind jedoch relativ aufwändig und vielleicht ein wenig 
überdimensioniert, wenn man nur einen oder einige wenige kleine vServer 
betreiben will.

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal alle Dienste, die ich oben genannt habe, beendet und den 
Server so einige Zeit stehen lassen. Das ist jetzt noch an Prozessen 
übrig:
ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  30248  2552 ?        Ss   Dec24 155:23 /sbin/init
root        90  0.0  0.1  17184  1688 ?        S    Dec24   0:52 upstart-udev-bridge --daemon
root        98  0.0  0.1  21216  1924 ?        Ss   Dec24   0:00 /sbin/udevd --daemon
root       179  0.0  0.1  15000  1412 ?        S    Dec24   0:52 upstart-socket-bridge --daemon
root      1859  0.0  0.1  18992  1920 ?        Ss   Dec24   0:00 /sbin/rpcbind -w
root      1913  0.0  0.1  14596  1500 tty2     Ss+  Dec24   0:00 /sbin/getty -8 38400 tty2
root      2007  0.0  0.5 120600  6100 ?        Sl   Dec24   0:41 /usr/sbin/rsyslogd -c5
root      2054  0.0  0.1  57648  1320 ?        Ss   Dec24   0:00 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
root      2055  0.0  0.0  57648    52 ?        S    Dec24   0:00 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
root      2086  0.0  0.2  49964  2244 ?        Ss   Dec24   0:00 /usr/sbin/sshd
root      2118  0.0  0.1  19584  1484 ?        Ss   Dec24   0:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root      2200  0.0  0.1  18900  1756 ?        Ss   Dec24   0:03 /usr/sbin/cron
root      2730  0.0  0.2  31564  2156 ?        S    00:45   0:00 /USR/SBIN/CRON
root      2734  0.0  0.2   9236  2244 ?        Ss   00:45   0:00 /bin/sh -c /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
root      2735  0.0  0.2   9244  2188 ?        S    00:45   0:00 /bin/bash /usr/local/ispconfig/server/cron.sh
root      2736  0.0  0.2   9244  2336 ?        S    00:45   0:00 /bin/sh -c /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
root      2737  0.0  2.9 277304 30884 ?        S    00:45   0:00 /usr/bin/php -q -d disable_classes= -d disable_functions= -d open_basedir= /usr/local/ispconfig/server/cron.php
root      3249  0.0  0.2  32792  2936 ?        Ss   Dec24   0:18 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:110
root      3322  0.0  0.8 165512  9188 ?        Sl   Dec24   3:52 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock
root      3324  0.0  0.1  22320  1668 ?        S    Dec24   0:36 /usr/lib/gamin/gam_server
root      3359  0.0  0.1  14596  1716 console  Ss+  Dec24   0:00 /sbin/getty -8 38400 console
root      3362  0.0  0.1  14596  1712 tty1     Ss+  Dec24   0:00 /sbin/getty -8 38400 tty1
root      5729  0.0  0.2  31564  2148 ?        S    00:57   0:00 /USR/SBIN/CRON
root      5730  0.0  0.2   9236  2248 ?        Ss   00:57   0:00 /bin/sh -c /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
root      5731  0.0  0.2   9248  2600 ?        S    00:57   0:00 /bin/bash /usr/local/ispconfig/server/server.sh
root      5732  0.0  0.2   9244  2340 ?        S    00:57   0:00 /bin/sh -c /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
root      5774  0.0  2.8 276772 30212 ?        S    00:57   0:00 /usr/bin/php -q -d disable_classes= -d disable_functions= -d open_basedir= /usr/local/ispconfig/security/check.php
root      5819  0.0  0.1  14596  1784 ?        Ss   00:57   0:00 /sbin/getty -8 38400 tty3
root      5821  0.0  0.1  14596  1812 ?        Ss   00:57   0:00 /sbin/getty -8 38400 tty4
root      5871  0.0  0.1  15328  1904 pts/4    R+   00:57   0:00 ps aux
nobody   16225  0.0  0.2 198452  2104 ?        Sl   Dec30   0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
root     30825  0.0  0.0  21212   512 ?        S    Dec30   0:00 /sbin/udevd --daemon
root     30826  0.0  0.0  21212   512 ?        S    Dec30   0:00 /sbin/udevd --daemon
root     32541  0.0  0.5  71304  5332 ?        Ss   00:08   0:00 sshd: root@pts/4
root     32548  0.0  0.2  17956  3116 pts/4    Ss   00:08   0:00 -bash
Dec 31 00:46:02 myserver kernel: [4233593.059596] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Dec 31 00:46:02 myserver kernel: [4233593.061172] [ 8355]     0  8355    46158      238      26       4       74             0 systemd
Dec 31 00:46:02 myserver kernel: [4233593.062413] [ 8691]     0  8691    11908       37      27       3       95             0 rpcbind
Dec 31 00:46:02 myserver kernel: [4233593.074408] [ 9158]     0  9158   231460     5571     106      18      267             0 PM2 v2.8.0: God
Dec 31 00:47:41 myserver kernel: [4233691.725986] [ 8693]   106  8693    71521      332      43       3      158             0 rsyslogd
Dec 31 00:47:41 myserver kernel: [4233691.729455] [ 8809]     0  8809     3929        0      13       3       39             0 agetty
Dec 31 00:48:37 myserver kernel: [4233747.878567]  dump_stack+0x63/0x8b
Dec 31 00:48:37 myserver kernel: [4233747.882410]  mem_cgroup_oom_synchronize+0x31e/0x340
Dec 31 00:48:37 myserver kernel: [4233747.886184]  page_fault+0x28/0x30
Dec 31 00:48:37 myserver kernel: [4233747.889608] R10: 0000000000000022 R11: 0000000000000246 R12: 00000000000fa000
Dec 31 00:48:37 myserver kernel: [4233748.306942] R10: 0000000000000022 R11: 0000000000000246 R12: 000000000012c000
Dec 31 00:48:37 myserver kernel: [4233748.323121] [28961]     0 28961   305823     7279      75      31        0             0 postmon-mta: ma
Dec 31 00:50:24 myserver kernel: [4233855.344810] [ 8810]     0  8810     3929        0      13       3       39             0 agetty
Dec 31 00:52:30 myserver kernel: [4233980.722977]  dump_stack+0x63/0x8b
Dec 31 00:52:30 myserver kernel: [4233980.724898]  oom_kill_process+0x208/0x410
Dec 31 00:52:30 myserver kernel: [4233980.726810]  mem_cgroup_oom_synchronize+0x31e/0x340
Dec 31 00:52:30 myserver kernel: [4233980.728709]  mm_fault_error+0x8f/0x190
Dec 31 00:52:30 myserver kernel: [4233980.730561]  page_fault+0x28/0x30
Dec 31 00:52:30 myserver kernel: [4233980.732316] RAX: 0000000000000002 RBX: 00007ffefde0df78 RCX: 0000000000000002
Dec 31 00:52:30 myserver kernel: [4233980.749570] [ 5301]     0  5301     8820     1625      21       3        0             0 systemd-journal
Dec 31 00:52:30 myserver kernel: [4233980.753084] [31851]     0 31851   219982     3571      51      16        0             0 npm
Dec 31 00:52:38 myserver kernel: [4233988.822251] Call Trace:
Dec 31 00:52:38 myserver kernel: [4233988.825372]  out_of_memory+0x11d/0x4c0
Dec 31 00:52:38 myserver kernel: [4233988.828484]  mm_fault_error+0x8f/0x190
Dec 31 00:52:38 myserver kernel: [4233988.831496] RSP: 002b:00007fdb7d828e70 EFLAGS: 00010202
Dec 31 00:52:38 myserver kernel: [4233988.849052] [ 5301]     0  5301     8820     1626      21       3        0             0 systemd-journal
Dec 31 00:54:21 myserver kernel: [4234092.095397] CPU: 5 PID: 3437 Comm: mysqld Tainted: G           O    4.13.4-1-pve #1
Dec 31 00:54:21 myserver kernel: [4234092.098527]  ? mem_cgroup_scan_tasks+0xc4/0xf0
Dec 31 00:54:21 myserver kernel: [4234092.101808]  ? get_mem_cgroup_from_mm+0x90/0x90
Dec 31 00:54:21 myserver kernel: [4234092.104871]  page_fault+0x28/0x30
Dec 31 00:54:21 myserver kernel: [4234092.107747] RBP: 00007f8385f6bb40 R08: 00007f8385f6b950 R09: 00007f8385f6c9c0
Dec 31 00:54:21 myserver kernel: [4234092.124487] [31291]     0 31291    16381      180      35       3        0         -1000 sshd
Dec 31 00:54:58 myserver kernel: [4234128.941634] [ 8858]   114  8858   194667      135      75       4      356             0 opendkim
Dec 31 00:54:58 myserver kernel: [4234128.946554] [ 3416]     0  3416   262226    21010     126      84        0             0 node /usr/share
Dec 31 00:55:06 myserver kernel: [4234137.110922] mysqld cpuset=ns mems_allowed=0
Dec 31 00:55:06 myserver kernel: [4234137.116238]  dump_header+0x97/0x225
Dec 31 00:55:06 myserver kernel: [4234137.122260]  mem_cgroup_oom_synchronize+0x31e/0x340
Dec 31 00:55:06 myserver kernel: [4234137.128194]  do_page_fault+0x22/0x30
Dec 31 00:55:06 myserver kernel: [4234137.133807] RDX: 0000000000350000 RSI: 00007f86f7201040 RDI: 00007f86f70d0000
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 6  0   2888 507896      0 467372    2    2  4180   174    0    1 15  7 68 10
 6  1   2888 507672      0 467372    0    0 184092    28 1370 8970  3  8 87  2
 5  0   2888 507660      0 467372    0    0 182808   456 1385 9211  3  7 73 17
 6  0   2888 507652      0 467372    0    0 185584    72 1428 8665  4 10 86  0
 5  0   2888 507900      0 467372    0    0 185936   140 1325 9511  3  8 87  3
 6  0   2888 507968      0 467372    0    0 184292   324 1659 9325  3  8 74 14
 7  0   2888 507968      0 467372    0    0 183612   100 1650 11018  4 11 83  3
 7  4   2888 507972      0 467372    0    0 175808   264 1764 10435  4 13 68 15
 7  0   2888 507712      0 467372    0    0 172844    56 1757 9076  4 14 79  3
 7  0   2888 507880      0 467372    0    0 176852   216 1775 9391  4 13 80  3

Trotz jetzt ausreichend freien Speichers und nur wenigen Prozessen 
häufen sich noch immer die Fehlermeldungen und noch immer ist io/bi sehr 
hoch. :/

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Ich bin am Überlegen, ob ich das Caching deaktiviere... und wie.
> Zumindest mal für ein Experiment. Mit jeder meiner Optimierungen wächst
> der Cache.

Laß' es. Das ist sogar noch irrsinniger als eine Swapdatei anzulegen. 
Das System benutzt den Dateisystemcache, um häufig genutzte Dateien zu 
cachen, damit das System sie nicht bei jedem Zugriff von der Festplatte 
laden muß. Eine Deaktivierung des Dateisystemcache erhöht daher die 
I/O-Last auf der Festplatte MASSIV. Das kann das ganze System 
unbenutzbar machen, zumal Du oben ja ohnehin schreibst, daß Du eine 
enorme I/O-Last hast.

Linux benutzt für den Dateisystemcache aber eh nur freien 
Arbeitsspeicher, und gibt Cache-Speicher wieder frei, sobald eine 
Anwendung mehr Speicher anfordert als gerade frei ist. Außerdem wird der 
Dateisystemcache für die Pufferung und Gruppierung von Schreibzugriffen 
benutzt. Das bedeutet, daß Linux das tatsächlichen Schreibvorgänge so zu 
gruppieren versucht, daß die zu beschreibenden Festplattensektoren 
möglichst nahe bei einander liegen, um möglichst geringe Verfahrwege des 
Schreibkopfes und möglichst wenige Drehungen der Diskplatter zu 
erzielen. Derartige Positionierungen kosten nämlich bei klassischen 
Platter-Festplatten (Rotierender Rost) sehr viel Zeit, I/O-Performance 
und Zugriffslatenz.

Letztlich ist es ein sehr gutes Zeichen, wenn der Cache mit jeder Deiner 
Optimierungen wächst. Denn das zeigt zunächst nur, daß Deine 
Optimierungen tatsächlich wirken und Arbeitsspeicher freimachen. Wenn 
trotzdem weiterhin OOM-Fehler im Kernellog auftreten, zeigt das daher 
nur, unter welch hohem Druck Dein System gestanden hat und noch steht. 
Die Fehler sollten jetzt aber seltener auftreten, oder?

Wie auch immer: ein Server sollte im normalen Betrieb trotz vollem Cache 
immer noch freien Arbeitsspeicher für die Applikationen übrig haben.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Eine nette Übersicht über Performance-Aspekte bietet "conky". Gibts als 
X11-Version, aber auch als Textversion. Hier hatte ich vorsätzlich einen 
"cp" laufen lassen:
[code]
Uptime:      175d 16h 19m
Frequency:   800MHz 800MHz
Temperature: 33°C
RAM Usage:   ##________ 707MiB / 2.92GiB - 23%, Cached: 2.15GiB
Swap Usage:  ________ 0B / 0B - No swap%
CPU Usage:   ##________ 23%
Load avg:    1m: 1.65, 5m: 0.65, 15m:0.25
Processes:   191, Running: 0, Threads: 10
Networking:  Out: 2591.4KiB - In: 34.4KiB
Disk I/O:    Read: 1.01MiB - Write: 82.5MiB
Filesystems: /       ###_______ 4.60GiB / 14.5GiB
             /work   ###_______ 2.03TiB / 7.28TiB
             /temp   ###_______ 4.60GiB / 14.5GiB
             /archiv ######____ 771GiB / 1.34TiB
Name               PID    CPU%   MEM%   IO%
 cp               31589   8.06   0.05 100.00
 btrfs-transacti   1698   5.65   0.00   0.00
 kworker/u8:7     31572   2.42   0.00   0.00
 kswapd0             29   2.42   0.00   0.00
 VBoxHeadless      4323   1.61  11.75   0.00
 kworker/u8:8     31584   0.81   0.00   0.00
 conky            31573   0.81   0.07   0.00
[/code}

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Ich habe mal alle Dienste, die ich oben genannt habe, beendet und den
> Server so einige Zeit stehen lassen. Das ist jetzt noch an Prozessen
> übrig:
> [...]
> Trotz jetzt ausreichend freien Speichers und nur wenigen Prozessen
> häufen sich noch immer die Fehlermeldungen und noch immer ist io/bi sehr
> hoch. :/

Sehr merkwürdig. Ok, da läuft immer noch ein PHP, ein saslauthd, ein 
xinetd, ein gam_server und ein memcached, aber das sollte eigentlich 
nicht der Punkt sein. Ist es möglich, daß Dein Cron-Daemon irgendwas 
Riesiges aufruft, das uns entgangen ist? Ist es möglich, daß Du oder 
Dein Hoster Euch irgendeine Sauerei wie ein Rootkit eingefangen habt, 
das sich vor den handelsüblichen Diagnosewerkzeugen verbirgt? Und welche 
Prozesse werden jetzt überhaupt gekillt?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Sehr merkwürdig.

Mir kommt das schon eine Weile seltsam vor. Nachdem ich sah, dass er 
anfangs schon schrieb, das Verhalten wäre von seinen Services 
unabhängig.

> Ist es möglich, daß Dein Cron-Daemon irgendwas
> Riesiges aufruft, das uns entgangen ist?

Das sollte dann aber im "ps" irgendwie sichtbar sein. Soviel I/O völlig 
ohne CPU geht doch fast nicht und die akkumulierte CPU steht da drin. 
Blieben noch extreme Respawns, aber auch die sollten doch irgendwie 
auffallen.

> Dein Hoster Euch irgendeine Sauerei wie ein Rootkit eingefangen habt,
> das sich vor den handelsüblichen Diagnosewerkzeugen verbirgt? Und welche
> Prozesse werden jetzt überhaupt gekillt?

Oder manche Statistik-Werte sind mit etwas Vorsicht zu geniessen. 
Vielleicht werden darin mehr Daten eingefangen, als nur jene, die zu 
dieser VM gehören.

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die restlichen Dienste (cron, php, bind, saslauth, xinet, memcached, 
...) habe ich jetzt auch noch abgeschossen und gewartet. Keine Änderung!

vmstat io/bi hoch
fehler im kernel.log

Was mich wundert: Ich bekomme immernoch Meldungen zu mysqld im 
kernel.log, obwohl der schon längst nicht mehr läuft!?
Ich frage mich gerade, ob ich Meldungen von einem anderen Container 
sehe..... und ob vmstat die Werte des Hostservers anzeigt.

Hm, egal, ich reboote jetzt und warte auf die Antwort des Anbieters.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Ich frage mich gerade, ob ich Meldungen von einem anderen Container
> sehe..... und ob vmstat die Werte des Hostservers anzeigt.

"dmesg shows host's log"
https://github.com/lxc/lxd/issues/3148

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieser Mist füllt über kurz oder lang die Platte. Als ich es gemerkt 
habe, waren es schon 1 GB an Logs. Das landet ja nicht nur in 
kernel.log, sondern auch in messages, syslog, dmesg... Dann wird der 
Unsinn ja auch noch komprimiert und das anscheinend auf jedem Container. 
So ein Quatsch kann doch nicht normal sein. Das ist ein fetter Bug.

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver V. schrieb:
> Hm, egal, ich reboote jetzt und warte auf die Antwort des Anbieters.

Gute Idee, hoffentlich macht der Support jetzt den andern Kunden zur Sau 
der seinen RAM nicht im Griff hat.

A. K. schrieb:
> "dmesg shows host's log"

Vielleich fragt man mal höflich nach ob man nicht auf einen ruhigeren 
Server gelegt werden kann...

Autor: Oliver V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sie haben ihm heute morgen wohl den Saft abgedreht. Zumindest kam 
seitdem keine Meldung mehr ins Log und auch der load average ist wieder 
um 1 herum.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.