Selbst bei einer frisch installierten Instanz und nur einem registrierten Benutzer dauert der Seitenaufbau durchweg 2-3 Sekunden.
Das kenne ich so auch und habe da bisher auch noch keine richtige Lösung gefunden.
Die Datenbank nicht auf dem selben Host zu haben, könnte in jedem Falle ein ordentlicher Flaschenhals sein. Auch wenn die Latency recht gering ist.
Wie sind nginx und fpm verbunden? TCP auf Localhost oder per Unix Socket? Ersteres könnte ein Bottleneck sein.
Hat hier jemand ein Mailcow auf einem 4GB Server am laufen? Funktionieren ClamAV und Solr dort vernünftig?
Hatte ich ziemlich lange. Aber ab nem bestimmten Punkt sind mir immer ClamAV und Rspamd OOM mäßig abgestorben. Denke die 8GB sollte man da schon bereitstellen - ich hab zu dem Zeitpunkt dann auch geupgraded.
Darfst freilich fragen, ich hatte eine Preisgarantie von ca 10 cent bis Jänner 2023 und hab dann gewechselt, im Februar waren es 24cent, im März 20cent und jetzt für April sind es 14cent (jeweils Brutto, Anbieter nennt sich Go Green Energie mit dem Tarif "strom flex")
Ah. Hat mich echt gewundert, warum das so günstig ist. Dann habe ich das ".at" in der Domain gesehen und von einer Österreichischen Strompreisbremse gelesen lol.
Naja, ich zahl dann mal weiter fleißig den tollen deutschen Strom, und freue mich darüber, dass ich mit 37ct/kWh für deutsche Verhältnisse günstig unterwegs bin.
Mein Stromanbieter im Flex Tarif hat mir vor 2 Tagen geschrieben, dass mein Strompreis für April bei 14.4c/kwh liegen wird, was auf dem Niveau von ende 2021 / anfang 2022 ist. Strom und Gaspreise sind an den Energiebörsen auch niedriger als zuvor.
Darf man fragen, was du mit diesem Tarif in den letzten... sagen wir mal 18 Monaten maximal pro kWh gezahlt hast? Würde mich wirklich mal interessieren.
Ich würde ebenfalls vorschlagen, ein Git-Repository zu nutzen und von dort aus per CI/CD den Code auf die Zielsysteme auszuliefern.
Wenn Container vernünftig gepflegt und aktuell gehalten werden, sind sie hier wohl ein guter Ansatz. Zum aktuell halten kann ich wärmstens Renovate empfehlen.
Das Session-Handling deines PHP-FPM solltest du nicht vergessen. Hier wäre es z.B. denkbar, ein Redis Cluster über alle Server zu nutzen und die PHP-FPMs jeweils daran anzuzapfen. Dabei aber auf jeden Fall darauf achten, die Verbindung zwischen den Redis Instanzen sicher zu halten und das Redis Cluster vor Fremdzugriffen zu schützen. Wenn das nicht sicher ist, hast du das Risiko von Session Hijacking - das ist dann spielend einfach möglich.
Problem, es gibt Cronjobs, die auch direkt System-Befehle ausführen bzw. Dienste nutzen, die Abseites des Webservers laufen.
Ich denke hier wären mehr Details sinnvoll. Des Problems Lösung ist stark vom Use Case abhängig.
Temporär die Antwort einmal hier platziert: LXD 5.11 brachte etwas „syntaktischen Zucker“ (und einen ZFS-Block-Modus), welcher die einfache Einbindung von Nicht-ZFS-Dateisystemen ermöglicht (beispielsweise Btrfs*, ext4), sodass man mit Docker den „overlay2"-Treiber verwenden kann; ein Demo-Video vom Projektleiter findet sich hier. Bis zum Erscheinen einer neuen ZFS-Hauptversion, welche Container den Zugriff auf einen Teil des Host-ZFS-Pools erlaubt, sollte das gut genug sein für DroneCI und Co. (hiermit hatte ich bislang keinerlei Probleme).
*Btrfs-auf-ZFS funktionierte seinerzeit vor einigen Monaten nach einem LTS-5.10-Update nicht mehr und überlastete die KVM-Instanzen; seitdem lasse ich die Finger davon.
ZFS und Docker in LXC mögen sich auch nicht. Dem Problem bin ich auch schon einmal bei meinem Brötchengeber begegnet.
Wir haben das so gelöst, dass wir in einem zvol einen LVM Thinpool angelegt haben, wo die LXC Container dann ihre Disks drin hatten.
Und den nächsten hats getroffen. Maxnod datacenter ist abgeraucht.
Ab in die Cloud, mit den Daten!
Lese ich das richtig - wieder Franzosen, und wieder war eine USV bzw. ein Fehler in der Elektrik schuld? Ich sehe parallelen.
Und Anbieter D findet es eine gute Idee echo 3 > /proc/sys/vm/drop_caches in seine Images als Crontab stündlich laufen zu lassen.
Ich öffne jetzt einfach mal die Büchse der Pandora... nicht bezüglich eines Hosters, sondern bezüglich meines HomeLab. Ich habe ein Proxmox mit ZFS am Laufen - und darauf VMs. Jetzt habe ich auf Hostseite einen Cache im RAM - aber bei den Gastsystemen ja auch. Das kommt mir irgendwie ziemlich doppelt gemoppelt vor.
Wie geht ihr mit sowas um?
Wie wird das in großen Firmen oder bei euch in der Arbeit gemacht?
Gegeben des Falles, wir hätten vier mal einen Herbert Mustermann, dann würde das so ausschauen:
herbert.mustermann@example.com
herbert.h.mustermann@example.com
herbert.he.mustermann@example.com
herbert.her.mustermann@example.com
(...und so weiter.)
Sehr großer Konzern mit weit über 300k Mitarbeitern. Namensdopplungen sind absolut normal und das beschriebene Vorgehen gibt es quasi schon ewig.
Kommt drauf an - an sich ist das bei 100% Tochter Firmen nicht selten, das die Mitarbeiter immer bei der Haupt Firma (bzw. einer anderen) angestellt sind.
Machen z.B. viele Supermärkte auch so - die Märkte an sich sind unabhängig, die Mitarbeiter arbeiten aber für eine (Regionale) Dach Gesellschaft - damit könne die Mitarbeiter z.B. getauscht werden, zwischen den Läden
Das ist so natürlich vollkommen korrekt.
Aber schau dir doch mal die Ausschreibungen an. Egal wie viel ich da jetzt im Kopf noch kombiniere oder drehe, das macht halt oft einfach nicht sehr viel Sinn. 
Netcup hat mit dem Support nichts mehr zu tun. Diese Aufgabe übernimmt scheinbar Anexia vollständig.
Aus der Bilanz 2021 (ca. 2 Wochen alt)
Wenn man mal die Job-Ausschreibungen anschaut, sieht man IMHO auch, dass da wild gemischt wird. Ich kann mir nie im Leben vorstellen, dass das alles Netcup Stellen sind. Also von wegen bei Netcup bewerben und bei Netcup arbeiten ist da vermutlich in den meisten Fällen nicht gegeben.
Schreib mir gerne eine Konversation mit ein paar Details (welches OS, welche Applikation läuft darauf, etc.), dann mache ich dir ein Angebot.
Hint: This is a community forum, where customers are helping customers.
Please note, that the netcup support is extremly slow regarding to accounting/billing requests. I waited 17 days for my last request, until it was resolved. So basically, you cannot do anything except being patient... sad. But the low prices must come from somewhere.
Offensichtlich scheint es so zu sein, dass Borgbackup immer das komplette NFS ausliest, wenn es Änderungen auf diesem gab. Wie im Graph zu sehen, ist das zwar nicht viel, was sich da ändert, aber es reicht offensichtlich als Anlass, um alles auszulesen. Auf normalen, lokalen ext4 Dateisystemen passiert das nicht.
Zu früh gefreut...
Ich verstehe das nicht... das ergibt überhaupt keinen Sinn. Mal passiert es, mal nicht.
Kann sich das hier jemand erklären?
Ich habe jetzt mal etwas getestet und seit zwei Tagen ist Ruhe.
Ursprünglich hatte ich den NFS Share einfach mit dem Parameter "defaults" in der /etc/fstab eingehangen.
So ganz sinnvoll ist das nicht, musste ich feststellen.
Aus verschiedensten Quellen habe ich mir jetzt die Parameter "auto,noatime,nolock,intr,tcp,actimeo=5184000,fsc" zusammengestoppelt.
Das funktioniert allerdings nur, weil ich den Storagespace ausschließlich für einen Server nutze. Denn actimeo sagt, dass ich am Host z.B. die Attribute von Dateien im NFS für bis zu 60 Tage cache. Und auch der Parameter "fsc" aktiviert den Cache für Dateien im NFS. Das ist natürlich alles problematisch, wenn man mit mehreren Hosts arbeitet, denn ein anderer Host könnte ja derweil eine Datei im NFS modfizieren.
Ich beobachte das ganze mal noch einige Tage und hoffe, dass nun Ruhe ist.
Schonmal mit iostat oder nfsiostat geschaut?
Was sagen die CPUs. Ist das Netz da?
Ich habe auch einen 10TB storage ueber vlan angebunden. 3 von 14 Servern haben Probleme, weil das vlan intern mit vxlan emuliert wird. Paketverluste von 80%. Unvorhersagbar. Ich weiss nicht, wie borgbackup damit klarkommt.
Noch nicht, nein. Was ich sagen kann: Das Netz ist definitiv durchgehend da und der NFS Storagespace durchgehend erreichbar. Die CPU Last ist, abgesehen vom iowait, fast durchgehend Null.
Der Storagespace ist über das normale WAN Interface angebunden - das ist ja eine NetApp von Netcup, die eine öffentliche IPv4-Adresse hat.
Borg Cache?
Es wird doch dennoch für jede Datei eine Prüfsumme berechnet - somit der gesamte Storagespace eingelesen.
Ja aber nein. Dann müsste ja auf dem großen Server jedes mal so 1,5TB+ vom SAS Storage gelesen werden, was recht offensichtlich nicht der Fall ist. Die Doku sagt dazu:
QuoteBackup speed is increased by not reprocessing files that are already part of existing archives and weren’t modified. The detection of unmodified files is done by comparing multiple file metadata values with previous values kept in the files cache.
This comparison can operate in different modes as given by
--files-cache:
- ctime,size,inode (default)
Interessanterweise ist das ganze letzte Nacht nicht aufgetreten, die Nächte zuvor allerdings immer. Und ja, das Backup ist gelaufen lol.
Ich werde weiter beobachten.
OT: Was ist das fürn Monitoring Tool?
Icinga2 + selbstgeschriebene Plugins + InfluxDB2 + Grafana
Moin Gemeinde,
ich habe vor einigen Tagen einige Server in mein Monitoring aufgenommen und habe eine Interessante Feststellung gemacht.
Gegeben sind mehrere homogen aufgebaute Rootserver unterschiedlicher Größe mit Debian 11 und mit einem LAMP Stack. Einer dieser Server wurde, aufgrund von Storagemangel, mit einem Netcup Storagespace erweitert. Dieser ist per NFS eingehangen - alles soweit unspektakulär.
Gesichert werden alle diese Server per Borgbackup auf ein Offsite Ziel (per SSH). Im Normalfall geht das alles recht zügig, da die Backups inkrementell sind und es nur wenige Veränderungen auf den Systemen gibt. Trotzdem dauert das Backup auf diesem einen Server mit dem Storagespace sehr lang, was sich in einem mehrere Stunden langen Zeitfenster mit sehr viel iowait äußert.
Zum Vergleich hier nochmal zwei Screenshots von einem bedeutend größeren System:
Ich bin mir sehr sicher, dass der Storagespace als NFS Mount ein Problem darstellt. Allerdings habe ich keine Idee, warum das Ganze auf einer normalen lokalen Platte so "flawless" durchläuft und beim NFS so massiven I/O erzeugt. Der Borg Cache sollte ja eigentlich auch für den NFS Mount greifen. Hat jemand von euch eine Idee, woran das liegen könnte?
Das Ganze ist für die Nutzer der Applikation recht unschön, weil ich die Applikation für ein konsistentes Backup natürlich für den Zeitraum des Backups sperren muss. Gerade die Frühaufsteher freuen sich da mächtig drüber.
habe ich einen Trend verpasst? 🤨
Ja.
