Bekijk Volledige Versie : 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 reboot: 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.
cyberbootje
27/06/13, 14:18
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.
IceHosting
27/06/13, 15:26
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.
Yourwebhoster
28/06/13, 07:50
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...
cyberbootje
28/06/13, 10:39
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.
crossplatform
01/07/13, 11:13
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:
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.
crossplatform
02/07/13, 08:45
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:
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?
crossplatform
03/07/13, 11:42
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.
Het lijkt er op dat de HTTP dan niet meer werkt. De websites willen dan niet laden. En de mailserver knalt dan ook uit, dit merk ik dan direct op in Apple Mail. In mijn control panel om de Cloudbox te beheren zie ik dan dat de server wel draait, deze is niet uit.
De specs zijn:
1.024 MB RAM
1 CPU Cores
100 GB Harde Schijf
Processor Name: QEMU Virtual CPU version 0.9.1
Vendor ID: GenuineIntel
Processor Speed (MHz): 2400.144
Kan het misschien zijn dat een website met Wordpress geinstalleerd de boel laat vastlopen?
Een van de websites werd namelijk geblokeerd op een Shared Hosting, deze heb ik toen overgezet naar deze server.
Klopt die van 9:09 is omdat ik toen de server heb gereboot.
Tevens ontvang ik ook steeds deze meldingen via DA:
Warning: The system load average is 10.16
&
Warning: The system load average is 213.98
En daarin dan:
This is an automated message notifying you that the 5 minute load average on your system is 213.98.
This has exceeded the 10 threshold.
One Minute - 219.61
Five Minutes - 213.98
Fifteen Minutes - 198.09
top - 00:47:33 up 3 days, 9:32, 0 users, load average: 219.61, 213.98, 198.09
Tasks: 982 total, 8 running, 974 sleeping, 0 stopped, 0 zombie
Cpu(s): 42.6%us, 8.9%sy, 0.3%ni, 2.9%id, 44.8%wa, 0.5%hi, 0.1%si, 0.0%st
Mem: 1018620k total, 838476k used, 180144k free, 1412k buffers
Swap: 4194296k total, 1538172k used, 2656124k free, 41804k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1545 mysql 20 0 875m 28m 2476 S 47.6 2.9 1435:09 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/lib/mysql/vps.wehosted.nl.err --pid-file=/var/lib/mysql/vps.wehosted.nl.pid
28874 apache 20 0 410m 44m 1364 R 7.0 4.5 0:21.65 /usr/sbin/httpd -k start -DSSL
29274 apache 20 0 407m 46m 1392 R 7.0 4.6 0:15.21 /usr/sbin/httpd -k start -DSSL
28866 apache 20 0 408m 36m 1224 R 6.2 3.7 0:40.37 /usr/sbin/httpd -k start -DSSL
28864 apache 20 0 408m 35m 1232 R 5.5 3.6 0:36.60 /usr/sbin/httpd -k start -DSSL
27822 apache 20 0 410m 37m 1652 R 4.7 3.8 0:36.42 /usr/sbin/httpd -k start -DSSL
28 root 20 0 0 0 0 R 3.9 0.0 4:01.57 [kswapd0]
27606 apache 20 0 411m 15m 1764 S 3.1 1.6 1:49.66 /usr/sbin/httpd -k start -DSSL
29636 root 20 0 15680 1924 860 R 3.1 0.2 0:00.09 /usr/bin/top -c -b -n 1
27605 apache 20 0 408m 17m 1648 S 2.3 1.7 0:30.23 /usr/sbin/httpd -k start -DSSL
28876 apache 20 0 378m 14m 1336 S 2.3 1.4 0:09.61 /usr/sbin/httpd -k start -DSSL
29366 apache 20 0 376m 33m 1216 S 1.6 3.4 0:03.71 /usr/sbin/httpd -k start -DSSL
30922 root 20 0 220m 636 236 D 1.6 0.1 4:03.30 /usr/local/directadmin/dataskq
1 root 20 0 19228 176 172 S 0.0 0.0 0:01.00 /sbin/init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kthreadd]
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 [migration/0]
4 root 20 0 0 0 0 S 0.0 0.0 0:16.92 [ksoftirqd/0]
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 [migration/0]
6 root RT 0 0 0 0 S 0.0 0.0 0:05.65 [watchdog/0]
7 root 20 0 0 0 0 S 0.0 0.0 0:29.58 [events/0]
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [cgroup]
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [khelper]
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [netns]
================================
Automated Message Generated by DirectAdmin
Je mag denk niet direct op de server kijken of wel ? Wat geven je logs weer van Mysql en Apache? Zie Mysql bovenaan staan die dus met iets bezig dat de load doet gaan oplopen op je server. Waarschijnlijk een query ofzo die niet lekker loopt oid.
Ik vermoed dat een site veel te veel vraagt van je server (ruim 900 draaiende processen is erg veel), vervolgens loopt je geheugen vol (er wordt zo'n 2,5 GB gebruikt op maar 1 GB 'echt' geheugen) en wordt je machine traag omdat de VPS waarschijnlijk op relatief trage storage draait. In het screenshot van top zie je dat je CPU bijna de helft van de tijd aan het wachten is op devices (waarschijnlijk disks). Vervolgens loopt de load enorm op.
Je zult de monitoring moeten aanpassen om te zien wat precies de overbelasting veroorzaakt. Als je een verdachte site hebt dan zou ik daar in ieder geval de logs van bekijken. Verder is het natuurlijk verstandig om het aantal processen en/of de hoeveelheid geheugen die 1 site kan gebruiken (verder) te beperken, zeker als het allemaal binnen 1 GB moet draaien.
Als de 900 gelijktijdig draaiende processen wel normaal zijn (wat ik mij eigenlijk niet kan voorstellen) dan zou je het geheugen van de VPS kunnen upgraden naar bv 4 GB om het performanceprobleem op te lossen.
@bigbud ik kan de logs van de mysql niet vinden in /var/log/, dit staat wellicht niet aan...? Ik heb ook het vermoeden dat het om een query gaat.
@NederHost hoe kan ik de hoeveelheid processen/geheugen aanpassen per site?
In directadmin geeft de HTTPD dit aan:
httpd httpd (pid 22749 23465 23777 23844 23846 23941 23983 23986 24048 24052 24054 24066 24067 24068 24264 24266 24267 ) 648.5 MB
Lijkt me ook erg veel!
44.8%wa ..... je processoren zijn dus op disk aan het wachten. Dit komt (waarschijnlijk) doordat je uit je geheugen loopt. Dus upgraden naar meer ram en eventueel PHP e.d. lagere limieten geven per proces.
Er draaien totaal niet veel sites op. Is die Cloudbox dan zo slecht... Welke handeling kan ik nu nog uitvoeren om het probleem te vinden of om de server beter in te stellen?
Thanks alvast voor alle moeite!
Het aantal sites is niet belangrijk, maar meer hoe zwaar ze belast worden.
Kijk eerst eens je logs na, als je heel inefficiënte query's hebt waarbij MySQL (die gebruikt bijna de helft van je cpu) te veel geheugen gebruikt en je server gaat swappen is het niet heel gek dat de VPS te veel gaat wachten op de harde schijf en uiteindelijk vast loopt.
Probleem is opgelost! Er zat een probleem in een Wordpress site, deze maakte steeds revision bestanden aan in MYSQL.
De tabel wp_posts bevatten 150.000 regels :P Dat is nu opgelost door een update van WP uit te voeren en de server draait weer optimaal!
Iedereen bedankt voor het meedenken!