>However, in my experience it is unusual for a too low limit on the number
of open files to result in a segmentation fault. Especially in a well
written program like Apache HTTPD. A well written program will normally
check whether the >open (or any syscall which returns a file descriptor)
failed and refuse to use the -1 value as if it were a valid file descriptor
number. So I would be surprised if increasing that value resolved the
segmentation fault.

Kurtis: I think Darryl's issue here is with the resource intensity of
siege, not so much his LAMP stack. But generally speaking I agree, tweaking
the ulimits is a hack and should not be necessary for most mature software.
Though, I have seen posts (not necessarily here) wherein people mention
adjusting the ulimit in the Apache environment to facilitate higher
concurrency. But, personally, I wouldn't do it in a production environment.

>I have set my siege concurrency level a bit lower (20 users) and that
seems to have resolved the segfault issue. Its strange that I hadn't read
anywhere else that a lack of resources could cause that, but there it is. I
guess that running >Debian 8, Apache 2.4.10, php-fpm and Mariadb was just a
bit too much to ask of my single core 512mb VPS?

Daryl: Siege is a hobby project of one individual (at least last I
checked), and while it is a valuable tool, it needs some optimization and
is highly resource intensive. It uses a virtualization procedure to
simulate user concurrency - this is where available memory and the ulimit
issue can be a factor. In my case, I ended up spinning up a separate
virtual machine with 16GB RAM just to run siege against my development LAMP
stack. I adjusted the security limits in
/etc/sysconfig/security/limits.conf to allow for higher concurrency - to
the extent that in the end the ulimit wasn't the issue - the server ran out
of memory due to all of the virtual sessions spawned by siege.

It does sound as though you are tight on resources - though you could
certainly run your LAMP stack on that server acceptably depending on
expected traffic load. If a light load is expected, you should be ok. But
if you are running siege locally for load testing, I would definitely
recommend running it remotely from another machine if you have the
architecture available, as siege and your LAMP stack will be competing for
resources obviously if you run both locally.


Cheers,

Ryan

On Sat, Aug 22, 2015 at 9:58 AM, Daryl King <allnatives.onl...@gmail.com>
wrote:

> I have set my siege concurrency level a bit lower (20 users) and that
> seems to have resolved the segfault issue. Its strange that I hadn't read
> anywhere else that a lack of resources could cause that, but there it is. I
> guess that running Debian 8, Apache 2.4.10, php-fpm and Mariadb was just a
> bit too much to ask of my single core 512mb VPS?
> On Aug 22, 2015 1:13 PM, "Kurtis Rader" <kra...@skepticism.us> wrote:
>
>> On Fri, Aug 21, 2015 at 6:14 PM, Daryl King <allnatives.onl...@gmail.com>
>> wrote:
>>
>>> Thanks Ryan. Strangely when running "ulimit -n" it returns 65536 in a
>>> ssh session, but 1024 in webmin? Which one would be correct?
>>>
>>
>> Limits set by the ulimit command (and the setrlimit syscall) are correct
>> if they are high enough to allow a correctly functioning program to perform
>> its task. They are incorrect if set too low for the needs of a correctly
>> functioning program or so high that a malfunctioning program is able to
>> adversely affect the functioning of other processes. So the answer to your
>> question is: it depends.
>>
>> Having said that it is very unusual these days for "ulimit -n" to be set
>> too high. Supporting thousands of open files in a single process is
>> normally pretty cheap in terms of kernel memory, CPU cycles, etc. So if you
>> have a reason to think your program (e.g., httpd) has a legitimate need to
>> have more than 1024 files open simultaneously go ahead and increase the
>> "ulimit -n" (which is the setrlimit RLIMIT_NOFILE parameter) to a higher
>> value.
>>
>> However, in my experience it is unusual for a too low limit on the number
>> of open files to result in a segmentation fault. Especially in a well
>> written program like Apache HTTPD. A well written program will normally
>> check whether the open (or any syscall which returns a file descriptor)
>> failed and refuse to use the -1 value as if it were a valid file descriptor
>> number. So I would be surprised if increasing that value resolved the
>> segmentation fault.
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>

Reply via email to