MAX limit of file descriptor

[Peter Teoh]

one more:

To modify system-wide limits:

 */etc/security/limits.conf*


On Tue, Feb 12, 2013 at 5:31 PM, Peter Teoh <htmldeveloper at gmail.com> wrote:

> perhaps i can add more info, after doing more investigation:
>
> a.   "ulimit" is a shell feature, it is not a command line binary.   "man
> bash" and "man sh" and u can see ulimit has different feature available for
> u.
>
> b.   ulimit control all the resources defined by the processes spawn from
> the current shell onwards...ie, once ulimit is change, all child processes
> from that shell onwards will change.  but resources limit in another shell,
> existing processes etc does not.
>
> c.   ulimit is a userspace feature, the kernel will have all the
> corresponding feature of max open files etc...but definitely it is not
> unlimited like that of ulimit.
>
> d.   to see ALL the open files u can use "lsof" and "-p" give u control to
> point at which process to dig for open files.   it also list all the open
> connections (TCP) for u....which is what u want.
>
> e.   generally java applications will open many many files descriptor
> concurrently:
>
>
> http://www.java.net/forum/topic/glassfish/glassfish/too-many-open-files-issue
>
> (above listed 4500, and many others java apps like IBM RSA also have many).
>
> On Sat, Feb 9, 2013 at 1:10 PM, horseriver <horserivers at gmail.com> wrote:
>
>> hi:)
>>
>>    In one process ,what is the max number of opening file descriptor ?
>>    Can it be set to infinite ?
>>
>>    In network programing ,what is the essential for  the maximum of
>> connections
>>    dealed per second
>>
>> thanks!
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
>
> --
> Regards,
> Peter Teoh
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130212/536d0532/attachment-0001.html