Onderwerp: Downtime

Ik heb sinds kort een server met FreeBSD en CPanel. Ik ben nooit voorstander geweest van FreeBSD en heb er dus ook nauwlijks ervaring mee (werkte altijd met debian).

Nu gaat onze server snachts gewoon ineens uit, in zoverre dat de server onbereikbaar is maar wel alle poorten open staan. Het lijkt dus op een fatale crash

Waar moet ik naar kijken, welke logs? Na reboot doet de server het weer als een trein?


edit-
in messages.log staat vóór dat de machine down ging;

Oct 31 01:02:31 bt1 /kernel: pid 62164 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:02:34 bt1 /kernel: pid 62166 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:02:43 bt1 /kernel: pid 62168 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:02:45 bt1 /kernel: pid 62170 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:02:50 bt1 /kernel: pid 62172 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:05 bt1 /kernel: pid 62174 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:08 bt1 /kernel: pid 62176 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:13 bt1 /kernel: pid 62178 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:34 bt1 /kernel: pid 62180 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:44 bt1 /kernel: pid 62182 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:45 bt1 /kernel: pid 62184 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:04:56 bt1 /kernel: pid 62186 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:05:13 bt1 /kernel: pid 62229 (cpsrvd), uid 0: exited on signal 10
Oct 31 01:06:14 bt1 /kernel: pid 62265 (cpsrvd), uid 0: exited on signal 10

Signal 10 is a bus error... which usually indicates a data alignment problem.

Waar staat je server dan ?

leaseweb netwerk

Werkt de server nu weer naar behoren?

na het rebooten, ja. Maar toch is dit de 2e keer in 1 week dat hij snachts er uit vliegt.

Ik ben nu bezig met een apache update, zo gaf CPanel aan.. maar ik kan me niet voorstellen dat daar het probleem in zit.

Zal er nog meer downtime komen of blijft de server nu stabiel draaien?

Beetje rare vraag vind je niet? Ik zeg net, het is de 2e keer. Ik wil dus weten wat er aan de hand is om te achterhalen of ik actie moet ondernemen.

Ben nu apache/php aan het doen.. server load 1.50 en memory usage 85%

Ok, ik wacht rustig af. Tot zover bedankt voor de snelle reactie.

Goed updates gingen goed (mooi systeem dat cpanel update) maar nu wil ik nog graag achterhalen waarom onze server vanacht zomaar down ging.

IEMAND een oplossing?

Controleer je dmesg eens. En zijn er cronjobs actief rond eht tijdstip van begeven?

ik zie alleen dingen staan over de hardware.

dmesg:
http://www.budgettrends.nl/test.txt

en wat crons rond het tijdstip;

Oct 31 01:00:00 bt1 /usr/sbin/cron[55879]: (root) CMD (newsyslog)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55880]: (root) CMD (/usr/local/cpanel/bin/dcpumon >/dev/null 2>&1)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55881]: (root) CMD (/usr/local/cpanel/whostmgr/bin/dnsqueue > /dev/null 2>&1)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55882]: (vegainte) CMD (php public_html/cron/cron_right.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55883]: (vegainte) CMD (php public_html/cron/cron_wr.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55884]: (vegainte) CMD (php public_html/cron/cron_prot.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55885]: (vegainte) CMD (php public_html/cron/cron_power.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55886]: (vegainte) CMD (php public_html/cron/cron_sc2.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55887]: (vegainte) CMD (php public_html/cron/cron_sc.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55888]: (vegainte) CMD (php public_html/cron/cron_bank.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55889]: (vegainte) CMD (php public_html/cron/cron_dl.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55890]: (vegainte) CMD (php public_html/cron/cron_attack.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55891]: (vegainte) CMD (php public_html/cron/cron_spy.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55892]: (vegainte) CMD (php public_html/cron/cron1.php)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55893]: (root) CMD (/usr/libexec/atrun)
Oct 31 01:00:00 bt1 /usr/sbin/cron[55894]: (vegainte) CMD (php public_html/cron/cron_oat.php)
Oct 31 01:01:00 bt1 /usr/sbin/cron[58202]: (root) CMD (adjkerntz -a)
Oct 31 01:05:00 bt1 /usr/sbin/cron[62192]: (root) CMD (/usr/libexec/atrun)
Oct 31 01:05:00 bt1 /usr/sbin/cron[62193]: (root) CMD (/usr/local/cpanel/bin/dcpumon >/dev/null 2>&1)
Oct 31 01:05:00 bt1 /usr/sbin/cron[62194]: (vegainte) CMD (php public_html/cron/cron_right.php)
Oct 31 01:05:00 bt1 /usr/sbin/cron[62195]: (vegainte) CMD (php public_html/cron/cron_prot.php)
Oct 31 01:05:00 bt1 /usr/sbin/cron[62196]: (vegainte) CMD (php public_html/cron/cron_power.php)

FreeBSD is wel stable. Zo'n crash komt meestal door dingen die met sharing van hardware te maken hebben zoals IRQ sharing , VGA ram share (te veel), een IRQ botsing etc.



Het kan zijn dat hij crashed tijdens een van die crontab jobs in midnacht dat hij overbelast raakt en al reboot voordat hij iets kan wegschrijven.

Ik zie dat je ongeveer 469 MB gehuegen hebt, ik neem aan dat je een VGA hebt die ongeveer 32 pakt van je werk gehuegen, niet weinig als je er niet op werkt; als het inderdaad 32 is kan je het probeeren te verlagen in je BIOS, als je er toch in bent zet dan ook de LPT0 uit (printer poort) disable dus, en je floppy drive ook disablen (als je ooit een reinstall doet, kan je hem aan zetten maar noteer even)... je serial poort kan je ook uit zetten etc etc.

512 / 469mb na sharing is toch niet veel memory, als je wat swap gebruikt en load op je server hebt is het weinig. dus dit tot 1gb brengen is niet gek

Ik weet niet hoeveel ethernet kaarten je gebruikt maar het blijkt dat je een SIS en Realtek hebt, als je deze niet allebei gebruikt disable, of trek ze uit de server.

Ik raad aan om de SIS te gebruiken als ethernet controller omdat je moederboard SIS is, zo dus is de communicatie tussen de south bridge beter.

De combinatie IRQ10 share is ook dodelijk. USB en je SIS 900 Fast ethernet zitten allebei op irq10. Zet de usb af als je die niet nodig hebt, ik dink het dus niet.

Je kan het altijd nog goed doen om de secondary ide uit te doen want de 2 ide kanaalen trekken alebei een aparte IRQ. (mits je op de secondary niks hebt zitten)

ten tweede, ziet FreeBSD je vga kaart als een standard ISA generic vga, het zal wel een pci zijn maar toch, dit is dus de driver voor alle onbekende kaarten.


Als je dit gaat doen, adviseer ik wel bij de server te blijfen. Je komt eigenlijk niet in de bios zonder er bij te zijn tot hij er weer bij komt.


Al deze IRQ nemen tijd van de CPU (clock). dus elke cycle moet de cpu kijken of er nog een bucket staat. Zodra een IRQ wordt gedeelte is deze situatie nog erger en kan een OS crashen op het effect van wachten voor een hardware component dat realtime hoort te antwoorden.

Tegenwoordig zijn de OS er wel op gericht. Maar vooral de mensen bij freebsd gaan er van uit dat je minimalist approach neemt met de resource allocation . Als je dit alemaal gedaan hebt, dan komt het wel stabieler uit dan nu.

Dus die claims dat freebsd het langst blijft draaien moet je toch nog wel waar maken met wat settings en hardware specifiek tweaks, je moet je server dus kennen en voelen terwijl hij wat load neemt, dus praaten we hier over load boven de 1 (meer dan 100%) en dat processen moeten wachten. Dan zie je vanzelf de harddisk of memory/cpu reageren als je op de shell bent

Groeten
jelle van o3

Aan de CRON lijkt het niet te liggen, vanmiddag gaf hij ook ineens het leven en besloot uit te gaan. Zonder meldingen wederom.

Ik heb hem weer herstart via APC en alles draait als een zonnetje tot nu op dit moment (23.00)

hij heeft nu een CPU load van 0.15 (aldus cpanel) en een memory usage van 87.31 procent.. daarbij ook nog een 25% swap.

Ik heb nagevraagd bij iemand die verstand heeft van FreeBSD en die vond de 87 procent memory usage normaal. Toch vind ik dat nogal veel voor een machine die (op dit moment) even niets doet.


@ozone
Het lijkt me sterk dat een paar IRQ's zoveel problemen kunnen veroorzaken toch? Ik ga er vanuit dat FreeBSD dat soort zaken zelf kan oplossen?

Mischien word je server gewoon te warm? Al lijkt het me sterk aangezien de server nog best lang blijft draaien..

Houd er rekening mee dat FreeBSD eigenlijk altijd alle memory claimed. Motto van FreeBSD is "Free memory is wasted memory"

FreeBSD gebruikt de memory als disk cache