Homo-Adminus Blog - Latest Comments in SOS!

Re: SOS!

Siava — Tue, 31 Jul 2007 04:29:53 -0000

Была похожая проблема после обновления ядра до 2.6.21.*, всё стало на свои места после возвращения на ветку 2.6.16.*

Re: SOS!

Anxious — Tue, 10 Jul 2007 17:24:38 -0000

...so? :S

Re: SOS!

Dimon — Wed, 16 May 2007 22:40:14 -0000

We have rebuilt the kernel - versions from 2.6.16.51 to 2.6.19.7 - nothing helped. Trying different NIC cards also didn't help.

Re: SOS!

ugenk — Thu, 03 May 2007 07:16:37 -0000

Возможно, проблема с sendfile в ядре?

Re: SOS!

Aleks — Sat, 21 Apr 2007 17:26:19 -0000

Any news?!

Re: SOS!

Benjamin — Fri, 20 Apr 2007 18:51:39 -0000

Can you share your nginx configuration file?

Re: SOS!

Scoundrel — Fri, 20 Apr 2007 18:19:09 -0000

2Camel: Test script was local, but errors was on local and remote clients - distance from the server does not matter.

Re: SOS!

Scoundrel — Fri, 20 Apr 2007 10:02:46 -0000

Hmmm... I've got major update - looks like there is no problem when web server is not on port 80. Just tested it with the same config but on port 8080 - everything works fine on full speeds without any problems (at lest on my 100-files-download test). Really strange :-(

Re: SOS!

Camel — Fri, 20 Apr 2007 09:28:52 -0000

Were your test scripts local or remote? I've had similar issues, check your ethernet MTU, it couldn't hurt to try lowering it to 1450.

Re: SOS!

Scoundrel — Fri, 20 Apr 2007 09:10:37 -0000

2Aleks: Thanks - I'll take a look at this tcp scaling problem.

About chatting with me - you can reach me via any IM (contacts are on resume page).

I've deleted strace/tcpdump/etc but I think I can get new dumps ;-)

Re: SOS!

Aleks — Fri, 20 Apr 2007 08:26:36 -0000

are the strace output available for download?

Re: SOS!

Aleks — Fri, 20 Apr 2007 08:19:44 -0000

Is there a irc or mail channel to talk.

Re: SOS!

Aleks — Fri, 20 Apr 2007 08:18:18 -0000

Have you some tcpdumps from client and server?!

Re: SOS!

Aleks — Fri, 20 Apr 2007 08:10:52 -0000

Hi,

could this be the reason:

http://www.debian.org/releases/stable/i386/rele...

Hth

Aleks

Re: SOS!

id — Fri, 20 Apr 2007 06:59:29 -0000

to _Andrey_:
нет, не тестировали, но такое проявляется редко на ещё одном сервере и было ещё на одном. Т.е. 3 разных сервера, на которых один и тот же баг - имо вариант проблем с памятью да и с железом в целом исключают.

Re: SOS!

_Andrey_ — Fri, 20 Apr 2007 06:10:42 -0000

Память тестировали?

Re: SOS!

DM — Fri, 20 Apr 2007 04:49:37 -0000

Итак, вот что вышло у меня:
файл размером в 1М, забит нулями, PHP работает как модуль апача. В процессе была загрузка 100% (cpu: Pentium(R) 4 CPU 1400MHz, mem: 516680 kB)
Тестил через ab -c 100 http://dm.test/test.php
Если скажете как скачать его 100 раз иначе - попробую иначе.

Server Software: Apache/2.2.3
Server Hostname: dm.test
Server Port: 80

Document Path: /test.php
Document Length: 1048576 bytes

Concurrency Level: 1
Time taken for tests: 474.532609 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 104877000 bytes
HTML transferred: 104857600 bytes
Requests per second: 0.21 [#/sec] (mean)
Time per request: 4745.326 [ms] (mean)
Time per request: 4745.326 [ms] (mean, across all concurrent requests)
Transfer rate: 215.83 [Kbytes/sec] received

Re: SOS!

dkubb — Fri, 20 Apr 2007 03:18:57 -0000

@Soundrel: I wasn't even suggesting writing a wrapper, I was more suggesting writing a "bot" that communicates with the script via the FastCGI protocol directly. You could run it directly against the app and raise any exceptions if the data comes out other than expected.

A wrapper seems like a more difficult problem to solve. A bot would simply need to simulate a FastCGI request, and log the response.

Re: SOS!

Scoundrel — Fri, 20 Apr 2007 02:10:19 -0000

2Dan Kubb: Thanks for advices. I've tried unix and tcp sockets without luck :-(

Your idea of writing some wrapper to be sure than php sends correct data is really great - will try to implement it tomorrow.

Re: SOS!

dkubb — Fri, 20 Apr 2007 01:07:46 -0000

I see no one's replied yet, so I'll throw my hat in. Not sure how much help I can be -- I'm not a PHP developer, but I have debugged PHP/FastCGI with LightTPD and Nginx before, so anything's probably better than nothing...

The weird part about this is that you tried Apache, Nginx and LightTPD and you got the same result with each. This plus the fact that strace shows PHP is sending all the requested information to the server is really weird.

Have you tried communicating with the FCGI process using a unix socket AND an internet socket? Can you eliminate the web server from the equation, and write a script that uses the FastCGI protocol to talk to the FCGI process directly?

When I hit a wall, I usually try to reduce things to the smallest number of moving parts and then try again. Close the feedback loop as tightly as possible. Eliminate the web server if you can. Try to compile PHP in FastCGI mode with no external library dependencies. Heck, even see if you can execute the script from the command-line with the ENV variables set to expected values and try duplicate the problem.