abe interesno mi e kakvo shte stane , ako promenia max broi
 na procesite koito mogat da se pusnat, iasno e che sistemata
 shte si raboti pak , no dali shte ima syshtata
 proizvoditelnost? i kakva e optimalnata im broika , pri
 koiato ordinatoryt na procesite si "vyrshi rabotata" nai -
dobre :) ?
merci na otgovorilite

 Пи принцип, броят на процесите не се задава глобално, а само
 за определени потребители или членова на дадена група. Не си
 и помисляй да ограничаваш броя на процесите за цялата
система. Просто ще се счупи и няма да работи. Затова има групи и 
потребителите се органазират по групи.

 За работа в Х оптимално е да зададеш 100-150 процеса на
 юзер. Ако ще работят само в конзола примерно през SSH -
 10-15 процеса ще са им напълно достатъчни. Всичко зависи от
това какво смяташ да им разрешиш да правят.

 drasti. dobyr vypros. sistemata ti (nai veroiatno) niama da
 raboti po-dobre ili po-losho ako uvelichish ili namalish
 broia na user procesite. niama i magichesko chislo, koeto da
 e podhodiashto za vseki host. vsichko e subektivno i opira
 do precenkata na dadenia sysadmin ;] sega, za max
procesite:

# ulimit -a

kazva

max user processes            (-u) 4091

ako gi setnesh na unlimited -

# ulimit -u unlimited

max user processes            (-u) unlimited

 t.e. ne pokazva kolko sa tochno. mojesh da opitash da
proverish obache s getrlimit() kakvo si misli linuxa ti:

#include 
#include 
#include 
#include 

int main(void)
{
        struct rlimit rlimit_cur;

        getrlimit(RLIMIT_NPROC, &rlimit_cur);
         printf("cur: %lu max: %lu\n", rlimit_cur.rlim_cur,
rlimit_cur.rlim_max);
        return(0);
}

# ./sgetrlimit
cur: 4294967295 max: 4294967295
# uname -a
 Linux thinkpad 2.6.0-test7-bk4 #2 SMP Mon Oct 13 11:18:29
EEST 2003 i686 i686 i386 GNU/Linux
 
 ne mislia obache, che tova e optimalnia broi. dobre shte e
niakoi da se porazrovi iz lkml.

 Така е, ако ползваш ulimit, но това е куца работа. Има си
 /etc/security/limits.conf, където нещата са далеч по-удобни
и функционални, защото ulimit може да се заобикаля.

 Слагането на лимит на потребителските процеси е задължително
 за многопотребителска среда. Иначе става весело, ако някой
се изгаври и пусне fork bomb;)

nikola, ne si prav. 

 faktyt, che za teb e po-lesno da rabotish s limits.conf, v
 nikakva stepen ne go pravi po-udoben ili po-fukncionalen, a
 bash ili ksh (procheti za ulimit) kuci :-) oshte poveche che
 pri mnogo distribuci (da ne govorim za drugi operacionni
 sistemi) takyv file dori ne se izpolzva (ot pam modulite).
 ne znam kakvo imash v predvid pod "zaobikaliane na ulimit".
 ako prochetesh oshte, shte razberesh che metodyt na rabota
 na ulimit i limits.conf (pam_limits.so) se svejda do
 manipulirane na niakolko system call-a, a po-tochno -
 getrlimit(75) i setrlimit(76). kakto znaem, obiknovenite
 potrebiteli ne mogat da kontrolirat tiahnoto povedenie.
 otnosno fork bombite i drugi detski igrachki - mnogo trudno
 mojesh da "schupish" niakoi linux s iadra sled 2.3, poradi
 nachina na rabota na memory managera/vm; out of memory
 killer, enhanced sched, preemption i t.n., no za tam 
 triabva dori poveche chetene :-) inache, da, syglasen sym
 che edna multi-user systema (v smisyla, koito vlagash ti)
 triabva da se dyrji po izkyso. zatova kazah che e
subektivno, no veche se otdalechih dostatychno ot vyporsa.

vsichko hubavo

s.

 Като казах куца, не исках да обиждам никого, още по-малко
 ulimit;) Куца е от гледна точка на функционалността. Ако си
 мислиш, че е трудно да се счупи система, в която нямаш
 сетнати ограничения на процесите в limits.conf или не си се
 бъзикал с ulimit, грешиш. Няма нищо по-лесно от това. Няма
 значение версията на ядрото, повярвай ми. Ако не ми вярваш,
дай ми име и парола;) Дистрибуцията е без значение.

 Или направо опитай някой от тези примери -
http://linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=352271146

P.S. Можеш да се поинтересуваш какво правят провайдърите на
безплатни шел-акаунти. Или да си регистрираш такъв в sf.net и
да се логнеш през shell.sourceforge.net. Освен, че ползват ядро с
grsecurity, хората са се постарали доста да пипнат в limits.conf. 
Друг начин просто няма;)

 ehh :-) zashto niama poveche takiva diskusii tuk. vijdam che
 si skaran s ulimit i v tova niama nishto losho. ako neshto v
 nego ne ti haresva obache, vinagi mojesh da si napishesh
 progie kato tova gore na 10 reda i da si reshish problema,
 osobeno kato niama pam na sistemata (ili ne ti se
instalira). tozi vypros go schitam za prikluchen.

 no ne sym syglasen s ostanalata chast ot posta ti; pohvalno
 e che rovish i pishesh po temata iz linux-bg; kakto spomenah
 obache, s nai-dobri chuvstva te syvetvam da poprochetesh v/u
 kernel preemption, latency, oom, che dori i za novia 0/1
 scheduluer, za da ne tvyrdish takiva neshta. ima dostatychno
 statii po vyprosa (phrack, phreedom magazine, lj i drugi
resursi).

 za syjalenie sym zad niakolko nat-a, bez realen adres, taka
 che ne moga da ti osiguria dostyp do men. mashinata koiato
 poizmychih e notebooka mi, koito e sravnitelno byrzo jeliazo
(ili titan, whatever...:-)

 eto primer za shto-gode snosen fork bomb, s koito
experimentirah:

 main() { int *root; while(1) { root=(int *)malloc(10000);
fork(); } }

 v/u linux s 2.6.0-test7-bk4 iadro. do kolkoto pomnia,
 preemptible hacka na robert love e mergenat v 2.4 source
 tree sled .19, ta mojesh i da go razgledash. predvaritelno
 mahnah vsiakakvi restrikcii otkym broi na user procesi. sled
 kato pusnah fork-a, go podyrjah okolo 15tina minuti, pri
 koeto mashinata se pozabavi, no beshe napylno responsive
 prez cialoto vreme. nakraia oom killera zapochna da ubiva
niakoi procesi i go spriah. loada beshe dosta visok

 23:18:41  up 21:19,  20 users,  load average: 804.83,
906.33, 407.26

 no systemata ne si i pomisli da se "chupi" nito za mig.
po-nagledno ot tova ne bih mogyl da go predstavia :-)

 a, i m/u drugoto limits.conf, ulimit, grsec i t.n. dalech ne
 sa edinstvenite opcii da predotvratish eventualna fork
 ataka. mojesh da spresh niakoi linux capabilities ot kernela
 si, koeto e dosta grubo (lcap,
 http://www.phreedom.org/article.php?id=35), a syshto taka i
da polzvash lkm, koito sledi za podobni sybitia.

 Така е, начини много. Не съм скаран с ulimit, просто не го
 ползвам;) С pam_limit, както сам знаеш, можеш да зададеш
 доста детайлни настройки не само над броя на процесите или
размера на стековете и т.н. Сигурно има и други решения, но
досега не съм видял по-удобно средство за контрол над
системните ресурси по потребители и групи. 

 Тествахме първата форкбомба от материала на ядро 2.4.21 с
 grsecurity и без допълнителни настройки - счупи се,
 по-трудно отколкото без пачовете, но след минута системата
 заби безотказно. Ако машинта е по-мощна, просто оставяш
 програмката да я претовари, т.е. изисква се повече време. С
 2.6 не съм пробвал, то излезе по-късно и не съм си играл
 вече. С ограничавеното на броя на процесите и броя на
 едновременните логвания примерно до 4, при пускане на
 програмата процесорът започна да се товари, вече не помня
 показателите, но при достигане на лимита ядрото започна да
реже програмата и толкова. 

 Това е, при повечето линукс-дистрибуции имаш pam_limits и не
виждам защо да не се използва. Нали и за това? ;)

Поздрави!