iowaits schaukeln sich wieder hoch

E

elmo

New Member
Hi,

bei meinem s4y Vserver schaukelt sich wieder die iowait Werte hoch, soweit bis der Server kaum mehr benutzt werden kann (mysql Zugriffe zB bleiben hängen). Kann ich da irgendwas machen? Da bleibt dann alles furchtbar arg hängen oder ist ganz zäh. Alle anderen Prozesse scheinen flüssig zu laufen - nur Prozesse mit argen Plattenzugriff bleiben fast stehen oder laufen ins leere. :confused:

Grüße
elmo
 
Wieviel RAM hat denn der vServer?

Wenn zudem die HDD des Hosts langsam ist bzw. von anderen stark beansprucht wird, dann kann man recht wenig machen.
 
Hallo mr_brain. ;)

Also, RAM ist nicht viel vorhanden, aber ich bin der Meinung damit recht sparsam umzugehen - will sagen, ich habe meine Einstellungen recht konservativ gehalten.

Code: 
             total       used       free     shared    buffers     cached
Mem:       1310720     374692     936028          0          0          0
-/+ buffers/cache:     374692     936028
Swap:            0          0          0

Code: 
less user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
    156229: kmemsize                  6774440             14623446             17777274             19555001                    0
            lockedpages                     0                    0                  868                  868                    0
            privvmpages                 87258               147768               327680               344064                    0
            shmpages                      646                 1302                25078                25078                    0
            dummy                           0                    0                    0                    0                    0
            numproc                        50                  136                  434                  434                    0
            physpages                   74613               117221                    0  9223372036854775807                    0
            vmguarpages                     0                    0               131072  9223372036854775807                    0
            oomguarpages                74613               117221               163840  9223372036854775807                    0
            numtcpsock                     25                  196                  434                  434                    0
            numflock                        5                   20                  694                  763                    0
            numpty                          1                    2                   43                   43                    0
            numsiginfo                      0                   14                 1024                 1024                    0
            tcpsndbuf                  414272               953392              4148094              5925758                    0
            tcprcvbuf                  409600              1217280              4148094              5925758                    0
            othersockbuf               178144               625552              2074047              3851711                    0
            dgramrcvbuf                     0               104280              2074047              2074047                    0
            numothersock                  109                  236                  434                  434                    0
            dcachesize                 140859               305694              3883246              3999744                    0
            numfile                      4119                 5201                 6944                 6944                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      30                   30                  128                  128                    0

Grüße
elmo
 
Last edited by a moderator:
elmo said:
Kann ich da irgendwas machen?
Click to expand...

... kündigen! Hab ich auch gemacht, jetzt geht´s mir besser :-)
Die selbe Config auf einem Stravo vServer läuft ohne Probleme,
obwohl mir s4y in mehreren Tickets die Schuld in die Schuhe schieben wollte.

Kleiner Denkanstoss:
Hohe iowaits und ein hoher Load liegen nicht immer an Kunden,
sondern können auch an einem überlasteten Hostsystem liegen.

Aber mach Dir wegen Tickets nicht so die Hoffnung, dieser Text
wird Dir des öfteren entgegen kommen:

Sehr geehrter Kunde,

es ist temp. möglich dass auf dem Server eine hohe Plattenlast vorhanden ist. Trotz der Virtualisierung lässt sich dies nicht vermeiden. Im Moment kann ich keine Probleme auf dem Hostsystem erkennen. Die Last ist im normalen Bereich.
Click to expand...

Aber genug des "Druckablassens" :-)
Du könntest wenn Du Ram übrig hast versuchen die Tabellen zu cachen,
also in den Ram zu legen. Dann minimierst Du die Plattenzugriffe. Je nach
Ram könntest Du an der Mysql-Config schrauben.

lg
Basti
 
Last edited by a moderator:
Also im Grunde bin ich ja bisher zufrieden. Ich war zuvor bei 2 anderen Providern mit virtuellen Webservern und hatte so wirklich meine Probleme. Die haben mir auch immer die Schuld in die Schuhe gesteckt. Haben mir irgendwas vom Pferd erzählt... :confused:

Ist halt nicht alles Gold was glänzt, das muss ich leider nun auch bei meinem DSL und VoIP Anbieter bemerken, der nicht mal T.38 anbietet und ich mir die Anschaffung eines FAX Gerätes hätte sparen können.

Geiz ist geil ist halt doch nicht so dolle.

Grüße
elmo
 
Ich musste leider auch leidvoll feststellen was der Satz "you get what you payed for" so bedeutet. Ich hab mich von 1blu über ISPone zu server4you so durchprobiert, und bin ständig auf die Fresse gefallen... Strato scheint bis jetzt (klopf, klopf) die richtige Entscheidung gewesen zu sein. (Danke Marneus :D)
 
Hi,

@elmo: Gib mir mal die Servernummer, wir tauschen gerade bei allen vSERVER Systemen die RAID Controller gegen neue mit mehr Power, ich moecht mal gucken ob du auf einem mit einem alten langsamen liegts, denn normal passiert genau das beschriebene Szenario nur dort.

@traced: Ich weiss nicht was "kuendigen" mit zu hoher IO-Wait zutun hat, aber vielleicht komm ich noch dahinter. ;)
 
mbroemme said:
@traced: Ich weiss nicht was "kuendigen" mit zu hoher IO-Wait zutun hat, aber vielleicht komm ich noch dahinter. ;)
Click to expand...

Gut, wenn Du zu der Erkenntnis gelangt bist gib diese bitte an Deine Kollegen weiter :p

Spass beiseite, einfach der Umgang mit Kunden, und das ständige Abspeisen mit Standardtexten ging mir auf die nerven. Ausserdem war es für mich das einzig richtige, da ich die Hoffnung aufgegeben habe dass sich überhaupt jemand von Euch mal die Finger schmutzig macht und auf den Host schaut etc. Wie gesagt, anderer Anbieter, selbes Setup und kein einziges Problem... Also denke ich nicht dass ich die Schuld an meinem Setup suchen muss.

wir tauschen gerade bei allen vSERVER Systemen die RAID Controller gegen neue mit mehr Power, ich moecht mal gucken ob du auf einem mit einem alten langsamen liegts, denn normal passiert genau das beschriebene Szenario nur dort.
Click to expand...

Mit so einer Aussage kann man arbeiten, aber nicht damit womit Ihr Kunden in den Tickets abspeist!

lg
Basti
 
Also das Thema ist bei mir noch immer akut. :mad:

Ich habe jetzt ein Ticket seit Mittwoch, den 6.2. auf und keinerlei Rückmeldungen daraufhin erhalten. Das System ist für mich wie weg und kann definitiv nicht genutzt werden, wenn die iowaits hochgehen.

Aktuell war es gerade:



Über die Woche verteilt sieht es übrigens so aus - also kein Einzelfall oder nur ein vorrübergehendes Belastungsproblem seitens des Hostsystems:



Ich wäre sehr dankbar, wenn s4y da irgendwas unternehmen könnte und wenn es ein "auf die Finger klopfen" wäre bei dem jeweiligen Kunden, der das System so stark beansprucht. Es sind definitiv bei so hohen Werten keine mysql Zugriffe mehr möglich. Seiten, die von einer Datenbank "leben" sind praktisch tot. :(

Grüße
elmo
 
Hi,

@elmo: Ich hab mir das gerade angeguckt, leider bist du derjenige der die IOs da massiv auslastet (was zum Teil auch schon die anderen Kunden nervt) Dein MySQL Server hab ich mir jetzt die letzten 15 Minuten angeguckt, der zieht permanent 30-40% CPU-Time. Erstmal macht ein MySQL das niemals, es sei denn da laufen Queries mit LIKEs, WHERE auf Spalten ohne Indices usw... und zweitens kann ich da nichts weiter machen, da du derjenige bist der das Problem verursacht. :(
 
Hi,

aua... das schockiert nun doch etwas. Ich habe in Anbetracht dessen mal die Cachingwerte etwas höher gesetzt und nun warte ich was passieren wird. Beim letzten rum schrauben mit den Werten lief mir der Speicher voll (edit: ach ne das war beim Apache). Ich sitze also hier und beobachte das mal eben. Eigentlich sollte da nun die Belastung runtergehen.

So, der Cache sollte nun höher sein und wird auch genutzt:

Code: 
mysql> SHOW STATUS like '%qc%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 158      |
| Qcache_free_memory      | 15295040 |
| Qcache_hits             | 11588    |
| Qcache_inserts          | 6179     |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 21       |
| Qcache_queries_in_cache | 782      |
| Qcache_total_blocks     | 1797     |
+-------------------------+----------+
8 rows in set (0,00 sec)


Grüße
elmo
 
Last edited by a moderator:
Code: 
Cpu(s):  0.2% us,  0.1% sy,  0.0% ni, 66.6% id, 33.1% wa,  0.0% hi,  0.0% si

Code: 
11471 mysql     15   0 54552  29m 3396 S  1.3  2.3   3:13.20 mysqld

Na das verstehe ich jetzt nicht so ganz...
 
Wie wärs wenn du deine Datenbanken mal an sich optimierst?
Überhänge entfernen, Indizies anlegen, die einzelnen Queries optimieren usw.

Immer nur mehr Speicher reinzustopfen ist nicht immer die einzigste Lösung. :rolleyes:
 
Hi,

Also, scheint wieder im Lot zu sein. Bis jetzt.

Ich überwache nun zusätzlich die CPU Nutzung des mysql Prozesses im mrtg, war etwas frickelig, aber es geht. Und eins kann ich jetzt schon sagen: Steigende CPU Last des Mysql decken sich nicht unbedingt mit steigenden Queries, aber ich habe es erst angeknipst. Mal sehen wie es aussieht, wenn es länger läuft.

Grüße
elmo
 
You must log in or register to reply here.
Back
Top