Hello! On Tue, Nov 19, 2013 at 09:39:44AM +0200, Nikolaos Milas wrote:
[...] > The problem is that there is a repeating error of the form (I have > changed real host name and web root path, as well as client IP > address): > > 2013/11/17 12:39:14 [alert] 20709#0: *9059 pread() read only 38605 > of 39107 from "/path/to/web/root/HTML/gmap/gmapv3_auto_el.html" > while sending response to client, client: ::ffff:xxx.xxx.241.42, > server: www.example.com, request: "GET > /HTML/gmap/gmapv3_auto_el.html HTTP/1.1", host: "www.example.com" > > I found here: > > http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=_t&hl=pt-PT&ie=UTF-8&u=http%3A%2F%2Fforum.nginx.org%2Fread.php%3F21%2C9856&act=url > > ...that this is probably related to the "open_file_cache" directive, > and in fact I do use (based on advice found on the Internet): It's not "related" to the "open_file_cache" directive, but the "open_file_cache" directive makes the underlying problem more visible. The root cause of the messages in question is non-atomic file update. Somebody on your system edited the file in question in-place, instead of re-creating it with a temporary name and then using "mv" to atomically update the file. Non-atomic updates create a race: a file which is opened by nginx (and stat()'ed for nginx to know it's length) suddenly changes. This can happen in the middle of a response, and results in a corrupted response - first part of a response is from original file, and second is from updated one. If nginx is able to detect the problem due to file size mismatch - it logs the message in question. The only correct solution is to update files atomically, i.e., create a new file and then rename to a desired name. However, the "open_file_cache" directive makes the race window bigger by keeping files open for a long time. Switching it off is a good idea if you can't eliminate non-atomic updates for some reason. [...] > Should I disable open_file_cache or not? (I do not entirely > understand its implications.) > > How should we determine the directive benefits? > > Note: The aim is to be able to serve a few thousand requests per sec > at peak, while normal traffic is < 20 reqs/sec. I don't think that open_file_cache results in a measurable difference in your case. I would recommend disabling it unless you have good reasons to enable it, just to simplify maintenance. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
