Wenn du es im Rettungssystem auf das gemountete System spielst, dann "eventuell" ja.
Eventuell bedeutet: Alle Anwendungen die eine bestimmte IP Adresse, MAC-Adresse oder sonstige Einstellungen (GUID des Laufwerks zum mounten in der /etc/fstab?) haben müssen angepasst werden.
Hallo Felix,
bei mir gings auch mit Ubuntu nicht (genaugenommen aber Ubuntu Mate).
Hier auf Arbeit habe ich:
Firefox 51.0.1 (32-Bit)
Auflösung: 1920 x 1080
Anbei ein Screenshot der Console. Direkt so wie sie aufgeht, also nicht richtig Vollbild, aber schon das Fenster über den kompletten Bildschirm.
Außerdem eines im Vollbild.
Wenn ihr weitere Infos braucht könnt ihr gerne fragen. Ihr könnt auch kurz per Teamviewer schnüffeln wenns hilft...
Thomas
Ich denke was du hier nicht berücksichtigst ist die virtualisierungstechnologie.
Netcup virtualisiert mit KVM. Das ist eine Voll-Virtualisierung und du merkst somit quasi keinen Unterschied zu einem physikalischen System. Außerdem sind die Systeme von netcup auch nicht überbucht.
Kurz und Knapp: Das was du bezahlst bekommst du auch.
Das ist übrigens auch der Grund wieso man das System nicht einfach so upgraden kann...
(Okay, teschnisch gesehen würde es schon gehen, aber es ist nicht ganz so einfach wie bei Containervirtualisierung)
Andere Firmen virtualisieren dagegen mit Containervirtualisierung, da ist das upgraden deutlich einfacher. Oft erkennt man das an solchen Aussagen wie "max. RAM" und "garantierter RAM".
Containervirtualisierung ist -theoretisch- leistungsfähiger als eine Vollvirtualisierung. Dadurch aber dass hier in Wirklichkeit kein echtes System virtualisiert wird hast du einige Einschränkungen:
- Ressourcen können vom Anbieter beliebig beschränkt werden. Nennt sich Beancounters. -> Ich hatte schon einige Bekannte die gegen eine lächerlich geringe Anzahl an gleichzeitiger TCP Verbindungen oder Inodes geschlagen sind.
- Du kannst nicht einfach ein eignes OS installieren. Es gibt hier nicht einfach "Ubuntu" oder "Debian", denn es muss ein Kernel sein der speziell für diese Virtualisierung gebaut worden ist. Also nix mit CD einlegen und Setup starten.
Ich hatte schon einige Bekannte die die günstigen Angebote bei 5&5 oder XXrato genutzt haben und nach einigem Leiden dann doch zu Netcup kamen. Sekundenlang auf die Antwort eines einfachen 'ls'-Befehls zu warten, oder eine Internetseite die ohne erkennbaren Grund doppelt so langsam ist wie bei netcup mag halt nicht jeder.
Versteh mich nicht falsch, ich persönlich finde dass bei netcup derzeit am meisten "Bang for the Buck" zu holen ist - kann aber auch sein dass dein anderer Anbieter sein Versprechen einhält, die Systeme nicht hoffnungslos überbucht sind und es super läuft.
Ich denke übrigens der RS1000 käme mit 30 Webseiten klar, würde persönlich aber eher zum RS 2000 tendieren.
Thomas
PS: Ein paar Daten und Tests gibts in meinem Blog beim Artikel "Neue vServer Generation bei netcup". Eine gewisse Vanessa hat da sogar ein paar Gutscheincodes gepostet...
PPS: Ich würde mich freuen wenn du mir das andere Angebot mal per PM schickst. 12GB RAM, 300 GB SSD und 4 Kerne für 9€/Monat würd ich mir gerne ansehen...
Kann ich auch nachvollziehen.
Im alten VCP kein Problem. Im neuen kriegt man aber nie mehr als ein viertel der Tastatur zu sehen.
Bei mir sowohl im Chrome als auch im Firefox. Fenster vergrößern oder verkleinern hilft auch nicht - es ist mal mehr und mal weniger der Tastatur zu sehen, aber nie die komplette Tastatur.
Hallo Feuertraum,
die SQL Befehle zum löschen und neu erstellen der Tabellen sind:
DROP TABLE IF EXISTS wcf1_session;
CREATE TABLE wcf1_session (
sessionID char(40) NOT NULL default '',
packageID int(10) unsigned NOT NULL default 0,
userID int(10) unsigned NOT NULL default 0,
ipAddress varchar(39) NOT NULL default '',
userAgent varchar(255) NOT NULL default '',
lastActivityTime int(10) unsigned NOT NULL default 0,
requestURI varchar(255) NOT NULL default '',
requestMethod varchar(4) NOT NULL default '',
username varchar(255) NOT NULL default '',
spiderID int(10) unsigned NOT NULL default 0,
PRIMARY KEY (sessionID),
KEY (packageID, lastActivityTime, spiderID),
KEY (userID)
) ENGINE=MEMORY DEFAULT CHARSET=utf8;
DROP TABLE IF EXISTS wcf1_session_data;
CREATE TABLE wcf1_session_data (
sessionID char(40) NOT NULL default '',
userData mediumtext NULL,
sessionVariables mediumtext NULL,
PRIMARY KEY (sessionID)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-> Dies zumindest bei einem Burning Board 3.1.7 was wohl eine ähnlliche bis gleiche Datenbankstruktur hat.
Du musst das obere nur unter SQL einfügen und fertig.
Achte aber darauf dass die Feldstruktur auch deiner entspricht!
Momentan hast du aber wohl ein anderes Problem:
sql error: The table 'wcf1_session' is full
Die Tabelle sollte Eninge=Memory haben. Das heißt das erhöhen des Parameters max_heap_table_size in mysql sollte da mehr Daten reinlassen.
Alternativ könntest du die Tabelle auch als MyISAM speichern, dann liegt sie auf der Platte und kann mehr Daten fassen. Das ist aber eventuell etwas langsamer...
Thomas
PS: Es wäre wohl am ratsamsten wenn du jemanden das machen lässt. Hast du da jemanden zur Hand?
Hmmm, das Problem ist gestern wieder aufgetreten. Diesmal hats sogar den Indianer erwischt.
Dies ist das einzige System was den Speicher so durchgehend fragmentiert und in der Nacht lange Zeit kräftig CPU braucht.
Meine anderen Systeme haben den gleichen Kernel aber keine Probleme.
Wenn ein Fix am 20.02 Februar rauskommen sollte halte ich das bis dahin aus. Alle drei Tage mal routinemäßig rebooten sollte ja ausreichend sein.
Und tagsüber reboot ist für ein Backup System welches nachts Backups macht auch kein Problem.
Jaaaa! Genau den Kernel hab ich!
Damit ist das Problem wohl gefunden, vielen Dank!
Wenn du mal auf eine Tasse (netcup) Espresso eingeladen werden willst, melde dich bei mir 
Hallo .A.,
danke für die Links, werd ich mir mal durchlesen.
Was mich nur wundert: imho war ja mein Speicher garnicht voll, das heißt eigentlich hätte der OOM-Killer doch garnicht erst loslaufen sollen. Warum aber ist er losgelaufen?
Thomas
Hallo fieseline,
mach mal statt 'ls', 'ls -l'.
Thomas
Stimmt. Klar.
Aber die Datei/Ordner 'httpdocs/cloud/config/config.php' sollte sich irgendwo über SSH finden lassen.
Und entweder gibts den Pfad nicht, oder die Rechte stimmen nicht.
Um das derzeitige Problem zeitnah aufspüren zu können, würde ich das System nicht neu starten, da dadurch mit höchster Wahrscheinlichkeit das derzeitige Problem nur nach hinten verschoben wird.
Hallo AndreasDe - da hast du natürlich eigentlich recht. Aber das System ist halt doch produktiv und ich will nicht riskieren dass irgendwas notwendiges nicht mehr sauber läuft.
Beim letzten Mal hat es nach dem Neustart ca. 1 Woche gedauert bis das Problem wieder aufgetreten ist.
Durchs entzerren der Crontab wirds wohl (hoffentlich) gar nicht mehr auftreten. Ist zwar nur ein Workaround aber auf eine Lösung des "eigentlichen Problemes" habe ich momentan wenig Hoffnung.
Mehr als die jetzt schon gesicherten Logfiles würde es auch nicht geben. Mehr als ein 5-minütiges Monitoring der Speicherauslastung mit Munin wird wahrscheinlich auch nichts neues zu Tage bringen.
Außer jemand hätte einen Lösungsansatz, dann probier ich das gerne aus!
Thomas
Naja, ich hatte vermutet dass der OOM-Killer loszieht sobald eine Speicher-Allokierung nicht geklapt hat - und das könnte natürlich der Fall sein wenn der VM-Host keinen Speicher hergibt.
War nur ein Schuß ins blaue - anders kann ich mir das Verhalten leider bislang noch nicht erklären 
Meld dich doch mal per SSH an und schau obs den folgenden Pfad/Datei überhaupt gibt:
/var/www/vhosts/hosting5545.af938.netcup.net/httpdocs/cloud/config/config.phpDer Support hat geantwortet und gesagt:
a) Die Systeme werden nicht überbucht, und
b) Das Hostsystem hatte zum fraglichen Zeitpunkt keine Ressourcenprobleme
So, und wie komme ich jetzt hier weiter?
Wenn irgendwo stehen würde dass zum fraglichen Zeitpunkt tatsächlich alle 4 GB (+ SWAP) verwendet worden sind wäres ja klar - aber das steht ja nirgendwo.
Grumpf!
Ich reboote jetzt mal das System und guck wanns wieder auftritt...
Außerdem hab ich die Sicherungsjobs etwas entzerrt und nutze nun mehr Nacht aus
Um 06:25 Uhr laufen natürlich die Daily-Crontabs. Damit auch ein updatedb.
updatedb bei einer 300 GB SAS Platte dauert auch ein Stück...
Gutem Rat bin ich natürlich weiterhin nicht abgeneigt!
Thomas
Um ~04 Uhr sinds 366565 Inodes. Aber um ~01 Uhr sinds ca. 19344 Dateien.
Um ~01 Uhr läuft auch garkein rsync, da läuft nur der tar (laut Ausgabe des OOM-Killers).
Um ~4 Uhr läuft tatsächlich der rsync während der OOM rumturnt, sogar zweimal. Aber an VM belegt er '44176 KB' und '31477 KB'.
Anbei das Log um 4 Uhr beim OOM-Killer.
Aber auch hier, wenn ich die Speicherbelegung der Prozesse zusammenzähle komme ich auf 2318 MB.
Und auch das Munin zeigt ja (siehe Bilder im ersten Beitrag) immer noch mindestens 1 GB Cache an. Also freier Speicher der genutzt werden kann.
Momentan überlege ich ob eventuell die Hostmaschine den Speicher overprovisioned und meine VM deshalb einfach keinen Speicher mehr allokieren kann, wobei daraufhin der OOM-Killer rumturnt.
Das wäre momentan die einzige vernünftige Erklärung (aus meiner Sicht).
Ich habe den netcup-Support angeschrieben und hoffe dass er mir weiter hilft und nachforscht wie die Speicherauslastung des Hosts zu den fraglichen Zeitpunkten war.
Thomas
PS: Danke für deine Hilfe killerbees19!
Ich habe im entsprechenden OOM-Killer Log mal die Spalte total_vm aller Prozesse zusammengezählt und komme auf:
2489786
Sollten das also Kb sein so sind das 2489 MB. Also 2 GB. Kein Problem für meine theoretischen 4 GB Ram und 4 GB Swap. Möchte man meinen...
Das mit dem Swap gibt der OOM-Killer sogar zu:
Jan 27 01:42:27 blackbird kernel: [659060.647579] Free swap = 4013248kB
Jan 27 01:42:27 blackbird kernel: [659060.647581] Total swap = 4190204kBHier nochmal die aktuelle '/proc/meminfo':
MemTotal: 4046480 kB
MemFree: 135632 kB
MemAvailable: 3494088 kB
Buffers: 1855008 kB
Cached: 382892 kB
SwapCached: 8376 kB
Active: 1297544 kB
Inactive: 1097204 kB
Active(anon): 75736 kB
Inactive(anon): 105484 kB
Active(file): 1221808 kB
Inactive(file): 991720 kB
Unevictable: 3656 kB
Mlocked: 3656 kB
SwapTotal: 4190204 kB
SwapFree: 4054952 kB
Dirty: 8 kB
Writeback: 0 kB
AnonPages: 154396 kB
Mapped: 68096 kB
Shmem: 21948 kB
Slab: 1469628 kB
SReclaimable: 1434568 kB
SUnreclaim: 35060 kB
KernelStack: 3888 kB
PageTables: 13788 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6213444 kB
Committed_AS: 1966544 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 26624 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 1345408 kB
DirectMap2M: 2848768 kBIch besitze seit ein paar Monaten einen S 2000 G7 - also einen KVM Server mit 'relativ wenig' Ram und 'relativ wenig' CPU. Dafür aber ordentlich Plattenplatz.
Die Daten in Kürze:
- 2 vCores
- 4 GB DDR4 RAM (ECC)
- 3 TB SAS Platten
- Hostname: blackbirdAuf dem Server läuft ein Ubuntu 16.04.1 LTS mit: Apache, MariaDB, PHP + BIND9 (und Munin + Icinga2).
Normalerweise hat der Server mehr als genug RAM frei, hier ein aktuelles 'free':
total used free shared buff/cache available
Mem: 3951 177 188 21 3585 3442
Swap: 4091 131 3960Nun hat der Server vier Aufgaben:
a) In der Nacht macht er ordentlich Backups die er sich selber über rsync holt und komprimiert (fängt gegen 1 Uhr an und ist gegen 6 Uhr fertig). Das treibt die load im Zeitraum um 04:39 Uhr rum auf bis zu 2.5 - also etwas mehr als die 2 Cores gemütlich weg frühstücken können.
b) Er macht DynDNS für eine Domain mittels BIND9.
c) Er monitored verschiedene andere Server mit Munin.
d) Er monitored verschiedene andere Server mit Icinga2.
Nun trägt es sich zu dass im fraglichen Zeitraum (also um 04:39 Uhr) der BIND9 vom OOM-Killer unsanft aus dem Leben befördert wurde. Das sieht man im systemd:
root@blackbird:~# service bind9 status
? bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
Drop-In: /run/systemd/generator/bind9.service.d
+-50-insserv.conf-$named.conf
Active: failed (Result: exit-code) since Fri 2017-01-27 04:39:05 CET; 3h 35min ago
Docs: man:named(8)
Process: 19408 ExecStop=/usr/sbin/rndc stop (code=exited, status=1/FAILURE)
Process: 26841 ExecStart=/usr/sbin/named -f -u bind (code=killed, signal=KILL)
Main PID: 26841 (code=killed, signal=KILL)Und man sieht es in der syslog:
Jan 27 01:42:27 blackbird kernel: [659060.651955] Killed process 26955 (mysqld) total-vm:1421004kB, anon-rss:26276kB, file-rss:7428kB
Jan 27 04:39:01 blackbird kernel: [669654.885996] Killed process 12941 (mysqld) total-vm:974540kB, anon-rss:10432kB, file-rss:7668kB
Jan 27 04:39:05 blackbird kernel: [669658.297823] Killed process 12083 (ssh) total-vm:70908kB, anon-rss:24640kB, file-rss:4880kB
Jan 27 04:39:05 blackbird kernel: [669658.375007] Killed process 26841 (named) total-vm:290684kB, anon-rss:3308kB, file-rss:5320kBDie meisten Prozesse wehren sich gegen das ungemütliche vor die Tür setzen dank systemd:
Jan 27 01:42:32 blackbird systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Jan 27 01:42:32 blackbird systemd[1]: mariadb.service: Unit entered failed state.
Jan 27 01:42:32 blackbird systemd[1]: mariadb.service: Failed with result 'signal'.
Jan 27 01:42:32 blackbird systemd[1]: mariadb.service: Service hold-off time over, scheduling restart.
Jan 27 01:42:32 blackbird systemd[1]: Stopped MariaDB database server.
Jan 27 01:42:32 blackbird systemd[1]: Starting MariaDB database server...Leider der bind9 nicht:
Jan 27 04:39:08 blackbird systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Jan 27 04:39:08 blackbird rndc[19408]: rndc: connect failed: 127.0.0.1#953: connection refused
Jan 27 04:39:08 blackbird systemd[1]: mariadb.service: Unit entered failed state.
Jan 27 04:39:08 blackbird systemd[1]: mariadb.service: Failed with result 'signal'.
Jan 27 04:39:08 blackbird systemd[1]: bind9.service: Main process exited, code=killed, status=9/KILL
Jan 27 04:39:08 blackbird systemd[1]: bind9.service: Control process exited, code=exited status=1
Jan 27 04:39:08 blackbird systemd[1]: bind9.service: Unit entered failed state.
Jan 27 04:39:08 blackbird systemd[1]: bind9.service: Failed with result 'exit-code'.
Jan 27 04:39:08 blackbird systemd[1]: mariadb.service: Service hold-off time over, scheduling restart.
Jan 27 04:39:08 blackbird systemd[1]: Stopped MariaDB database server.
Jan 27 04:39:08 blackbird systemd[1]: Starting MariaDB database server...Bevor ich aber jetzt im systemd den bind9 auch einfach restarten lasse, würde ich gerne wissen was der OOM eigentlich für ein Problem hat.
Beim killen vom ersten mysqld in der Nacht sagt er was von "total-vm:1421004kB" - meiner Meinung ist das also eine komplett-Belegung von 1421 MB virtual Memory. Bei 4 GB Ram sollte mich das doch nicht jucken.
Anbei mal die Speicherbelegung (laut munin) um 01:42 Uhr und um 04:39 Uhr.
Script mäßig läuft um 01:42 Uhr ein 'tar -cf' einer sehr großen Datei. Und um 04:39 ein komplett Rsync eines kompletten Servers (~8000 MB).
Die ausführlichere OOM-Ausgabe von 01:42 Uhr habe ich mal angehängt, dort sieht es so aus als sei Icinga für den Start des OOM-Killers verantwortlich:
Jan 27 01:42:27 blackbird kernel: [659060.647302] icinga2 invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0
erklärt aber immer noch nicht warum der OOM-Killer gerade mal was von "total-vm:1421004kB" erzählt.
Das System läuft momentan, den BIND9 habe ich nicht neu gestartet. Hat jemand Ideen, Erklärungen oder Ecken in denen ich suchen soll?
Danke!
Thomas
Unter Ubuntu/Debian sollte das installieren des Paketes 'xrdp' schon ausreichen.
Thomas
PS: Ja, GUI auf Linux Server ist nicht unbedingt eine gute Idee, aber das wirst du ja wissen.
Hmmm, ohne die Domain zu kennen ist es nicht ganz so einfach.
Prinzipiell sollte das Mailsystem schon immer einen FQDN haben (Fully Qualified Domain Name). Das heißt also 'mail.domain.de' oder 'igel.domain.de', was genau ist vollkommen egal, es muss also nicht 'mail' sein.
Dieser FQDN muss natürlich im DNS auflösbar sein auf die IP Adresse des Servers. Und die IP Adresse des Servers muss beim reverse Auflösen diesen FQDN zurückliefern.
Der FQDN 'vxxxxxx.goodserver.de' ist insofern problematisch als das verschiedene Mailprovider (gmx, hotmail, web, gmail) solche 'generischen Namen' mögen die oft nicht.
Thomas
Hallo zoro,
ja, als erste Spielwiese gleich einen ziemlich leistungsfähigen Server zu nehmen ist definitiv nicht optimal. Aber das weißt du ja jetzt...
An deiner Stelle würde ich übrigens nicht Froxlor oder irgendwas anderes nehmen, sondern ein Minimal-Image.
Dann erstmal lernen sich per SSH zu verbinden, auf der Kommandozeile umzugehen und erste Befehle auszuführen.
Wenn du für den einzigen User auf dem Server ein starkes Passwort hast gehst du da auch noch kein Risiko ein.
Wenn du dich sicher fühlst kannst du dann ja mal einen Lamp (Apache + PHP + Mysql) installieren und ne Webseite (Wordpress?) zum laufen bringen.
Und erst danach würde ich mich mit Mailservern beschäftigen, denn die sind -imho- so ziemlich das komplizierteste.
Wenn du Fragen oder Probleme hast helf ich dir gerne, schreib mir einfach eine PM oder schreib hier im Forum!
Thomas