I have a Debian 5 server, which gets a lot of traffic. Right now the server has 4 GB of RAM and no swap memory. I see in top that Apache processes consume roughly 180 MB virtual memory (VIRT) each, and 16 MB of real RAM (RES). So how many Apache threads can I have running at the same time? About 4 GB / 180 MB = 22 or 4 GB / 16 MB = 256?
The virtual memory size isn't as important as your resident set. Virtual memory is going to include things that are mapped in such as shared libraries and whatnot (which will only be resident in physical RAM once). RSS tells you what's actually in memory, where as Virt. tells you how much of the available virtual address space has been swallowed.
Your second calculation is going to be closer, though it's quite low. A server with 4GB of RAM can run far more than 256 Apache processes. Depending on your traffic patterns and IO wait limitations, running more than 256 may be a good idea as a good number of those processes may just be sitting around waiting for the kernel to shovel data from device to device. Also factor in things like COW & the fact that everything points to the same 'httpd' binary, and you get more efficiencies.
Now, go and rebuild that system of yours with a good 2GB of swap space. Swap doesn't just act as "slow memory" anymore.
As a disclaimer, It's been a long time since I've cared about the specifics of Linux memory management, and might be off a bit on my facts, but the gist is solid!
This value is mainly down to experimentation with your current server load.
try collecting some data with 'apache top'. Make some configuration changes and trying again. As i don't know you particular use case it's hard to come up with some concrete figures.
If you want predictable memory consumption for your web server please take a look at http://wiki.nginx.org/Main
It's solves some scalability problems in a very cool way.
It's not right for every use case, but certainly consider it.
You can deploy it to reduce the load on your apache instance. It's suited for serving static and cache content in a reverse proxy configuration, as well as other high load scenarios.
Give it a whirl, it's free :-)