Threads können nicht erstellt werden

A

Altefier

New Member
Moin,

ich habe vor ein paar Tagen einen vServer von Strato gemietet, Ubuntu vorinstalliert. Ich habe bisher keine Erfahrungen mit Servern gemacht, das ist jetzt mein erster Anlauf.

Zuerst habe ich TeamSpeak installiert und das läuft auch, aber SteamCMD und Minecraft-Server wollen nicht. Bei dem Versuch, jeglichen Server über SteamCMD herunterzuladen, kam es zu Stillständen und letztendlich Fehlermeldungen von wegen Threads, die nicht erstellt werden können. Beim Versuch, einen Minecraft-Server zu starten, habe ich ein ähnliches Problem. Spezifisch lautet hier die Fehlermeldung:

Code: 
[warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached.

Ich weiß nicht, woran das liegen kann. Auf dem Server läuft momentan nur TeamSpeak. Insgesamt CPU-Auslastung <1%, 125MB RAM von 8GB.
 
Ok, hat ein paar Stunden gedauert, aber jetzt habe ich doch noch selbst herausgefunden, woran es lag.

Anscheinend begrenzt Ubuntu die maximalen Threads standardmäßig extrem stark, bei mir auf 60. Das ist gar nichts; TeamSpeak allein braucht schon 21 Threads und insgesamt war das System bei 56 Threads. Kein Wunder, dass Minecraft und SteamCMD nicht liefen.

Man kann in der Datei /etc/systemd/system.conf die DefaultTasksMax erhöhen und dann den Server neu starten. Habe ich gemacht und jetzt läuft es :)
 
Last edited:
Ich denke nicht, dass dies eine Begrenzung von Ubuntu ist. Was sagt
Code: 
 cat /proc/user_beancounters

Code: 
cat /proc/sys/kernel/threads-max
 
cat /proc/sys/kernel/threads-max sagt 8250787

Was cat /proc/user_beancounters mir sagen soll, weiß ich nicht genau. Ich poste das auch einfach mal rein.

Code: 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
   2959606: kmemsize                 53866496             56213504  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                    0  9223372036854775807  9223372036854775807                    0
            privvmpages                749352               763760  9223372036854775807  9223372036854775807                    0
            shmpages                      281                 2062  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        90                   90                  400                  400                    0
            physpages                  739752               740967              2097152              2097152                    0
            vmguarpages                     0                    0  9223372036854775807  9223372036854775807                    0
            oomguarpages               739752               740967                    0                    0                    0
            numtcpsock                      0                    0  9223372036854775807  9223372036854775807                    0
            numflock                        0                    0  9223372036854775807  9223372036854775807                    0
            numpty                          3                    3  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                  297  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                       0                    0  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                       0                    0  9223372036854775807  9223372036854775807                    0
            othersockbuf                    0                    0  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                    0  9223372036854775807  9223372036854775807                    0
            numothersock                    0                    0  9223372036854775807  9223372036854775807                    0
            dcachesize               13504512             13504512  9223372036854775807  9223372036854775807                    0
            numfile                       857                 1515  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                      44                   44                 2000                 2000                    0
 

Prozesse vs. Threads bei Linux V-Servern

Erweitern der Anzahl der Prozesse bei Linux V-Servern selbst vornehmen
www.strato.de www.strato.de

Da das halt ein Container ist, gibt es halt Limits wie numproc, beim Rootserver oder KVM Server hast du das nicht.
Die beamcounters sagen dir halt, wie die aktuelle auslastung ist und wenn failcnt größer 0 ist, heißt dass, das du das Limit erreicht hast.
 
Neogreen said:

Prozesse vs. Threads bei Linux V-Servern

Erweitern der Anzahl der Prozesse bei Linux V-Servern selbst vornehmen
www.strato.de www.strato.de

Da das halt ein Container ist, gibt es halt Limits wie numproc, beim Rootserver oder KVM Server hast du das nicht.
Die beamcounters sagen dir halt, wie die aktuelle auslastung ist und wenn failcnt größer 0 ist, heißt dass, das du das Limit erreicht hast.
Click to expand...

Das Limit war wie gesagt viel geringer und von der Ubuntu-Installation in der Systemkonfiguration definiert, das hatte nichts mit diesen genannten Limits zu tun
 
Ich nehme an du meinst den sysctl Parameter kernel.threads-max?
Dieser ist standardmäßig von Ubuntu laut meinem System nicht verändert und auf den üblichen 449100 gleichzeitigen Threads.
Falls es sich hierbei um den gleichen Parameter handelt und dieser standardmäßig bei Strato auf 60 stehen sollte, so stellt das mehr Fragen über Strato als Ubuntu.

Meine Meinung zu Strato's Vermieten von Workload-Container als virtuellem Server (ist es nicht. Container ist Container) im Jahr 2022 ist: such dir einen vernünftigen Anbieter
 
Altefier said:
Das Limit war wie gesagt viel geringer und von der Ubuntu-Installation in der Systemkonfiguration definiert, das hatte nichts mit diesen genannten Limits zu tun
Click to expand...
Strato nutzt bei den V-Servern Virtuozzo = OpenVZ. Dort werden deine Limits, sichtbar, vom Host gesetzt.
Andernfalls würde auch /proc/user_beancounters nicht existieren.

Lediglich deren CloudServer + Windows V-Server laufen via KVM (o.ä.) soweit ich weiß.
 
Also nochmal zur Erklärung, das liegt schon in erster Linie an Ubuntu. V-Server haben deutlich weniger Threads zur Verfügung als dedizierte Server, logischerweise. Aber immer noch mehr als genug.

Was Ubuntu jedoch standardmäßig macht, ist die Anzahl der zulässigen Threads auf 15% der maximal verfügbaren Threads zu reduzieren. Warum, weiß ich nicht. Bei normalen Computern und Servern hat das keine negative Auswirkung, aber bei virtuellen Servern ist das fatal.

Ihr müsst mir nichts von vernünftigen Anbietern erzählen oder sonst etwas. Das Problem ist doch schon lange gelöst. Erst lesen, dann lästern. Der Server läuft super, kann gleichzeitig einen Webspace, TeamSpeak und Spiele wie Minecraft, Terraria und TF2 hosten und das finde ich für den Preis echt klasse.
 
Ihr müsst mir nichts von vernünftigen Anbietern erzählen oder sonst etwas. Das Problem ist doch schon lange gelöst. Erst lesen, dann lästern.
Click to expand...
Nur weil dein spezifisches Problem gelöst ist, bedeutet das nicht dass objektiv gesehen die Technologie und der Anbieter dem Stand der Technik von heute entsprechen. Wenn ich lästern wollen würde, hätte ich jetzt behauptet dass man hier ein Beispiel vom Endowment-Effekt sieht.

Altefier said:
V-Server haben deutlich weniger Threads zur Verfügung als dedizierte Server, logischerweise.
Click to expand...
Nein, und das ist mein ganzes Argument auf den Punkt gebracht. VServer verhalten sich kerneltechnisch ziemlich genau wie eine Blechbüchse. *Container* hingegen tun das nicht weil der Host-Kernel alle Untermieter betreibt.

Altefier said:
Bei normalen Computern und Servern hat das keine negative Auswirkung, aber bei virtuellen Servern ist das fatal.
Click to expand...
Mein System wo ich die Thread-Limits herausgezogen habe habe, ist selbstverständlich virtuell - so wie alle meine Systeme ausser Desktops und IOT.


=== Sinnvoller Teil====
So, um dem Thread auch noch einen sinnvollen Teil bei zu fügen, hier meine aufgearbeitete Vermutung zur "echten" Ursache (und warum Strato doch schuld ist).

Fangen wir an mit SystemD's DefaultTasksMax=15%. Laut Handbuch:
Defaults to 15% of the minimum of kernel.pid_max=, kernel.threads-max= and root cgroup pids.max. Kernel has a default value for kernel.pid_max= and an algorithm of counting in case of more than 32 cores. For example with the default kernel.pid_max=, DefaultTasksMax= defaults to 4915, but might be greater in other systems or smaller in OS containers.
Click to expand...

Vergleichen wir das mit der "numproc" Zeile der user_beancounters, also der Maximalanzahl an Prozessen die Strato erlaubt:
uid resource held maxheld barrier limit failcnt
numproc 90 90 400 400 0
Click to expand...

Nach Adam Riese -> 15% von 400 ist.... 60 :)

Damit; Systemd (und damit praktisch alle modernen Distros) sind standardmässig nicht erwartungsgemäss lauffähig in einer Strato OpenVZ-Umgebung. Das könnte Strato aber sehr einfach korrigieren, indem sie entweder das Template anpassen oder mehr als eine Handvoll Prozesse im Container erlauben. Alternativ kann der Kunde es ändern indem er von Workload-Container auf eine virtuelle Maschine migriert.
 
Nein, Strato ist immor noch nicht daran Schuld, dass Ubuntu die maximalen Threads auf 15% reduziert. Sie haben ja auch extra dafür den Support-Artikel aufgesetzt, dass das bei Ubunutu nun mal der Fall ist.

Vielleicht kommst du dir jetzt oberschlau vor, dass du herausgefunden hast, dass 400 die 100% sind. Ja ne, is klar. So weit war ich auch schon. Tatsache ist, bis ich jemals die 400 Threads erreichte, hätte ich schon lange keinen Arbeitsspeicher mehr und die Prozessoren wären vermutlich auch an der Grenze. Mit drei Spieleservern, einem TeamSpeak-Server und einem Webserver komme ich nicht mal auf 200 Threads. Von dem Limit merke ich also gar nichts.

Wenn ich lästern wollen würde, hätte ich jetzt behauptet dass man hier ein Beispiel vom Endowment-Effekt sieht.
Click to expand...
Was natürlich eine komplett bescheuerte Einschätzung ist, wenn man bedenkt, dass mir der Server nicht gehört und man monatlich kündigen und zu einem anderen Anbieter wechseln kann. Aber das lasse ich besser bleiben, solange es läuft und mit erstaunlich großem Abstand am billigsten ist.
 
@Altefier Dein Ton ist nicht angemessen. Das ist kein SSF Standard. Diskutiere vernünftig oder wir werden mit Verwarnungen beginnen.

Die letzte OpenVZ Version ist von 2016, also 6 Jahre alt. Das ist definitiv ein totes und längst überholtes Pferd, das Strato da nach wie vor reitet, Strato selbst und viele andere VServeranbieter setzen auf KVM, damit würde man als Kunde deutlich besser fahren. Wer sich damit gegen schmales Geld mit einer uralten Technik begnügen will, viel Spaß.
Aber bedenke: ohne diese uralte Plattform gäbe es diesen Thread nicht, denn es hätte schlicht alles einfach funktioniert.
 
Altefier said:
Vielleicht kommst du dir jetzt oberschlau vor
Click to expand...
Altefier said:
Was natürlich eine komplett bescheuerte Einschätzung ist
Click to expand...
Wie arrogant und anmaßend muß man sein, sich hier als absoluter Neuling mit gerade mal 6 Beiträgen derart im Ton zu vergreifen?

BTW:
Altefier said:
Mit drei Spieleservern, einem TeamSpeak-Server und einem Webserver
Click to expand...
und das alles zusammen auf einer OpenVZ-Kiste:oops:
Jeder Admin, der schon mal Gameserver gehostet hat, wird dir erklären können, warum das nicht unbedingt clever ist. Ich werde es dir nicht erklären, sonst motzt du mich noch genauso an wie @d4f :cool:
 
Mich würd jetzt aber doch interessieren wo steht dass Ubuntu die max-Threads auf irgendeinen geringen Wert setzt?
Du hast von einem Artikel geschrieben wo das steht? Bitte mal den Link posten.

Vielleicht macht dass ein angepasstes Image vom Strato, aber ein normales Ubuntu begrenzt da nichts großartig (Ich behaupte mal 62954 Threads sind 'quasi' unbegrenzt)

Keiner meiner Ubuntu Server (und das sind in den letzten Jahren einige gewesen) hat bei mir die Threads irgendwie (realistisch) begrenzt. Die sind aber halt auch alle mit KVM virtualisiert. Die Strato Virtualisierung tu ich mir nicht mehr an weil ich damit auch einiges an Problemen hatte (sehr geringes Inode Limit, schlechtes IO System).

Und noch zur Klarstellung: 400 Threads sind nicht unbedingt soo viel. Und mit Arbeitsspeicher oder gar CPU Last muss das garnichts zu tun haben da Arbeitsspeicher virtuell ist und zwischen Threads geteilt wird (z.B. COW) und Threads meistens blocked sind und deswegen gar nicht on-cpu.

PS: Habs nun -endlich- kapiert. Ubuntu errechnet die max-Threads (per systemd unit) prozentual von den systemweiten max-Procs aus. Und da diese max-Procs bei Strato auf nur 400 begrenzt sind gibt das so einen geringen Wert. Würde also Strato die max-Procs nicht so massiv begrenzen gäbe es hier keine Probleme. Wobei die das wegs Vietuozzo so begrenzen müssen weil ja sonst der Host evtl. Probleme bekommt.
Läuft halt trotzdem alles drauf raus: Ob mit Strato oder nicht, aber mit KVM wäre das halt nicht passiert!
 
Last edited:
@nexus Danke.
Afaik ist das aber doch irgendein systemd per unit limit und nicht das eigentliche systemweite thread limit, oder?

Und systemd ist auch nicht Ubuntu…
 
Wie arrogant und anmaßend muß man sein, sich hier als absoluter Neuling mit gerade mal 6 Beiträgen derart im Ton zu vergreifen?
Click to expand...
Wie arrogant und anmaßend muss man sein, zu glauben, dass eine Beitragsanzahl bei so etwas eine Rolle spielt? Abgesehen davon wurde sich im Ton bereits vergriffen, als mir Irrtümer in meiner eigenen Erfahrung vorgeworfen wurden und impliziert wurde, ich wüsste nicht, wie viele Threads der Server zur Verfügung hat. Vielleicht kann es ja auch einfach, eventuell, so ganz zufällig, der Fall sein, dass alles funktioniert und ich keine Probleme habe? Wie ich schon zig Mal gesagt habe?

nexus said:
und das alles zusammen auf einer OpenVZ-Kiste:oops:
Jeder Admin, der schon mal Gameserver gehostet hat, wird dir erklären können, warum das nicht unbedingt clever ist. Ich werde es dir nicht erklären, sonst motzt du mich noch genauso an wie @d4f :cool:
Click to expand...
Brauchst du auch nicht, es funktioniert ja :oops::oops::oops: unglaublich aber wahr :cool:

Ich denke nicht, dass ich unangemessen reagiere. Schließlich wird mir hier ja stumpf und ohne Angaben von realen Gründen vorgeschlagen, ich solle doch mal eben ein Gesamt-Backup machen, kündigen, mir einen teureren Anbieter suchen und alles nochmal aufsetzen, wovon ich dann genau welchen Mehrwehrt nochmal hätte? Nachdem das Problem schon lange gelöst und der Thread durch ist, wohlgemerkt. Andere, naivere Nutzer könnten das dann tatsächlich machen. Hier scheint ein Hauch von Elitismus durch den Raum zu wehen – vielleicht braucht man einfach nicht immer das Beste vom Besten. Ist nun mal so.
 
Kannst du dir denn nicht vorstellen dass wir -teilweise aus eigener Erfahrung- schlicht wissen dass Strato oft problematisch ist (wie schon gesagt existieren solche Probleme bei anderen Anbietern wegs anderer Technik nicht) und dir deshalb einen guten Rat geben wollen?

Niemand will dich zwingen hier auf einen Anbieter mit besserer Technik zu wechseln, wir kriegen dafür auch kein Geld.

Wie gesagt hatte ich Probleme mit zuwenig verfügbaren Inodes (hast du diese mal gecheckt bei dir?) und einem teilweise sekundenlang nicht reagierendem IO System.

Gerade weil andere Anbieter diese Probleme wegs besserer Technik (KVM statt Virtuozzo) nicht haben können (max Inodes und max Threads sind da quasi unbegrenzt) und noch dazu nicht wirklich teurer sind, ist ein Wechsel möglichst früh (bevor immer mehr und mehr auf dem Server läuft) eben ein guter Rat.

Niemand will hier Strato um des Namens willen schlecht machen, aber dass deren Virtualisierungstechnik veraltet ist und Limits hat die es bei quasi allen anderen Anbietern nicht gibt ist nunmal ein Fakt.

Wenn du uns sagen magst welches Paket du bei Strato hast und was du zahlst können wir gerne ein paar Benchmarks und Limits vergleichen.

Auch das ist nur ein nett gemeintes Angebot welches für mich nur Arbeit ist, wenn du es annehmen solltest. Ich bin dir also nicht böse wenn du es nicht annehmen magst!

PS: Alle Limits die in der /proc/user_beancounters stehen existieren bei KVM grundsätzlich nicht.

PPS: Du weißt dass du bei der Virtualisierungstechnik von Strato den Kernel nicht aktualisieren kannst?
Ein Update von z.B. Ubuntu 20.04 auf 22.04 ist somit nicht möglich. (ob das immer sinnvoll ist sei mal dahingestellt)

Auch ein installieren eines Betriebssystems direkt vom Installationsmedium (CD/ISO) ist nicht möglich. Du bist drauf festgelegt welche Images Strato anbietet (wobei diese wahrscheinlich von den OS Versionen her schon ausreichend sind). Die Frage ist nur wie lange es dauert bis neue Images kommen (z.B. das bald erscheinende Ubuntu 22.04) was durchaus mal mehr als ein halbes Jahr dauert (Erfahrungswert aus dem Kopf).
Und eigentlich will man ja Server oft gerne aus dem offiziellen ISO installieren als dem (wer weiß wie veränderten) Image des Anbieters zu vetrauen.
 
Last edited:
Vermutlich bezieht er sich auf https://www.strato.de/server/linux-vserver/mini-vserver/ für 1-3€, da wäre der Virtualisierer Virtuozzo.
  • 1 vCore
  • 2 GB RAM garantiert
  • 50 GB SSD
wären da die Werte für den 3€ Server. Wobei "1 vCore" nicht mit "1 vCore" bei einem anderen Anbieter vergleichbar sein muss. Minecraft Server auf derartiger Hardware ist imho unmöglich. Wenns das nicht ist, gehts auf https://www.strato.de/server/linux-vserver/ mit 5€ mindestens weiter.

Ich gehe stark davon aus, dass z.B. ein VPS 200 oder 500 von Netcup oder vergleichbare Server von vielen anderen Anbietern (manche auch hier im Forum) hier bei vergleichbaren Kosten mehr bieten würde. Zwar evtl nicht die gleiche SSD Speichermenge (hier gibt es übrigens auch große Unterschiede), aber der Rest dürfte wohl besser sein. Und man kann halt vor allem machen was man will: eigene ISOs einlegen und installieren u.v.m. und oben genannte Probleme können einem egal sein, da KVM.

Ein Punkt auch noch: wenn das Produkt eher den Einstiegspunkt einer Palette darstellt (anstatt das Ende) kann man ohne Neuinstallation relativ einfach upgraden.
 
You must log in or register to reply here.
Back
Top