Onderwerp: VPS valt elke dag weg...

Goedendag,

Ik heb een VPS server met CentOS 6.2 x64 erop geinstalleerd, echter is het bijna nu zo dat elke dag de websites niet meer draaien. Dan kunnen de pagina's niet meer worden geladen.

Heeft iemand enig idee hoe dit kan? Of waar ik kan vinden wat de oorzaak hiervan is?

Na een reboot doet de server het namelijk weer. En dan na een dag zijn de websites weer niet bereikbaar.

Alvast dank!

Mvg,

Tychon

Misschien lopen je logs vol. Dit heeft als resultaat dat de schijf vol loopt en de VPS vaak onderuit gaat.

Als de VPS onderuit gaat omdat de logs vollopen zou die nog steeds problemen moeten geven na een rebo de logs staan dan nog even vol. Misschien is het wel een idee om in de logs te kijken als de websites offline zijn. Worden er meldingen gemaakt?

Zijn de websites dan offline of is je hele VPS offline? Kan je 'm pingen? Draaien er nog andere services op je VPS behalve http? Zijn die op zo'n moment ook offline?

Bedankt voor de reactie! Ik ga dit even na, en laat het weten zodra ik iets heb gevonden.

Oorspronkelijk geplaatst door tychon

Bedankt voor de reactie! Ik ga dit even na, en laat het weten zodra ik iets heb gevonden.

Klein gokje, IOPS tekort op storage, effect: cpu stijgt --> ram loopt vol --> Swap loopt vol.
Restultaat "out of memory", reboot dan is ram en swap leeg en werkt alles weer
Is het geheel ook traag? Zo ja, dat is ook een symptoom dat hierbij past.

Maar ik zou zeggen, logs doornemen en eventueel grafieken van cpu en mem bekijken.

Heb je de /var/log/messages al eens bekijken? Hier kan je vaak de logs vinden die gerelateerd kunnen zijn aan de crash (zoals kernel panics, out of memory, etc)

Om ergens te beginnen;
- Maak je gebruik van een controlpanel? Zo ja, draaien de benodigde services nog op het moment dat de website offline zijn? Wat doet een herstart van desbetreffende services?
- Is de server nog wel te bereiken? netwerk interfaces? Wat doet een herstart van de network service?
- Output van df -h ? voldoende schijfruimte?
- Wat zegt de Apache error/access log? Is hier een trend te zien?
- Wat doet de CPU load? b.v. door mass mailing?

Mocht je er niet uit komen laat het ons weten op info (at) nso.eu. Wij kijken en denken graag even mee, helemaal als service.

Oorspronkelijk geplaatst door cyberbootje

Klein gokje, IOPS tekort op storage, effect: cpu stijgt --> ram loopt vol --> Swap loopt vol.
Restultaat "out of memory", reboot dan is ram en swap leeg en werkt alles weer
Is het geheel ook traag? Zo ja, dat is ook een symptoom dat hierbij past.

Maar ik zou zeggen, logs doornemen en eventueel grafieken van cpu en mem bekijken.

Dat is wel heel kort door de bocht. Er kunnen tal van redenen zijn... RAM kan bijv ook vollopen zonder trage storage...

Oorspronkelijk geplaatst door Yourwebhoster

Dat is wel heel kort door de bocht. Er kunnen tal van redenen zijn... RAM kan bijv ook vollopen zonder trage storage...

Dat is net zo kort door de bocht als de hoeveleheid info dat in de beginpost staat.
Maargoed, IOPS tekort of storage traag, hangt wel samen of niet?

TS moet sowieso zelf even kijken/iemand laten kijken. Laten we eerlijk zijn, IOPS/storage issue is wel heel vaak het probleem met al die vpjes die te koop staan dus ik ben bang dat ik er niet heel ver naast zit. Begint zorgelijk te worden om eerlijk te zijn.

TS heeft totaal geen details gegeven van de vps. Dus dan blijft het gissen.
Persoonlijk denk ik dat het een klein vpsje is en dat deze tegen een OOM killer aan loopt.
Services als apache of mysql worden gestopt. En na een reboot is alles er weer, maar is natuurlijk geen uiteindelijke oplossing.

Ben overigens niet eens met cyberbootje. Kort door de bocht en alles over 1 kam scheren.

Iederen bedankt voor het meedenken!

Ik merk op uit mijn logs dat er steeds Firewall meldingen ervoor verschijnen, zoals bijv:

Code:

Jun 26 17:41:52 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:a5:61:06:08:00 SRC=159.253.7.57 DST=255.255.255.255 LEN=153 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17500 DPT=17500 LEN=133

Voor de beveiliging gebruik ik CSF, dit zal ik nog eens nalopen. Misschien dat ik deze nog beter kan instellen.

Tychon,

Jouw probleem is dat je server na verloop van tijd stopt met werken. Als je firewall het probleem veroorzaakt zal je dat direct merken, niet na een dag ofzo.
Mocht je willen dat ik een blik op je systeem werp, geheel vrijblijvend, dan moet je me maar een PM sturen.

Bedankt, indien nodig zal ik je een PM sturen.

Mijn server viel weer weg vannacht. Om 9:09 heb ik deze weer opgestart, dit zijn de logs ervan:

Code:

Jul  2 20:28:55 vps ntpd[1414]: synchronized to 185.18.149.149, stratum 2
Jul  2 20:28:55 vps ntpd[1414]: time reset +3570.551812 s
Jul  2 20:28:55 vps ntpd[1414]: kernel time sync status change 2001
Jul  2 20:29:02 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:3d:f9:c2:08:00 SRC=159.253.5.244 DST=255.255.255.255 LEN=131 TOS=0x00 PREC=0x00 TTL=128 ID=10225 PROTO=UDP SPT=17500 DPT=17500 LEN=111 
Jul  2 20:29:03 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  2 20:29:05 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:f1:53:4d:08:00 SRC=159.253.5.47 DST=255.255.255.255 LEN=140 TOS=0x00 PREC=0x00 TTL=128 ID=21916 PROTO=UDP SPT=21327 DPT=21327 LEN=120 
Jul  2 20:29:05 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:f1:53:4d:08:00 SRC=159.253.5.47 DST=255.255.255.255 LEN=140 TOS=0x00 PREC=0x00 TTL=128 ID=21917 PROTO=UDP SPT=21327 DPT=21328 LEN=120 
Jul  2 20:29:11 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:a5:61:06:08:00 SRC=159.253.7.57 DST=255.255.255.255 LEN=153 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17500 DPT=17500 LEN=133 
Jul  2 20:29:11 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  2 20:29:12 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:2f:e6:f7:08:00 SRC=185.13.225.54 DST=255.255.255.255 LEN=140 TOS=0x00 PREC=0x00 TTL=128 ID=23932 PROTO=UDP SPT=17500 DPT=17500 LEN=120 
Jul  2 20:29:35 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:f1:53:4d:08:00 SRC=159.253.5.47 DST=255.255.255.255 LEN=140 TOS=0x00 PREC=0x00 TTL=128 ID=21919 PROTO=UDP SPT=21327 DPT=21328 LEN=120 
Jul  2 20:29:40 vps kernel: Firewall: *ICMP_IN Blocked* IN=eth0 OUT= MAC=01:00:5e:00:00:01:5c:26:0a:f9:db:9d:08:00 SRC=192.168.2.5 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=63201 PROTO=ICMP TYPE=9 CODE=0 
Jul  2 20:29:41 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:a5:61:06:08:00 SRC=159.253.7.57 DST=255.255.255.255 LEN=153 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17500 DPT=17500 LEN=133 
Jul  2 20:29:41 vps kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:16:3e:2f:e6:f7:08:00 SRC=185.13.225.54 DST=255.255.255.255 LEN=140 TOS=0x00 PREC=0x00 TTL=128 ID=24766 PROTO=UDP SPT=17500 DPT=17500 LEN=120 
Jul  2 20:34:00 vps ntpd[1414]: synchronized to 185.18.149.149, stratum 2
Jul  2 21:00:34 vps named[1708]: client 178.18.26.144#50723: query (cache) '1rip.com/ANY/IN' denied
Jul  2 21:11:34 vps named[1708]: client 60.28.246.143#47363: query (cache) 'google.com/A/IN' denied
Jul  2 21:53:12 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  2 22:44:40 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  2 22:51:35 vps named[1708]: client 60.28.246.143#34283: query (cache) 'google.com/A/IN' denied
Jul  3 00:04:16 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  3 00:20:38 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  3 00:31:23 vps named[1708]: client 60.28.246.143#37674: query (cache) 'google.com/A/IN' denied
Jul  3 00:41:00 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  3 02:11:00 vps named[1708]: client 60.28.246.143#49053: query (cache) 'google.com/A/IN' denied
Jul  3 03:50:23 vps named[1708]: client 60.28.246.143#37183: query (cache) 'google.com/A/IN' denied
Jul  3 04:11:45 vps kernel: __ratelimit: 6 callbacks suppressed
Jul  3 04:51:58 vps ntpd[1414]: synchronized to 212.71.20.188, stratum 2
Jul  3 05:29:44 vps named[1708]: client 60.28.246.143#54582: query (cache) 'google.com/A/IN' denied
Jul  3 06:42:44 vps ntpd[1414]: synchronized to 185.18.149.149, stratum 2
Jul  3 07:09:18 vps named[1708]: client 60.28.246.143#40651: query (cache) 'google.com/A/IN' denied
Jul  3 08:48:45 vps named[1708]: client 60.28.246.143#46365: query (cache) 'google.com/A/IN' denied
Jul  3 09:09:43 vps init: tty (/dev/tty1) main process (1650) killed by TERM signal
Jul  3 09:09:43 vps init: tty (/dev/tty2) main process (1652) killed by TERM signal
Jul  3 09:09:43 vps init: tty (/dev/tty3) main process (1654) killed by TERM signal
Jul  3 09:09:43 vps init: tty (/dev/tty4) main process (1656) killed by TERM signal
Jul  3 09:09:43 vps init: tty (/dev/tty5) main process (1658) killed by TERM signal
Jul  3 09:09:43 vps init: tty (/dev/tty6) main process (1660) killed by TERM signal

Ik zie dat er weer aanvallen zijn geweest... Kan ik dit nog beter tegengaan?

Hoi Tychon,

Is er vandaag weer een probleem geweest aan het systeem? Zo ja, vanaf hoe laat ongeveer? Was dat rond 9u vanmorgen?
De meldingen: Jul 3 09:09:43 vps init: tty (/dev/tty6) main process (1660) killed by TERM signal
Kunnen zijn veroorzaakt door te weinig resources.

Wat voor specs heeft je vps?

Ik zie dat er weer aanvallen zijn geweest... Kan ik dit nog beter tegengaan?

Ik zie in de logs geen aanvallen; die paar UDP-pakketjes op poort 17500 zijn broadcastverkeer (volgens professor Google waarschijnlijk dropbox-clients op het lokale netwerk) en die nameserverqueries horen erbij als je een nameserver draait. Recursion staat schijnbaar uit dus niets aan de hand.

Verder maak ik uit het log op dat je VPS nog gewoon draaide toen je 'm herstartte; om 8:48 heeft named immers nog iets gelogd en de shutdown van je terminals is ook keurig gelogd. Ik denk dat je toch beter zult moeten toelichten wat je precies bedoelt met het 'wegvallen' van je server.

De meldingen: Jul 3 09:09:43 vps init: tty (/dev/tty6) main process (1660) killed by TERM signal
Kunnen zijn veroorzaakt door te weinig resources.

Nee, deze zijn veroorzaakt door het rebooten van de VPS om 9:09.