Netfabrik Basic: VZ Quotas geändert?

Ja, das beschriebene Verhalten kann ich bestätigen! free zeigt mir rund 128 MB freien Speicher, privvmpages liegt über 64000.

Und bitte lesen Sie, Herr Brömme, noch einmal genau meine Postings. Ich schrieb, dass vor dem fstat-Bug alles korrekt lief, die 256 MB waren wirklich ausreichend. Doch jetzt nach dem Update sind die Mem-Werte wirklich *ohne mein Zutun* erhöht bzw. laufen innerhalb von 24h voll, so dass die gesamte VM hängt.

Z.B. gestern abend: Es waren mal wieder nur Mails auf einem Konto eingegangen, dies deutete in letzter Zeit auf einen hängenden Server hin. Ich also per SSH auf den Server, was in diesen Fällen auch nicht immer ging, aber dann war Schluss! Jeder Befehl, den ich in der Bash-Shell absetzte, wurde mit "Killed" sofort beendet. Ich initierte also den Neustart im Controlpanel, und kurze Zeit später lief der Server wieder. Zumindest bis jetzt, der Failcount ist gleichgeblieben.

Und bezüglich der Config: Was soll ich denn noch tun, als alle Serverprozesse auf maximal einen Thread/Prefork zu begrenzen? Apache, die Authdemons, Postfix (master.cf), alle laufen schon nur einfach.

MfG
Andreas
 
Hi,

@dennis2society: Habs gerade verschickt, ich denke das wird ein paar Tage dauern bis das gefixt ist:

Hi,

well since some weeks we are using the '/proc/meminfo' virtualization and
it seems that we found the first issue with it. ;) Well according to the
manpage the '--meminfo' switch has two different modes

- pages:value - set total memory in pages
- privvmpages:value - set total memory as expression privvmpages * value

I have tried both and both result in the wrong behaviour. Let us use way
two.

My VE 2038168 has the following ubc values set:

OOMGUARPAGES="65536:2147483647" (256 MB RAM)
PRIVVMPAGES="98304:106496" (384 MB RAM)

After that i did the following:

$ vzctl set 2038168 --meminfo privvmpages:1 --save

Right after that i logged in to VE:

root@vs2038168:/# free
total used free shared buffers cached
Mem: 393216 76160 317056 0 0 0
-/+ buffers/cache: 76160 317056
Swap: 0 0 0

root@vs2038168:/# cat /proc/user_beancounters | grep -E 'privvmpages|oomguarpages'
privvmpages 31868 32840 98304 106496 0
oomguarpages 19034 19122 65536 2147483647 0

Well okay after calculating it i got:

oomguarpages * 4 = 19034 * 4 = 76136
privvmpages * 4 = 31868 * 4 = 127472

Okay used memory shows me the used oomguarpages value which is wrong, i am
using 127472 KB not 76136 KB. Some of our customers already asked us, how it
can happen that they use all available privmpages and still have free memory.

Here is a example with a VE using all available privvmpages:

root@vs2038168:/# cat /proc/user_beancounters | grep -E 'privvmpages|oomguarpages'
privvmpages 89347 97933 98304 106496 4
oomguarpages 26016 26457 65536 2147483647 0
root@vs2038168:/# free
total used free shared buffers cached
Mem: 393216 104100 289116 0 0 0
-/+ buffers/cache: 104100 289116
Swap: 0 0 0

--Maik
 
Und was heißt das nun? Ich lese aus der Fehlermeldung, dass nur die free-Anzeige nicht stimmt, oder? Selbst wenn das gefixed würde, löst das nicht unsere Probleme.

MfG
Andreas
 
ich will das mein vServer wieder ordentlich seine Arbeit macht

Ich kann mich nur anschließen. Mir ist es zuerst am Freitag, den 23.03.2007 aufgefallen, das der vServer nicht mehr ordentlich arbeitet. Mailverkehr geht gar nicht mehr. Am System habe ich auch nichts geändert. Früher lief der vServer über Monate ohne Probleme. Ich bin echt sauer.

Ich erwarte hier umgehend Abhilfe und Vertragserfüllung.
 
Für mich sieht das leider auch so aus, als ob nur die
Anzeige von "free" nicht stimmt. Demnach wäre uns nicht
wirklich geholfen wenn das gefixt wird.
Allerdings stellt sich dann die Frage, wieso wir mit den paar
grundlegenden LAMPP-Diensten die zur Zeit laufen bereits die
ganzen 256MB belegen.
Das hat doch vorher schon mal funktioniert. :confused:
 
Hi,

@dennis und jumphigh: Bei euch beiden hatte ich ja die vSERVER Nummern und hab mal in die VEs geguckt, Ein simples LAMP System wuerde funktionieren, allerdings verbrauchen bei euch beiden, spamd, clamd und amavis zusammen schon fast 80MB RAM. Hier wuerde ich mal ansetzen und das optimieren, das ist unnormal.
 
Wollen Sie uns damit sagen, dass man einen kleinen VServer nicht für LAMP (praktisch kein Verkehr) und Mail (ca. 50 am Tag) nutzen kann? Komisch, aber warum ging das nur vor dem Bug??? Irgendwie weichen Sie dieser Frage immer aus...

Und bezüglich Clamd und Amavis: Mit der Zeit füllen sich natürlich die Datenbanken, nur wie soll man das begrenzen, ohne den gelernten Spam-Schutz zu verlieren? In den Configs finden sich, so weit ich das überblicken kann, keine Einstellungen zum Speicherverbrauch. Alles was ich tun kann, ist die Anzahl der Prozesse/Threads herunterzuschrauben, damit nicht mehrere Mails gleichzeitig gescannt werden.

Nun gut, dann habe ich jetzt die Speichercaches für MySQL dramatisch gesenkt. Ich hoffe, ein Key-Cache von 5 MB statt der voreingestellten 20MB reicht auch noch. :-) (Wie gesagt, vorher ging das aber mit diesen Werten.)

Darf man fragen, wann Sie auf unsere Server geschaut haben? So gegen 10:45-10:50 habe ich einige fehlerhafte(?) Authentifizierungsversuche vom saslauthd geloggt. Von aussen können die kaum gekommen sein, da SSH nur auf Keyexchange reagiert. Was haben Sie denn da gemacht?

Und sind Sie auch dafür verantwortlich, dass alle Failcnts auf Null gesetzt wurden? Laut Ihrer Aussage hier im Forum würde das nur bei einem Serverreboot passieren, aber das Controlpanel verzeichnet einen solchen nicht. Auch mein VS hat keinerlei Einträge dafür in den Logs.

MfG
Andreas
 
Last edited by a moderator:
Ich denke nicht, dass mbroemme in unseren Servern rumgemacht hat,
sondern eher, dass der Betreiber durchaus die Möglichkeit hat
sich die Prozesse der einzelnen virtuellen Maschinen anzuschauen.
Vermutlich ist das eine Option der Virtualisierungssoftware.
Ich denke nicht, dass dafuer erst die root-Passwörter geknackt werden müssen ;)

Auf das mit dem Reset vom Output von "cat /proc/user_beancounters"
hat mbroemme mit an Sicherheit grenzender Wahrscheinlichkeit auch keinen
Einfluss. Mich wundert auch, dass ich inzwischen die "Ihr Server wurde
rebootet"-Mails erst einige Stunden nach dem erfolgreichen Reboot kriege,
aber immer nachdem ich diese Mail kriege ist auch die Ausgabe von den
userbeancounters resettet.

Dass trotz allem der Betrieb zur Zeit nicht mehr möglich ist, ist echt
bedauerlich, aber ich hab keine Idee, WAS bei mir soviel Speicher
verbrauchen könnte. Und da ich eh in absehbarer Zeit mal Java
einsetzen möchte und ein Upgrade bei Netfabrik anscheinend nicht
vorgesehen ist, bin ich gerade dabei, den Hoster zu wechseln.
 
Natürlich nehme ich nicht an, dass Herr Brömme unsere Server hackt. ;-)
Ok, habe noch mal genau nachgesehen, irgend ein Depp wollte wohl Postfix als Relay benutzen, und hat dazu versucht, sich anzumelden. Das sieht man aber auch nicht so oft, zumindest bei mir.

Bezüglich der Failcnts und Reboot-Mails: Ja, die Mails kommen jetzt immer auch sehr spät, was aber auch daran liegen kann, dass der Empfänger gerade neu gebootet wird. :-) Ich kenne das Intervall für Neuversuche nicht.
Aber dass die Failcnts auf Null gesetzt werden, ist mir heute zum ersten Mal passiert, bis gestern waren da trotz Reboots über 8000 aufgelaufen.

Mit der MySQL-Anpassung bleibe ich jetzt unter 100MB. Und es stimmt schon, dass speziell Amavis mal so eben 60 MB braucht. Nur erklärt das wirklich nicht, warum es vorher reibungslos funktionierte. Ich hatte eher das Gefühl, dass da irgendein Fehler vorliegt.
Vor allem verwirrt mich, dass sich die Mail in der Mailqueue stauten, weil Amavis sie auf Grund von Speichermangels nicht verarbeiten konnte. Aber nach einem Serviceneustart (soweit SSH noch möglich war) bzw. einem Reboot war die Schlange leer. Warum kam es dann nicht zu einer Speicherüberschreitung??? Ich meine, die Mail waren doch die gleichen wie zuvor. Also entweder war irgendein SuSE-Update fehlerhaft (ich habe aber nur eines für Clamd mitbekommen), oder Virtuozzo mag uns nicht mehr. :eek:

MfG
Andreas
 
Nachtrag zum Speicherverbrauch:

Also ich kenne mich ja mit Linuxprogrammierung nicht wirklich aus, aber IMHO ist Amavis irgendwie Schrott. Bei mir läuft amavisd als Master, gestartet durch init in den Runlevels. Dieser Masterprozess erstellt einen amavisd-Kindprozess, der AFAIK als Mailscanner fungiert. Nur warum müssen beide(!) Prozesse jeweils über 35 MB verbrauchen? Sollte der amavisd-Master-Prozess nicht nur Kontrollaufgaben haben, d.h. die Child-Forks ausführen und Aufgaben verteilen?

Und Clamd benötigt fast 50 MB. Fallen die eigentlich auch an, wenn man den sekundären Kommandozeilenscanner clamscan in Amavis benutzt? Bei geringem Mailaufkommen wäre es IMHO nicht tragisch, wenn der Scanner erst bei jeder Mail extra geladen würde.

MfG
Andreas
 
Last edited by a moderator:
Hallo vROOT,

dieses Forum bietet den Luxus einer Edit-Funktion!
Diese darf sogar Kostenfrei genutzt werden ;)

Das dein Versand nicht geht ist nicht schön, aber dein Hinweis (obwohl Postfix läuft) fördert nicht gerade die Problemlösung. ;)

Aber ich denke das das (vermutlich) nicht in diesen Thread passt.
 
jumphigh said:
Wollen Sie uns damit sagen, dass man einen kleinen VServer nicht für LAMP (praktisch kein Verkehr) und Mail (ca. 50 am Tag) nutzen kann? Komisch, aber warum ging das nur vor dem Bug??? Irgendwie weichen Sie dieser Frage immer aus...
Click to expand...

Ok damit mir keiner mehr sagt: "Ich weiche der Frage aus" Da ich mich sehr gut mit dem Thema auskenne, kann ich auch definitiv sagen, dass hat nichts damit zutun. ;) Das Problem ist ja auch folgendes: In der Standarkonfiguration funktioniert das einwandfrei. Erst spaeter, wenn man zum Beispiel in MySQL INNODB einschaltet (ist per Default aus) oder viele Mails bekommt und mehrere Postfaecher hat, kann das schnell auftreten. ClamAV kann man aber auch beibringen nur einen Thread zu benutzen, das gleiche gilt fuer den spamd etc...

@dennis: Das Upgrade wird in Kuerze wieder eingeschaltet, fragen wirklich viele Kunden nach.
 
Last edited by a moderator:
Ich will Ihnen da gar nicht widersprechen. Sicherlich sind die Datenbanken von Amavis und Clamd mit der Zeit größer geworden und verbrauchen so mehr Speicher. Auch die anderen von Ihnen angesprochenen Configänderungen resultieren natürlich in erhöhtem Speicherverbrauch.

Unbestritten bleibt aber, dass hier mittlerweile 3 User davon berichten, dass seit dem Auftreten des Bugs und dem folgenden Fixing die Speicherauslastung ohne Änderung(!) der schon davor bestehenden und funktionierenden Konfiguration signifikant gestiegen ist. Ginge es nur mir so, wäre ich bereit anzunehmen, dass jetzt meine Datenbestände den Punkt erreicht haben, wo ein Basic-VS zu klein wird. Aber bei drei Nutzer kann ich nicht mehr an so einen Zufall des Zusammentreffens unabhängiger Ereignisse glauben!

Wenn Sie bzw. der Bug und das Fixing wirklich nicht schuld an den Missständen sind, dann bliebe nur anzunehmen, dass ein SuSE-Update etwas am System geändert hat. Aber da ist mir in der Zeit des Bugauftretens eigentlich nur ClamAV aufgefallen. Momentan ist bei mir die Version clamav-0.90.1-1.2 installiert. Es wäre interessant zu erfahren, ob jemand noch die Vorgängerversion hat und mal einen Vergleich bezüglich der Speicherauslastung anstellen könnte. Bei mir hat Clamd ein virtuelles Workingset von 51460KB, davon 46MB an Daten. Allerdings kann ich nicht glauben, dass vorher die Virus-DB sonderlich kleiner war.

Können vielleicht durch den fstat-Bug die Amavis/Spamassassin-DB korrumpiert worden sein? Mein /var/spool/amavis-Verzeichnis hat nämlich auch nur eine Gesamtgröße von 6MB. Woher kommen dann die 2x 35MB bei den laufenden Diensten?

MfG
Andreas
 
Hi,

@jumphigh: Eben nicht, die Leute haben alle unterschiedliche Konfigurationen, nur alle entsprechen nicht mehr "Der von NetFabrik vorgegebenen" und woher die Speicherausnutzung von Amavis resultiert, das muesstest du doch eigentlich wissen. Du administrierst den Amavis doch. :)

Und nein, das fstat() Problem hat nichts damit zutun, das ist ein reines Kernel 32/64 Bit -> 32 Bit Userspace glibc Problem. Bevor mich da jetzt noch mehr fragen, das kann man auf der LKML nachlesen, den Link poste ich jetzt nochmal:

LKML: Jeff Layton: [PATCH 0/3] i_ino uniqueness: alternate approach -- hash the inodes

Das hat absolut nichts mit irgendeinem Speicherverbrauch zutun. Mal ganz nebenbei, wenn wir dieses Zahlenbeispiel anbringen. Drei Kunden stehen einer weitaus anderen Zahl nicht beschwerener Kunden gegenueber, auch die UBC Ueberschreitungen aller Kunden halten sich in Grenzen, nix was ungewoehnlich ist. Manche wollen eben mehr und haben ein zu kleines Angebot. Das eine VE mit der Zeit waechst, mehr Festplattenplatz belegt und eventuell mehr Speicher verbraucht sollte hinreichend bekannt sein und das man das ClamAV Update vorher testet eigentlich auch. :\
 
3 Kunden

"... wenn wir dieses Zahlenbeispiel anbringen. Drei Kunden stehen einer weitaus anderen Zahl nicht beschwerener Kunden gegenueber ..."

1. ob jeder Netfabrikkunde dieses Forum kennt?
2. wenn meine eigen Mail´s nicht über den vServer laufen würden, wären mir die dauernden Störungen noch gar nicht aufgefallen.
3. natürlich verändern Kunden die vServer, Webpresenzen anlegen, Mailkonten anlegen, ... oder gehen die vServer von Netfabrik nur wenn sie "Jungfräulich" bleiben.
4. vServer stopt ständig einzelne Dienste, wie zum Beispiel Postfix.
5. auf meinem gibt es drei Confixxprofile. Mit zwei Mailkonten, drei Webprsenzen, eine kleine Datenbank für einen kleinen Shop. Der Shop hat nicht mal 50 Artikel und bisher Null Kunden.
6. Diese Konfiguration besteht seit über einem Jahr. Im letzten Jahr hat es nie Störungen gegeben.
7. PHP gibt neuerdings Fehler die es früher nicht gab.

MfG einer von "nur" drei Kunden
 
Hi,

@vROOT: root-Zugang, der Schluessel zum Glueck... Was ich damit sagen will, log dich doch endlich mal ein und konfigurier die Dienste so um, dass sie laufen oder falls du dass nicht kannst, ruf beim Support an oder falls du das nicht willst, beim Vertrieb und upgrade den Server.
 
You must log in or register to reply here.
Back
Top