Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #72781 > unrolled thread

Virtual memory limits for 1 process

Back to article view | Back to comp.sys.mac.system

Contents

  Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-07 04:08 -0400
    Re: Virtual memory limits for 1 process Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-04-07 08:29 -0400
      Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-07 13:10 -0400
        Re: Virtual memory limits for 1 process Alan Baker <email@domain.com> - 2015-04-07 10:42 -0700
          Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-07 16:08 -0400
        Re: Virtual memory limits for 1 process Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-04-07 20:36 -0400
    Re: Virtual memory limits for 1 process billy@MIX.COM - 2015-04-07 16:54 +0000
      Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-07 13:33 -0400
    Re: Virtual memory limits for 1 process Siri Cruz <chine.bleu@yahoo.com> - 2015-04-07 22:14 -0700
      Re: Virtual memory limits for 1 process Huge <Huge@nowhere.much.invalid> - 2015-04-08 07:19 +0000
        Re: Virtual memory limits for 1 process Siri Cruz <chine.bleu@yahoo.com> - 2015-04-08 00:27 -0700
          Re: Virtual memory limits for 1 process Huge <Huge@nowhere.much.invalid> - 2015-04-08 08:26 +0000
            Re: Virtual memory limits for 1 process Siri Cruz <chine.bleu@yahoo.com> - 2015-04-08 08:02 -0700
      Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-08 03:43 -0400
        Re: Virtual memory limits for 1 process David Ritz <dritz@mindspring.com> - 2015-04-08 10:01 -0500
          Re: Virtual memory limits for 1 process Barry Margolin <barmar@alum.mit.edu> - 2015-04-08 12:08 -0400
          Re: Virtual memory limits for 1 process Siri Cruz <chine.bleu@yahoo.com> - 2015-04-08 10:41 -0700
            Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-08 15:41 -0400
              Re: Virtual memory limits for 1 process Barry Margolin <barmar@alum.mit.edu> - 2015-04-08 15:48 -0400
                Re: Virtual memory limits for 1 process Siri Cruz <chine.bleu@yahoo.com> - 2015-04-08 12:58 -0700
                  Re: Virtual memory limits for 1 process JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-04-08 19:15 -0400
          Re: Virtual memory limits for 1 process Alan Baker <email@domain.com> - 2015-04-08 11:55 -0700

Page 1 of 2  [1] 2  Next page →

#72781 — Virtual memory limits for 1 process

Am writing a C application that will be matching GPS tracks with
elevation data.

At the moment, the application does an mmap to a .tif elevation file
(about 25MB) to do testing, but potemtially hundreds of such files could
be needed. (all of australia for instance)

I open the files reald only and speified the "shared" option in mmap.

Does OS-X at the unix level (command line) impose limits on number of
files tat can be opened at a time, and the virtual memory that can be
mapped via mmap ?

last I played with such data, it was a 30° dataset which required only 2
files be opened for all of australia.  With the SRTM 1 second data
available, we are talking about 25MB for each square degree, each in its
own file.

If handing so many files is a problem, I would concentrate on merging
the tif files into one raw data file, instead of the app directly
accessing hundreds of those tif files.

[toc] | [next] | [standalone]

#72784

On 2015-04-07 04:08, JF Mezei wrote:
> Am writing a C application that will be matching GPS tracks with
> elevation data.
>
> At the moment, the application does an mmap to a .tif elevation file
> (about 25MB) to do testing, but potemtially hundreds of such files could
> be needed. (all of australia for instance)
>
> I open the files reald only and speified the "shared" option in mmap.
>
> Does OS-X at the unix level (command line) impose limits on number of
> files tat can be opened at a time, and the virtual memory that can be
> mapped via mmap ?
>
> last I played with such data, it was a 30° dataset which required only 2
> files be opened for all of australia.  With the SRTM 1 second data
> available, we are talking about 25MB for each square degree, each in its
> own file.
>
> If handing so many files is a problem, I would concentrate on merging
> the tif files into one raw data file, instead of the app directly
> accessing hundreds of those tif files.

Oddly enough I do some GPS work with a 32 bit compiler.  Thought I don't 
need nearly so much memory, in testing the limits I can load up to 3.5 
GB of data into dynamically allocated memory (b-trees and linked lists 
of large arrays).

[toc] | [prev] | [next] | [standalone]

#72797

On 15-04-07 08:29, Alan Browne wrote:

> Oddly enough I do some GPS work with a 32 bit compiler.  Thought I don't 
> need nearly so much memory, in testing the limits I can load up to 3.5 
> GB of data into dynamically allocated memory (b-trees and linked lists 
> of large arrays).


on VMS, there are specific per precess limits on number of files that
can be opened at a time and how much virtual (and physical) memory a
process is allowed to consume. So when designing an app, you have to
make sure the app either fits those limits, or that you boost the limits.

On OS-X/Unix, I have no kowledge of such limits, hence my question of
whether opening hundreds of files and doing an mmap on them is
somethingt that is within the limits.   (this is to eventually build 3D
model of australia so there are a lot of tiles that needs to be loaded).

[toc] | [prev] | [next] | [standalone]

#72802

On 2015-04-07 17:10:08 +0000, JF Mezei said:

> On 15-04-07 08:29, Alan Browne wrote:
> 
>> Oddly enough I do some GPS work with a 32 bit compiler.  Thought I don't
>> need nearly so much memory, in testing the limits I can load up to 3.5
>> GB of data into dynamically allocated memory (b-trees and linked lists
>> of large arrays).
> 
> 
> on VMS, there are specific per precess limits on number of files that
> can be opened at a time and how much virtual (and physical) memory a
> process is allowed to consume. So when designing an app, you have to
> make sure the app either fits those limits, or that you boost the limits.
> 
> On OS-X/Unix, I have no kowledge of such limits, hence my question of
> whether opening hundreds of files and doing an mmap on them is
> somethingt that is within the limits.   (this is to eventually build 3D
> model of australia so there are a lot of tiles that needs to be loaded).

There are such limits, and they can be modified if you have special 
requirements.

This command: "sysctl -a | grep file"

kern.maxfiles = 12288
kern.maxfilesperproc = 10240
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
kern.corefile = /cores/core.%P
kern.maxfiles: 12288
kern.maxfilesperproc: 10240

kern.corefile: /cores/core.%P
kern.hibernatefile: /var/vm/sleepimage
kern.num_files: 3565
vm.vm_page_filecache_min: 209715

This guy has a bit more to say on how to change the limits:

<http://krypted.com/mac-os-x/maximum-files-in-mac-os-x/>

[toc] | [prev] | [next] | [standalone]

#72805

On 15-04-07 13:42, Alan Baker wrote:

> There are such limits, and they can be modified if you have special 
> requirements.
> 
> This command: "sysctl -a | grep file"
> 
> kern.maxfiles = 12288
> kern.maxfilesperproc = 10240
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Many thanks. For me, it shows 150,000 files per process as max. a *tad*
more than I need so I should be OK. I believe I need roughly 1200 for
australia.

[toc] | [prev] | [next] | [standalone]

#72816

On 2015-04-07 13:10, JF Mezei wrote:
> On 15-04-07 08:29, Alan Browne wrote:
>
>> Oddly enough I do some GPS work with a 32 bit compiler.  Thought I don't
>> need nearly so much memory, in testing the limits I can load up to 3.5
>> GB of data into dynamically allocated memory (b-trees and linked lists
>> of large arrays).
>
>
> on VMS, there are specific per precess limits on number of files that
> can be opened at a time and how much virtual (and physical) memory a
> process is allowed to consume. So when designing an app, you have to
> make sure the app either fits those limits, or that you boost the limits.
>
> On OS-X/Unix, I have no kowledge of such limits, hence my question of
> whether opening hundreds of files and doing an mmap on them is
> somethingt that is within the limits.   (this is to eventually build 3D
> model of australia so there are a lot of tiles that needs to be loaded).

So write a program with a linked list of file handles, open and link, 
open and link ... with a displayed counter.  When the computer crashes 
you'll know the limit.

I got to 2558 files before an error 4 occurred.  Code below.
(error 4 is freepascal for "too many files open").

Whether that is a FPC error or Unix error I don't know.

/Volumes/RamDisk/YellowPinkoCommies_0.txt
/Volumes/RamDisk/YellowPinkoCommies_1.txt
/Volumes/RamDisk/YellowPinkoCommies_2.txt
...
/Volumes/RamDisk/YellowPinkoCommies_2556.txt
/Volumes/RamDisk/YellowPinkoCommies_2557.txt
2558 files opened at once
Alans-iMac:pascal alanbrowne$



Program TestFileLimit;

TYPE
	TFListPtr = ^TFList;
	TFList=record
		F: text;
		Fn: ansistring;
		next: TFlistPtr;
	END;
	
CONST
	namebase = '/Volumes/RamDisk/YellowPinkoCommies_';
VAR
	n: int64 = 0;
	root : TFListPtr = nil;
	S: string[255];
	Ttemp, Tprev : TFlistPtr;
	Ei : integer;
	j : word;
	
	
BEGIN
	Repeat
		str(n:0,S);
		new (Ttemp);
		Ttemp^.next := nil;
		Ttemp^.Fn := namebase + S + '.txt';
		writeln (TTemp^.Fn);
		assign (Ttemp^.F,TTemp^.Fn);
		{$I-}
		rewrite (TTemp^.F);
		Ei := IOResult;
		if Ei = 0 then
		  begin
				for j := 1 to 25000 do write
					 (TTemp^.F,chr($41+random(26)));
				if root = nil then
				begin
					root := TTemp;
					Tprev := Ttemp;
				end
		  	   else
		  			Tprev^.next := TTemp;
			inc(n);
		  end;
	Until Ei <> 0;	
	Tprev := root;
	Repeat
		Close (Tprev^.F);
		Tprev := Tprev^.next;
	Until Tprev = nil;
	writeln (n+1,' files opened at once');
end.

[toc] | [prev] | [next] | [standalone]

#72796

JF Mezei <jfmezei.spamnot@vaxination.ca> writes:

> Does OS-X at the unix level (command line) impose limits on number of
> files tat can be opened at a time

HFS may be a problem.  Take a look at this thread -

large scale (audio) file I/O on OS X : help or insight requested
http://lists.apple.com/archives/coreaudio-api/2015/Mar/msg00018.html

Sadly, the base note is not in the archive, but you can see it quoted
here.  There are several interesting followups to this query, which can
be read by following the links at the bottom of the pages.

Yea, I realize you probably won't be simultaneously reading all your
open files, but this may be useful info anyway.

Billy Y..
-- 
        sub     #'9+1   ,r0             ; convert ascii byte
	add     #9.+1   ,r0             ; to an integer
	bcc     20$                     ; not a number

[toc] | [prev] | [next] | [standalone]

#72801

On 15-04-07 12:54, billy@MIX.COM wrote:

> large scale (audio) file I/O on OS X : help or insight requested
> http://lists.apple.com/archives/coreaudio-api/2015/Mar/msg00018.html

Thankfully (for me) the above appears to be a performance issue. I am
not very concerned about performance, it is more to do whether it will
work or not.

While I will have to pre-open all files first, and do preliminary scan
of the TIFF tags to geolocate each tile, the rest of the 25MB of data is
generally going to be accessed on a block by block basis as my request
for elevation will be near the previous request and move in consistent
direction.

So I can let the virtual memory system work its magic in terms of which
portions of files are needed in RAM at any one point in time. And since
those files are opened read-only and "shared", I hope/think that the
mapping will be done directly to the file and not make use of any
page/swap file.

Failing this, I may have to build a preliminary scan of all files and
load their geographical limits in memory, and then do "on-demand"
mapping of individual files and manually close them when no longer needed.

[toc] | [prev] | [next] | [standalone]

#72822

> Does OS-X at the unix level (command line) impose limits on number of
> files tat can be opened at a time, and the virtual memory that can be
> mapped via mmap ?

It can. The C interface is getrlimit and setrlimit. The shell command to 
interrogate and set limits is ulimit
    ulimit -a

Your process should have defaults considerred reasonable, and you should be able 
to extend any limit to the hardware avaiable on your box.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#72827

On 2015-04-08, Siri Cruz <chine.bleu@yahoo.com> wrote:
>> Does OS-X at the unix level (command line) impose limits on number of
>> files tat can be opened at a time, and the virtual memory that can be
>> mapped via mmap ?
>
> It can. The C interface is getrlimit and setrlimit. The shell command to 
> interrogate and set limits is ulimit
>     ulimit -a
>
> Your process should have defaults considerred reasonable, and you should be able 
> to extend any limit to the hardware avaiable on your box.

Could you consider including some attribution information, please? Otherwise
it is very hard to know to whom you are replying.


-- 
Today is Pungenday, the 25th day of Discord in the YOLD 3181
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#72828

In article <cok33kF5jdqU2@mid.individual.net>, Huge <Huge@nowhere.much.invalid> 
wrote:

> On 2015-04-08, Siri Cruz <chine.bleu@yahoo.com> wrote:
> >> Does OS-X at the unix level (command line) impose limits on number of
> >> files tat can be opened at a time, and the virtual memory that can be
> >> mapped via mmap ?
> >
> > It can. The C interface is getrlimit and setrlimit. The shell command to 
> > interrogate and set limits is ulimit
> >     ulimit -a
> >
> > Your process should have defaults considerred reasonable, and you should be 
> > able 
> > to extend any limit to the hardware avaiable on your box.
> 
> Could you consider including some attribution information, please? Otherwise
> it is very hard to know to whom you are replying.

http://slrn.sourceforge.net/docs/slrn-manual-7.html#ss7.2

get_parent_header
Default: "ESC p"
Goes to the current article's parent, downloading it from the server if 
necessary. When used with a prefix argument, the whole thread is reconstructed; 
the prefix argument two makes this faster, but more likely to miss some articles 
(see get_children_headers for a discussion of this).

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#72832

On 2015-04-08, Siri Cruz <chine.bleu@yahoo.com> wrote:
> In article <cok33kF5jdqU2@mid.individual.net>, Huge <Huge@nowhere.much.invalid> 
> wrote:
>
>> On 2015-04-08, Siri Cruz <chine.bleu@yahoo.com> wrote:
>> >> Does OS-X at the unix level (command line) impose limits on number of
>> >> files tat can be opened at a time, and the virtual memory that can be
>> >> mapped via mmap ?
>> >
>> > It can. The C interface is getrlimit and setrlimit. The shell command to 
>> > interrogate and set limits is ulimit
>> >     ulimit -a
>> >
>> > Your process should have defaults considerred reasonable, and you should be 
>> > able 
>> > to extend any limit to the hardware avaiable on your box.
>> 
>> Could you consider including some attribution information, please? Otherwise
>> it is very hard to know to whom you are replying.
>
> http://slrn.sourceforge.net/docs/slrn-manual-7.html#ss7.2

Thanks for confirming you're a selfish, intolerant, ignorant cunt and can
be killfiled and forgotten along with your ilk.


-- 
Today is Pungenday, the 25th day of Discord in the YOLD 3181
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#72848

> >> Could you consider including some attribution information, please? 
> >> Otherwise
> >> it is very hard to know to whom you are replying.
> >
> > http://slrn.sourceforge.net/docs/slrn-manual-7.html#ss7.2
> 
> Thanks for confirming you're a selfish, intolerant, ignorant cunt and can
> be killfiled and forgotten along with your ilk.

No problem. You're welcome.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#72830

On 15-04-08 01:14, Siri Cruz wrote:

> It can. The C interface is getrlimit and setrlimit. The shell command to 
> interrogate and set limits is ulimit
>     ulimit -a


Ahh... Many thanks.

velo:source $  ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1250
virtual memory          (kbytes, -v) unlimited



So by default, 256 files. So I'll have to raise it.

(Now have to figure out how to donwload all those individual tile files).

[toc] | [prev] | [next] | [standalone]

#72847

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

On Wednesday, 08 April 2015 03:43 -0400, 
 in article <5524dc0a$0$16874$c3e8da3$76a7c58f@news.astraweb.com>, 
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-04-08 01:14, Siri Cruz wrote:

>> It can. The C interface is getrlimit and setrlimit. The shell command to 
>> interrogate and set limits is ulimit
>>     ulimit -a

> Ahh... Many thanks.

> velo:source $  ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> file size               (blocks, -f) unlimited
> max locked memory       (kbytes, -l) unlimited
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 256
> pipe size            (512 bytes, -p) 1
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 1250
> virtual memory          (kbytes, -v) unlimited

> So by default, 256 files. So I'll have to raise it.

No, you are mistaking the 256 currently open files for a limit.  Using 
the same tool, I show 2560 currently open files.

-- 
David Ritz <dritz@mindspring.com>
 Be kind to animals; kiss a shark.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUlQq8ACgkQUrwpmRoS3uvjWwCgqHibl5U6ihkYKkbD3dklMKws
b+QAniIBK205TNG9ok+aU5jg0LyVzjow
=NdR+
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#72857

In article <alpine.OSX.2.20.1504080957520.61536@mako.ath.cx>,
 David Ritz <dritz@mindspring.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> On Wednesday, 08 April 2015 03:43 -0400, 
>  in article <5524dc0a$0$16874$c3e8da3$76a7c58f@news.astraweb.com>, 
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > On 15-04-08 01:14, Siri Cruz wrote:
> 
> >> It can. The C interface is getrlimit and setrlimit. The shell command to 
> >> interrogate and set limits is ulimit
> >>     ulimit -a
> 
> > Ahh... Many thanks.
> 
> > velo:source $  ulimit -a
> > core file size          (blocks, -c) 0
> > data seg size           (kbytes, -d) unlimited
> > file size               (blocks, -f) unlimited
> > max locked memory       (kbytes, -l) unlimited
> > max memory size         (kbytes, -m) unlimited
> > open files                      (-n) 256
> > pipe size            (512 bytes, -p) 1
> > stack size              (kbytes, -s) 8192
> > cpu time               (seconds, -t) unlimited
> > max user processes              (-u) 1250
> > virtual memory          (kbytes, -v) unlimited
> 
> > So by default, 256 files. So I'll have to raise it.
> 
> No, you are mistaking the 256 currently open files for a limit.  Using 
> the same tool, I show 2560 currently open files.

ulimit doesn't show current usage, it just shows the current limits.

Note that there are both hard and soft limits. The soft limit is the 
restriction that's currently enforced, and is shown by default with 
ulimit -a, but you can increase it up to the value of the hard limit.

$ ulimit -a -H
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) unlimited
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 65532
cpu time               (seconds, -t) unlimited
max user processes              (-u) 532
virtual memory          (kbytes, -v) unlimited
$ ulimit -n 1000
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1000
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 266
virtual memory          (kbytes, -v) unlimited

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#72862

In article <alpine.OSX.2.20.1504080957520.61536@mako.ath.cx>,
 David Ritz <dritz@mindspring.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> On Wednesday, 08 April 2015 03:43 -0400, 
>  in article <5524dc0a$0$16874$c3e8da3$76a7c58f@news.astraweb.com>, 
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > On 15-04-08 01:14, Siri Cruz wrote:
> 
> >> It can. The C interface is getrlimit and setrlimit. The shell command to 
> >> interrogate and set limits is ulimit
> >>     ulimit -a
> 
> > Ahh... Many thanks.
> 
> > velo:source $  ulimit -a
> > core file size          (blocks, -c) 0
> > data seg size           (kbytes, -d) unlimited
> > file size               (blocks, -f) unlimited
> > max locked memory       (kbytes, -l) unlimited
> > max memory size         (kbytes, -m) unlimited
> > open files                      (-n) 256
> > pipe size            (512 bytes, -p) 1
> > stack size              (kbytes, -s) 8192
> > cpu time               (seconds, -t) unlimited
> > max user processes              (-u) 1250
> > virtual memory          (kbytes, -v) unlimited
> 
> > So by default, 256 files. So I'll have to raise it.
> 
> No, you are mistaking the 256 currently open files for a limit.  Using 
> the same tool, I show 2560 currently open files.

There's no reason not to have different limits on different boxes. The defaults 
should be large enough to run processes without running out of hardware. Since 
Macs is mostly running a single user at a time, MacOSX doesn't prohibit you from 
screwing up yourself the way timesharing multiuser unix try to do.

ulimit -Sa are soft limits. Violate a soft limit and you get a warning.
ulimit -Ha are hard limits. Violate those and kernel sends a signal to abort or 
something like that. (man setrlimit for details.)

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#72874

On 15-04-08 13:41, Siri Cruz wrote:

> There's no reason not to have different limits on different boxes. 

My *assumption* is that if ulimit gets raised by by an app at one point,
it remains high for the duration of that process.

Opening files consumes resources (file descriptors in memory, locks to
indicate file has been opened etc). So I can understand an OS putting
limits on how many files can be opened at one point.


> ulimit -Sa are soft limits. Violate a soft limit and you get a warning.

will the fopen or open in C still function ? I take it that it will
issue warning for each file after 256 that is being opened, so if I have
to opene 1200 files, that would be a LOT of warnings. More happy to
ulimit -f 1300 before running my program to be sure.

[toc] | [prev] | [next] | [standalone]

#72875

In article <5525845d$0$64257$c3e8da3$b280bf18@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-04-08 13:41, Siri Cruz wrote:
> 
> > There's no reason not to have different limits on different boxes. 
> 
> My *assumption* is that if ulimit gets raised by by an app at one point,
> it remains high for the duration of that process.
> 
> Opening files consumes resources (file descriptors in memory, locks to
> indicate file has been opened etc). So I can understand an OS putting
> limits on how many files can be opened at one point.
> 
> 
> > ulimit -Sa are soft limits. Violate a soft limit and you get a warning.
> 
> will the fopen or open in C still function ? I take it that it will
> issue warning for each file after 256 that is being opened, so if I have
> to opene 1200 files, that would be a LOT of warnings. More happy to
> ulimit -f 1300 before running my program to be sure.

It doesn't "issue a warning", the attempt to open a file simply fails. 
The difference is that the process can increase its own soft limit, up 
to the amount in the hard limit (only a system administrator can 
increase the hard limit).

A better way to think of it is that the soft limit is a self-imposed, 
voluntary limit, while the hard limit is a system-imposed limit.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#72877

In article <barmar-170BFD.15485408042015@88-209-239-213.giganet.hu>,
 Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <5525845d$0$64257$c3e8da3$b280bf18@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > On 15-04-08 13:41, Siri Cruz wrote:
> > 
> > > There's no reason not to have different limits on different boxes. 
> > 
> > My *assumption* is that if ulimit gets raised by by an app at one point,
> > it remains high for the duration of that process.
> > 
> > Opening files consumes resources (file descriptors in memory, locks to
> > indicate file has been opened etc). So I can understand an OS putting
> > limits on how many files can be opened at one point.
> > 
> > 
> > > ulimit -Sa are soft limits. Violate a soft limit and you get a warning.
> > 
> > will the fopen or open in C still function ? I take it that it will
> > issue warning for each file after 256 that is being opened, so if I have
> > to opene 1200 files, that would be a LOT of warnings. More happy to
> > ulimit -f 1300 before running my program to be sure.
> 
> It doesn't "issue a warning", the attempt to open a file simply fails. 
> The difference is that the process can increase its own soft limit, up 
> to the amount in the hard limit (only a system administrator can 
> increase the hard limit).

It's been awhile since I've used setrlimit, so the details, except to remember 
'man setrlimit', become fuzzy.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web