|
|
 | | From: | david bonde | | Subject: | ulimit | | Date: | Tue, 21 Dec 2004 23:45:28 +0100 |
|
|
 | Mac OS X verkar ha sin file descriptor limit satt till 256 vilket är lite lågt. Trodde jag skulle kunna använda ulimit för att höja detta men jag har ingen binär ulimit utan bara man ulimit (3). Något annat sätt att höja antalet 'filbeskrivare'?
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
 | | From: | Per Hedeland | | Subject: | Re: ulimit | | Date: | Wed, 22 Dec 2004 12:29:52 +0000 (UTC) |
|
|
 | I artikel skriver i97_bedREMOVETHIS@i.kth.se (david bonde): >Mac OS X verkar ha sin file descriptor limit satt till 256 vilket är >lite lågt. Trodde jag skulle kunna använda ulimit för att höja detta men >jag har ingen binär ulimit utan bara man ulimit (3). Något annat sätt >att höja antalet 'filbeskrivare'?
Pga sin natur kan ulimit (liksom cd m fl) inte implementeras som en binär, utan måste vara inbyggd i shellet, vilket den också är - om du kör ett shell som inte tillhör *csh-familjen. Motsvarande kommando i *csh heter bara 'limit' (och har annan syntax). På FreeBSD drar såväl 'man ulimit' som 'man limit' upp sidan builtin(1), som har hänvisningar till resp shell-mansida för alla inbyggda kommandon.
Det finns inget annat sätt än endera av dessa kommandon för att *från shellet* höja gränsen för alla program som shellet kör (plus för shellet självt, vilket faktiskt är det enda som [u]limit gör - gränserna ärvs av de processer som shellet sedan drar igång). Däremot kan det finnas sätt att höja dem "system wide" eller per användar-login-session (i bådadera fallen krävs förstås att man loggar in på nytt för att de ska få effekt).
T ex i FreeBSD det förra:
$ sysctl kern.maxfilesperproc kern.maxfilesperproc: 11008
och det senare (från login.conf(5)):
openfiles number Maximum number of open files per process.
--Per Hedeland per@hedeland.org
|
|
 | | From: | david bonde | | Subject: | Re: ulimit | | Date: | Wed, 22 Dec 2004 15:23:00 +0100 |
|
|
 | Per Hedeland wrote:
> Pga sin natur kan ulimit (liksom cd m fl) inte implementeras som en > binär, utan måste vara inbyggd i shellet, vilket den också är - om du > kör ett shell som inte tillhör *csh-familjen. Motsvarande kommando i > *csh heter bara 'limit' (och har annan syntax). På FreeBSD drar såväl > 'man ulimit' som 'man limit' upp sidan builtin(1), som har hänvisningar > till resp shell-mansida för alla inbyggda kommandon. > > Det finns inget annat sätt än endera av dessa kommandon för att *från > shellet* höja gränsen för alla program som shellet kör (plus för shellet > självt, vilket faktiskt är det enda som [u]limit gör - gränserna ärvs av > de processer som shellet sedan drar igång). Däremot kan det finnas sätt > att höja dem "system wide" eller per användar-login-session (i bådadera > fallen krävs förstås att man loggar in på nytt för att de ska få effekt). > > T ex i FreeBSD det förra: > > $ sysctl kern.maxfilesperproc > kern.maxfilesperproc: 11008 > > och det senare (från login.conf(5)): > > openfiles number Maximum number of open files per > process.
Tack!
Jag drar slutsatsen att detta innebär att om programmet som krånglar startas från kommandoraden 'som vanligt' så räcker det att ändra antalet file descriptors temporärt i det skalet? (till skillnad från om det autostartades tex under systemstart då man skulle behöva höja det systemwide på det sätt du beskrev för FreeBSD).
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
 | | From: | Per Hedeland | | Subject: | Re: ulimit | | Date: | Wed, 22 Dec 2004 16:57:08 +0000 (UTC) |
|
|
 | I artikel skriver i97_bedREMOVETHIS@i.kth.se (david bonde): >Per Hedeland wrote: > >> Pga sin natur kan ulimit (liksom cd m fl) inte implementeras som en >> binär, utan måste vara inbyggd i shellet, vilket den också är - om du >> kör ett shell som inte tillhör *csh-familjen. Motsvarande kommando i >> *csh heter bara 'limit' (och har annan syntax). På FreeBSD drar såväl >> 'man ulimit' som 'man limit' upp sidan builtin(1), som har hänvisningar >> till resp shell-mansida för alla inbyggda kommandon. >> >> Det finns inget annat sätt än endera av dessa kommandon för att *från >> shellet* höja gränsen för alla program som shellet kör (plus för shellet >> självt, vilket faktiskt är det enda som [u]limit gör - gränserna ärvs av >> de processer som shellet sedan drar igång). Däremot kan det finnas sätt >> att höja dem "system wide" eller per användar-login-session (i bådadera >> fallen krävs förstås att man loggar in på nytt för att de ska få effekt). >> >> T ex i FreeBSD det förra: >> >> $ sysctl kern.maxfilesperproc >> kern.maxfilesperproc: 11008 >> >> och det senare (från login.conf(5)): >> >> openfiles number Maximum number of open files per
>Jag drar slutsatsen att detta innebär att om programmet som krånglar >startas från kommandoraden 'som vanligt' så räcker det att ändra antalet >file descriptors temporärt i det skalet? (till skillnad från om det >autostartades tex under systemstart då man skulle behöva höja det >systemwide på det sätt du beskrev för FreeBSD).
Ja. (Men om du ändrar t ex systemwide så slipper du förstås ändra temporärt i shellet - efter nyinloggning.) Tilläggas ska väl också att det finns hårda och mjuka limits - utan att vara root kan man inte höja över de hårda (från shellet alltså - systemwide/login-session är det ju root som sätter).
--Per Hedeland per@hedeland.org
|
|
 | | From: | Måns Nilsson | | Subject: | Re: ulimit | | Date: | 23 Dec 2004 12:02:16 GMT |
|
|
 | Thus spoke Per Hedeland: > I artikel > skriver i97_bedREMOVETHIS@i.kth.se (david bonde): >>Mac OS X verkar ha sin file descriptor limit satt till 256 vilket är >>lite lågt. Trodde jag skulle kunna använda ulimit för att höja detta men >>jag har ingen binär ulimit utan bara man ulimit (3). Något annat sätt >>att höja antalet 'filbeskrivare'? > > Pga sin natur kan ulimit (liksom cd m fl) inte implementeras som en > binär, utan måste vara inbyggd i shellet, vilket den också är - om du > kör ett shell som inte tillhör *csh-familjen. Motsvarande kommando i > *csh heter bara 'limit' (och har annan syntax). På FreeBSD drar såväl > 'man ulimit' som 'man limit' upp sidan builtin(1), som har hänvisningar > till resp shell-mansida för alla inbyggda kommandon.
Per har så klart rätt. (som vanligt...)
rasmus:/tmp mansaxel$ uname -a Darwin rasmus.kthnoc.net 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc rasmus:/tmp mansaxel$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 6144 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) 14336 rasmus:/tmp mansaxel$ id uid=501(mansaxel) gid=501(mansaxel) groups=501(mansaxel), 79(appserverusr), 80(admin), 81(appserveradm) rasmus:/tmp mansaxel$ ulimit -n 2048 rasmus:/tmp mansaxel$ ulimit -a | grep ^open open files (-n) 2048
Det verkar gå att bara skruva upp det. Jag testade som min gäst- användare också, och även hon kan skruva upp som hon vill.
-- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
|
|
 | | From: | Per Hedeland | | Subject: | Re: ulimit | | Date: | Thu, 23 Dec 2004 12:31:05 +0000 (UTC) |
|
|
 | I artikel skriver =?iso-8859-1?Q?M=E5ns?= Nilsson : > >rasmus:/tmp mansaxel$ uname -a >Darwin rasmus.kthnoc.net 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 >16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power >Macintosh powerpc >rasmus:/tmp mansaxel$ ulimit -a >core file size (blocks, -c) 0 >data seg size (kbytes, -d) 6144 >file size (blocks, -f) unlimited >max locked memory (kbytes, -l) unlimited >max memory size (kbytes, -m) unlimited >open files (-n) 1024 >pipe size (512 bytes, -p) 1 >stack size (kbytes, -s) 8192 >cpu time (seconds, -t) unlimited >max user processes (-u) 100 >virtual memory (kbytes, -v) 14336 >rasmus:/tmp mansaxel$ id >uid=501(mansaxel) gid=501(mansaxel) groups=501(mansaxel), >79(appserverusr), 80(admin), 81(appserveradm) >rasmus:/tmp mansaxel$ ulimit -n 2048 >rasmus:/tmp mansaxel$ ulimit -a | grep ^open >open files (-n) 2048 > >Det verkar gå att bara skruva upp det. Jag testade som min gäst- >användare också, och även hon kan skruva upp som hon vill.
'ulimit -Hn' ska ge den hårda gränsen (som förstås teoretiskt kan vara "unlimited"). På min FreeBSD verkar mjuka gränsen alltid vara satt till hårda (kan iofs bero på mitt loginshell, som är tcsh:-):
$ uname -a FreeBSD pluto.hedeland.org 5.3-RELEASE FreeBSD 5.3-RELEASE #3: Mon Dec 13 09:51:17 CET 2004 per@pluto.hedeland.org:/usr/src/sys/i386/compile/PLUTO i386 $ ulimit -n 11008 $ ulimit -Hn 11008 $ ulimit -n 11007 $ ulimit -n 11009 ulimit: bad limit: Operation not permitted
--Per Hedeland per@hedeland.org
|
|
 | | From: | Måns Nilsson | | Subject: | Re: ulimit | | Date: | 24 Dec 2004 03:40:55 GMT |
|
|
 | Thus spoke Per Hedeland: >>Det verkar gå att bara skruva upp det. Jag testade som min gäst- >>användare också, och även hon kan skruva upp som hon vill. > > 'ulimit -Hn' ska ge den hårda gränsen (som förstås teoretiskt kan vara > "unlimited"). På min FreeBSD verkar mjuka gränsen alltid vara satt till > hårda (kan iofs bero på mitt loginshell, som är tcsh:-):
Ok, mer tester på OSX:
En användare i Admin-klassen har som root, dvs "Unlimited", medan en luser har 1024, med ursprungsvärde satt till 256. Admins har också 256 som ur- sprungsvärde. Alla får bash som skal. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
|
|
 | | From: | david bonde | | Subject: | Re: ulimit | | Date: | Sun, 26 Dec 2004 22:14:37 +0100 |
|
|
 | Måns Nilsson wrote:
> Ok, mer tester på OSX: > > En användare i Admin-klassen har som root, dvs "Unlimited", medan en luser > har 1024, med ursprungsvärde satt till 256. Admins har också 256 som ur- > sprungsvärde. Alla får bash som skal.
Hur kom du fram till detta? Testade både med bash och tcsh och med vanlig användare och admin-användare och i samtliga fall rapporterade ulimit -n resp limit 1024 file descriptors.
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
 | | From: | Måns Nilsson | | Subject: | Re: ulimit | | Date: | 26 Dec 2004 22:02:06 GMT |
|
|
 | Thus spoke david bonde:
>> En användare i Admin-klassen har som root, dvs "Unlimited", medan en luser >> har 1024, med ursprungsvärde satt till 256. Admins har också 256 som ur- >> sprungsvärde. Alla får bash som skal. > > Hur kom du fram till detta? Testade både med bash och tcsh och med > vanlig användare och admin-användare och i samtliga fall rapporterade > ulimit -n resp limit 1024 file descriptors.
Hmm, nu testade jag om här, och det verkar som om jag kan sätta upp gränsen en gång till 10240 som max; även om jag sätter högre så trunkeras det tyst. jag kan ha gjort någon manöver som lät mig lyfta gränsen högre.
-- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
|
|
|