Beiträge von julian-w

Zitat von vmk

Zum Nachtrag: Das behauptet hier niemand. Du verdrehst hier mit voller Absicht die Fakten. Hast du dir überhaupt einen der Links in diesem Thread angeschaut?

Here we go again

Ich zitiere mal noch aus dem verlinkten Artikel von mir:

"The CPU usage probably also benefits from HTTP/2 being binary protocols which explains why HTTP/2’s (with encryption) CPU usage is slightly lower than HTTP/1.1 without encryption."

Also laut dem Benchmark (Details im Link oben) ist HTTP2 selbst mit Verschlüsselung sparsamer was "CPU" angeht auf Seite des Servers. Klar Verschlüsselung braucht CPU-Leistung, aber der Vorteil in der Effizienz des Protokolls ist größer wie der zusätzliche Verschlüsselungsaufwand laut diesem Test, was unterm Strich die CPU entlastet. Davon ab verursacht TLS keinen all zu großen Overhead, dank CPU-Features etc. Ich gebe zu, der Test oben ist nur von einer "unbedeutenden Person", daher hier noch ein paar Links von größeren Organisationen die massenhaft Traffic bewältigen müssen

https://www.keycdn.com/blog/https-performance-overhead/

Zitat

"If you are running on HTTP/2 (HTTPS) this only requires a single connection per origin which means few sockets, memory buffers as well as TLS handshakes. Because of this it you might be able to handle more users with fewer resources as opposed to HTTP"

"In January 2010, Gmail switched to using HTTPS for everything by default. They didn’t deploy any additional machines or special hardware and on their frontend machines, SSL/TLS accounted for less than 1% of the CPU load."

"Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." – Adam Langley, Google

Hier noch ein älterer Test von 2013 (!) mit SPDY im Vergleich zu HTTP und HTTPS, auch hier ist bis auf einen minimal größeren CPU overhead SPDY mit TLS effizenter wie HTTP:

https://www.neotys.com/blog/performan…ed-web-servers/

Zitat

It turns out that SPDY also has advantages on the server side:

• Compared to HTTPS, SPDY requests consume less resources (CPU and memory) on the server.
• Compared to HTTP, SPDY requests consume less memory but a bit more CPU. This may be good, bad, or irrelevant depending on which resource (if either) is currently limiting your server.
• Compared to HTTP/S, SPDY requires fewer Apache worker threads, which increases server capacity. As a result, the server may attract more SPDY traffic

From these results, it is clear that Apache tuning performed for HTTP/S may not be appropriate after SPDY is enabled on the server.

Das Paper "Is HTTP/2 More Energy Efficient Than HTTP/1.1 for Mobile Users?" ist echt interessant, hier mal ein Direktlinkals PDF zum lesen:

https://pdfs.semanticscholar.org/b832/ba3ceb435…9308ebed7b1.pdf

Auch zum Thema CPU Last sind hier ein paar interessante Dinge die ich selbst nicht wusste:

https://medium.com/@DarkDrag0nite…th-10dbb8458feb

"Upgrading from HTTP/1.1 with encryption to HTTP/2 with encryption will reduce both CPU usage and bandwidth of your server."

Ich glaub ich muss meine mini vServer alle auf HTTP/2 umstellen und HTTP/1.1 komplett deaktivieren

Wenn wir hier Vorschläge sammeln:

Eine Unterteilung des Wartungsfensters wie hier vorgeschlagen in 8 oder mehr Slots wird wohl schwierig zu handhaben sein, aber warum nicht nur zwei Slots anbieten?:

• Wartung während Geschäftszeiten (6-18 Uhr)
• Wartung außerhalb Geschäftszeiten (18-6 Uhr)
• Wartungsfenster egal

Damit kann man mindestens 50% der Wünsche der Kunden erfüllen Welche Zeiten da ideal sind weiß ich nicht, aber sowas ist wohl einfacher zu handhaben wie etliche verschiedene sich nicht überlappende Zeitwünsche und vielleicht lassen sich VMs so umziehen das Hosts mit Kunden gleicher Wünsche gefüllt werden können, gibt ja nur 2 Wünsche. Eventuell anzeigen welche "Präferenz" der aktuelle Host hat. Wenn man dann bereit ist z.B. Nachts eine Downtime in Kauf zu nehmen kann man vielleicht den Host wechseln zu einem mit seiner Präferenz (falls Platz/Tauschkandidat vorhanden ist). Und als Premium-Feature für einen bestimmten Betrag X dann das Wartungsfenster garantieren, hier wurde ja schon Zahlungsbereitschaft angedeutet

Ich werde mir dem Rat, den ich hier auch mehrfach per PN erhalten habe und auch hier im Thread vorhanden ist, anschließen und zukünftig (nach diesem Post) die Regel "never discuss with mainziman" (oder ist es eher "Don't feed the trolls?") beherzigen. Diskutieren im Internet macht Spaß (bzw. kann Spaß machen), da darf man auch etwas streiten. Aber mit mainziman ist es einfach nur sinnlos, wurde hier ja schon zu genüge erwähnt warum. Fehlende Einsicht, kein eingehen auf Argumente, bringt immer wieder krude neue Argumente, notfalls von Ursystemen und kann vor allem keine Fehler eingestehen und will immer Recht haben.

Zitat von mainziman

Dir fehlen anscheinend die Grundlagen; das mit (w|_t)WinMain ist erstens ein Spezifikum von Microsoft und hat nichts zu sagen und zweitens wäre Dein Programm durchgefallen; Worker Threads ohne GUI sind sinnlos;

Hier steht schon so viel Blödsinn... Du hast die WinMain zum Standard gehimmelt und ich als Spezifikum von Microsoft (Visual C++) beschrieben... und natürlich machen Worker Thredas ohne GUI Sinn, was denkst du wie nginx, Apache, Datenbanken oder sonst was funktionieren

Zitat von mainziman

sieh Dir einfach mal an was der Parameter /ENTRY und der Parameter /SUBSYSTEM des LINK commands bedeuten;

wir reden hier ausschließlich von /SUBSYSTEM:CONSOLE

Was soll das jetzt mit dem ursprünglichen Thema zu tun? Ist das der Teil um "clever" zu klingen?

Zitat von mainziman

Du solltest vlt. andere nicht als unwissend hinstellen, besonders dann wenn Dir anscheinend entsprechendes Basiswissen fehlt;

Brauch ich nicht (mehr), du disqualifizierst dich selbst

Zitat von mainziman

und sein Programm ist auch aus anderen Gründen sinnlos, es verdampft nur CPU-Zeit und liefert kein Ergebnis; und Fortschritt sieht man auch keinen;

Wir reden die ganze Zeit von "100% Workload", ist doch vollkommen egal was die macht. Wenn du Pi auf 100000 Stellen berechnest oder sonst was ist das genau so unnötig wie eine while-Schleife

Zitat von mainziman

Vlt. solltest Du zugeben, daß Dir mangels Kenntnis etwas fehlt bevor Du anderen Fehler unterstellst, die nicht da sind; so schwer ist das auch nicht;

und spätestens mit dem Kommentar "Windows 2000" (von dem ich nicht gesprochen habe) wußte ich, der hat eh keine Ahnung und will nur Schlau rüberkommen;

Zitat von mainziman

das ist schon mal ein Blödsinn, denn GUI Programme haben kein main sondern ein WinMain, wir reden ja von Windows ...

Es tut mir leid mit dir zu Argumentieren macht einfach keinen Spaß wenn nur Blödsinn behauptet wird Korrekt ist:

Unter Visual C++ gibt es eine "wWinMain" (WinMain unterstützt nur ANSI als Parameter, wWinMain auch Unicode und soll bevorzugt verwendet werden) als Einstiegsfunktion, das ist korrekt, nichtsdestotrotz kann es auch einfach eine "main" sein, ist tausendfach so und vermutlich auch in der Mehrzahl der Programme so, schon nur alle Frameworks wie QT, GTK, ... benutzen eine einfach "main" als Programmeinstieg und diese bildet meist den "GUI-Thread" ab. Im Grunde gibt es die wWinMain nur bei Visual C++, "Standard" C++ benutzt zu 99% die "main". Also bitte nicht den Sonderfall verallgemeinern und als Standard ausrufen.

Ja die Formulierung GUI-Thread ist etwas salopp. Die "main" als Einstieg (bei GUI Programmen) ist aber genauso üblich wie eine wWinMain (eher ist die wWinMain der Exot). Davon ab stellen beide den "GUI-Thread" da (Salopp formuliert). Und auch bei Shell-Programmen gibt es einen "GUI-Thread" oder "main-Thread" oder "intaraktiver-Thread" oder wie man ihn immer nennen mag.

Zitat von mainziman

wennst unter Windows es so

start /REALTIME calculate

aufrufst, dann gibt es diese Geschubse auch nicht;

Ich bin mir ziemlich sicher das der Taschenrechner nicht dafür gedacht ist, ewig lange Berechnungen durchzuführen, bei mir konnte ich gar keine provzieren, soviel ich weiß ging das nur in älteren Versionen, aber gut bist ja gerne in der Vergangenheit Aber wenn dass das Problem löst und es das Geschubse nicht mehr gibt, ist doch alles gut, zeigt ja einmal mehr das es an deinem unsauberen Code liegt bzw falscher Priorisierung.

Zitat von mainziman

diese Argumentation erinnert mich an meine Schulzeit, wo mein Sitznachbar von einem Computer-Virus erzählte:

"man sieht eine entzückende Animation und dann war die Festplatte formatiert"

Und das hat jetzt exakt womit was zu tun? Ich hab dir einen Fehler nach etlichem Hin und Her aufgezeigt. Oder soll ich dir jetzt Dokumente zeigen das eine hohe Arbeitslast im GUI-Thread bzw main-Thread ungünstig ist? Das findest du auch selbst mit Google heraus.

Ich hab mir mal die Mühe gemacht und deinen Code getestet. In der einfachsten Ausführung wie du es hast läuft das bei mir direkt "nur" auf 2 Cores, wird also nicht quer Beet hin und her gestupst. Liegt vielleicht an dem ständigen printf das aufgerufen wird.

pasted-from-clipboard.png

Also habe ich das ganze kurz als Thread ausgelagert und konfiguriert und siehe da, alles läuft so wie es laufen soll, kein gestupse oder sonst was und die Ausgaben klappen auch noch.

pasted-from-clipboard.png

Den Code findest du hier, der sollte auch ohne Probleme compilierbar sein. Möglicherweise macht mein Code was anderes wie deiner (auf mathematischer Ebene), aber ist ja auch egal bzw du kannst auch lauffähigen C-Code liefern.

// CMakeProject1.cpp: Definiert den Einstiegspunkt für die Anwendung.
//

#include "CMakeProject1.h"
#include <stdio.h>
#include <math.h>
#include <process.h>
#include <Windows.h>

#define CNT 6250

using namespace std;

bool threadFinished = false;
void calc(void *param);

int main()
{
    cout << "Hello CMake." << endl;

    getchar();

    //cout << _beginthread(calc, 0, NULL);
    calc(NULL);

    while (!threadFinished)
    {        
        _sleep(1000);
    }    

    getchar();
}

void calc(void *param)
{
    /*
    HANDLE process = GetCurrentProcess();
    DWORD_PTR processAffinityMask = 1;
    BOOL success = SetProcessAffinityMask(process, processAffinityMask);
    cout << success << endl;
    */


    unsigned long long ullDest[CNT];
    unsigned long long ullSrc[2 * CNT];
    unsigned long ul;
    unsigned int n = 0;

    unsigned int ii = 0;

    for (ii = 0; ii < 1000000; ii++)
    {
        for (ul = 0; ul < CNT; ul++)
        {
            ullSrc[ul] = 0xFFFFFFFFFFFFFFFF;
            ullSrc[ul + CNT] = 0;
        }

        for (ul = 0; ul < CNT; ul++)
        {
            ullDest[ul] = ullSrc[ul] / CNT;
        }
    }

    printf("\n\n\n");
    ul = CNT;

    while (ul > 0)
    printf("%016llu", ullDest[--ul]);

    threadFinished = true;
}

Zitat von mainziman

dann zeige mal Deine Single-Thread-Workload ...

Hab ich doch: es handelt sich um den HeavyGate Benchmark. Unter Linux "yes" und das "stress" Tool.

Zitat von mainziman

erklär mir nicht das wäre fehlerhaft;

Ist es aber leider, was soll ich sagen... für dich kann ich ja schlecht die Fakten verdrehen...

Hohe Last soll man nie, nie, niemals im "GUI" Thread bzw. im interaktiven Thread zur Benutzer-Maschine-Kommunikation (main-Function) laufen lassen, aber genau das tust duUnd das ist der große Fehler, eigentlich lernt man das doch von Anfang an, bei einer GUI merkt man ja direkt das dann schlichtweg nichts mehr geht. Deine Shell dürfte aber auch recht träge werden, da sämtliche Last im "interaktiven User Thread" läuft. Da am Shell-Prozess ganz viel dran hängt, kann so ein Thread nicht gut gescheduled werden, somit ist schlichtweg dein Code fehlerhaft. Schau dir mal den Code von Linux "stress" an (https://people.seas.harvard.edu/~apw/stress/) den ich oben benutz habe, der hat einmal die main-function, macht aber für jede "100%-Last" einen eigenen Thread auf und wartet im main nur auf das terminieren der Child-Threads, die 100% Last erzeugen. Die main-function selbst erzeugt keine Last.

Es gibt auch einen "Windows-Port" hier (https://github.com/RichardKav/Stress-for-Windows), der erzeugt auch die Last in externen Threads.

Wenn du deine Last in einen externen Thread auslagerst und in der main-function wartest bis diese terminiert (natürlich nicht busy-waiting), dann sollte das klappen, kann das nachher mal selbst testen und deinen Code korrigieren. Aber die main-function für 100% Lasten zu missbrauchen ist nie gut.

Zitat von mainziman

vmk das Hin- und Hergeschubse ist bei Win10 immer noch gegeben;

ob der HT dabei berücksichtigt oder nicht spielt da keine Rolle;

Bei deiner Workload die keiner kennt, vielleicht ist es ja gar keine Single-Thread Last, sondern eine Endlosschleife im Terminal was sich auf bis zu 3 Threads verteilen kann Und natürlich spielt HT eine Rolle, du würdest dich bedanken wenn Windows die CPU-lastigen Threads auf einen HT-Core legen würde während die anderen nichts tun

Zitat von mainziman

ergo sind wir wieder dort, bei meiner Aussage, der Scheduler von Windows zählt nicht dazu ...

über den von Linux kann ich keine Aussage treffen;

Unter Linux ist es das gleiche: der einfache Befehel "yes" der einfach nur "Y" in Endlosschleife ausgibt wird ebenfalls, wie deine Workload unter Windows, hin und her geschubst (da er nicht weiter optimiert ist vermute ich mal, warum auch):

pasted-from-clipboard.png

Ein "richtiger" Stresstest mit "stress" wiederum funktioniert einwandfrei, dieser bleibt auf einem Kern:

pasted-from-clipboard.png

Der Scheduler kann ja nichts dafür, wenn der Benutzer ihn falsch benutzt

Zitat von mainziman

julian-w dich holt tatsächlich die Vergangenheit ein;

Eher dich die Settings (oder irgendwelche Steinzeit Benchmarks von Win98-Zeiten). Die meisten Benchmarks laufen mit "niedriger als normal", was oftmals zu deinem Verhalten führen kann. Kein Wunder, du sagst dem Scheduler "ey lass das mal laufen, aber ist nicht so wichtig, alles andere ist wichtiger"... warum sollte der Scheduler dann einen kompletten Kern reservieren!? Sobald man die Benchmarks mit "normal" oder höher als Priorität laufen lässt, erscheint oftmals folgendes Bild (HeavyLoad Benchmark, mit einem "Kern", nur einen "Core" gibt es leider nicht als Settings, aber er benutzt ja ganz korrekt nur einen Kern):

pasted-from-clipboard.png

Genau was du erwartest, kein gestupse oder sonstiges. Er nutzt sogar die zwei Threads eines physikalischen Kernes, macht also alles korrekt. Das Problem was du Andeuten willst existiert so nicht. Das tritt einzig und allein auf wenn die Workload "falsch" initialisiert worden ist, und für fehlerhafte Infos kann der Scheduler nichts, Fehler von Benutzer ausbügeln kann er noch nicht

Ein simple Endlosschleife in eine Batch-File funktioniert z.B. nicht, weder unter Windows/Linux noch sonst einem mir bekannten System.Eine korrekt angelegte Single-Thread Workload klappt ohne hin- und hergestupse unter Windows und Linux, gerade selbst getestet.

Ich meine mich auch düster an die "Operating Systems" Vorlesung zu erinnern wo genau das erwähnt wurde was ich oben schon gesagt habe: der Scheduler weiß nicht wie viel CPU-Zeit ein Thread in Zukunft brauchen wird, daher weiß er nie ob es Sinn macht ihm einen ganzen Kern "zu opfern", könnte ja sein das plötzlich noch 10 andere Threads kommen die auch CPU-Zeit wollen oder der Thread danach beendet oder ein Thread mit höherer Priorität viel CPU-Zeit will oder oder oder... und da der Scheduler-Code so klein wie nur möglich sein soll (da unzählige Male pro Sekunde ausgeführt), kann man da nicht ganz so wild spekulieren. Wenn man dem Scheduler aber seine Wünsche mitteilt (eine Zeile Code), werden die unter Windows und Linux berücksichtigt. Eine eierlegende Wollmilchsau ist es halt nicht

Zitat von mainziman

so sieht die Definition der CPUs am Host f. die VM aus

Um welche Software zur Virtualisierung handelt es sich denn hierbei? Das sieht irgendwie nach WinXP oder davor aus, also eine ältere Software? Oder benutzt du nur gerne den alten Stil unter Windows

Und das der Gast keine HT-Cores sieht ist doch logisch, es sind ja schließlich keine eingestellt im Hypervisor soweit man das dem Screenshot entnehmen kann.

Aber irgendwie passen deine Coreinfo ausgaben überhaupt nicht, hier das ganze unter Windows 10 x64 mit einem Core i5-4771 (4 Kerne + HT):

Logical to Physical Processor Map:
**------  Physical Processor 0 (Hyperthreaded)
--**----  Physical Processor 1 (Hyperthreaded)
----**--  Physical Processor 2 (Hyperthreaded)
------**  Physical Processor 3 (Hyperthreaded)

Logical Processor to Socket Map:
********  Socket 0

Logical Processor to NUMA Node Map:
********  NUMA Node 0

No NUMA nodes.

Logical Processor to Cache Map:
**------  Data Cache          0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Instruction Cache   0, Level 1,   32 KB, Assoc   8, LineSize  64
**------  Unified Cache       0, Level 2,  256 KB, Assoc   8, LineSize  64
********  Unified Cache       1, Level 3,    8 MB, Assoc  16, LineSize  64
--**----  Data Cache          1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Instruction Cache   1, Level 1,   32 KB, Assoc   8, LineSize  64
--**----  Unified Cache       2, Level 2,  256 KB, Assoc   8, LineSize  64
----**--  Data Cache          2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Instruction Cache   2, Level 1,   32 KB, Assoc   8, LineSize  64
----**--  Unified Cache       3, Level 2,  256 KB, Assoc   8, LineSize  64
------**  Data Cache          3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Instruction Cache   3, Level 1,   32 KB, Assoc   8, LineSize  64
------**  Unified Cache       4, Level 2,  256 KB, Assoc   8, LineSize  64

Logical Processor to Group Map:
********  Group 0

So in etwa sollte das bei jedem Core iX-XXXX aussehen der Hyperthreading unterstützt. Bei dir sieht es halt komplett anders aus.

Am Host sind die Caches nicht korrekt zugeordnet, zu den CPUs gibt es gar keine Infos, und im Gast kommt eh nur noch einzelne Dinge an. Kein Wunder das der Task-Manager da keinen korrekten Wert finden kann. Irgendwas läuft da schief bei dir

Edit: Dein Host meint das alle Caches von allen CPU-Kernen direkt zugegriffen werden können, daher kann der auch munter Threads zwischen den CPU-Kernen verschieben Und laut Dump hast du nur einen physikalischen Kern der 8 Hyper-Threading Kerne simuliert oder sowas in der Art...

Zitat von mainziman

damit wird in der VM sehr wohl die Info zum Cache und so angezeigt,

Bei dir im Screenshot sehe ich nur "nicht zutreffend" (ich vermute mal das soll es heißen). Von daher werden die Infos wohl nicht ganz korrekt angezeigt an der Stelle wo sie es sollten.

Zitat von mainziman

es werden damit 8 physikalische Einzel-CPUs angezeigt an Stelle von einer CPU mit 8 Cores (4 HT Cores)

Das klingt aber eher so als ob die Virtualisierung da was nicht ganz durchgibt. Ich kenne dein Setup nicht, von daher kann ich nichts weiter dazu sagen zu deinem Test. Nur soviel: von sich aus wird qemu/KVM oder sonstige Virtualisierungslösungen wie VirtualBox keine HT-Cores als "HT-Cores" durchreichen. Schon nur weil du mehr CPUs simulieren kannst wie der Host hast oder auch weniger durchreichst. Der Scheduler ändert dann je nachdem noch den Core und schwupp macht eine (automatische) Zuordnung keinen Sinn, und on-the-fly dem Gast die CPUs ändern ist eher eine schlechte Idee. Wenn man das ganze manuell per Hand einrichtet (CPU Pinning etc.) dann mag es möglich sein, weiß ich aber nicht. Bei VirtualBox hab ich noch nie eine Funktion zum anlegen von HT-Cores gesehen.

Von daher hättest du am besten die Ausgabe von Coreinfo gepostet, so ist das nur ein rätselraten was Windows hier erkennt, laut Screenshot nichts korrektes.

Zitat von mainziman

julian-w Multi-Threaded-Programme sollen SetThreadAffinityMask verwenden; SetProcessAffinityMask setzt dies f. alle Threads eines Prozesses;

diese sind dann aber was die Verwendbarkeit auf anderen System angeht eingeschränkt;

In deinem Beispiel ging es doch um Single-Thread Last oder täusche ich mich da? Von daher passt das doch (bzw. würde beides passen).

Zitat von killerbees19

Nur weil man Postfächer und Aliase anlegen kann, müssen diese ja noch nicht aktiv sein. Die Domain und alle damit verknüpften Einträge könnten erst aktiviert werden, wenn die Domain vollständig verifiziert ist. Das machen einige Anbieter so bzw. würde ich es so lösen, wenn ich dieses Feature brauchen würde.

Wenn Plesk das intern nicht unterstützt, wird netcup daran nur wenig ändern können. Außer es als Feature Request einzubringen.

Und genau das ist glaub ich der Punkt. Es gab schon mal einen Thread dazu und da war das genau der Knackpunkt wenn ich mich recht erinnere, also wenn es in Plesk eingerichtet ist, ist es für alle anderen Server direkt aktiv...

Zitat von mainziman

oder wie erklärst sonst obiges Bild?

Vielleicht einfach unsauber programmiert falls es wichtig ist das der Thread auf einem Core läuft bzw. dadurch tatsächlich mehr Performance bringt Windows unterstützt Core Affinitäten (SetProcessAffinityMask). die man zur Laufzeit setzten kann/soll/muss. Davon ab ist die Meinung dazu "der Scheduler weiß besser wie du was er macht, lass ihn seinen Job tun", Initial ging es auch eher darum ob es für Windows egal ist ob es ein HT-Core ist oder ein physikalischer Core, und genau darauf achtet Windows penibel (siehe Screenshot von vmk).

Davon ab hast du bei jedem Context-Switch den Fall das die Register meist geflusht und die L1/L2-Caches nutzlos werden, da ein anderer Thread meist einen anderen Code ausführt und auf einem anderen Daten-Bereich arbeitet. Daher macht es in den meisten Fällen wohl keinen großen Unterschied wenn der Kern getauscht wird (L3-Cache ist ja noch da), und da wo es wirklich einen macht kann der Programmierer das entsprechend mitteilen. Außer man teilt dem System explizit mit auf einem Kern nur einen Thread laufen zu lassen. Das kann der Scheduler aber schwer entscheiden, da er ja nicht weiß wie viel CPU der Thread im nächsten bzw. aktuellen Zyklus brauchen wird. Von daher wird erst mal alles "nach Prioritäten" verteilt, sodass jeder irgendwie irgendwann dran kommt. Jedem Thread der mal etwas CPU gebraucht hat direkt einen kompletten Core zu reservieren kann wohl schnell nach hinten losgehen, gerade unter Windows wo im Hintergrund unzählige Threads laufen die gerne auch mal etwas mehr CPU fressen, da will man nicht das die alle einen Core blockieren.

Falls es wirklich Sinn macht (und die Workload ist wohl eher selten, auf einem fetten Multicore System einen fetten Single-Thread Task laufen zu lassen) muss man dies halt von Hand festlegen, bzw einfach die CPU-Affinität so setzten das der Thread nur auf einem Kern laufen darf. Das ist bei dir wohl schlichtweg nicht der Fall.

Das ganze ist auch in Wiki schön erklärt: https://en.wikipedia.org/wiki/Processor_affinity

Wichtig ist aber das wenn 4 Cores (bei einer 4-Core CPU => 8HT-Core CPU) die mit 4 Threads zu 100% belastet wird, diese 4 Threads alle auf physikalischen Kernen laufen und nicht zwei zusammen auf einem HT-Core und das klappt so auch (siehe Screenshot vmk)

https://serverfault.com/questions/4116…cross-cpu-cores

https://superuser.com/questions/2624…ead-across-cpus

https://docs.microsoft.com/en-us/windows/…iple-processors

Zitat von mainziman

dich hat die Vergangenheit eingeholt,

Das bezweifel ich, ich komme hier nicht direkt mit Win3.11, DOS oder sonstwas an wenn mir etwas nicht passt bzw ich was als "nicht state-of-the-art" darstellen will Und wie du bei vmk siehst wird da nix wild durch die Gegend geschoben.Was du immer hier an Sonderfälle ranpackst wird es immer geben, dafür sind Systeme zu vielfältig, du findest sicher auch irgendein Exoten-OS wo heutzutage nicht mit HT umgehen kann.

Edit: das virtuelle hab ich auch überlesen, da der Scheduler dadurch keinerlei Informationen über CPU-Aufbau oder ähnliches hat (er kennt nicht mal den L1-Cache), ist das natürlich alles hinfällig und er "ignoriert" die Hardware, was will er auch sonst machen er weiß ja nichts über die Hardware

mainziman schwelgt halt gerne in alten Erinnerungen, anders kann ich mir den Exkurs zu WinG und Win3.1 im letzten Beitrag auch nicht erklären oder warum er immer mit so Urzeitsystemen vergangener Tage ankommt wenn er was allgemeines über den Task-Manager schreibt und dann mit WinXP ankommt. Damit rechnet man heutzutage nicht mehr

Aber wie vmk schreibt, alle Scheduler der letzten 10 Jahre (grob) können ordentlich mit HT umgehen und schieben auch keine CPU-lastigen Threads wild durch die Gegend. Sofern man ein halbwegs aktuelles OS betreibt, braucht man sich also darum keinerlei Sorgen machen

Zitat von mainziman

zum Windows Scheduler hat ThomasChr es schon gesagt; und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist, und schon wird, wenn nichts dagegen spricht 'geschoben' mit allen Konsequenzen

Aber gerade da wird doch erwähnt, das der Scheduler auf die Core-Konfiguration achtet: "taking into account [...] as well as the configuration of the multiprocessor system." Und vmk hat das ja noch passend ergänzt: "Windows XP and Windows Server 2003 are hyperthreading-aware."

Und das es Rechenkerne mit anderen Konfiguration gibt wie 2 logische Cores pro physikalischem Core ist ja erst mal egal, das ist halt nur der einfachste Fall. Von daher wird der Windows Scheduler vermutlich eher einen neune CPU-lastigen Thread auf einen zu 5% belegten physikalischen Core legen, anstatt ihn auf den "HyperThread-Core" eines physikalischen Cores zu legen, der zu 100% bereits ausgelastet ist. Erst wenn alle "physikalischen Cores" zu sind, macht es Sinn die HT-Cores zu nutzen (in den meisten Fällen). Okay die Benennung ist etwas doof, aber ich denke man versteht es

Zitat von mainziman

und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist

Nur vor Windows XP, ab dann nicht mehr Bei Linux finde ich gerade die Kernel-Version nicht

Zitat von mainziman

nicht mehr supported ist gut; zum Zeitpunkt als ich mir den Rechner kaufte gabs den Support noch;

Security is a Journey, Not a Destination

Zitat von JohnBoy

Das mag stimmen, dass Mails vonm netcup Mailserver direkt an das "neue" Postfach ausgeliefert werden, aber das ist ein eher geringes Problem - finde ich.

99,9% der Mails bekommen wir nicht von Natcup-Adressen

Das ist aber für netcup das größte Problem, da vermutlich das Briefgeheimnis etc.verletzt werden würde. Mit bösen Absichten könnte man da schon viel Unfug mit treiben. Und eben wie erwähnt, bei 50 Mitarbeitern plus lohnt sich vermutlich ein kleines managed Hosting auf dezidiertem Server, dort hat man all diese Probleme nicht Bei 50 Mitarbeitern macht das unter 1€ pro Mitarbeiter pro Mail, das sollte machbar sein

Und unter Linux gibt es passend dazu "CONFIG_SCHED_SMT" (SMT (Hyperthreading) scheduler support) als Konfigurationsparameter für den Kernel.

Von daher achtet jedes (halbwegs moderne) Betriebssystem schon darauf auf was für Kerne es läuft und erkennt einen Unterschied zwischen zwischen 8 physikalischen Kerne (ohne HT) und 8 logischen Kernen die nur auf 4 physikalische Kerne (dankt HT) abbilden. Und meist wird dies auch dem Nutzer direkt angezeigt bzw. man kann es abfragen

Zitat von mainziman

bei mir sieht es so aus

Konnte ja nicht wissen das wir hier von Systemen reden, die seit Jahren nicht mehr supported werden, zu der Zeit gab es glaub nicht mal Hyper-Threading (Win 2000 vermute ich mal)

Zitat von mainziman

der von Windows zählt hier nicht dazu

Warum nicht? Unter Linux gibt es auch Task-Viewer die das anzeigen, außerdem findet man das recht schnell in der Konsole raus Und der Scheduler ist sich bewusst wenn Hyper-Threading vorhanden ist, das zwei logische Cores auf einen physikalischen Core abbilden. Kann ja auch sinnvoll sein zu wissen was der Hyperthread-Core ist und was nicht, falls man z.B. CPU-Pinning oder ähnliches nutzt (gibt Fälle da sind zwei physikalische Cores besser, aber auch Fälle wo zwei Hyper-Threaded Cores besser sind die auf eine physikalische CPU abbilden, Caching etc.).

Zitat von mainziman

was sich dem Benutzer präsentiert hat dieser z.B. im Task-Manager keinen Unterschied ob es eine CPU mit z.B. 4 Kernen ohne HT od. eine Dual-Core CPU mit HT od. 2 Dual-Core CPUs ohne HT ist/sind ...

Das stimmt so aber nicht, im Taskmanager sieht man sehr wohl einen Unterschied

pasted-from-clipboard.png

Und die meisten Scheduler versuchen schon, wenn sie z.B. zwei Threads (von zwei verschiedenen Programmen) haben die viel CPU brauchen, diese auf physikalisch getrennte Cores laufen zu lassen und nicht auf einem zwei logischen Cores die auf einen Core abbilden.

Zitat von demlak

welches ich auch nicht unbedingt unmittelbar mitbekomme

Eigenes Monitoring schalten?

Zitat von demlak

Externer DNS hat auch immer die _Möglichkeit_ von MITM-Attacken. Hinzu kommen unnötige Datenspuren in Logs von externen Anbietern (Thema Datenschutz),

Was meinst du mit MITM? Das hast du doch immer, DNS-Abfragen sind auch (meist) nur unverschlüsselter, unauthentifizierter Traffic. Und Datenspuren hinterlässt du auch so, ich meine du willst ja deine IP weltweit bekannt und abrufbar machen, jeder kann diese loggen wenn er möchte, man muss einfach nur alle 5min eine DNS-Abfrage starten Viel mehr weiß dein DynDNS-Anbieter auch nicht, gut er kann noch den http-Header auswerten vom API-Call, da kannst du aber selbst bestimmen was du mit sendest.

Zitat von demlak

Wenn da Mist gebaut wird und/oder der Service eingestellt wird, hab ich ein (möglicherweise längeres) Problem

Naja bei DynDNS sollte die TTL sehr klein sein, von daher sollte das Problem nicht lange dauern, ein neuer Anbieter findet sich recht flott und ist i.d.R. superschnell eingebunden (egal ob Fritz!Box oder Linux). Und davon ab ist mir bei den "großen" Anbietern nichts wirklich bekannt, wie z.B. bei dyn.com

Zitat von JohnBoy

Wünschenswert in meinen Augen wäre es, wenn man direkt nach dem Kauf der Domain und vor der wirklichen Übertragung bereits mit der Einrichtung der Webseite und der Emails anfangen könnte.

Mit der Website wäre es noch möglich, E-Mails sind schlichtweg nicht möglich (oder nur mit zusätzlichem Aufwand, ich glaube Plesk unterstützt das aber nicht)

Folgendes Problem: angenommen du transferierst "gmail.com" zu netcup und sagst "jaja, Authcode liefere ich später nach, richtet als mal ein". Dann würden alle E-Mails, die vom Server an diese Domain versendet werden nicht mehr an diese Domain gesendet, sondern direkt lokal zugestellt, da der Server sich schon zuständig fühlt. Somit könntest du sämtlichen E-Mail Verkehr einer Domain innerhalb netcups abfangen.

gmail.com ist jetzt nur ein krasses Beispiel, aber im Grunde besteht das Problem bei jeder Domain die noch nicht zu netcup transferiert wurde: netcup weiß nicht ob du den Auth-Code noch liefern wirst und ob dir die Domain wirklich gehört. Bei gmail.com wäre es noch offensichtlich, bei anderen Domains halt nicht.

Zitat von JohnBoy

Gerade bei vielen Mailadressen und einer komplexen Webseite kan das sicher eine Weile dauern, in der evtl. Emails abgelehnt werden, weil die Mailadresse nicht existiert und die Leute nur eine "hier entsteht eine neue Webseite"-Seite sehen.....

Direkt ein Catch-All einrichten sollte das Problem lösen, danach muss man halt eventuell etwas nachsortieren. Und eine kurze "Website wird gewartet, schauen sie in 30min wieder vorbei"-Seite sollte auch nicht all zu tragisch sein, man wechselt seinen Hoster ja nicht jeden Monat

Davon ab könnte es auch noch Probleme mit der DNS TTL geben, je nachdem was dein alter Hoster da eingestellt hat kann es von dieser Seite aus auch etwas dauern bis ein Umzug überhaupt überall angekommen ist.

Könnte man in die Benachrichtigung E-Mails nicht den Spitznamen des Servers einfügen?

Mit diesem kann ich mehr anfangen wie mit der v22016XXXXXXXXXXXXX Nummer die mir meist gar nichts sagt. So muss ich immer nachsehen welcher Spitzname der Server hat um herauszufinden welches System jetzt neugestartet wird.