Re: client_max_body_size bug or documentation issue again?

Sorry i went back to look at my configuration for testing. I found out  
my location block wasn't being triggered at all anyways because i was  
passing off to php fastcgi process to do the processing of the upload  
(Since i found out you cannot post to static files for testing) so it  
was using the php location block instead. So i redid all my testing  
and used a proxy_pass on location / block and from there i was not  
able to reproduce it. Sorry for wasting mail traffic on this bogus mail.

v/r
Rob Schultz
On Apr 30, 2008, at 12:02 AM, Igor Sysoev wrote:
>
>
> The client_max_body_size directive should work inside location.
> I could not reproduce the bug. Could you create debug log of your  
> case ?
>
>
> -- 
> Igor Sysoev
> http://sysoev.ru/en/
>

Too many open files

Re: Too many open files

Davy Campano <dcampano <at> ...> writes:

> 
> I'm getting a "Too many open files in system" error after running for about 10
minutes.  I'm in the process of testing out nginx and it's a pretty busy server
doing around 200 requests/sec.  My current open file limit is 131072.  Does
anyone know a safe amount to set this to for a 32-bit linux system with 6GB ram?

ulimit -n actually returns 1024, i'm thinking this should be higher

cat /proc/sys/fs/file-max   returns 131072

Document type / content type problems

Hello list,

I have a strange problem where one of my domains is experiencing
problems. The problem is that under Firefox, it gives me a prompt to
download the file rather than displaying it in the browser window. The
same domain works just fine under Safari or IE. I thought there is
some problem with the headers or something but I tried all I could and
the problem is still here:

if I do "curl -i" I get:

HTTP/1.1 200 OK
Server: nginx/0.6.30
Date: Thu, 01 May 2008 02:51:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 4082
Last-Modified: Thu, 01 May 2008 01:18:04 GMT
Connection: keep-alive
Accept-Ranges: bytes

The domain in question is icepique.com

I do not even know what info to provide as I do not know what is
relevant so if you know what I should check first, let me know and I
can provide more info.

Thanks in advance,
Kiril

Re: Document type / content type problems

http://www.icepique.com/ works for me in Firefox 3.0b5.  Did you
recently change the default content type?  If so you could try
clearing cache.

On Thu, May 1, 2008 at 10:58 AM, Kiril Angov <kupokomapa@...> wrote:
> Hello list,
>
>  I have a strange problem where one of my domains is experiencing
>  problems. The problem is that under Firefox, it gives me a prompt to
>  download the file rather than displaying it in the browser window. The
>  same domain works just fine under Safari or IE. I thought there is
>  some problem with the headers or something but I tried all I could and
>  the problem is still here:
>
>  if I do "curl -i" I get:
>
>  HTTP/1.1 200 OK
>  Server: nginx/0.6.30
>  Date: Thu, 01 May 2008 02:51:41 GMT
>  Content-Type: text/html; charset=utf-8
>  Content-Length: 4082
>  Last-Modified: Thu, 01 May 2008 01:18:04 GMT
>  Connection: keep-alive
>  Accept-Ranges: bytes
>
>  The domain in question is icepique.com
>
>  I do not even know what info to provide as I do not know what is
>  relevant so if you know what I should check first, let me know and I
>  can provide more info.
>
>  Thanks in advance,
>  Kiril
>
>

Re: Too many open files

Re: Document type / content type problems

Yes, I cleared the cache and it works on 2.x too. Strange, I did hard
refresh many times but yes I was trying to fix it so I guess something
worked :)

Sorry to bother.

Kiril

On Wed, Apr 30, 2008 at 11:10 PM, Eden Li <eden@...> wrote:
> http://www.icepique.com/ works for me in Firefox 3.0b5.  Did you
>  recently change the default content type?  If so you could try
>  clearing cache.
>
>
>
>  On Thu, May 1, 2008 at 10:58 AM, Kiril Angov <kupokomapa@...> wrote:
>  > Hello list,
>  >
>  >  I have a strange problem where one of my domains is experiencing
>  >  problems. The problem is that under Firefox, it gives me a prompt to
>  >  download the file rather than displaying it in the browser window. The
>  >  same domain works just fine under Safari or IE. I thought there is
>  >  some problem with the headers or something but I tried all I could and
>  >  the problem is still here:
>  >
>  >  if I do "curl -i" I get:
>  >
>  >  HTTP/1.1 200 OK
>  >  Server: nginx/0.6.30
>  >  Date: Thu, 01 May 2008 02:51:41 GMT
>  >  Content-Type: text/html; charset=utf-8
>  >  Content-Length: 4082
>  >  Last-Modified: Thu, 01 May 2008 01:18:04 GMT
>  >  Connection: keep-alive
>  >  Accept-Ranges: bytes
>  >
>  >  The domain in question is icepique.com
>  >
>  >  I do not even know what info to provide as I do not know what is
>  >  relevant so if you know what I should check first, let me know and I
>  >  can provide more info.
>  >
>  >  Thanks in advance,
>  >  Kiril
>  >
>  >
>
>

Re: Too many open files

Weird timeouts, not sure if I've set the right threshholds

It is proxying (basically just load balancing) to 3 upstream nginx
webservers which do FastCGI/PHP/normal static files.

I get a lot of "upstream timed out" errors and I can't determine why
exactly. Perhaps my buffers are too high, too low, timeouts are too
high, too low? I bumped up the timeouts on my proxy machine higher
than I normally would set so it wouldn't timeout as often but it still
does. All the machines are quad-core xeons with 4GB RAM, SATA2 disks,
dedicated to web/fastcgi/php, all connected via a private gigabit
VLAN... the files are hosted on NFS, but I'm not seeing any errors
related to that in logs either..

nginx PROXY:

user www-data www-data;
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
working_directory /var/run;
error_log /var/log/nginx/error.log error;
pid /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    upstream webservers {
        server web01:80;
        server web02:80;
        server web03:80;
    }
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    client_max_body_size 100m;
    client_header_buffer_size 8k;
    large_client_header_buffers 12 6k;
    keepalive_timeout 5;
    gzip on;
    gzip_static on;
    gzip_proxied any;
    gzip_min_length 1100;
    #gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_types text/plain text/html text/css application/x-javascript
text/xml application/xml application/xml+rss
    gzip_disable "MSIE [1-6]\.";
    gzip_vary on;
    server_names_hash_max_size 4096;
    server_names_hash_bucket_size 128;
    server {
        listen 80;
        access_log off;
        location / {
            proxy_pass http://mikehost;
            proxy_next_upstream error timeout http_500 http_503 invalid_header;
            proxy_max_temp_file_size 0;
            proxy_read_timeout 50;
            proxy_connect_timeout 30;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_ignore_client_abort on;
        }
    }
}

nginx WEBSERVERS:

user www-data www-data;
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
working_directory /var/run;
error_log  /var/log/nginx/error.log debug;
pid /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    set_real_ip_from 10.13.5.16;
    access_log off;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    client_max_body_size 100m;
    client_header_buffer_size 8k;
    large_client_header_buffers 12 6k;
    keepalive_timeout  5;
    server_tokens off;
    gzip off;
    gzip_static off;
    server_names_hash_max_size 4096;
    server_names_hash_bucket_size 128;

# then an example vhost block
 server {
    listen 80;
    server_name michaelshadle.com www.michaelshadle.com;
    index index.php;
    root /home/mike/web/michaelshadle.com/;
    location ~ .php {
        include /etc/nginx/fastcgi.conf;
        fastcgi_pass 127.0.0.1:11000;
        fastcgi_index index.php;
    }
    if (!-e $request_filename) {
        rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
    }
}

Any thoughts? Would turning off some buffers on the proxy make it
better, or would turning off buffering on the webservers make it
better? Not quite sure here where the best place would be to change
(if anywhere...)

Thanks..

Re: Weird timeouts, not sure if I've set the right threshholds

On Wed, Apr 30, 2008 at 09:37:09PM -0700, mike wrote:

> It is proxying (basically just load balancing) to 3 upstream nginx
> webservers which do FastCGI/PHP/normal static files.
> 
> I get a lot of "upstream timed out" errors and I can't determine why
> exactly. Perhaps my buffers are too high, too low, timeouts are too
> high, too low? I bumped up the timeouts on my proxy machine higher
> than I normally would set so it wouldn't timeout as often but it still
> does. All the machines are quad-core xeons with 4GB RAM, SATA2 disks,
> dedicated to web/fastcgi/php, all connected via a private gigabit
> VLAN... the files are hosted on NFS, but I'm not seeing any errors
> related to that in logs either..

The timeout errors have a "while ..." string that describes conditions,
when the error has happened.

> nginx PROXY:
> 
> user www-data www-data;
> worker_processes 4;
> worker_cpu_affinity 0001 0010 0100 1000;
> working_directory /var/run;
> error_log /var/log/nginx/error.log error;
> pid /var/run/nginx.pid;
> 
> events {
>     worker_connections  1024;
> }
> 
> http {
>     upstream webservers {
>         server web01:80;
>         server web02:80;
>         server web03:80;
>     }
>     include /etc/nginx/mime.types;
>     default_type application/octet-stream;
>     sendfile on;
>     tcp_nopush on;
>     tcp_nodelay on;
>     client_max_body_size 100m;
>     client_header_buffer_size 8k;
>     large_client_header_buffers 12 6k;
>     keepalive_timeout 5;
>     gzip on;
>     gzip_static on;
>     gzip_proxied any;
>     gzip_min_length 1100;
>     #gzip_http_version 1.0;
>     gzip_comp_level 2;
>     gzip_types text/plain text/html text/css application/x-javascript
> text/xml application/xml application/xml+rss
>     gzip_disable "MSIE [1-6]\.";
>     gzip_vary on;
>     server_names_hash_max_size 4096;
>     server_names_hash_bucket_size 128;
>     server {
>         listen 80;
>         access_log off;
>         location / {
>             proxy_pass http://mikehost;
>             proxy_next_upstream error timeout http_500 http_503 invalid_header;
>             proxy_max_temp_file_size 0;
>             proxy_read_timeout 50;
>             proxy_connect_timeout 30;
>             proxy_set_header Host $host;
>             proxy_set_header X-Real-IP $remote_addr;
>             proxy_ignore_client_abort on;
>         }
>     }
> }
> 
> 
> nginx WEBSERVERS:
> 
> user www-data www-data;
> worker_processes 4;
> worker_cpu_affinity 0001 0010 0100 1000;
> working_directory /var/run;
> error_log  /var/log/nginx/error.log debug;
> pid /var/run/nginx.pid;
> 
> 
> 
> events {
>     worker_connections  1024;
> }
> 
> http {
>     include       /etc/nginx/mime.types;
>     default_type  application/octet-stream;
> 
>     set_real_ip_from 10.13.5.16;
>     access_log off;
>     sendfile on;
>     tcp_nopush on;
>     tcp_nodelay on;
>     client_max_body_size 100m;
>     client_header_buffer_size 8k;
>     large_client_header_buffers 12 6k;
>     keepalive_timeout  5;
>     server_tokens off;
>     gzip off;
>     gzip_static off;
>     server_names_hash_max_size 4096;
>     server_names_hash_bucket_size 128;
> 
> # then an example vhost block
>  server {
>     listen 80;
>     server_name michaelshadle.com www.michaelshadle.com;
>     index index.php;
>     root /home/mike/web/michaelshadle.com/;
>     location ~ .php {
>         include /etc/nginx/fastcgi.conf;
>         fastcgi_pass 127.0.0.1:11000;
>         fastcgi_index index.php;
>     }
>     if (!-e $request_filename) {
>         rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
>     }

Instead of this "if" it's better to use:

      location / {
          error_page  404  = //wordpress/index.php?q=$uri;
      }

> }
> 
> 
> Any thoughts? Would turning off some buffers on the proxy make it
> better, or would turning off buffering on the webservers make it
> better? Not quite sure here where the best place would be to change
> (if anywhere...)

The timeout errors has no relation to buffers. These errors usually
means that backends are too slow.

--

-- 
Igor Sysoev
http://sysoev.ru/en/