[erledigt] Überlastung - Load bis auf 80

[fulltilt]

Hatte gestern auf einem System eine Load von 80 - Server war für 2 Stunden kaum noch erreichbar.
Habe die logs alle durchforstet finde aber nichts was den Grund dazu liefert.
Einige seltsame Logs habe ich allerdings gefunden:

Code:

ispcp_daemon[29877]: send_line(): socket write error: Connection reset by peer

munin-node invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Davon gab es jede MENGE

Lock already exists: /var/run/munin/munin-update.lock. Dying.

Cannot open a connection to the mailserver 'localhost:25' -- Transport endpoint is not connected

'amavisd' service timed out and will not be checked anymore

[jmeyerdo]

Ich würde auf den ersten Blick eher tippen, dass das Auswirkungen des Load-Problems sind - und nicht die Ursache...
VG, Jens

[fulltilt]

Hammer - wenn ich den Apache neustarte, geht die load auf 80 hoch
Sieht irgendwie nach einem Apache Problem aus ...

Hatte heute morgen auch noch über 400 php5-cgi Prozesse laufen, momentan werden immer noch bis zu 300 gestartet, an den Configs habe ich in letzter Zeit nichts geändert.
Normalerweise habe ich immer ca. 200 Prozesse laufen.

Hier noch einige Logs von gestern:

Code:

Apache Error:

[warn] (32)Broken pipe: FastCGI: write() to PM failed (ignore if a restart or shutdown is pending)

Das lief so über Stunden


Syslog:

May 13 21:30:15 host1 suhosin[1612]: ALERT - canary mismatch on efree() - heap overflow detected (attacker '67.195.52.121', file '/var/www/virtual/xxxxxxx/htdocs/xxxxxx.php')
May 13 21:30:15 host1 spamd[1668]: prefork: child states: II
May 13 21:30:15 host1 postfix/master[16127]: fatal: bind 0.0.0.0 port 25: Address already in use
May 13 21:31:57 host1 /USR/SBIN/CRON[15214]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/dev/null; fi)
May 13 21:31:57 host1 /USR/SBIN/CRON[15255]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
May 13 21:32:27 host1 /USR/SBIN/CRON[16576]: (root) CMD (if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/dev/null; fi)
May 13 21:33:14 host1 amavis[319]: (00319-03) (!) TempDir removal: tempdir is to be PRESERVED: /var/lib/amavis/tmp/amavis-20080513T201841-00319
May 13 21:33:17 host1 monit[2337]: SMTP: error receiving data -- Resource temporarily unavailable

May 13 21:34:34 host1 kernel:  [<c02134a7>] elv_next_request+0x67/0x114
May 13 21:35:03 host1 postfix/policyd-weight[1651]: child 1029 exited
May 13 21:35:09 host1 postfix/smtpd[886]: warning: connect to private/anvil: Connection refused
May 13 21:35:09 host1 postfix/smtpd[3181]: warning: problem talking to server private/tlsmgr: Connection refused
May 13 21:35:09 host1 postfix/smtpd[2237]: warning: connect to private/anvil: Connection refused
May 13 21:35:09 host1 postfix/smtpd[2271]: warning: connect to private/anvil: Connection refused
May 13 21:35:09 host1 postfix/smtpd[2270]: warning: connect to private/anvil: Connection refused
May 13 21:35:09 host1 postfix/smtpd[887]: warning: connect to private/anvil: Connection refused
May 13 21:35:09 host1 postfix/smtpd[887]: warning: problem talking to server private/anvil: Connection refused


May 13 21:36:31 host1 kernel:  [<c0356e50>] __wait_on_bit_lock+0x4b/0x52
May 13 21:36:31 host1 kernel:  [<c012ee75>] __lock_page+0x58/0x5e
May 13 21:36:31 host1 kernel:  [<c0131015>] filemap_nopage+0x152/0x29f
May 13 21:36:31 host1 kernel:  [<c013a15c>] __handle_mm_fault+0x134/0x7c2
May 13 21:36:31 host1 kernel:  [<c010d38d>] do_page_fault+0x20d/0x52c
May 13 21:36:31 host1 kernel:  [<c01539b4>] sys_select+0x161/0x187
May 13 21:36:31 host1 kernel:  [<c010d180>] do_page_fault+0x0/0x52c
May 13 21:36:31 host1 kernel:  [<c0357dba>] error_code+0x72/0x78
May 13 21:36:31 host1 kernel:  =======================
May 13 21:36:31 host1 kernel: Mem-info:
May 13 21:36:31 host1 kernel: DMA per-cpu:
May 13 21:36:31 host1 kernel: CPU    0: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:   1 usd:   0
May 13 21:36:31 host1 kernel: Normal per-cpu:
May 13 21:36:31 host1 kernel: CPU    0: Hot: hi:  186, btch:  31 usd:  12   Cold: hi:   62, btch:  15 usd:  57
May 13 21:36:31 host1 kernel: HighMem per-cpu:
May 13 21:36:31 host1 kernel: CPU    0: Hot: hi:  186, btch:  31 usd:  11   Cold: hi:   62, btch:  15 usd:  50
May 13 21:36:31 host1 kernel: Active:232692 inactive:232355 dirty:0 writeback:0 unstable:0
May 13 21:36:31 host1 kernel:  free:11751 slab:11438 mapped:15 pagetables:6237 bounce:0
May 13 21:36:31 host1 kernel: DMA free:7872kB min:68kB low:84kB high:100kB active:2336kB inactive:1776kB present:16256kB pages_scanned:6603 all_unreclaimable? yes
May 13 21:36:31 host1 kernel: lowmem_reserve[]: 0 873 1952
May 13 21:36:31 host1 kernel: Normal free:38236kB min:3744kB low:4680kB high:5616kB active:377340kB inactive:376048kB present:894080kB pages_scanned:1254585 all_unreclaimable? yes
May 13 21:36:31 host1 kernel: lowmem_reserve[]: 0 0 8633
May 13 21:36:31 host1 kernel: HighMem free:896kB min:512kB low:1668kB high:2828kB active:551092kB inactive:551596kB present:1105092kB pages_scanned:1737589 all_unreclaimable? yes

[ephigenie]

Du hattest eine Kernel panic wie es ausschaut ... schon mal neu gebootet ?

[fulltilt]

ephigenie Wrote:Du hattest eine Kernel panic wie es ausschaut ... schon mal neu gebootet ?

Habe alle relevanten Dienste neu gestartet und Prozesse gekillt ...
Momentan siehts wieder gut aus, meinst Du der sollte rebootet werden?

hm - das habe ich noch entdeckt:
kernel: Total swap = 3943948kB
kernel: Free swap: 0kB

[fulltilt]

Hilfe :-)
habe hier eine log Datei entdeckt:

/var/log/apache2/users

domain-error.log = 3829 MB

Das könnte bereits das Problem sein oder?
Was mache ich damit - löschen und das Web sperren?

[BeNe]

Verschiebe die Log wo anderst hin. Es wird dann eh eine neue erstellt.
Und dann schaue mal mit tail rein was der Grund dafür ist.
Aber bei solchen Loggrößen kann es schon probleme eben

Greez BeNe

[fulltilt]

Danke BeNe,

ich habe gestern erst einmal die Domain gesperrt und die 2 Logdateien verschoben.

Code:

tail -n 500 domain.tld-error.log

[Tue May 13 20:44:31 2008] [error] [client xx.xxx.xxx.xx] FastCGI: server "/var/www/fcgi/domain.tld/php5-fcgi-starter" stderr: PHP Warning:  feof(): supplied argument is not a valid stream resource in /var/www/virtual/domain.tld/htdocs/administrator/components/com_magazine/admin.magazine.php on line 1056, referer: http://www.domain.tld/administrator/index2.php

Die Datei ist voll damit ...
Es handelt sich um die Joomla Komponente com_magazine dazu gibt es einige Sicherheitswarnungen > SQL Injection

die Funktion ist bei mir auf disabled, hat daher wohl die Fehler produziert.
Ist aber ein wenig heftig 3829 MB für error logs - kann man da etwas machen damit solche Dateien nicht so gross werden?
Das könnte im Zusammenhang mit der Quota Cron und Munin ein System zum Crash bringen ...

BeNe Wrote:Verschiebe die Log wo anderst hin. Es wird dann eh eine neue erstellt.
Und dann schaue mal mit tail rein was der Grund dafür ist.
Aber bei solchen Loggrößen kann es schon probleme eben

Greez BeNe

[BeNe]

Quote:Ist aber ein wenig heftig 3829 MB für error logs

Bei X Zugriffe auf die Seite kann das schon mal anwachsen...

Quote:kann man da etwas machen damit solche Dateien nicht so gross werden?

Auser Logrotate fällt mir da nicht grad viel ein. Müssten halt kleinere abstände gewählt werden.

Greez BeNe

[fulltilt]

Hi BeNe,

die Logs bereiten mir echt noch Kopfzerbrechen
Ich werde nach RC5 dran optimieren, soweit es geht und nützt.
Ich denke ab einer Grösse von 100 MB rotieren lassen ...
Mal ne dumme Frage: Könnte man das Webserver Logsystem nicht in eine Datenbank verfrachten? Muss ja nicht mySQL sein ...

BeNe Wrote:

Quote:Ist aber ein wenig heftig 3829 MB für error logs

Bei X Zugriffe auf die Seite kann das schon mal anwachsen...

Quote:kann man da etwas machen damit solche Dateien nicht so gross werden?

Auser Logrotate fällt mir da nicht grad viel ein. Müssten halt kleinere abstände gewählt werden.

Greez BeNe