Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

CPU Last hoch bei Cache-Instanz

Cilow

Stamm User
Registriert
28. Mai 2012
Beiträge
1.037
Reaktionspunkte
146
Punkte
223
Ort
Homeland
Ich nutzen nun zum ersten mal 2 Instanzen. Die 1. ist die Haupt- und die 2. ist Cacheinstanz.
Auf der Hauptinstanz läuft alles wie geschmiert. Reiter Status, unten USERS INFO, CPU USAGE Summary: ~2-3%. Soweit alles gut.
Auf der Cacheinstanz allerdings sieht das ganz anders aus. Da schwankt die CPU extrem zwischen 50/60% und 100/130%, mal auch höher.

Bei htop ist die CPU oft bei 400%. Es ist ein CuadCore verbaut.

Momentan (es wird noch verschiedenes getestet) sieht es bei mir so aus, dass ich 17 Partner drin habe.
Die USER bekommen maxhop 5. Caids sind auch drin.
Die READER habe ich (erstmal) auf maxhop 10 drin. Auch hier sind Caids drin, und zwar die, die ich brauche.
CacheSize liegt momentan bei ~2200.
Delay: 10
Max Time: 10
Max hit time: 30
CacheEx CW Check: 1722:0:2,1834:0:2,09C7:0:3,1830:0:3,1843:0:3,1702:0:3,09CD:0:3,09C4:0:3,098C:0:3,0500:0:3,0100:0:3
Wait time: 1722:4500,1834:4500,09C7:1000,1830:4500,1843:1000,1702:4500,1833:4500,09C4:1000,098C:1000,09CD:1000,093B:1000,0919:1000,0100:3500,0500:3500
Cycle Check Caids: 1722,1834,09C7,1702,1833,09C4,098C,1830,1843,09CD,0100,0500,1810,0D00,0B00,0B01,0B02,1802,1880
Client Timeout: 5000

Wenn ich die User (also pushes) mal komplett deaktiviere, sinkt zwar die CPU Last, aber nicht dass ich sagen würde Ok, daran liegt es. Die CPU Last ist immer noch im höheren Bereich.
Was wäre hier eigentlich 'normal' ?

Dann hab ich mir sagen lassen, dass das ein Problem von einem KVM sei. Ein OpenVZ würde hier wesentlich bessere Ergebnisse erzielen zwecks CPU Last. OpenVZ kommt mir aber nicht in die Tüte.
Ein Kollege hat exakt den gleichen VPS (CPU, RAM, KVM usw.), mit mehreren Cachepartnern und bei ihm ist die CPU Last deutlich geringer. Ich meine das war so bei 35%, was ich bei mir auch wünschen würde.

VPS hat 1GB Ram. Intel E3 & E5 Xeon Quadcore und Traffic ist genügend vorhanden.
 
AW: CPU Last hoch bei Cache-Instanz

Du hast doch sicher nicht 4 Kerne in der VPS oder?!
 
AW: CPU Last hoch bei Cache-Instanz

... nicht schlecht, aber ganz schön übertrieben!
Code:
[SIZE=1]Delay: 10
Max Time: 10
Max hit time: 30
CacheEx CW Check: 1722:0:2,1834:0:2,09C7:0:3,1830:0:3,1843:0:3,1702:  0:3,09CD:0:3,09C4:0:3,098C:0:3,0500:0:3,0100:0:3
Wait time: 1722:4500,1834:4500,09C7:1000,1830:4500,1843:1000,   1702:4500,1833:4500,09C4:1000,098C:1000,09CD:1000,   093B:1000,0919:1000,0100:3500,0500:3500
[/SIZE]
ich würde so machen ...
Code:
Delay: 0
Max Time: 20
Max hit time: 15
CacheEx CW Check: 0:1:1,0500@032830:1:1,0500:1:2,0BAA:1:2,1702:1:2
Wait time: 0:6000:0,0100@003311:2700:0,0500@032830:2700:0,09C7:1750:0,09:1420:0
 
AW: CPU Last hoch bei Cache-Instanz

Hi,
auf der CE-Instanz könnte man die Waittimes auch ganz weg lassen und dafür
Code:
 wait_until_ctimeout  = 1
setzen.
Es geht ja nur darum, dass ggf. CE1-User nicht gleich abgewiesen werden, wenn nichts passendes im Cache wäre.
Diese können dann ihre eigenen Waittimes setzen.

Außerdem würde ich den Cyclechek auf der CE-Instanz ganz abschalten.
Darum sollten sich die User selbst kümmern.

Das alles wird aber deine CPU-Last nicht drastisch senken, denke ich.
Was sagt denn ein
Code:
cat /proc/loadavg
und ein
Code:
cat /proc/cpuinfo

Gruß
janni1
 
AW: CPU Last hoch bei Cache-Instanz

Hi
@Hunchback
Es ist eine reine Cacheinstanz, da spielen Waittimes eigentlich keine Rolle.
Man hat da ja keine direkten Anfragen, außer eben evtl. über CE1-User.
Diese setzen dann aber Ihre Waittimes selber in ihren Servern.

Gruß
janni1
 
AW: CPU Last hoch bei Cache-Instanz

Lässt man CE1 User in die CE Instanz benötigt man dringend valide Waittimes in der CE Instanz.

Und ja die WT für NDS sind viel zu hoch
 
AW: CPU Last hoch bei Cache-Instanz

Hi,
Sorry Cilow, dass das wieder leicht OT wird.

@DarkStarXxX
Kannst du das bitte näher erklären?
Ein Beispiel von mir:
Nehmen wir an, ich nutze ebenfalls zwei getrennte Instanzen.
Auf der Hauptinstanz/Partnerinstanz mittels CE1 verbunden, nutze ich valide Waittimes z.B.
wait_time = 09C4:200
Auf der Cacheinstanz nutze ich utopische Waittimes
wait_time = 09C4:1500:0
Die Werte sind frei erfunden und sollen nur der Veranschaulichung dienen.

Was passiert bei einer Anfrage auf meiner Haupinstanz?
Die Anfrage wird sofort auf meine CEinst. verbunden und abhängig von -wärend "max_hit_time"- registrierter Hits, dyn. Waittime ausgelöst
und zwar die auf der Haupinst. hinterlegte (200ms).
Auf der CEinst. greift, wenn nichts passendes im Cache die statische Waittime (1500ms).
Wenn nichts passendes im Cache der CEinst. auftaucht, bricht die Hauptinst. die Anfrage nach Ablauf der dyn.Waittime ab und fragt einen realen Reader an. Das würde dann so aussehen: "found (350 ms) by reader1 (L/x/y/z) - Sky irgedwas 1 (real 150 ms) (cwc OK)"

Auf der CEinstanz endet die Anfrage mit "not found (1501 ms)".
Wenn man anstatt der utopischen Waittime "wait_until_ctimeout" setzt, endet hier die Anfrage mit "rejected group (5001 ms)" bei "clienttimeout = 5".

Wo liegt nun das Problem? Bin ich hier vieleicht auf dem Holzweg und hab was wichtiges übersehen?
Wie gesagt ich betreibe es so und hatte nie Probleme. Meine Partner die per CE1 gekoppelt sind auch nicht.

Ich rede hier ausschließlich von CE-Mode1 und nicht von CE-Mode2-Clienten mit cacheex_allow_request=1, was auf einer CEinst auch keinen Sinn machen wüde.

Sorry nochmal für OT

Gruß
janni1
 
Zuletzt bearbeitet:
AW: CPU Last hoch bei Cache-Instanz

Wieso braucht man zwingend Timeouts in the CE Instanz? Ist es nicht besser diese nur im "Exit Node" wo die richtigen User dranhängen Waittimes entsprechend der Verfübarkeit an lokalen / Proxy Cards zu definieren und in der CE Instanz einfach wait till ctout zu setzen? So kann jeder CE1 Peer flexibel festlegen wie lange er warten will...
 
AW: CPU Last hoch bei Cache-Instanz

Du hast doch sicher nicht 4 Kerne in der VPS oder?!
Laut dem Hoster denke ich schon:


htop zeigt mir auch vier Kerne an, oder halt die Threads:


ich würde so machen ...
Code:
Delay: 0
Max Time: 20
Max hit time: 15
CacheEx CW Check: 0:1:1,0500@032830:1:1,0500:1:2,0BAA:1:2,1702:1:2
Wait time: 0:6000:0,0100@003311:2700:0,0500@032830:2700:0,09C7:1750:0,09:1420:0
Bin was CacheEx angeht noch nicht ganz sooo fit.
Die Caids, die ich brauche sind in 'CacheEx CW Check' nicht drin?
Wieso die 0500/0100 Caid mit dem Provider begrenzen? Andere 0500/0100er sind doch auch evtl interessant?
Jetzt muss ich nochmal ganz bescheiden fragen, 09C7:1750:0 = Caid:Waittime:? Wofür stand die 0 nochmal?


auf der CE-Instanz könnte man die Waittimes auch ganz weg lassen und dafür
Code:
 wait_until_ctimeout  = 1
setzen
Es geht ja nur darum, dass ggf. CE1-User nicht gleich abgewiesen werden, wenn nichts passendes im Cache wäre.
Diese können dann ihre eigenen Waittimes setzen.

Außerdem würde ich den Cyclechek auf der CE-Instanz ganz abschalten.
Darum sollten sich die User selbst kümmern.
Also Wait time komplett leer lassen, und dafür bei Wait until ctimeout einen Haken rein. Okay, wieso nicht, bin ja eh dabei alles auszuprobieren.
Den Cyclecheck würde ich aber "eigentlich" für meine Hauptinstanz brauchen, oder? Oder spielt der auf der Cacheinstanz keine Rolle, da der auf der Hauptinstanz aktiv ist?

Was sagt denn ein
Code:
cat /proc/loadavg
Code:
12.84 12.15 11.40 23/188 30461

und ein

Code:
cat /proc/cpuinfo

12.84 12.15 11.40 23/188 30461
root@debian:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 0x1
cpu MHz : 3300.022
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse3 6 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 hypervisor lahf_lm
bogomips : 6600.04
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 0x1
cpu MHz : 3300.022
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse3 6 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 hypervisor lahf_lm
bogomips : 6600.04
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 0x1
cpu MHz : 3300.022
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse3 6 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 hypervisor lahf_lm
bogomips : 6600.04
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version (cpu64-rhel6)
stepping : 3
microcode : 0x1
cpu MHz : 3300.022
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse3 6 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 hypervisor lahf_lm
bogomips : 6600.04
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Lässt man CE1 User in die CE Instanz benötigt man dringend valide Waittimes in der CE Instanz.

Und ja die WT für NDS sind viel zu hoch

Also mit diesen Waittimes auf der Cacheinstanz habe ich auf der Hauptinstanz keine Probleme, selbst bei NDS nicht. Diese sind auf der Hauptinstanz ja soweit richtig eingestellt.
Ich versteh das in etwa so:
Auf der Cacheinstanz kommt erstmal alles rein, von den Zeiten her das maximum was möglich ist. S02 zB bis zu 4000ms, 09C7 bis zu 600 oder mehr (da muss ich noch mal genauer forschen) usw.
Die Hauptinstanz, die mit CE1 auf der Cacheinstanz schnüffelt, besorgt sich die nötigen CW's für die Clienten, anhand der richtigen Waittimes auf der Hauptinstanz.
Und so läuft das eigentlich ganz gut bei mir.
 
AW: CPU Last hoch bei Cache-Instanz

Hi
@fun
dieses Vorgehen mit den übertriebenen Waittimes, stammt noch aus der Zeit bevor es wait_until_ctimeout gab.
Also von vor SVN r9483.

@cilow
09C7:1750:0 = Caid:Waittime:? Wofür stand die 0 nochmal?
Caid:awtime:dwtime
awtime: (always wait time),statisch,immer
dwtime: (dynamic wait time), dynamisch, nur wenn sich's lohnt :emoticon-0105-wink:

Gruß
janni1
 
Zuletzt bearbeitet:
AW: CPU Last hoch bei Cache-Instanz

Ohne Waittime für CE1 gibt's kaum Hits.

Auch mit wait_until_ctimeout

Gerade nochmal getestet.
 
Zurück
Oben