Das längste Thema

  • Jemand ne Idee wie ich debuggen kann, wieso ein Request welches von einem NGINX verarbeitet wird reproduzierbar in unregelmäßigen Abständen exakt 3 Sekunden länger dauert als sonst?


    Am Backend liegts (scheinbar) nicht, da das verhalten bei einem curl direkt auf die Anwendung nicht eintritt. Es scheint ein Problem vom NGINX zu sein...

  • Jemand ne Idee wie ich debuggen kann, wieso ein Request welches von einem NGINX verarbeitet wird reproduzierbar in unregelmäßigen Abständen exakt 3 Sekunden länger dauert als sonst?


    Am Backend liegts (scheinbar) nicht, da das verhalten bei einem curl direkt auf die Anwendung nicht eintritt. Es scheint ein Problem vom NGINX zu sein...

    Benutzt du den Rate Limiter?


    Oder - andere Gedanke, sind nicht geüngend Worker Prozesse da, sodass der Request auf einen freien Slot warten muss? Oder passiert das vielleicht zufällig nur, wenn zeitgleich ein anderer ressourcenintensiver Task läuft?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Nur als kleiner Hinweis für Jitsi Nutzer:


    Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.

    Backup hat zwar geregelt, aber ich werde meine geänderten Dateien in diesem Verzeichnisjetzt mal mit chattr sichern - hoffe das schützt mich vor weiteren Verlusten. ^^

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Komisch: rsnapshot -v (installiert per apt auf Debian 10) liefert als Version nur "rsnapshot" :/


    Code
    jeff@storage2:~$ rsnapshot -v
    rsnapshot
    Usage: rsnapshot [-vtxqVD] [-c cfgfile] [command] [args]
    Type "rsnapshot help" or "man rsnapshot" for more information.

    Auf meiner WD MyCloud kommt wenigstens eine Versionsangabe, dafür ist die Version 10 Jahre alt :D

    Code
    root@JEFF-NAS root # rsnapshot -v
    rsnapshot 1.3.1
    Usage: rsnapshot [-vtxqVD] [-c cfgfile] [command] [args]
    Type "rsnapshot help" or "man rsnapshot" for more information.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Benutzt du den Rate Limiter?

    Nicht in dem server {} Block um den es geht. Generell aber ja.

    Oder - andere Gedanke, sind nicht geüngend Worker Prozesse da, sodass der Request auf einen freien Slot warten muss? Oder passiert das vielleicht zufällig nur, wenn zeitgleich ein anderer ressourcenintensiver Task läuft?

    Habe ich auch schon gedacht. Aktuell sind im Schnitt 800 Connections offen und verarbeitet werden zirka 18 Requests pro Sekunde. Ich habe die VM schon weitere Cores verpasst und die Worker Zahl von 2 auf 3 angehoben. Das hat aber keinerlei Unterschied gemacht. Daher gehe ich nicht davon aus, dass es daran liegt.

  • Hat jemand Interesse an einen VPS 200 G8 Ostern 2019? 1,79€ / Monat, bezahlt bis 21.04.21

    Ich bin dabei umzustellen/auszumisten...

    Verfügbar ab Montag/Dienstag

    Webhosting: Bestprice Classic

    Server: RS Frankenstein - VPS 200 G8 BF20

  • Komisch: rsnapshot -v (installiert per apt auf Debian 10) liefert als Version nur "rsnapshot" :/

    Für Debian-Verhältnisse ist der Fehler #934349 aber noch gar nicht so lange bekannt!

    *duckt und verdrückt sich schleunigst…

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Du hast dann auch nicht das aktuellste FC nn;)

    Was ist ein "FC nn"?

    Nur als kleiner Hinweis für Jitsi Nutzer:


    Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.

    Backup hat zwar geregelt, aber ich werde meine geänderten Dateien in diesem Verzeichnisjetzt mal mit chattr sichern - hoffe das schützt mich vor weiteren Verlusten. ^^

    Ist da nicht der Paketmanager schuld? Ich weiß nicht wie Debian/Ubuntu das machen aber wenn ich unter openSUSE eine Config bearbeitet hab, legt er die neue Upstream-Config unter program.conf.rpmnew ab. Mit rpmconfigcheck kann man überprüfen, ob es neue Config gibt.

    Fedora/RedHat macht das auch so, ist ja wie openSUSE RPM-basiert.

    https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Ist da nicht der Paketmanager schuld? Ich weiß nicht wie Debian/Ubuntu das machen aber wenn ich unter openSUSE eine Config bearbeitet hab, legt er die neue Upstream-Config unter program.conf.rpmnew ab. Mit rpmconfigcheck kann man überprüfen, ob es neue Config gibt.

    Fedora/RedHat macht das auch so, ist ja wie openSUSE RPM-basiert.

    https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/

    Jain. Das ist quasi die "Website" von Jitsi und die wird scheinbar nicht als Config anerkannt, sondern als Anwendungsdaten. Aber da kann man trotzdem noch Dinge einstellen und machen und tun. Das ist das Problem... daher bügelt der da einfach drüber...


    Bei Konfigurationen fragt einen apt, aber nicht bei Anwendungsdaten. Ich meine da fragen yum/dnf oder zypper auch nicht. Wäre ja auch irre.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • die wird scheinbar nicht als Config anerkannt

    handelt es sich um Daten im /etc-Verzeichnisbaum?


    Aber da kann man trotzdem noch Dinge einstellen und machen und tun

    vlt. ein Designfehler, die Config vom Rest zu trennen; ich mein wenn das die Website ist, und man da in einem HTML, JS od. sonstwas noch etwas konfigurieren kann, dann ist das irgendwie nicht logisch;

    Was ist ein "FC nn"?

    FC = Fedora Core und kein Fußballclub^^

    und nn die höchste Nummer, momentan 32 soweit ich das sehe ;)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • handelt es sich um Daten im /etc-Verzeichnisbaum?

    Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.



    vlt. ein Designfehler, die Config vom Rest zu trennen; ich mein wenn das die Website ist, und man da in einem HTML, JS od. sonstwas noch etwas konfigurieren kann, dann ist das irgendwie nicht logisch;

    Da hast du natürlich wahr - an Jitsi gibt es technisch so einige Designfehler, wenn du micht fragst. Das ist eine .js Datei mit einigen Konfigurationsdirektiven für das Frontend. Hat schon mit der Website zu tun, ist aber trotzdem eine Konfiguration.

    Zweifelsfrei ein Designfehler, wie du selbst sagst...

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Falls du die interface_config.js meist: Einfach via nginx ein Alias anlegen und mit nach /etc/jitsi/meet/ schmeißen

    Meine ich. Aber chattr tuts jetzt auch... ^^

    Betrifft auch noch einige andere Dateien in dem Verzeichnis, von daher. ;)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Je mehr ich hier über Jitsi lese, desto weniger möchte ich so ein Teil irgendwo administrieren müssen! ^^


    (Muss ich zum Glück auch nicht. Und werde ich freiwillig auch nicht machen.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)