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

[Maxim Dounin]

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