Links + Ladezeiten

[Yuki]

Hi,

ich muss mal wieder am Forum rummeckern

Erstens ist mir aufgefallen, dass wenn ich einen Beitrag schreibe und keine Formatierungen oder so nutze, sondern einfach hintereinander weg schreibe und einen Link einfüge, wie z.B. https://minecraftforum.deund dann weiter schreibe, wird das Leerzeichen zwischen dem Link und dem folgenden Text durch die automatische Formatierung des Links entfernt, sollte man hier sehen.

Weiterhin hab ich mal eine komische Frage, mir ist es schon häufiger aufgefallen, dass das Forum bei mir manchmal eine Ladezeit von um die 30 Sekunden hat und danach wieder ganz normal schnell funktioniert.

Ist bei mir zuhause wie auch hier auf Arbeit so.

Ist das noch wem aufgefallen, oder bin ich das nur?

-Yuki

[boomer41]

IP-Board wir lieben dich...Wenn man nicht alles selber coded....

ÄÄh, b2t

Ich murks es dann mal um mit den Links und füg ein Leerzeichen ein.

Zu den Ladezeiten kann es sein dass es an den IP-Board Caches liegt oder an der Verbindung zu OVH. Siehe gestern 15 Uhr.

€dit: Dank IPB sind Links keine BB-Codes. Daher kann man es nicht ummurksen...

bearbeitet 30. Juli 2015 von boomer41

[Yuki]

Hi,

hehe, hast du wirklich etwas anderes erwartet?

Und nein, ich mach mir diesmal nur wegen dem Leerzeichen nicht die Mühe und such, wo man das ändern kann.

Da klick ich lieber nochmal auf Beitrag bearbeiten und mach das Leerzeichen hin.

-Yuki

[Knight]

Hey,

Ich denke man sollte so langsam mal für jeden Bug ein Ticket aufmachen.

Das Shoutbox Overlay zeigt sein Fenster zum editieren unter seinem eigentlichen Overlay an, URL BBCodes s.o. und für IPB 4 ein ganz eigenes

Die Typen vom Support machen ihren Job ganz gut. Glaube aber kaum, das da noch was passieren wird. IPB 4 ist nun deren Thema. Die alte Software wird wohl nur noch Sicherheitsupdates bekommen so wie das aussieht. Es ist ja auch nicht auszuschließen, das wir was geändert haben und ich davon nichts weiß. Problem ist, das IPB4 einfach nicht so recht stabil ist wie ich das gerne hätte. Da warte ich lieber noch etwas, außerdem brauchen wir ein neues Design - Standard ist lame.

https://community.invisionpower.com/blogs/entry/9731-ipboard-348-released/

Immerhin Updates bis April 2017

Zu dem "Ich chill mal ab Bug".

Denn kenne ich, leider kann ich bislang nicht genau sagen was ihn verursacht da er keinen direkten Log Eintrag erzeugt. Keine andere VM auf dem Host hat diese Art von Problemen. Ansonsten ist der Host auch nicht wirklich ausgelastet mit ~20 - 30% CPU Last. Aber ja es steht auf der beobachten Liste. Kann man eingrenzen wie oft das passiert?

Ansonsten noch einen schönen #SysAdminDayhttps://twitter.com/search?q=%23SysAdminDay&src=tyah

[Yuki]

Hi,

danke für die Infos.

Hab gerade mal geschaut, das IPB3 ist ja auch schon wieder von 2009, die Zeit vergeht...

Hast du sonst noch was in der VM laufen wo das Board ist? Wäre halt interessant zu wissen, ob wirklich die ganze VM "hängt" also auch andere Sachen in der VM betroffen sind oder ob es wirklich einfach nur am Board liegt.

Solche sporadischen Probleme sind immer die besten, die Kunden erwarten Antworten und Lösungen und man weiß selbst garnicht, wo man anfangen soll.

Hatte seit einiger zeit Probleme mit einer VM wo auch nur ein kleiner Apache drin lief, dass hier ständig Netzwerkausfälle waren, bzw keine Pings mehr durch gingen. Total unkontrolliert, mal ging es einen Tag und dann wieder mal ein Tag, wo alle 5-15 Minuten für ca. 20 Sekunden kein Ping durch ging. In den anderen 3 VMs auf dem Server lief alles, bzw ist dort nix aufgefallen.

Letztens ist der Switch an dem der Server hängt ausgefallen und seit der neue dran ist, kein einziger Fehler mehr. Frag mich nicht warum und vorallem warum nur bei der einen VM.

Ich werde mal darauf achten, wie oft das bei mir so auftritt, aber ich bin halt hier von der Arbeit aus auch nur unregelmäßig im Forum unterwegs, wie ich halt dazu komme.

-Yuki

[Knight]

Hey,

gerne.

Das Problem ist einfach, das IPB 4 so ein wenig wie Windows 10 ist. Erste Frage dort im Forum war einige Zeit lang, GEHT DAS UPDATE???

Eigentlich sehr schade, aber das hat mir meine Test Installation schon zweimal kaputt gemacht. Dann war der Upgrader im Upgrade stehen geblieben mit einem Fehler. Alles in allem recht ungetestet und schlecht überlegt für zwei Jahre Entwicklung. Es fehlen einfach etliche Funktionen im Admin Interface. Wenn vBulletin 100% Funktionen beinhaltet, hat IPB 3.4 ca. 60% und IPB 4 vllt. 20%. Das sind zt. recht banale Dinge bis hin zu wichtigen Funktionen die einfach fehlen mit der Begründung das es so einfacher ist. Wenn ein Admin sich damit nicht beschäftigen möchte, sollte er sich überlegen es vllt. sein zu lassen - andere benötigen vllt. genau diese Funktion. Da finde ich den komischen updater schon recht bemitleidenswert als Upgrade Grund überhaupt zu erwähnen. Ob ich nun 10.000 Dateien uploade/entpacke oder 100 ist heute mit den guten Anbindungen sehr zu vernachlässigen. Von uns hat zb. bislang keiner IPB 4 wirklich erwähnt, vermisst oder danach gefragt.

Außerdem konnte ich das chill Problem finden. Ist anscheinend etwas tiefer im Kernel zu finden. Ich haben als der Ram voll wurde in Proxmox die dynamische Ram Verwaltung angemacht. Gestern Mittag war es dann so weit, das ich im Minutentakt Mails bekam vom Monitoring und tatsächlich kam dann der Fehler zum Vorschein in Form des Kernel Fehlers "vballoon: page allocation failure: order:0" und "virtio_balloon virtio0: Out of puff! Can't get 1 pages". Ein Test erbrachte dann, das er den Ram tatsächlich einfach nicht mehr bekommt. Ich versuchte 8 GB zu belegen, bekam aber nur 3,8 GB zugewiesen - es gab natürlich keinen Log Eintrag - obwohl der Host noch 6 GB frei hatte. Nun hat das System wieder seinen festen Ram, PHP hat weniger spare Server und der Host ist neugestartet aus einem anderen Grund. Die Proxmox Firewall wollte sich einfach nicht einrichten lassen sodass sie geht. Sie brachte es immerhin einen Fehler zu erschaffen und sorgte dafür, das IPTables einfach nicht mehr richtig funktionierte und der Kernel sekündlich ca. 50 Einträge erstellte mit "ip_set_hash_net: disagrees about version of symbol module_layout" dazu findet man leider recht wenig. Als ich versuchte ein Modul zu deaktivieren ging kein Paket mehr rein oder raus. Das war alles schon sehr komisch - aber jetzt geht alles wieder

Hier ein Auszug der Kernel Fehlers mit dem vballoon Ram Problem.

Aug 2 12:51:07 main kernel: [1592976.989064] vballoon: page allocation failure: order:0, mode:0x310da

Aug 2 12:51:07 main kernel: [1592976.989070] CPU: 1 PID: 347 Comm: vballoon Tainted: G C 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1 Aug 2 12:51:07 main kernel: [1592976.989079] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 Aug 2 12:51:07 main kernel: [1592976.989081] ffff8800ba5ebc80 ffffffff8150b405 00000000000310da ffffffff811426ef Aug 2 12:51:07 main kernel: [1592976.989084] 0000000000000000 0000000000000000 0000000000000003 0000000000000001 Aug 2 12:51:07 main kernel: [1592976.989086] ffff88023fff7c00 ffffffff81159242 ffffffff81145108 0000000000000286 Aug 2 12:51:07 main kernel: [1592976.989088] Call Trace: Aug 2 12:51:07 main kernel: [1592976.989097] [] ? dump_stack+0x41/0x51 Aug 2 12:51:07 main kernel: [1592976.989102] [] ? warn_alloc_failed+0xdf/0x130 Aug 2 12:51:07 main kernel: [1592976.989105] [] ? next_online_pgdat+0x22/0x50 Aug 2 12:51:07 main kernel: [1592976.989108] [] ? drain_pages+0x28/0xa0 Aug 2 12:51:07 main kernel: [1592976.989111] [] ? __alloc_pages_nodemask+0x8ca/0xb30 Aug 2 12:51:07 main kernel: [1592976.989115] [] ? alloc_pages_current+0x9d/0x150 Aug 2 12:51:07 main kernel: [1592976.989118] [] ? balloon_page_enqueue+0x18/0x80 Aug 2 12:51:07 main kernel: [1592976.989146] [] ? fill_balloon+0xaa/0x120 [virtio_balloon] Aug 2 12:51:07 main kernel: [1592976.989150] [] ? balloon+0xc7/0x2a0 [virtio_balloon] Aug 2 12:51:07 main kernel: [1592976.989153] [] ? prepare_to_wait_event+0xf0/0xf0 Aug 2 12:51:07 main kernel: [1592976.989157] [] ? update_balloon_stats+0xe0/0xe0 [virtio_balloon] Aug 2 12:51:07 main kernel: [1592976.989160] [] ? kthread+0xbd/0xe0 Aug 2 12:51:07 main kernel: [1592976.989163] [] ? kthread_create_on_node+0x180/0x180 Aug 2 12:51:07 main kernel: [1592976.989166] [] ? ret_from_fork+0x58/0x90 Aug 2 12:51:07 main kernel: [1592976.989168] [] ? kthread_create_on_node+0x180/0x180 Aug 2 12:51:07 main kernel: [1592976.989170] Mem-Info: Aug 2 12:51:07 main kernel: [1592976.989172] Node 0 DMA per-cpu: Aug 2 12:51:07 main kernel: [1592976.989174] CPU 0: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989175] CPU 1: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989176] CPU 2: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989178] CPU 3: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989179] CPU 4: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989180] CPU 5: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989181] CPU 6: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989182] CPU 7: hi: 0, btch: 1 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989183] Node 0 DMA32 per-cpu: Aug 2 12:51:07 main kernel: [1592976.989185] CPU 0: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989186] CPU 1: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989187] CPU 2: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989188] CPU 3: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989189] CPU 4: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989190] CPU 5: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989191] CPU 6: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989192] CPU 7: hi: 186, btch: 31 usd: 0 Aug 2 12:51:07 main kernel: [1592976.989193] Node 0 Normal per-cpu:

Aug 2 12:51:07 main kernel: [1592976.989194] CPU 0: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989195] CPU 1: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989196] CPU 2: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989197] CPU 3: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989198] CPU 4: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989199] CPU 5: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989200] CPU 6: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989201] CPU 7: hi: 186, btch: 31 usd: 0

Aug 2 12:51:07 main kernel: [1592976.989204] active_anon:196678 inactive_anon:34075 isolated_anon:0

Aug 2 12:51:07 main kernel: [1592976.989204] active_file:75349 inactive_file:546039 isolated_file:0

Aug 2 12:51:07 main kernel: [1592976.989204] unevictable:0 dirty:73 writeback:16 unstable:0

Aug 2 12:51:07 main kernel: [1592976.989204] free:25748 slab_reclaimable:26212 slab_unreclaimable:9062

Aug 2 12:51:07 main kernel: [1592976.989204] mapped:34933 shmem:27303 pagetables:9738 bounce:0

Aug 2 12:51:07 main kernel: [1592976.989204] free_cma:0

Aug 2 12:51:07 main kernel: [1592976.989207] Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(ano$

Aug 2 12:51:07 main kernel: [1592976.989211] lowmem_reserve[]: 0 2980 7987 7987

Aug 2 12:51:07 main kernel: [1592976.989214] Node 0 DMA32 free:44844kB min:25172kB low:31464kB high:37756kB active_anon:309236kB inactive_anon:69224kB active_file:104160kB inactive_file:783572kB u$

Aug 2 12:51:07 main kernel: [1592976.989218] lowmem_reserve[]: 0 0 5006 5006

Aug 2 12:51:07 main kernel: [1592976.989220] Node 0 Normal free:42240kB min:42276kB low:52844kB high:63412kB active_anon:477476kB inactive_anon:67076kB active_file:197236kB inactive_file:1400584kB$

Aug 2 12:51:07 main kernel: [1592976.989224] lowmem_reserve[]: 0 0 0 0

Aug 2 12:51:07 main kernel: [1592976.989226] Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB ? 3*4096kB (EM) = 15908kB

Aug 2 12:51:07 main kernel: [1592976.989235] Node 0 DMA32: 182*4kB (UEM) 251*8kB (UEM) 598*16kB (UEM) 395*32kB (UEM) 138*64kB (UEM) 37*128kB (UEM) 4*256kB (U) 6*512kB (U) 0*1024kB 0*2048kB 1*4096k$

Aug 2 12:51:07 main kernel: [1592976.989244] Node 0 Normal: 259*4kB (UEM) 822*8kB (UE) 935*16kB (UEM) 334*32kB (UEM) 93*64kB (UEM) 6*128kB (UM) 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB ? = 440$

Aug 2 12:51:07 main kernel: [1592976.989252] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

Aug 2 12:51:07 main kernel: [1592976.989254] 653169 total pagecache pages

Aug 2 12:51:07 main kernel: [1592976.989255] 4588 pages in swap cache

Aug 2 12:51:07 main kernel: [1592976.989256] Swap cache stats: add 1669698, delete 1665110, find 51086866/51298135

Aug 2 12:51:07 main kernel: [1592976.989258] Free swap = 8100556kB

Aug 2 12:51:07 main kernel: [1592976.989258] Total swap = 8388604kB

Aug 2 12:51:07 main kernel: [1592976.989259] 2097021 pages RAM

Aug 2 12:51:07 main kernel: [1592976.989260] 0 pages HighMem/MovableOnly

Aug 2 12:51:07 main kernel: [1592976.989261] 724588 pages reserved

Aug 2 12:51:07 main kernel: [1592976.989262] 0 pages hwpoisoned

Aug 2 12:51:07 main kernel: [1592976.989266] virtio_balloon virtio0: Out of puff! Can't get 1 pages

[Knight]

Das Problem mit den langen Ladezeiten sollte behoben sein.

Meine Standardkonfiguration sieht vor, regelmäßig die Linux Caches zu löschen um Ram frei zu haben.

Da ich nun die ganze Zeit die Caches leerte, musste natürlich alles neu geladen werden was dann zu den langen Ladezeiten führte - vermutlich auch durch die Sommerferien. Nun wo es anstatt alle 30 Minuten immer um 6 Uhr (auf dem Bild noch 0 Uhr) ist, sagt mir auch das Monitoring das die Transactions wieder flutschen

Linux Page Cache =https://www.thomas-krenn.com/de/wiki/Linux_Page_Cache

Beitrag 400 von mir und es ist was gutes

[Yuki]

Hi,

danke für die Info und super, das du es nun doch noch gefunden hast.

Ich werde es auf jedenfall weiter beobachten und mich sofort beschweren, wenn ich wieder was merke.

-Yuki