File Descriptors
As far as I can see, pretty much everything is upgradeable, apart from the number of file descriptors, which is 1024.
I have had a quick look at wikipedia about file descriptors, but am none the wiser. I want to run a simple, but high volume, LAMP website that makes heavy use of caching.
Can you help me get a handle on what factors are relevant in determining in advance how many file descriptors such a site is likely to use? (My technical knowledge goes little beyond running my own server and being able to compile from tarballs).
What - in laymans terms - consumes file descriptors? If my php script uses a hige number of includes is that going to use up more descriptors than a monolithic script? If I open 100 connections to mysql at one time, does each connection use a file descriptor? If I cache html pages to disk is THAT going to increase my use of file descriptors….
Many thanks
6 Replies
One file descriptor is any file handle that is open by a process at any time. Meaning, a limit of 1024 file descriptors means that you can't have more than 1024 open files (including sockets to servers/ports) at any given time. If we also assume that a page served takes less than 1 second to process by PHP (and since PHP closes all open file handles at the end of script execution), and subtract the number of processes running, you can have a maximum of roughly 500 visitors at any given second (leaving room for several client processes of both Apache and MySQL).
Basically, if you need more than that to begin with, you really need a fully-dedicated server (considering that Wikipedia has statistically a little less than 10 requests at any given second).
As the FAQ answer says, with the number of file descriptors set to a maximum of 1024, it's set very high.
I hope this was slightly more descriptive.
As the FAQ answer says, with the number of file descriptors set
to a maximum of 1024, it's set very high.
The faq entry you reference actually states that the process limit is set very high, and that the file descriptors are limited to 1024. It does not indicate whether this latter is "high" or "moderate". Hence my original question.
Can I clarify - if my main php script includes say - 30 or so php files, does each include consume a file descriptor until script execution ends? If so, this is worth knowing as it is something I can change.
I appreciate that 500hits/minute may seem like a lot - but the particular application in question is serving xml out of mysql to a google map overlay, and thus each drag of the map requires multiple very simple "hits". A single user may thus consume 3 to 6 hits/second without breaking sweat. Given that peak hit values are always rather greater than average, that putative "500 hits/second" soon gets consumed….
Naturally, it is fairly heavily optimized - heap tables in mysql and heavy caching - so it ends up not terribly resource intensive in cpu terms. But the file descriptor limit on linode is set hard, and I don't want to run in to it, as I can't "upgrade" my way out of it.
best wishes
500hits/minute
should naturally have ben 500hits/second
regards
@NeonNero:
I assume you're referring to this FAQ item:
http://www.linode.com/products/faq.cfm?id=19
That FAQ entry is no longer true. I can't recall the exact details, but that only applied to older UML kernels / and or the kernel we used to run on the host.
The only fd limit in UML that exists now is the value you set in the kernel's settings: /proc/sys/fs/file-max. There is no limit set by Linode or UML.
-Chris
@caker:
@NeonNero:I assume you're referring to this FAQ item:
http://www.linode.com/products/faq.cfm?id=19
That FAQ entry is no longer true. I can't recall the exact details, but that only applied to older UML kernels / and or the kernel we used to run on the host.The only fd limit in UML that exists now is the value you set in the kernel's settings: /proc/sys/fs/file-max. There is no limit set by Linode or UML.
-Chris
I guess it's time to either remove or update that FAQ entry, then? (With a hint towards the /proc/sys/fs/file-max settings file, that is.)