ПРОЕКТЫ 


  АРХИВ 


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]

Too fast server?


  • To: nginx-ru@xxxxxxxxx
  • Subject: Too fast server?
  • From: "Alexey Kovyrin" <alexey@xxxxxxxxxxx>
  • Date: Thu, 19 Apr 2007 20:44:53 -0400
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=YgyKxKgt0Mod/pX+ohyVvmAWxMnp5nUnbgqG5YyQR20w0vE3oZa98BgdCnUBlwZLjLaQmCOCMwJftq5ZQrMcTtnVSJIZxtJS8jPKQK1aDvAvbsWx0GtVioO3lBb7QXSUsLgHQ+5uNTsWaorkBc/wEZBlCbb8+TuygRWKDYLAgs4=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=VjG3vM5TzXL6HXVgMgwH0KT+kexQ4lBMONVNWcAYfHFDyEx32S4JmomHQF0oh1tlApC3NVzMPWXb2cm0gB5ziTX3+R4WcNJ8R9fLK5Gmm6Sw8rq1FjRJczYCSkc2ozl/bLsIHJFp1XeOgAtRLHZYSfs9g4pKbYQr0mzqP715YR4=

Hi, all

Понимаю, что этот пост не слишком сильно связан с темой мейллиста, но,
т.к. в моем случае я наткнулся на проблему именно при использовании
нгинкса (а потом и лайти или апача), то опишу ее и здесь - может
кто-то подскажет, что делать и кто виноват.


Итак, есть сервер - 2xXeon 3.2Ghz with 4 Gb ram. На нем проект на пхп
у которого в админке есть достаточно-таки тяжелые страницы
(700кб-1,5Мб). Данный проект был перенесен на этот сервер со старой
медленной машинки где он успешно молотил свои данные больше двух лет.
После переноса и запуска проекта заметили проблему - иногда при клике
на ссылки, ведущие на те самые тяжелые страницы файрфокс предлагал
сохранить файлик на диск. При сохранении видели нужные нам данные в
перемешку с 1-2 блоками нулевых байтов.

После попыток рещить проблему обновлением софта и/или откатыванием на
старые версии (попробовали lighttpd, php 4.4, 5.0, 5.1, 5.2.0, 5.2.1
and 5.2.2RC2, apache 1.3, 2.0, 2.2, nginx 0.4.x and 0.5.x) увидели,
что проблема остается, а меняются только масштабы и частота
возникновения (мусор в выдаче присутствовал не всегда и не у всех
клиентов).

После полутора суток без сна и попыток решить проблему пришел черед
покопаться во внутренностях софта.  strace показал, что пхп отдает все
и всегда правильно. А вот выдача веб-сервера почти всегда разная. И
вот здесь наткнулись на самое главное:

1) создали файл с 1М пробелов и обозвали его  test.php.
2) скачали его 100 раз через nginx на локальную тачку - результат не
порадовал - 70 процентов файлов были больше 1М и содержали в середине
блок нулевых байтов.
3) взяли тот же пхп файл и переименовали его чтобы он отдавался как статика
4) 100 запросов - все идеально
5) запустили strace на единственного на тот момент воркера и попросили
записать лог в файл.
6) Тачка сильно прогнулась под стрейсом пишущим логи в момент когда
запустили тест, НО! - все файлы отдались без проблем (хотя и со
скоростью 500Кбайт в сек).
7) Перезапустили тест и в середине тестирования убили стрейс - почти
все оставшиеся файлы оказались побитыми.

В качестве дополнительных извращений пробовали отключение epoll,
tcp_nodelay и прочих полезных штук - это только влияло на масштабы
трагедии, но не решало проблему.

Конечным (я надеюсь, что временным) решением стал limit_rate =
128Kbytes/s. На нем в данный момент проблем не наблюдается (я пока не
нашел).

Если у кого-то есть какие-то мылси по этому поводу, можно написать
сюда или в личку или аськой (92459936) - был бы безмерно благодарен.

P.S. Debian GNU/Linux with 2.6.18-4 (Etch)

--
Alexey Kovyrin
http://kovyrin.info/


 




Copyright © Lexa Software, 1996-2009.