S4Y - Server oft nicht erreichbar / unglaublich langsam

Nach Telfonat mit dem Support wurde mir mitgeteilt das aktuell (seit gestern Abend) alle vServer die mit 166xxx anfangen nicht erreichbar sind. Eine Zeit wann es wieder geht konnte er mir nicht sagen...:(

Meine ID: 166124
 
Ah, ist jetzt 166 dran :) 251 ist gestern Abend fertig geworden. Allerdinge habe ich keine Ambitionen, meinen vSERVER jemals wieder zu benutzen, nach der mittlerweile eh abgeschicken Kündigung zum Vertragsende (23.4.) versuche ich im Moment noch ne fristlose Kündigung aus wichtigem Grund zu erreichen. Weil:

17.11. - Totalausfall des Mainframes für auf jeden Fall mehr als 8 Stunden, ich stellte den ausfall erst morgens um 6 fest, gelaufen ist er am späten Nachmittag dann irgendwann wieder.

20.11. - im Schnitt alle 2 Stunden Kleinausfälle für 2-15 Minuten und generell schlechte Netzwerkperformance. Das hielt sich auch beharrlich so die nächsten Tage, am 24. Kündigung raus, übers Wochenende wars dann wieder erträglich.

27.11. - gegen 09:45 rum Totalausfall des Mainframes. Viel hin und her mit den Tickets, die Hotline war nicht involviert, die hat nämlich einfach aufgelegt auf meinen Anruf hin, ich möchte aufgrund der Boardregeln das Gesamtszenario nicht weiter erläutern.

27.11. - um 18:06 Meldung in den News "das Filesystem Ihres Hostsystems ist durch einen Defekt read-only gemountet worden. Dadurch ist ein Filesystemcheck notwendig geworden, der voraussichtlich bis in den morgigen Vormittag andauern wird."

28.11. - gegen 21:30 wurde der "morgige Vormittag" wohl erreicht, der Mainframe nebst meinem vSERVER lief wieder.

36 Stunden Ausfall. Kein Datenverlust. Also kann der Schaden so groß nicht gewesen sein, was die 36 Stunden irgendwo in meinen Augen nicht wirklich berechtigt (ich verbringe meinen Alltag jobbedingt auch in einem RZ, hätte ich innerhalb von 36 Stunden einen Ausfall nicht beseitigt, würde ich jetzt Arbeitslosengeld empfangen, denke ich). Ich hab die Nacht noch ne finale Sicherung angeworfen und heute morgen das Backup per scp nach daheim rübergezogen, werde heute Abend sehen, ob das geklappt hat.

Sprich - Die Ausfälle/Probleme häufen sich im Moment wohl etwas und werden vor allem auch jedes mal drastischer. Ist so mein Eindruck.

Weiss da irgendjemand was? Es lief das letzte halbe Jahr ja durchaus annehmbar, für das Geld erwarte ich kein perfektes Hosting, aber häufige mehrstündige Ausfälle sind einfach nicht akzeptabel. Details, was da los ist, wären willkommen, im Moment sehe ich davon ab, den vSERVER wieder zu benutzen, weil er mir zu instabil läuft, und das missfällt mir insofern, daß ich dann nen halbes Jahr für nix gezahlt hätte...
 
Bei meinen beiden vServers ist es seit 19.11. ein Drama. Laut meinem mitlaufenden Monitoring ist seit dem die Last gestiegen und damit Reaktionszeit gesunken. SSH-Login dauert bis zu 10 Sekunden, Apache reagiert sehr träge, selbst in den frühen Morgenstunden.

Mir ist nur aufgefallen, daß massive Scans nach einem Wiki-Exploid laufen, möglich, daß die die anderen vServer belasten oder aber etliche schon übernommen wurden.
 
10 Sekunden bei SSH? Also das fällt bei mir in die Kategorie "performant". Normalerweise schmeiss ich ssh an, geh aufs Klo, hol ein Bier, mach vielleicht noch was zu essen zwischendurch, und kann dann mein Passwort eintippen.

Ausnahme morgens um 6, wenn ich aufsteh, da dauerts nur wenige Sekunden.

Das mit der Last kann ich aber bestätigen. Allerdings ist das Gesamtverhalten wohl in mehrere Problemgruppen zu unterteilen:

Die VM-Performance ist gelegentlich miserabel. Man hat das Gefühl, daß die gesamte VM im Swap gelandet ist, und erstmal wieder reingeswappt werden muss. Bestätigt sich dadurch, daß es nach Reboot meist schneller geht (nein, mittlweile habe ich definitiv fast keinen Speicher mehr benutzt, weil Cyrus/Sendmail/Apache wirklich nicht die 256MB nutzen, mit clamav und SpamAssassin zusätzlich drin war die Situation völlig unerträglich, drum hab ich die vor ner Weile rausgeworfen).

Dazu kommt aber die Netzwerkperformance. Und die ist sehr interessant:
SSH/IMAPS/HTTPS sind stellenweise extrem lahm, während HTTP schnell ist. So braucht z.B. mein Thunderbird gelegentlich Minuten, bis er ne Verbindung hat, aber ein HTTP-Zugriff trotz forced Reload geht richtig fix. Am Besten konnte ich das hier auch die Tage im Geschäft vergleichen, wo ich den Webmailer auf HTTPS immer offen hatte, und dann in so Lahmphasen nebenher mal nen HTTP-Request mit Shift-Reload drauf losgelassen hab, der dann schnell geht.

Man könnte meinen, daß da noch irgendein fieses Traffic Shaping läuft.

Aber das Hauptproblem ist wohl eine permanente Überlastung des "Mainframes". Vielleicht aus Kostengründen zu viele VMs drauf? Gerade, weil auch der Mainframe zu den Kleinausfällen immer als "offline" angezeigt wird, später aber mit weiter gelaufener uptime wieder "online" ist. Das riecht doch so, als würde das PowerPanel da nicht an den Mainframe rankommen zur Datenabfrage, weil das Netzwerk generell zu ist oder der Kasten keine Zeit hat, um sich auch noch um die Monitoringanfragen zu kümmern.
 
Ich habe das gleiche Problem (superlangsam und hoher Load des Hostsystems). Besonders ärgerlich finde ich den Ticketsupport:

20.11

Die Performance meines vServers ist seit heute heute Mittag sehr schlecht. Die Beancounterswerte werden zwar beim Start erreicht, überschreiten aber beim normalen Betrieb nicht die Barrieren. Dennoch ist mein vServer und die darauf gelagerten Webseiten schlecht (langsam) bis gar nicht (Internal Server Error) erreichbar.

20.11

Sehr geehrter Kunde,

vielen Dank für Ihre Mitteilung.

Ihr Anliegen ist an die für Sie zuständige Fachabteilung weitergeleitet worden.

Sobald alle erforderlichen Informationen vorliegen, werden wir uns zeitnah wieder bei Ihnen melden.

21.11

Auffällig ist übrigends auch der hohe Load, der sich zwischen 3,5 und 8 bewegt.

28.11

Ich warte seit 8 Tagen auf eine Problembehebung seitens Ihnen.

Bitte teilen SIe mir mit, wann ich meinen virtuellen Server wieder wie gewohnt benutzen kann.

30.11

derzeit können wir kein allgemeines Problem auf dem Hostsystem Ihres vServers feststellen.

Die Virtuallisierung limitiert die Ressourcen des Hostsystems, um eine gerechte Verteilung zwischen den vServer zu gewährleisten. Meist entstehen die Probleme (Ausfälle, lange Reaktionszeiten) lokal, das heisst innerhalb des vServers und nicht des gesammten Hostsystems. Daher sollten Sie prüfen, ob Ihr Server ausgelastet ist.

01.12

Wie erklären Sie sich dann bitte folgenden Inhalt von top?

top - 17:09:18 up 1 day, 3:32, 1 user, load average: 17.40, 13.22, 7.33

Diesen habe ich heute um 17:09 Uhr kopiert. Auffällig ist wie schon gesagt die hohe Load Average, die mit Sicherheit nicht durch mich verursacht werden kann, jedoch durch einen Fehler im Hostsystem verursacht werden wird.

Das hat mir ein Mitarbeiter an Ihrer Hotline übrigends bestätigt.

Sollten Sie nicht in der Lage sein, das Problem bis zum 7. Dezember zu lösen, werde ich Ihnen eine Kündigung schreiben. Da Sie Ihre Leistungen nicht erbringen, und ich meinen vServer zur Zeit kaum benutzen kann (seit dem 20.11; siehe Ticketdatum) werde ich mich auf mein Sonderkündigungsrecht beziehen.

Bitte lösen Sie das Problem, da ich bis jetzt mit Ihnen sehr zufrieden war. Über eine Stellungnahme würde ich mich freuen.
Click to expand...

Ich bin echt frustriert, dass sich seitens Server4You überhaupt *nichts* tut und ich schon eine Kündigungsdrohung machen muss.

Martin
 
He, klasse. Scheinbar reden wir auch nur mit Maschinen oder die Mitarbeiter vom Support sind nicht sehr kreativ (und haben fertige Texte), denn genau der gleichen Text mit Resourcen und Virtualisierung habe ich auch bekommen. Erst als meine 3. Antwort dann nicht mehr vom Patternmatching abgedeckt wurde (die nächste Antwort enthielt nämlich die Tips mit TOP und PS ist bei vServer nicht gut, vztop wäre besser - was ich bereits beim öffnen des Tickets als Quelle meiner Erkenntnisse geschrieben hatte), kam dann gar keine Antwort mehr und meine beiden Tickets liegen seit dem rum - und ja, bei beiden gab es die gleichen Antworten.
 
Hi,

nur mal als Info, die Load Average in einer VPS ist auch die tatsaechliche VPS Load, die wird nicht durch Nachbarn direkt beeinflusst. Wenn deine VPS ne Load von 17 hat, frag ich mich grad ernsthaft was du tust?
 
Hi Maik,
sorry, das wusste ich dann nicht.

Was mich nur wundert ist, dass mir top keinen Prozess mit über 1% CPU Auslastung anzeigt und dennoch die Load Average erschreckend hoch ist. Vorher gab es das Problem nicht, ich hab nichts, rein gar nichts an der Konfiguration geändert. Außerdem gab es hier ein paar Beiträge mit den gleichen Problemen. Zur Zeit ist die l-a bei 1,0, was eigentlich in Ordnung scheint. Dennoch sind dynamische Webseiten sehr langsam zu erreichen (Bsp. Soccer-on-Earth | Forum | Startseite war vorher innerhalb von 1er Sekunde da), was vorher unglaublich schnell war.

Vielleicht möchtest du ja mal einen Blick auf meinen vServer 2061068 werfen, seit dem 20. sind jedenfalls alle dyamischen Webseiten, IMAP und Co sehr lahm. Bei Stoßzeiten ist die Load Average auch sehr hoch, auch wenn der Apache nicht läuft und es keine Prozesse mit über 1% CPU Auslastung gibt.

Habt ihr vielleicht was an der Ressourcenzuteilung geändert?

Achja, beancounters:

Code: 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
   2061068: kmemsize        3465308    7060211    7056211    7761832     199345
            lockedpages           0          4        344        344          0
            privvmpages       37454      88529      87632      96396       7821
            shmpages            677       2725      19567      19567          0
            dummy                 0          0          0          0          0
            numproc              59        126        128        128          0
            physpages         11659      49653          0 2147483647          0
            vmguarpages           0          0      65536 2147483647          0
            oomguarpages      13024      53099      65536 2147483647          0
            numtcpsock           46        145        172        172      10540
            numflock              6         13        224        246          0
            numpty                1          1         16         16          0
            numsiginfo            0         23        512        512          0
            tcpsndbuf        193836    1067212    1416560    2768240    4724455
            tcprcvbuf           692     282216    1416560    2768240     309541
            othersockbuf      11140     590216     655717    1153621      71234
            dgramrcvbuf           0     384840     655717     655717          0
            numothersock         14         54        228        228          0
            dcachesize       499084     700974    1002127    1032191          0
            numfile            1171       2240       2240       2240       6844
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10         64         64          0

Die held Werte bewegen sich immer unter der barrier, nur beim Start werden diese anscheinden überschritten, dadurch tauchen die failcnts auf.

Danke,
Martin
 
Last edited by a moderator:
Hi!
Eigentlich ist es eine relativ einfache Standard Lamp Konfiguration mit Ubuntu 6.06, er startet Apache, Lighttpd, Exim, Courier, Spamassassin, sshd, Proftpd, MySQL und logds - ich beantrage aber nochmal einen Reboot um herauszufinden, ob dann die Limits wieder so hochgeknallt sind.
 
Yup, es ist wirklich das Booting:

Code: 
server01:~# cat /proc/user_beancounters 
Version: 2.5                                                                   
       uid  resource           held    maxheld    barrier      limit    failcnt
   2061068: kmemsize        3464647    7060211    7056211    7761832     199345
            lockedpages           0          4        344        344          0
            privvmpages       40774      88529      87632      96396       7821
            shmpages            676       2725      19567      19567          0
            dummy                 0          0          0          0          0
            numproc              51        126        128        128          0
            physpages         19271      49653          0 2147483647          0
            vmguarpages           0          0      65536 2147483647          0
            oomguarpages      19282      53099      65536 2147483647          0
            numtcpsock           28        145        172        172      10540
            numflock              6         13        224        246          0
            numpty                1          1         16         16          0
            numsiginfo            0         23        512        512          0
            tcpsndbuf          6684    1067212    1416560    2768240    4724455
            tcprcvbuf             0     282216    1416560    2768240     309541
            othersockbuf      19616     590216     655717    1153621      71234
            dgramrcvbuf           0     384840     655717     655717          0
            numothersock         18         54        228        228          0
            dcachesize       543282     700974    1002127    1032191          0
            numfile            1158       2240       2240       2240       6844
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10         64         64          0
server01:~# uptime
 00:17:10 up 2 min,  1 user,  load average: 0.73, 0.32, 0.11
server01:~#

Das war aber schon vorher so, als die Seiten auch schnell abrufbar waren :)
 
Last edited by a moderator:
Bei mir treibt ein simpler reboot die Load auf über 2. Starten von apache, sshd und postfix sollten aber sowas nicht schaffen - taten sie jedenfalls bis vor 2 Wochen noch nicht. Jetzt reichen 2 simple http-Requests, um die Load auf 1 zu treiben und sie tun dabei nicht wirklich viel, außer Dateien 1:1 rauszujagen.
 
Jo, ich kann es reproduzieren:

Code: 
16259 soe_main  16   0 20024 8980  14m R    4  0.1   0:00.17 php-cgi                                                                                         
16272 mirco     16   0 19276 8256  14m R    3  0.1   0:00.13 php-cgi                                                                                         
16331 mirco     16   0 16440 4352  14m R    1  0.1   0:00.04 php-cgi                                                                                         
16347 soe_main  18   0 16440 4504  14m R    1  0.1   0:00.04 php-cgi                                                                                         
    1 root      15   0  1488  532 1320 S    0  0.0   0:00.32 init                                                                                            
26081 root      16   0  1592  484 1416 S    0  0.0   0:00.00 dd

(das sind zumindest die Prozesse, die über 0,1% CPU Last erzeugen)

und
load average: 6.45, 4.48, 2.83
Click to expand...

Maik, habt ihr das so bewusst umgeändert? Ist etwas blöd, weil seit der Änderung alles wirklich sehr viel langsamer ist.
 
Mein Server4You Vserver = Schnecke !

Da dieser Beitrag geschlossen wurde, mache ich mal hier weiter.

Es handelt sich um einen Vserver Basic von Server4You mit Suse 9.3 und Confixx 1.4 der nur noch Lahmt.

cat /proc/user_beancounters

Code: 
vs206xxxx:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
   206xxxx: kmemsize        2668266    4069042    7056211    7761832          0
            lockedpages           0          8        344        344          0
            privvmpages       27886      51162      87632      96396          0
            shmpages            769       3489      19567      19567          0
            dummy                 0          0          0          0          0
            numproc              24         48        128        128          0
            physpages         19977      28580          0 2147483647          0
            vmguarpages           0          0      65536 2147483647          0
            oomguarpages      20198      34081      65536 2147483647          0
            numtcpsock           12         25        172        172          0
            numflock              5         11        224        246          0
            numpty                1          1         16         16          0
            numsiginfo            0          6        512        512          0
            tcpsndbuf          4456     187152    1416560    2768240          0
            tcprcvbuf             0     192420    1416560    2768240          0
            othersockbuf     138136     549108     655717    1153621          7
            dgramrcvbuf           0      12828     655717     655717          0
            numothersock        102        137        228        228          0
            dcachesize       598102     659810    1002127    1032191          0
            numfile            1232       2036       2240       2240          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            25         25         64         64          0

ps -aux

Code: 
vs206xxxx:~ # ps -aux
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0    608   252 ?        Ss   16:48   0:00 init [3]
root     25634  0.0  0.0   1460   652 ?        Ss   16:49   0:00 /sbin/syslogd -a /var/lib/named/dev/log -a /var/lib/ntp/dev/
root     25638  0.0  0.0   1400   472 ?        Ss   16:49   0:00 /sbin/klogd -c 1 -x -x
vscan    25668  0.0  0.2  19948 17340 ?        S    16:49   0:02 /usr/sbin/clamd
root     25690  0.0  0.0   3992  1156 ?        Ss   16:49   0:00 /usr/sbin/saslauthd -a pam -n 1
root     25706  0.0  0.0   2380  1136 ?        S    16:49   0:00 /bin/sh /usr/bin/mysqld_safe --user=mysql --pid-file=/var/li
mysql    25776  0.0  0.0  26304  6856 ?        Sl   16:49   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --u
root     25785  0.0  0.0   4532  1964 ?        Ss   16:49   0:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
root     25793  0.0  0.0   2076   932 ?        Ss   16:49   0:00 /usr/sbin/xinetd
root     25964  0.0  0.0   4316  1532 ?        Ss   16:49   0:00 /usr/lib/postfix/master
postfix  25988  0.0  0.0   4392  1476 ?        S    16:49   0:00 qmgr -l -t fifo -u
root     26061  0.0  0.1  24816  9544 ?        Ss   16:49   0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
root     26063  0.0  0.0   3204  1452 ?        S    16:49   0:00 /usr/bin/perl /usr/local/confixx/pipelog.pl
root     26068  0.0  0.0   1668   760 ?        Ss   16:49   0:00 /usr/sbin/cron
vscan    26076  0.0  0.0   3752  1328 ?        Ss   16:49   0:00 /usr/bin/freshclam -d
vscan    26108  0.0  0.4  40120 36268 ?        Ss   16:49   0:00 amavisd (master)
vscan    26241  0.0  0.4  40120 36268 ?        S    16:49   0:00 amavisd (virgin child)
wwwrun   23605  0.0  0.1  28388 14176 ?        S    17:33   0:03 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
wwwrun   17889  0.0  0.1  27528 13272 ?        S    18:17   0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
postfix  29973  0.0  0.0   4356  1436 ?        S    18:28   0:00 pickup -l -t fifo -u
root      5700  0.0  0.0   7592  2460 ?        Rs   18:35   0:00 sshd: root@pts/0
root      5734  0.0  0.0   2712  1740 pts/0    Ss   18:35   0:00 -bash
root      9291  0.0  0.0   2380   860 pts/0    R+   18:38   0:00 ps -aux

vzfree

Code: 
vs206xxxx:~ # vzfree
VPS Speichernutzung:
Momentan genutzt:       109.531 MB
Zugesichert:            256 MB
Maximal nutzbar:        376.547 MB

Top

Code: 
    1 root      16   0   608  252  456 S  0.0  0.0   0:00.19 init
25634 root      16   0  1460  652 1288 S  0.0  0.0   0:00.00 syslogd
25638 root      15   0  1400  472 1236 S  0.0  0.0   0:00.00 klogd
25668 vscan     16   0 19948  16m 3468 S  0.0  0.2   0:02.25 clamd
25690 root      18   0  3992 1156 3640 S  0.0  0.0   0:00.00 saslauthd
25706 root      16   0  2380 1136 2180 S  0.0  0.0   0:00.00 mysqld_safe
25776 mysql     16   0 26304 6856 7652 S  0.0  0.1   0:00.02 mysqld
25785 root      16   0  4532 1964 4136 S  0.0  0.0   0:00.28 sshd
25793 root      17   0  2076  932 1752 S  0.0  0.0   0:00.00 xinetd
25964 root      16   0  4316 1532 4100 S  0.0  0.0   0:00.00 master
25988 postfix   16   0  4392 1476 4180 S  0.0  0.0   0:00.00 qmgr
26061 root      16   0 24816 9544  21m S  0.0  0.1   0:00.36 httpd2-prefork
26063 root      15   0  3204 1452 2724 S  0.0  0.0   0:00.02 pipelog.pl
26068 root      16   0  1668  760 1496 S  0.0  0.0   0:00.00 cron
26076 vscan     16   0  3752 1328 3524 S  0.0  0.0   0:00.00 freshclam
26108 vscan     16   0 40120  35m 6072 S  0.0  0.4   0:00.82 amavisd
26241 vscan     18   0 40120  35m 6072 S  0.0  0.4   0:00.00 amavisd
23605 wwwrun    16   0 28388  13m  21m S  0.0  0.2   0:03.16 httpd2-prefork
17889 wwwrun    16   0 27528  12m  21m S  0.0  0.2   0:00.99 httpd2-prefork
29973 postfix   16   0  4356 1436 4144 S  0.0  0.0   0:00.00 pickup
5700 root      16   0  7592 2464 7012 S  0.0  0.0   0:00.03 sshd
5734 root      17   0  2712 1740 2368 S  0.0  0.0   0:00.03 bash
14101 root      16   0  1984 1064 1760 R  0.0  0.0   0:00.01 top
 
Übrigends, mein vServer ist jetzt wieder geschmeidig erreichbar. Danke an Maik oder denjenigen, der das Problem behoben hat! :)
 
Hallo.

Ich hab leider auch noch das Problem, das mein VServer ziemlich lahm ist. Das ist jetzt mittlerweile seit knapp 2 Wochen so und ich würde gerne mal wissen, wieso das so ist.

vs2062137
 
Hi,
s4y kommt mit der Bandbreitenicht klar.
niedrige Preise locken neue User an, und damit teilen die die Bandbreite imemr mehr auf.
Somit wird alles langsamer, dies ist bewiesen.
10 mbit ist ein Witz.
 
Hi,

nur mal so als Info, der Thread hier hat nichts mit S4Y dedicated zu tun und ich moechte auch nicht das er dazu abgleitet. Was ihr da fuer Probleme habt (mit Bandbreite was auch immer) hat hiermit nichts zutun. :)
 
Obwohl mein Server4You Vserver Basic 206xxxx seit gestern ca 20:00Uhr wieder sauschnell ist möchte ich euch die unverschämte Antwort des Supports nicht vorenthalten.

Mein Ticket am 03.12.06 - 10:31:14:
Können sie mir sagen warum mein Vserver nur noch Lahmt und wie lange ich das noch ertragen muss ?

Die Antwort von Server4You am 04.12.06 - 12:57:18:
Sehr geehrter Herr Txxxxxxx,

ihr Server hat öfters die Resourcenlimits überschritten. Die Überschreitung haben sehr wahrscheinlich zu einer Beeinträchtigung der laufenden Dienste beigetragen, die zu ihrem angesprochen Problem führten. Eine Erklärung der einzelnen Felder erhalten Sie auf folgender Webseite: SWsoft – Forums - Memory Allocation Parameters / user_beancounters in Virtuozzo 2.6.2 . Unter Linux können Sie bspw. mit den folgende Befehlen, die Ressourcen, die ein Prozesse verbraucht, analysieren: ps, lsof, pmap.

-------------------------------------
resource held maxheld barrier limit failcnt
othersockbuf 138136 549108 655717 1153621 7
------------------------------------

Mit freundlichen Grüßen
Sxxxxx Hxxxxx

@all Habe mich inzwichen an den Verbraucherschutz gewendet und dort wurde mir geraten über die nicht erbrachte Leistung genau buch zu führen.
Wenn es für mich wirklich unerträglich wird, werde ich in zusammenarbeit mit dem Verbraucherschutz die Jungs vor Gericht zerren, denn es reicht !

@mbroemme Ich bin der, der zu Doof ist den Reboot Button zu drücken :mad:
 
Last edited by a moderator:
Hallo!
Und jetzt erklär uns noch, was an der Antwort unverschämt ist.

mfG
Thorsten
 
You must log in or register to reply here.
Back
Top