• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

ram limit

Net-MAster

Registered User
Hi,

gibt es ein programm das den speicher zuweist also das programm x nur z.b. 100mb ram usen darf, oder dann das linux schon standartmäßig?

greetz Net-MAster
 
Um mal eine Antwort zu schreiben:
Nein.
Die Unix/Linux-Philosophie stellt grundsätzlich den benötigten Speicher zur Verfügung. Erst wenn es wirklich keinen Speicher mehr gibt ist einen Fehler. Und den nicht nur an das Programm, welches den memalloc macht, sondern auch gleich an syslog.

huschi.
 
Klar gibt das. Ist Teil eines jeden Unix. Auf der Shell gibts dafür den "ulimit" Befehl und in der libc gibts da nette set_ und get_ Aufrufe zu.

Irgendwie kann man auch im PAM diese ulimits setzen, denn ulimits ist meinst ein Shell-interner Befehl. Aber das hab ich irgendwie nie ganz hinbekommen.
 
Huschi said:
Um mal eine Antwort zu schreiben:
Nein.
Die Unix/Linux-Philosophie stellt grundsätzlich den benötigten Speicher zur Verfügung. Erst wenn es wirklich keinen Speicher mehr gibt ist einen Fehler. Und den nicht nur an das Programm, welches den memalloc macht, sondern auch gleich an syslog.

Also ich hab noch nie einen syslog Eintrag gesehen, wenn ich malloc(100000000) machen und es nur ein nettes NULL zurück gab. Zumal, wenn wirklich der Systemspeicher zuende ist, hat Syslog ganz andere Probleme als irgendwas in Dateien zu schreiben - es kämpf dann auch um sein Überleben, wie viele andere Prozesse, die ohne Speicher nicht mehr sauber laufen wollen.
 
brummfondel said:
Also ich hab noch nie einen syslog Eintrag gesehen, wenn ich malloc(100000000) machen und es nur ein nettes NULL zurück gab.
Bei den richtigen Einstellungen sieht man es schon... ;)
... gut dann sieht man auch vielen anderen Müll ...
Aber es gibt (Application-)Server, da muß man sowas sofort sehen.

Was die Libc angeht: Die Funktionien kann man als Programmierer verwenden und schiebt sich selber ein entsprechendes Limit. Und ulimit setzt die (libc-)Limits für die aktuelle Shell. Einen Daemon mit entsprechenden ulimit's starten zu können, ist glaub ich recht schwer. Ausserdem beziehen sich sowohl die libc-Funktionen als auch ulimit immer auf den vollständigen "virtuellen Speicherbereich". Man kann also ein Swappen oder ähnliches damit nicht verhindern.

huschi.
 
Huschi said:
Bei den richtigen Einstellungen sieht man es schon... ;)
... gut dann sieht man auch vielen anderen Müll ...
Aber es gibt (Application-)Server, da muß man sowas sofort sehen.
Aber doch nur, wenn das Programm selbst mitspielt und Logging nutzt. Selbst das Kernel-Logging motzt doch erst, wenn der Kernel-Speicher ausgeht, aber nicht der Applikationsspeicher...
Huschi said:
Was die Libc angeht: Die Funktionien kann man als Programmierer verwenden und schiebt sich selber ein entsprechendes Limit. Und ulimit setzt die (libc-)Limits für die aktuelle Shell. Einen Daemon mit entsprechenden ulimit's starten zu können, ist glaub ich recht schwer. Ausserdem beziehen sich sowohl die libc-Funktionen als auch ulimit immer auf den vollständigen "virtuellen Speicherbereich". Man kann also ein Swappen oder ähnliches damit nicht verhindern.

Doch, da kommt nämlich PAM ins Spiel. Über den läßt sich sowas einstellen. Frag mich nicht, wie. Hab die Maschine, wo ich das mal am laufen hatte, durch einen Fehler der IDE-Jumper geplättet (das waren üble Stunden danach, neben "warum" und "so ein Schrott" bis "hoffentlich lief das Backup"). Also kann man einen Daemon so starten. Irgendwo in der PAM-Doku gefunden.

Daß er nicht swappt ist zugegeben nicht ganz so einfach. Da muß der Prozess selbst schonmal mitspielen und seinen Speicher entsprechend markieren (Sicherheitskritische Programme tun sowas (hoffentlich) immer, damit eventuelle Passworte nicht auf die Platte kommen). Wird sowas beim fork vererbt?

Bleibt noch eine Frage: wenn man nicht swappen lassen will für einen Prozess, warum sollen es dann die anderen dürfen (mal von oben genanntem Grund abgesehen)? Das würde ja die Reaktionszeit eines Systems trotzdem reduzieren - zumindest unter Linux, große Unix-Systeme kommen damit besser klar. Man sollte dann also gleich ganz ohne Swap arbeiten.
 
Back
Top