gmane.comp.python.wsgi.uwsgi.general

Re: Help me please with accessing cache between 2 instances

2012-05-22T14:25:49

execueseme,

Did I  ask  something  silly,  that  no  replies at all about caching
framework?

I  found  solution for myselve,  how  to  run  2  scripts in 1 uwsgi instance as
solution, but why the way described in wiki doesn't work for me?

Early socket close?

Evgeny Turnaev — 2012-05-22T12:49:05

Hello.
    I just run into issue with uwsgi 1.2.3
    When i do start_response() with status code "302 Found"
    and header [('Connection', 'close'), ('Content-Type',
'text/html'), ('Location', 'http://ru.wikipedia.org/wiki/IPad')]
    and then uwsgi.disconnect() after that nginx says 502 and spits
out to error log:

2012/05/22 16:38:12 [error] 54019#0: *132735 upstream prematurely
closed connection while reading response header from upstream, client:
81.19.90.149, server: localhost, request: "GET
/cl?rex=0317D303E1FD2880&block=serp&st=1337690100&id=title_2&rnd=0.9527389095164835&_URL=http%3A//ru.wikipedia.org/wiki/IPad&yid=1337690100161757-1049739571324732019445193-4-009-XML&ruid=0000001D4F7D452C7D2C470D00000201
HTTP/1.1", upstream: "uwsgi://unix:/var/run/uwsgi_hypernova.sock:",
host: "....ru", referrer: "http://....ru/serp?query=ipad"

Same application works ok with uwsgi 1.1.2.

Sysinfo:
FreeBSD 8.1-20100727-SNAP
Python 2.7.2
nginx/1.1.16

Re: use --limit-as opetion, i got this error:“libgcc_s.so.1 must be installed for pthread_cancel to work ”

树上 — 2012-05-22T08:09:10

got it. thank you very mach.


2012/5/19 Roberto De Ioris <roberto-5KDOxZqKugI< at >public.gmane.org>

Re: Cron eating some resources?

Łukasz Mierzwa — 2012-05-22T07:57:17

Dnia wtorek, 22 maja 2012 00:36:33 Łukasz Mierzwa pisze:

After night without --idle option I don't have any zombie processes. It 
doesn't matter if I also use --reaper, removing --idle alone is enough (at 
least for ~8 hours).
 
Łukasz Mierzwa

_______________________________________________
uWSGI mailing list
uWSGI< at >lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Re: Cron eating some resources?

Łukasz Mierzwa — 2012-05-21T22:36:33

Dnia poniedziałek, 21 maja 2012 22:14:19 Roberto De Ioris pisze:

Do I read it correctly? cheap == using --idle option and having all workers 
shut down due to no requests? If so than yes, this is testing cluster and the 
app in question did not had much requests over last week, so most of the time 
it was running with no active workers. Should I disable --idle option and 
retest?


It wouldn't help my testing cluster, but my production apps are nagios 
checked, so there is at least one request per minute and --idle can't kill all 
workers.

Łukasz Mierzwa
_______________________________________________
uWSGI mailing list
uWSGI< at >lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Re: Cron eating some resources?

Roberto De Ioris — 2012-05-21T20:14:19


Reapers are called by workers, while command-crons (the ones you define
via --cron) are generated by the master.

I have checked the code, it looks like waitpid() calls are blocked while
in cheap (no workers) mode. Could it be your situation ?

Re: Cron eating some resources?

Riccardo Magliocchetti — 2012-05-21T15:14:25

Hi Łukasz,

Il 21/05/2012 16:36, Łukasz Mierzwa ha scritto:
[snip]

man fork (double check in your distro) suggests these:

        EAGAIN fork() cannot allocate sufficient memory to copy the 
parent's page tables and allocate a task structure for the child.

        EAGAIN It was not possible to create a new process because the 
caller's RLIMIT_NPROC resource limit was encountered.  To exceed this 
limit, the process must have either
               the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.

So you are hitting some limits somewhere :)

hth,
riccardo

_______________________________________________
uWSGI mailing list
uWSGI< at >lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Re: Cron eating some resources?

Łukasz Mierzwa — 2012-05-21T14:46:50

Dnia poniedziałek, 21 maja 2012 16:36:10 Łukasz Mierzwa pisze:

I've added reaper=true to my vassal config, but calling waitpid after each 
request seems like a bit overhead, so it would be nice to get rid of zombies 
instead of hunt for them.

Łukasz Mierzwa
_______________________________________________
uWSGI mailing list
uWSGI< at >lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Cron eating some resources?

Łukasz Mierzwa — 2012-05-21T14:36:10

I've left cron running every minute for whole week and it seems that it 
managed to eat all of some resources leaving all of my apps dying all the 
time:

pthread_create(): Resource temporarily unavailable [protocol.c line 1981]
DAMN ! worker 1 (pid: 2) died :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 3)
pthread_create(): Resource temporarily unavailable [protocol.c line 1981]
DAMN ! worker 1 (pid: 3) died :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 4)
pthread_create(): Resource temporarily unavailable [protocol.c line 1981]
DAMN ! worker 1 (pid: 4) died :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 5)
pthread_create(): Resource temporarily unavailable [protocol.c line 1981]
[...]

I also noticed those messages:

fork(): Resource temporarily unavailable [master_utils.c line 507]
waitpid(): No child processes [master.c line 786]
something horrible happened...
...brutally killing workers...

pthread_create(): Resource temporarily unavailable [master.c line 411]
falling back

Re: 4xx/5xx problem with new relic + uwsgi

Cal Leeming [Simplicity Media Ltd] — 2012-05-21T00:32:13

Hey Roberto,

Any word back from Graham on this??

Cheers

Cal

On Mon, May 14, 2012 at 2:00 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming-HmH0lFivbVQrOoA2nZzjtFtyfTMRv5qX< at >public.gmane.org> wrote:

_______________________________________________
uWSGI mailing list
uWSGI-FfzAktRlpg7/cILp9QSAqw< at >public.gmane.org
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Re: https support in the http router/load-balancer

Roberto De Ioris — 2012-05-20T07:37:11


Ok, i have managed to fix all of the performance/security points
not-related to session resuming.

Current implementation greatly passes the ssl test here:

https://www.ssllabs.com/ssltest/

--https takes a fourth optional argument for specifying the ciphers suite.
For example on a libssl 0.9.8 you can avoid BEAST attack with:

--https 81.174.68.62:443,foobar.crt,foobar.key,RC4-SHA:HIGH:!ADH

Now the only piece missing is session resuming (and i mean
shared-session-resuming, as we want true horizontal scalability).

The only thing scaring me is in the huge number of file descriptors (and
ephemeral inet ports) we will need for each connection.

For a memached/redis approach we will need:

1 socket for https -> 1 socket for memcached/redis -> 1 socket for uwsgi
instance.

So, three port for connection.

We can sacrifice a bit of performance closing the connection to
memcached/redis as soon as we get the value. This is faster that not
having session cache at all.

Regarding SNI it would be amazing having the

new feature: custom options

Roberto De Ioris — 2012-05-19T09:36:46


http://projects.unbit.it/uwsgi/wiki/CustomOptions

Feel free to add your ideas/implementations (with credits if you want) to
the wiki page

Help me please with accessing cache between 2 instances

2012-05-19T07:02:38

Hi everyone.

I have 2 uwsgi instances

1. the first one is  running  at   127.0.0.1:10001  with cache = 1000 (reads/writes
cache)
2.    the second    is    running  at  127.0.0.1:10002  with  cache  =  1
(reads/deletes values only from the first instance)

when  I'am  trying  to  access  cache,  from the second instance with this
command:  uwsgi.cache_get(val, '127.0.0.1:10001')

I'am getting this error:
read(): Operation now in progress [proto/uwsgi.c line 40]
Sat May 19 06:46:40 2012 - error parsing request

do I do something totally wrong?

Re: use --limit-as opetion, i got this error:“libgcc_s.so.1 must be installed for pthread_cancel to work ”

Roberto De Ioris — 2012-05-19T05:48:12


If it is triggered by --limit-as, maybe you need more address space for
your app. Try setting it to 1000 and start decreasing til it works.

Re: 502 badgateway error help

Roberto De Ioris — 2012-05-19T05:41:36



Be Sure

uwsgi_pass unix:/home/ubuntu/DJANGO/click/click.sock;

point to the same socket you have defined with --socket in uWSGI.

Check yor nginx logs. Maybe they are reporting permission issues. Be sure
nginx has access to the unix socket. If you do not want to waste time on
permission problems simply use tcp sockets:

--socket 127.0.0.1:3031 (in uwsgi)

uwsgi_pass 127.0.0.1:3031 (in nginx)

Re: 502 badgateway error help

2012-05-18T21:45:45

You should post your webserver configuration,
hello my webserver configuration is this. many thanks




cat /etc/nginx/nginx.conf
user ubuntu;
worker_processes  2;




error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    # multi_accept on;
}

http {
    include       /etc/nginx/mime.types;

    log_format main
'$upstream_response_time$time_local$status$body_bytes_sent$http_referer$http_x_forwarded_for$http_host$reques$remote_addr$http_user_agent$upstream_addr';

    access_log/var/log/nginx/access.log main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  75 20;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";


    proxy_connect_timeout       9800;
    proxy_send_timeout          9800;
    proxy_read_timeout          9800;
    send_timeout                9800;


    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
--------------

Re: 502 badgateway error help

Roberto De Ioris — 2012-05-18T21:01:47


You should post your webserver configuration

502 badgateway error help

2012-05-18T19:13:10

hello i have this configuration
[program:lab]
command=/usr/local/bin/uwsgi
  --socket /home/ubuntu/xxx/lab/lab.sock
  --pythonpath /home/ubuntu/xxx/lab
  --master
  --processes 2
  --module juego.deploy_wsgi
  --socket-timeout 18000
  --listen 64
  --post-buffering 16384
  --disable-logging
  --max-requests 100
directory=/home/ubuntu/DJANGO/lab
user=ubuntu
master = 1
autostart=true
autorestart=true
stdout_logfile=/home/ubuntu/xxx/lab/lab.log
redirect_stderr=true
stopsignal=QUIT

but i have many 502 every time helpme i dont not understand
_______________________________________________
uWSGI mailing list
uWSGI-FfzAktRlpg7/cILp9QSAqw< at >public.gmane.org
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

use --limit-as opetion, i got this error:“libgcc_s.so.1 must be installed for pthread_cancel to work ”

树上 — 2012-05-18T07:50:26

environments:
ubuntu 12.04 server LTS
python 2.7
uwsgi 1.2.3
web.py

use --limit-as 128 start uwsgi:
$ uwsgi -x /etc/uwsgi/apps-enabled/app.xml --limit-as 128
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/shuofr.xml
*** Starting uWSGI 1.2.3 (64bit) on [Fri May 18 07:03:00 2012] ***
compiled with version: 4.6.3 on 18 May 2012 06:51:07
   ...
   ...
   ...
spawned uWSGI master process (pid: 29231)
spawned uWSGI worker 1 (pid: 29232, cores: 1)
spawned uWSGI worker 2 (pid: 29233, cores: 1)
spawned uWSGI worker 3 (pid: 29234, cores: 1)
libgcc_s.so.1 must be installed for pthread_cancel to work
<-- got error on here.
DAMN ! worker 1 (pid: 29232) died, killed by signal 6 :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 29237)
^CSIGINT/SIGQUIT received...killing workers...
goodbye to uWSGI.

 i was installed libgcc_s.so.1.
$ ldd /usr/local/bin/uwsgi
        linux-vdso.so.1 =>  (0x00007fff018ab000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f982c8f5000)
        libm.so.6 =>

Re: Pass flags to Python interpreter

Roberto De Ioris — 2012-05-17T18:18:57


--env PYTHONDONTWRITEBYTECODE=1

for -B

There is currently no way for setting -3

Re: Pass flags to Python interpreter

Craig Younkins — 2012-05-17T17:55:26

Anyone?

Craig Younkins


On Tue, May 15, 2012 at 8:22 PM, Craig Younkins <cyounkins-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

_______________________________________________
uWSGI mailing list
uWSGI-FfzAktRlpg7/cILp9QSAqw< at >public.gmane.org
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi