nginx-0.8.9

Jim Ohlstein jim at ohlste.in
Thu Aug 20 09:34:23 MSD 2009 

Igor Sysoev wrote:
> On Wed, Aug 19, 2009 at 12:48:12AM -0400, Jim Ohlstein wrote:
>
>   
>> Igor Sysoev wrote:
>>     
>>> Changes with nginx 0.8.9                                         17 Aug 
>>> 2009
>>>
>>>    *) Feature: now the start cache loader runs in a separate process; 
>>>    this should improve large caches handling.
>>>  
>>>       
>> Can you briefly explain the function of cache manager and cache loader 
>> processes?
>>     
>
> Cache loader starts to work 60s later after nginx starts or was reconfigured.
> It may run for long time on large cache: even hours. After all caches
> will be loaded the cache loader exits. When nginx was reconfigured then
> new cache loader tests if a cache already has been loading. If so, then 
> the new loader goes to the next cache. So for large caches you may see
> two or more cache loader processes while reconifurations.
>
> Cache manager starts to work just after nginx starts or was reconfigured.
> It deletes inactive cache entries and checks caches size.
>
> Before 0.8.9 there was only cache manager process that at first loaded
> cache and then started to manage it. For large caches the caches were
> not managed before they will be completely loaded. Besides, if nginx
> was reconcifgured while it was loading caches, then a new cache manager
> started to load them from the very start: you will see two cache manager
> processes do the same thing.
>
>   
>>>    *) Feature: now temporarily files and permanent storage area may 
>>>    reside at different file systems.
>>>       
>> In the past files were moved from temporary system to cache with hard 
>> links if I am not mistaken. Does this mean that each file will now be 
>> written separately? Won't that have a negative impact on disk I/O on a 
>> busy system?
>>     
>
> Now they are just renamed(2)ed too. However, if rename() fails with EXDEV
> error, then nginx copies temporary file to permanent_name.random_number
> and then rename(2)s the permanent_name.random_number to just permanent_name.
>
> I see two usages of different temporary and permanent storage:
>
> 1) permanent storage has serveral mount points to different disks.
> 2) permanent storage is SSD.
>
>
>   
OK, I tried using this with an SSD (mounted as /falcon).

fastcgi_temp_path normally defaults to /usr/local/nginx/fastcgi_temp/

Relevant portion of nginx.conf:

http {
    ...
    fastcgi_cache_path /falcon/cache levels=1:2:2 keys_zone=one:512m 
inactive=1d max_size=40g;
    ...
}

Site config files are unchanged from 0.8.8 and include standard 
fastcgi_pass and cache statements. All was working well with temp files 
and cache were on same file system.

Relevant portion looked like this:

location ~ (6n7067|706r67|69636s|676966|637373|2r6n73|706567)$ {
    fastcgi_pass unix:/tmp/cgi.sock;
    fastcgi_cache one;
    fastcgi_cache_key $request_uri;
    fastcgi_ignore_headers  Cache-Control  Expires;
    fastcgi_cache_valid 200 302 3d;
    fastcgi_cache_valid 301 7d;
    fastcgi_cache_valid any 1d;
    include /usr/local/nginx/conf/fastcgi_params;
    fastcgi_buffers 16 4k;
    access_log  logs/cache.log  cachestatus;
    access_log  logs/mydomain.access.log combined;
}

(Just ignore the locations above and the URI's below - they are encoded 
by the app).
   
I had upgraded to 0.8.9 and get the following errors:

[jim at saturn falcon]# tail -5 /usr/local/nginx/logs/error.log
2009/08/20 00:50:03 [crit] 13576#0: *112534 rename() 
"/usr/local/nginx/fastcgi_temp/2/76/0000011762" to 
"/falcon/cache/b/0e/89/448e7f2e2aec3cbe4cf3387ffcb890eb" failed (18: 
Invalid cross-device link) while reading upstream, client: 
201.144.221.245, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s62612q6o2r636s6q2s696q616765732s66756r2s73746174757369636s6r2s757365725s6s66666p696r652r676966 
HTTP/1.1", upstream: "fastcgi://unix:/tmp/cgi.sock:", host: 
"mydomain.com", referrer: 
"https://mydomain.com/rtwhtrsyrn/010110A/687474702s62612q6o2r636s6q2s73686s777468726561642r7068703s733q656664353531386561326539666632653164356533366539646238386665393526703q37323331313838"

2009/08/20 00:50:03 [crit] 13579#0: *112762 rename() 
"/usr/local/nginx/fastcgi_temp/2/85/0000258852" to 
"/falcon/cache/f/42/46/36b478d7a11a84c5aa21bcc7bea4642f" failed (18: 
Invalid cross-device link) while reading upstream, client: 
201.144.221.245, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s62612q6o2r636s6q2s696q616765732s66756r2s6q6973632s71756s74696r672r676966 
HTTP/1.1", upstream: "fastcgi://unix:/tmp/cgi.sock:", host: 
"mydomain.com", referrer: 
"https://mydomain.com/rtwhtrsyrn/010110A/687474702s62612q6o2r636s6q2s73686s777468726561642r7068703s733q316166393439656134376332633861363735643265353361393762353265626126743q353831373638"

2009/08/20 00:50:12 [crit] 13576#0: *113033 rename() 
"/usr/local/nginx/fastcgi_temp/3/76/0000011763" to 
"/falcon/cache/2/54/d9/e163c8bccb1f60ea1fc6c612063d9542" failed (18: 
Invalid cross-device link) while reading upstream, client: 
201.144.221.245, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s6p636s6r74656r742r6562756464792r636s6q2s6p6974652s312r322r372s6q6s622s6r6574776s726o732s6q736r2r676966 
HTTP/1.1", upstream: "fastcgi://unix:/tmp/cgi.sock:", host: 
"mydomain.com", referrer: 
"https://mydomain.com/rtwhtrsyrn/010110A/687474702s61627564686162692r6562756464792r636s6q2s6q756p74692s6q6s622s636s6r74616374732r766q3o6n73657373696s6r69643q32364538364332443333344239453739424639344539353942413734463441363s743q3132353037343337343636353726706167653q33"

2009/08/20 00:50:31 [crit] 13580#0: *112239 rename() 
"/usr/local/nginx/fastcgi_temp/1/80/0000009801" to 
"/falcon/cache/a/97/de/10ea9d6c633e291c5fa2d061e0cde97a" failed (18: 
Invalid cross-device link) while reading upstream, client: 
201.144.221.245, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s766964656s732q6772617469732r70657461726461732r636s6q2s702s31313633303561343266633632323761313136313463623030353665333635392s67616p7065742s67616p65726961732s333231342s7468756q62695s312r6n7067 
HTTP/1.1", upstream: "fastcgi://unix:/tmp/cgi.sock:", host: 
"mydomain.com", referrer: 
"https://mydomain.com/rtwhtrsyrn/010110A/687474702s67616p65726961732r70657461726461732r636s6q2s766q2s333231342s3230"

2009/08/20 00:50:42 [crit] 13580#0: *112240 rename() 
"/usr/local/nginx/fastcgi_temp/2/80/0000009802" to 
"/falcon/cache/f/f4/5a/7096031122aaf7e38913bec80d55af4f" failed (18: 
Invalid cross-device link) while reading upstream, client: 
201.144.221.245, server: mydomain.com, request: "GET 
/rtwhtrsyrn/010110A/687474702s766964656s732q6772617469732r70657461726461732r636s6q2s702s31313633303561343266633632323761313136313463623030353665333635392s67616p7065742s67616p65726961732s333231342s7468756q62695s382r6n7067 
HTTP/1.1", upstream: "fastcgi://unix:/tmp/cgi.sock:", host: 
"mydomain.com", referrer: 
"https://mydomain.com/rtwhtrsyrn/010110A/687474702s67616p65726961732r70657461726461732r636s6q2s766q2s333231342s3230"

[jim at saturn falcon]#   nginx -V
nginx version: nginx/0.8.9
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-44)
configure arguments: --pid-path=/usr/local/nginx/logs/nginx.pid 
--sbin-path=/usr/local/sbin/nginx --with-http_ssl_module 
--with-http_stub_status_module --with-http_geoip_module 
--with-http_realip_module --user=nginx --group=nginx
[jim at saturn falcon]#

No files are written to the cache but directories are created. If I add 
the following line to proper location blocks within the site config 
files which reference the cache:

    fastcgi_temp_path /falcon/fastcgi_temp;

the the errors all go away and files are written to the cache.

I'm not anxious to have temporary files being constantly written to the 
SSD as writes are still relatively slow and the lifespan of the devices, 
which are still fairly expensive, are affected by the number of writes 
if I understand correctly.

What am I doing wrong?

Jim

More information about the nginx mailing list