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@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru
