2011/11/7 Xi Chen <[email protected]>: > I have checked my uwsgi process strace again, and found too many this: > send(19, "POST /v1/alternative.cgi HTTP/1.1"..., 198, 0) = 198 > poll([{fd=19, events=POLLOUT}], 1, 1000) = 1 ([{fd=19, revents=POLLOUT}]) > send(19, "{\"visitor\": \"82d6d2b773b9eab8bdd7"..., 123, 0) = 123 > poll([{fd=19, events=POLLIN}], 1, 1000) = 1 ([{fd=19, revents=POLLIN}]) > recv(19, "H"..., 1, 0) = 1 > poll([{fd=19, events=POLLIN}], 1, 1000) = 1 ([{fd=19, revents=POLLIN}]) > recv(19, "T"..., 1, 0) = 1 > poll([{fd=19, events=POLLIN}], 1, 1000) = 1 ([{fd=19, revents=POLLIN}]) > recv(19, "T"..., 1, 0) = 1 > poll([{fd=19, events=POLLIN}], 1, 1000) = 1 ([{fd=19, revents=POLLIN}]) > recv(19, "P"..., 1, 0) = 1 > > Looks like instead of recieve entire http header, but receive only one byte > at a time. Because I call many other external webservices, this could cause > tons of recv syscalls. > Really no clue why it only recv 1 byte. I have checked sysctl and seems > pretty fine. > Any ideas?
I heard python urllib reads http headers by 1 byte. That will be a lot of recv(1) if one have a lot of connections. Don`t know if this fixed/not fixed but searching in google confirms rumors. Althrough i can`t find recv(1) in python urllib. You can confirm this doing just urllib fetching without uwsgi and stracing. > On 6 November 2011 20:36, Xi Chen <[email protected]> wrote: >> >> Hi Roberto, >> Thanks for prompt response. I attatch a strace to one of running workers. >> In error log I can't find any harakiri information, so I don't think it >> happens during the high load period. >> >> On 6 November 2011 20:12, Roberto De Ioris <[email protected]> wrote: >>> >>> > Hi, >>> > >>> > I have a django site running with nginx 0.9.4 + uwsgi the latest stable >>> > (from pip install). My uwsgi starting opts: -s /tmp/storefront.socket >>> > -M >>> > -p >>> > 16 -d logfile.log -L -i --pythonpath /pathtoproject --module wsgi -t >>> > 120 >>> > -l 2048. The problem is during the rush hour, 2 cpus are working fully >>> > loaded. Here is a screenshot of top: >>> > >>> > top - 19:36:42 up 2 days, 20:00, 2 users, load average: 15.30, 13.73, >>> > 12.68 >>> > Tasks: 128 total, 15 running, 113 sleeping, 0 stopped, 0 zombie >>> > Cpu0 : 96.3%us, 1.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.7%hi, 1.3%si, >>> > 0.0%st >>> > Cpu1 : 97.7%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 1.0%si, >>> > 0.0%st >>> > Mem: 3115396k total, 2577056k used, 538340k free, 223072k >>> > buffers >>> > Swap: 2650684k total, 1008k used, 2649676k free, 1322648k cached >>> > >>> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> > 2171 www-data 20 0 45568 33m 3528 R 13 1.1 31:36.11 storefront >>> > 2866 www-data 20 0 45352 33m 3528 R 13 1.1 43:59.80 storefront >>> > 2882 www-data 20 0 43664 31m 3528 R 13 1.0 48:42.72 storefront >>> > 2771 www-data 20 0 44028 32m 3528 R 13 1.1 38:17.32 storefront >>> > 2867 www-data 20 0 44956 33m 3528 R 13 1.1 45:46.48 storefront >>> > 2925 www-data 20 0 44084 32m 3528 R 13 1.1 53:38.30 storefront >>> > 15360 www-data 20 0 45928 33m 3528 R 13 1.1 1:21.66 storefront >>> > 2924 www-data 20 0 47164 35m 3528 S 13 1.2 52:47.82 storefront >>> > 2933 www-data 20 0 68936 56m 3528 R 13 1.9 59:50.68 storefront >>> > 13934 www-data 20 0 45776 33m 3528 R 13 1.1 10:16.16 storefront >>> > 15036 www-data 20 0 45492 33m 3524 R 13 1.1 3:27.87 storefront >>> > 15553 www-data 20 0 36288 24m 3444 R 13 0.8 0:14.26 storefront >>> > 15608 www-data 20 0 39268 27m 3508 S 13 0.9 0:06.34 storefront >>> > 2801 www-data 20 0 47144 35m 3528 R 12 1.2 39:02.26 storefront >>> > 15182 www-data 20 0 45972 34m 3524 R 12 1.1 2:47.89 storefront >>> > 6252 www-data 20 0 6628 4044 1656 R 2 0.1 6:38.68 nginx >>> > >>> > >>> >>> You have pretty "strange" values, with your CPU running as hell but >>> without I/O. Can you attach a strace to the running workers ? (strace -p >>> <pid>) >>> >>> Does harakiri happens during this high-load ? If yes, can you add >>> --harakiri-verbose to the options ? >>> >>> -- >>> Roberto De Ioris >>> http://unbit.it >>> _______________________________________________ >>> uWSGI mailing list >>> [email protected] >>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> >> >> >> -- >> Med venlig hilsen >> Xi Chen, Unisport >> --------------------------- >> Unisport A/S >> Gammel Køge Landevej 121 >> DK 2500 Valby >> Tlf. 3325 0803 >> [email protected] >> www.unisport.dk • www.dbushoppen.dk > > > > -- > Med venlig hilsen > Xi Chen, Unisport > --------------------------- > Unisport A/S > Gammel Køge Landevej 121 > DK 2500 Valby > Tlf. 3325 0803 > [email protected] > www.unisport.dk • www.dbushoppen.dk > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > > -- -------------------------------------------- Турнаев Евгений Викторович +7 906 875 09 43 -------------------------------------------- _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
