S4Y - Server oft nicht erreichbar / unglaublich langsam

stadie

Registered User
Und mal wieder hängt mein vServerchen von S4Y.
Nachdem er gestern überraschend Offline war um eine Migration durchzuführen um "Ressourcen auf den Hostsystem freischaffen zu können" ist er zwar wieder Online - aber die Ressourcen wurden wohl auf einem anderen Server freigemacht. Bis ein apt-get update mal durch ist können schon mal 30 Minuten ins Land ziehen - Apache liefert Seiten oft erst nach 30 Sekunden und mehr (oder garnicht) aus. Vielleicht liegts ja an meiner Konfiguration - aber das ist wohl eher Wunschdenken. Reboot hat nichts gebracht. Hier mal ein paar Daten zum System:

Code:
cat /proc/user_beancounters 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
    170213: kmemsize        2262462    7060552    7056211    7761832         92
            lockedpages           0          0        344        344          0
            privvmpages       19597      82872      87632      96396          0
            shmpages           1921      19420      19567      19567        187
            dummy                 0          0          0          0          0
            numproc              37        126        128        128          0
            physpages         12957      45353          0 2147483647          0
            vmguarpages           0          0      65536 2147483647          0
            oomguarpages      12990      48069      65536 2147483647          0
            numtcpsock           66        172        172        172         31
            numflock              7         32        224        246          0
            numpty                3          3         16         16          0
            numsiginfo            1         60        512        512          0
            tcpsndbuf         17824    1421464    1416560    2768240         34
            tcprcvbuf             0     808164    1416560    2768240          0
            othersockbuf      54164     211108     655717    1153621          0
            dgramrcvbuf           0      12648     655717     655717          0
            numothersock         30        164        228        228          0
            dcachesize       351794     611008    1002127    1032191          0
            numfile             999       2240       2240       2240       1127
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         42         64         64         12

Code:
df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs             5.0G  3.6G  1.5G  72% /
tmpfs                 3.0G  4.0K  3.0G   1% /dev/shm

Code:
  ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   1872   640 ?        Ss   05:04   0:00 init [2]      
root      3437  0.0  0.0   1560   600 ?        Ds   05:11   0:00 /sbin/syslogd
root      3532  0.0  0.0   1500   472 ?        Ss   05:11   0:00 /sbin/klogd -x
root      5775  0.0  0.0   1668   620 ?        Ss   05:11   0:00 /usr/sbin/inetd
root      6103  0.0  0.0   8752  1076 ?        Ssl  05:12   0:00 /usr/sbin/nscd
root      7207  0.0  0.0   6204  1512 ?        Ss   05:12   0:00 /usr/sbin/saslauthd -n 1 -a pam
root      7219  0.0  0.0   4948  1736 ?        Ss   05:12   0:00 /usr/sbin/sshd
root      7333  0.0  0.0   2140   876 ?        Ss   05:12   0:00 /usr/sbin/cron
root      7414  0.0  0.0   1520   504 ?        Ss   05:12   0:00 /usr/sbin/portsentry -tcp
root      7438  0.0  0.0   1520   500 ?        Ss   05:12   0:00 /usr/sbin/portsentry -udp
root      7500  0.0  0.0   8332  2216 ?        Ss   05:12   0:00 sshd: root@pts/0 
root      7506  0.0  0.0   2700  1448 pts/0    Ss   05:12   0:00 -bash
bnc       7720  0.0  0.0   4228  2044 ?        S    05:13   0:00 ./psybnc
root     19711  0.0  0.1  12120 10308 pts/0    R+   05:26   0:00 apt-get upgrade
root     20069  0.0  0.0   8336  2244 ?        Ss   05:27   0:00 sshd: root@pts/1 
root     20175  0.0  0.0   2700  1460 pts/1    Ss+  05:27   0:00 -bash
root      7732  0.0  0.0   8336  2312 ?        Rs   05:46   0:00 sshd: root@pts/2 
root      7736  0.0  0.0   2716  1504 pts/2    Ss   05:46   0:00 -bash
root     14284  0.0  0.0   2384  1172 pts/1    S    05:55   0:00 /bin/sh /usr/bin/mysqld_safe
mysql    15485  0.0  0.1  19824  6384 pts/1    Sl   05:56   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pidroot     15486  0.0  0.0   1488   492 pts/1    S    05:56   0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
root     21641  0.0  0.1  27088  7708 ?        Ss   06:34   0:00 /usr/sbin/apache2 -k start
root     21646  0.0  0.0   3080  1364 ?        S    06:34   0:00 /usr/bin/perl /usr/local/confixx/pipelog.pl
root     32089  0.0  0.1  10828  9244 pts/0    D+   06:51   0:00 /usr/bin/dpkg --status-fd 14 --unpack /var/cache/apt/archives/bsdutils_1%3a2.12r-15_i386.deb
nobody   32495  0.0  0.0      0     0 ?        Ds   06:53   0:00 [proftpd]
root      1494  0.0  0.0   2820  1404 ?        Ds   06:55   0:00 proftpd
root      1662  0.0  0.0   2824  1404 ?        Ds   06:57   0:00 proftpd
www-data  1753  0.0  0.1  28404  9832 ?        S    06:58   0:00 /usr/sbin/apache2 -k start
root      1824  0.0  0.0   2500  1124 ?        Ds   06:59   0:00 proftpd
www-data  5301  0.0  0.1  28400  9828 ?        S    07:00   0:00 /usr/sbin/apache2 -k start
www-data  5380  0.1  0.1  30108 11560 ?        S    07:00   0:00 /usr/sbin/apache2 -k start
www-data  5600  0.2  0.1  28408  9884 ?        S    07:00   0:00 /usr/sbin/apache2 -k start
www-data  5697  0.1  0.1  29540 11072 ?        S    07:00   0:00 /usr/sbin/apache2 -k start
www-data  5868  0.0  0.1  28316  9596 ?        S    07:00   0:00 /usr/sbin/apache2 -k start
root      7255  0.0  0.0   2368   840 ?        Ds   07:01   0:00 proftpd
root      7827  0.0  0.0   2364   836 ?        Ds   07:03   0:00 proftpd
root      7914  0.0  0.0   2156   760 pts/2    R+   07:04   0:00 ps aux

Code:
 cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 4
cpu MHz         : 76.603
cache size      : 1024 KB
physical id     : 0
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid
bogomips        : 5505.02

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 4
cpu MHz         : 76.603
cache size      : 1024 KB
physical id     : 0
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid
bogomips        : 5586.94

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 4
cpu MHz         : 76.603
cache size      : 1024 KB
physical id     : 3
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid
bogomips        : 5586.94

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 4
cpu MHz         : 76.603
cache size      : 1024 KB
physical id     : 3
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid
bogomips        : 5586.94

cpu MHz : 76.603 <--- ist das eigentlich normal für einen "Intel(R) Xeon(TM) CPU 2.80GHz"? Kann sich da ein Fehler durch die Virtualisierung eingeschlichen haben?

Code:
cat /proc/stat
cpu  8076 0 11542 432387 4088138 0 0
cpu0 1347 0 4204 123999 1014094 0 0
cpu1 1320 0 2922 107666 1019762 0 0
cpu2 971 0 1552 113533 1031915 0 0
cpu3 4436 0 2862 87187 1022365 0 0
intr 0
swap 0 0
ctxt 286366582778
btime 1142248842
processes 320539491
procs_running 1
procs_blocked 0

Hat jemand eine Idee was man da machen könnte?
 
Last edited by a moderator:
In in dem Thread auch:
 
Gleiches Problem, siehe:
Vielleicht solltest du noch deine vServer id posten, sollte Maik mal vorbeischauen :)
 
Die UID (170213) steht doch bei den beancounters dabei :-)
Ich hab das Gefühl es liegt an der io-performance - aber das ist nur geraten.
 
Seltsam ist halt, daß es mehrere vServer trifft. Ich weiß zwar nicht, ob meine beiden nicht vielleicht doch auf dem selben Host liegen, aber wenn nicht, ist das doch ein klarer Nachweis, daß das ein generelles Problem ist.

Wie schon im anderen Thread geschrieben, wurden in den Logfiles bei mir massive Scans auf irgendwelche seltsamen Web-URLs durchgeführt - Exploits vermutlich. Wenn da der ganze IP-Block von s4y gescannt wird und dann vielleicht noch einige Erfolg haben, dann würde das Verhalten nicht verwundern. Aber scheinbar müssen erst mehr Tickets bei s4y geöffnet werden, bevor man sich über die Menge gedanken macht und doch an ein Problem glaubt.
 
Ich bin ja ebenfalls der Meinung, dass es sich hierbei um ein generelles Problem bei S4Y handelt.

Mein vServer liegt auf einem anderen Host (Opteron als Prozessor) und auch dort gibt es Phasen, wo das alles super läuft und die Seiten auch normal ausgeliefert werden. Das ist meist nachts der Fall.

Hauptsächlich -tagsüber- schleicht das System ziemlich oft. Das og. Problem mit apt-get kenne ich nur zu gut.

Die Netzwerkanbindung hingegen ist aber super, daran kann es nicht liegen.

Gruß
 
Ist ein generelles Problem! Habe grade mit der Hotline gesprochen und da wusste man schon, daß da was nicht richtig läuft...
Genauere Infos konnte man mir nicht geben.
Man hofft, daß das Problem im laufe des Tages behoben wird. :mad:
 
MOD: Full-Quote entfernt!

Das sollte gestern schon der Fall sein. Ich hoffe es dauert nicht wieder 7 Tage bis sich da was tut. Manmanman :mad:
 
Last edited by a moderator:
Hey.

Ich bin erst neu in der ganzen Virtuellen Server geschichte und bin auch noch nicht so wirklich sicher in sachen Linux.

Mein virtueller Server ist aber auch seit circa 1 Woche sehr sehr langsam. Bzw. liegt es glaub ich, an der Datenbank anbindung. Wenn ich in einem Unterprojekt bin, welches aus reinem HTML besteht, ist die Seite gewohnt sau schnell.
Wenn ich mich aber in der Copperminegalerie oder in dem PHPBB2Plusforum auf dem Server bewege, ist der Server langsam. Im Footer des Forum lass ich immer anzeigen, wie die Ladezeit der SQLanbindung war. Bis vor einer Woche hat das öffner einer Seite knapp 0,5 sec. gedauert, was auch normal ist.

Mittlerweile hab ich ladezeiten zwischen 1,5sec (wenn mal gut läuft) und 7sec.

Hab den MYSQL Dienst mal restartet und auch den Server neu gestartet. Nix. Null erfolg.

Liegt das evt. an den allgemeinen Problemem bei Server4you?

Achja, meine ServerID: vs2062137

Laut dem PowerPanel ist bei meinen VServer alles im grünen Bereich.

Gruß Hexo
 
Ich denke, es liegt nicht an den Datenbankanbindung sondern einfach daran, dass PHP sehr CPU belastend ist. Nur sind die Hostsysteme zur Zeit völlig ausgelastet, sodass das Generieren etwas dauert.
 
Schau dir die beancounters an, ich schätze, dass dein Server am Limit ist und nicht unbedingt das Hostsystem. Eventuell hast du doch noch zu viele andere Dinge auf dem Server laufen.
 
Server4You hat seit dem 20. Probleme, siehe auch die anderen Beiträge..
 
Last edited by a moderator:
Ich hab eigentlich auf dem Server nix neben dem Forum und der Galerie laufen. Ein Backup des Servers liegt auch auf nem Webspace von Funpic und da läuft die Seite super.

Ich hab leider keine Ahung wie man die Auslastung von dem Server interpretiert. Mit "top" kann ich ja die momentane auslastung sehen (über das shell)

Bitte könnt ihr mal drüber schauen, und mir sagen wie stark das system ausgelastet ist? Hexo=noob!

MOD : Bilder bitte immer als Anhang.
 

Attachments

  • cpu_auslastung.png
    cpu_auslastung.png
    20.1 KB · Views: 184
Last edited by a moderator:
Uff, vielleicht habe ich doch falsch geraten.

Rechts oben, die erste Zahl rechts neben load average, kannst du die mal überwachen?

Ist die oft über 2?

Martin
 
Auf anraten von @stadie hab ich mal folgenden befehl ausgeführt:


cat /proc/user_beancounters

das Ergebniss:

PHP:
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
   2062137: kmemsize        3062907    6186068    9384760   10323236          0
            lockedpages           0          0        430        430          0
            privvmpages       45172      72231     131448     144594          0
            shmpages            641       2017      23020      23020          0
            dummy                 0          0          0          0          0
            numproc              28         74        144        144          0
            physpages         15247      37530          0 2147483647          0
            vmguarpages           0          0      98304 2147483647          0
            oomguarpages      29435      52067      98304 2147483647          0
            numtcpsock           16         87        244        244          0
            numflock              5         45        336        369          0
            numpty                1          1         24         24          0
            numsiginfo            0          8        768        768          0
            tcpsndbuf        345340    1265504    1884024    3681759          0
            tcprcvbuf             0     154440    1884024    3681759          0
            othersockbuf     164872     502912     844366    1481926          0
            dgramrcvbuf           0       2920     844366     844366          0
            numothersock        103        288        288        288         37
            dcachesize       582752     730270    1503190    1548286          0
            numfile            1259       2945       3360       3360          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10         96         96          0

Leider kann ich das nicht interpretieren ;-(
Was genau sagt mir das?

achso, meine Servernr. ist: vs2062137
 
Auf anraten von @stadie hab ich mal folgenden befehl ausgeführt:

cat /proc/user_beancounters

[...]
Was genau sagt mir das?
[...]

Aus dem Netz:

"Die User Beancounters sind ein Set von pro-VE-Ressourcenzählern, Limits und Garantien. Es gibt etwa 20 Parameter, die sorgfältig ausgewählt werden müssen, um alle Aspekte der VE-Funktionalität zu berücksichtigen. Damit darf jedes einzelne VE nur die zugewiesenen Ressourcen nutzen und keinen Einfluss auf das Hostsystem oder andere VEs haben.

Die kontrollierten Ressourcen sind RAM und verschiedene in-kernel-Objekte wie IPC shared memory segments, network buffers usw. Jede Ressource kann man in /proc/user_beancounters anschauen. Hier werden 5 Werte für jeden einzelnen Parameter angezeigt: Aktuelle Auslastung, maximale Auslastung, Soft-Limit, Hard-Limit und fail counter.

Die Bedeutungen von Soft-Limit und Hard-Limit sind verschieden und hängen von Parametern ab. Generell gilt: wenn irgendeine Ressource das Limit überschreitet, wird der entsprechende fail counter erhöht. So kann der Besitzer des VEs, falls irgendein Problem im VE auftritt, die Ausgabe von /proc/user_beancounters analysieren und mögliche Ursachen ausfindig machen."

Mit anderen Worten: Der Fehler liegt IMHO vermutlich nicht daran dass Du an die in den user_beancounters angezeigten Grenzen Deiner von Deinem Provider zugeteilten Ressourcen kommst. Weiteres per PM.

Viele Grüße
Stadie
 
Last edited by a moderator:
Also die Erklärung ist klasse. Super. Dann weiß ich auf jeden Fall schon mal wieder ein wenig mehr. Ich hab Dir ne PN geschickt.
Super Forum hier. Ohne ******. Wirklich super!!!!!
Daumen hoch!!!
 
Back
Top