ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: В логах pread() failed



Hello!

On Wed, Mar 10, 2010 at 08:13:15AM +0200, Elifan wrote:

> Здравствуйте, Maxim.
> 
> Вы писали 10 марта 2010 г., 2:44:00:
> 
> > Hello!
> 
> > On Wed, Mar 10, 2010 at 12:05:49AM +0200, Elifan wrote:
> 
> >> Здравствуйте, Igor.
> >> 
> >> Вы писали 26 февраля 2009 г., 13:07:40:
> >> 
> >> > > Из странного, после обновления еще появилось:
> >> > > 
> >> > > 2009/02/26 13:11:31 [alert] 8690#0: *1999469 pread() read only 2361 of 
> >> > > 2787 
> >> > > from "/home/multiki/mult_raid/screen/mini/karusel_8.jpg" while sending 
> >> > > response to client, client: 92.100.96.143, server: mults.spb.ru, 
> >> > > request: 
> >> > > "GET /screen/mini/karusel_8.jpg HTTP/1.1", host: "mults.spb.ru", 
> >> > > referrer: 
> >> > > "http://mults.spb.ru/rss.php";;
> 
> > [...]
> 
> >> Подниму старую тему. Та же проблема, на маленьких файлах .js
> >> nginx/0.7.65
> >> 7.2-RELEASE FreeBSD
> >> ufs, gmirror
> >> 
> >> directio вообще не описан в конфиге, только
> >>     sendfile         off;
> >> 
> >> из кеширования есть еще:
> >>     open_file_cache          max=10000  inactive=200s;
> >>     open_file_cache_valid    2s;
> >>     open_file_cache_min_uses 2;
> >>     open_file_cache_errors   off;
> >> 
> >> open_file_cache_valid  раньше  был  300  секунд,  сейчас  занизил.  не
> >> помогает.  ошибки  о несоответствии ожидаемого и фактического размеров
> >> не уходят.
> 
> > Такое может быть, если файлы переписываются по месту.
> 
> Есть такое, по крону раз в 10 часов, но может быть форсировано вручную, через 
> веб, файл  изменяется
> php скриптом fopen('', "w")

Не делайте так (c)

Вообще странно что ещё кто-то так делает.  Апач в подобных 
ситуациях при некоторой доле везения начинал есть 100% CPU, должно 
было всех отучить надолго.  Забывается история... ;)

> > Сейчас open_file_cache проверяет inode number.  При редактировании
> > файла по месту - он не меняется, и кеш считает файл неизменившимся 
> > со всеми вытекающими последствиями.  Можно пытаться проверять ещё 
> > и размер/mtime, но это в общем-то мёртвому припарки - лишь снижает 
> > вероятность проблемы, но не устраняет её (т.е. если вы поменяете 
> > файл в момент между проверкой размера и собственно отдачей клиенту 
> > - опять же будет ошибка).  
> 
> А как же open_file_cache_valid    2s ?
> Даже  если  в  течении  этих  2х  секунд  и  был старый inode number и
> следовательно  старый  размер  файла,  то  почему  ошибка остается и в
> дальнейшем, пока не graceful ну и restart само собой?

Потому что 2 секунды - это вообще ничего не проверять.  Через 2 
секунды будет сделан stat(), nginx убедится что inode number не 
поменялся - и с чистой совестью продолжит возвращать старые 
данные.

На самом деле под FreeBSD всё немного не так (ибо вместо 
периодического stat()'а используется kevent(EVFILT_VNODE)), но часто 
запрашиваемый файл который пишут по месту поймается точно так же.

Наверное надо всё-таки сделать обновление закешированных данных 
stat() при проверке.  И скажем ругаться громко если они 
изменились, чтобы неповадно было...

> Даже через inactive=200s ничего хорошего не случается..

Для того чтобы сработал inactive=200s - нужно чтобы 200 секунд 
файл никто не спрашивал.  Я так понимаю это маловероятный 
сценарий.

> > Правильно - менять файлы атомарно.  Т.е. писать рядом новый файл, 
> > а потом делать mv(1) или rename(2).

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.