thanks a bunch. now i understand everything. good nginx lesson today :)

right now i get around 12G memory free, so i might see how it performs
in the future and adjust.

i have worker_connections 8192;

because there are large traffic spikes, and i need to prevent them
server from working slow.





Maxim Dounin wrote:
> Hello!
>
> On Sat, Nov 21, 2009 at 07:48:07PM +0100, Stefanita Rares Dumitrescu wrote:
>
>> fastcgi_buffers 64 64k;
>> fastcgi_buffer_size 64k;
>>
>>
>> i made the following mods in the fastcgi section, and waiting for
>> results. from what i understand:
>>
>> fastcgi_buffers 64 64k;
>>
>> the first 64 is the number of buffers and the second is the buffer
>> size,
>
> Yes. Note well - this numbers specify maximum number of buffers
> allocated *per request*.
>
>> so on a server that takes around 500 hits per second should i
>> increase it, or the value should be just fine ?
>
> Request rate isn't relevant here. It's the number of concurent
> requests that is relevant, including maximum allowed one.
>
> With 64 64k buffers it is possible for request to eat up to 4M of
> memory. With default settings (worker_connections 1024;
> worker_processes 1) this gives up to 4G (4M * 1 * 1024).
> Shouldn't be the problem for server with 16G of memory.
>
> If you have more worker processes and/or more worker connections
> allowed you may consider lowering this value a bit to make sure
> your server can't be DoS'ed by eating all memory for buffers and
> forcing swap activity.
>
> Maxim Dounin
>
>
>>
>> Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Sat, Nov 21, 2009 at 02:19:16PM +0100, Stefanita Rares Dumitrescu wrote:
>>>
>>>> fastcgi_max_temp_file_size 0;
>>>> This directive turns off fastcgi buffering according to the source code.
>>>>
>>>> i did this, and the buffer errors are gone. however, the pages load
>>>> very very slow. take about 5-10 seconds to load the page.
>>> As I already said, switching off disk buffering has it's cost.
>>> Without buffering backend processes will be busy for much longer
>>> time. There is no surprise that the same number of backend
>>> processes is no longer enough.
>>>
>>> Maxim Dounin
>>>
>