Home / user-133787

Barmi's questions

Martin Hope
Barmi
Asked: 2017-12-31 19:20:34 +0800 CST
  • 2

Installing a single table-dump is significant slower on U16.04 (and higher) than on U14.04. The test was done on the same computer with default settings.

testdb=# \d photos_searchlog
                                      Table "public.photos_searchlog"
  Column  |           Type           | Collation | Nullable |                   Default                    
----------+--------------------------+-----------+----------+----------------------------------------------
 id       | integer                  |           | not null | nextval('photos_searchlog_id_seq'::regclass)
 created  | timestamp with time zone |           | not null | 
 updated  | timestamp with time zone |           | not null | 
 lang     | character varying(2)     |           | not null | 
 q        | character varying(255)   |           | not null | 
 hits     | integer                  |           | not null | 
 count    | integer                  |           | not null | 
 ip_list  | text                     |           | not null | 
 locked   | boolean                  |           | not null | 
 ts_list  | text                     |           | not null | 
 ts_count | integer                  |           | not null | 
Indexes:
    "photos_searchlog_pkey" PRIMARY KEY, btree (id)
    "photos_searchlog_lang_q_key" UNIQUE CONSTRAINT, btree (lang, q)
    "photos_searchlog_count" btree (count)
    "photos_searchlog_created" btree (created)
    "photos_searchlog_ts_count" btree (ts_count)
    "photos_searchlog_updated" btree (updated)

testdb=# select count(*) from photos_searchlog;
  count  
---------
 4006671
(1 row)

U16.04 - Time 

time psql testdb < searchlog_noowner.sql
SET
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
CREATE SEQUENCE
ALTER SEQUENCE
ALTER TABLE
COPY 4006671
  setval  
----------
 16211932
(1 row)

ALTER TABLE
ALTER TABLE
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX

real    13m7.987s
user    0m0.688s
sys 0m0.268s

U16.04 - Postgres 10.1 logs

tail -f postgresql-10-main.log 
    FROM pg_catalog.pg_database d
    ORDER BY 1;
2017-12-31 03:30:59.567 CET [1114] postgres@postgres LOG:  duration: 1.809 ms  statement: SELECT d.datname as "Name",
           pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
           pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
           d.datcollate as "Collate",
           d.datctype as "Ctype",
           pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
    FROM pg_catalog.pg_database d
    ORDER BY 1;
2017-12-31 03:31:27.766 CET [1128] hans@postgres LOG:  duration: 244.787 ms  statement: CREATE DATABASE testdb;
2017-12-31 03:31:40.223 CET [1143] hans@testdb LOG:  duration: 0.098 ms  statement: SET statement_timeout = 0;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.038 ms  statement: SET lock_timeout = 0;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.018 ms  statement: SET client_encoding = 'UTF8';
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.017 ms  statement: SET standard_conforming_strings = on;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.013 ms  statement: SET check_function_bodies = false;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.012 ms  statement: SET client_min_messages = warning;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.022 ms  statement: SET search_path = public, pg_catalog;
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.013 ms  statement: SET default_tablespace = '';
2017-12-31 03:31:40.224 CET [1143] hans@testdb LOG:  duration: 0.011 ms  statement: SET default_with_oids = false;
2017-12-31 03:31:40.245 CET [1143] hans@testdb LOG:  duration: 21.011 ms  statement: CREATE TABLE photos_searchlog (
        id integer NOT NULL,
        created timestamp with time zone NOT NULL,
        updated timestamp with time zone NOT NULL,
        lang character varying(2) NOT NULL,
        q character varying(255) NOT NULL,
        hits integer NOT NULL,
        count integer NOT NULL,
        ip_list text NOT NULL,
        locked boolean NOT NULL,
        ts_list text NOT NULL,
        ts_count integer NOT NULL
    );
2017-12-31 03:31:40.250 CET [1143] hans@testdb LOG:  duration: 4.735 ms  statement: CREATE SEQUENCE photos_searchlog_id_seq
        START WITH 1
        INCREMENT BY 1
        NO MINVALUE
        NO MAXVALUE
        CACHE 1;
2017-12-31 03:31:40.255 CET [1143] hans@testdb LOG:  duration: 4.476 ms  statement: ALTER SEQUENCE photos_searchlog_id_seq OWNED BY photos_searchlog.id;
2017-12-31 03:31:40.261 CET [1143] hans@testdb LOG:  duration: 5.990 ms  statement: ALTER TABLE ONLY photos_searchlog ALTER COLUMN id SET DEFAULT nextval('photos_searchlog_id_seq'::regclass);
2017-12-31 03:31:47.883 CET [1095] LOG:  checkpoints are occurring too frequently (20 seconds apart)
2017-12-31 03:31:47.883 CET [1095] HINT:  Consider increasing the configuration parameter "max_wal_size".
2017-12-31 03:31:51.556 CET [1143] hans@testdb LOG:  duration: 11294.817 ms  statement: COPY photos_searchlog (id, created, updated, lang, q, hits, count, ip_list, locked, ts_list, ts_count) FROM stdin;
2017-12-31 03:31:51.560 CET [1143] hans@testdb LOG:  duration: 4.234 ms  statement: SELECT pg_catalog.setval('photos_searchlog_id_seq', 16211932, true);
2017-12-31 03:44:28.160 CET [1143] hans@testdb LOG:  duration: 756599.117 ms  statement: ALTER TABLE ONLY photos_searchlog
        ADD CONSTRAINT photos_searchlog_lang_q_key UNIQUE (lang, q);
2017-12-31 03:44:32.092 CET [1143] hans@testdb LOG:  duration: 3932.650 ms  statement: ALTER TABLE ONLY photos_searchlog
        ADD CONSTRAINT photos_searchlog_pkey PRIMARY KEY (id);
2017-12-31 03:44:36.149 CET [1143] hans@testdb LOG:  duration: 4056.127 ms  statement: CREATE INDEX photos_searchlog_count ON photos_searchlog USING btree (count);
2017-12-31 03:44:40.210 CET [1143] hans@testdb LOG:  duration: 4061.228 ms  statement: CREATE INDEX photos_searchlog_created ON photos_searchlog USING btree (created);
2017-12-31 03:44:44.602 CET [1143] hans@testdb LOG:  duration: 4391.615 ms  statement: CREATE INDEX photos_searchlog_ts_count ON photos_searchlog USING btree (ts_count);
2017-12-31 03:44:48.166 CET [1143] hans@testdb LOG:  duration: 3563.880 ms  statement: CREATE INDEX photos_searchlog_updated ON photos_searchlog USING btree (updated);

U14.04 - Time

time psql testdb < searchlog_noowner.sql
SET
SET
SET
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
CREATE SEQUENCE
ALTER SEQUENCE
ALTER TABLE
COPY 4006671
  setval  
----------
 16211932
(1 row)

ALTER TABLE
ALTER TABLE
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX

real 1m46.952s
user 0m0.784s
sys 0m0.240s

U14.04 - Postgres 10.1 logs

tail -f postgresql-10-main.log 
FROM pg_catalog.pg_database d
ORDER BY 1;
2017-12-31 03:32:38.645 CET [17171] postgres@postgres LOG:  duration: 0.618 ms  statement: SELECT d.datname as "Name",
       pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
       pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
       d.datcollate as "Collate",
       d.datctype as "Ctype",
       pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;
2017-12-31 03:33:22.935 CET [17201] hans@postgres LOG:  duration: 291.882 ms  statement: CREATE DATABASE testdb;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.069 ms  statement: SET statement_timeout = 0;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.015 ms  statement: SET lock_timeout = 0;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.013 ms  statement: SET idle_in_transaction_session_timeout = 0;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.014 ms  statement: SET client_encoding = 'UTF8';
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.015 ms  statement: SET standard_conforming_strings = on;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.012 ms  statement: SET check_function_bodies = false;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.011 ms  statement: SET client_min_messages = warning;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.010 ms  statement: SET row_security = off;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.019 ms  statement: SET search_path = public, pg_catalog;
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.010 ms  statement: SET default_tablespace = '';
2017-12-31 03:34:09.304 CET [17247] hans@testdb LOG:  duration: 0.008 ms  statement: SET default_with_oids = false;
2017-12-31 03:34:09.312 CET [17247] hans@testdb LOG:  duration: 8.316 ms  statement: CREATE TABLE photos_searchlog (
    id integer NOT NULL,
    created timestamp with time zone NOT NULL,
    updated timestamp with time zone NOT NULL,
    lang character varying(2) NOT NULL,
    q character varying(255) NOT NULL,
    hits integer NOT NULL,
    count integer NOT NULL,
    ip_list text NOT NULL,
    locked boolean NOT NULL,
    ts_list text NOT NULL,
    ts_count integer NOT NULL
);
2017-12-31 03:34:09.314 CET [17247] hans@testdb LOG:  duration: 1.382 ms  statement: CREATE SEQUENCE photos_searchlog_id_seq
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;
2017-12-31 03:34:09.315 CET [17247] hans@testdb LOG:  duration: 1.097 ms  statement: ALTER SEQUENCE photos_searchlog_id_seq OWNED BY photos_searchlog.id;
2017-12-31 03:34:09.316 CET [17247] hans@testdb LOG:  duration: 1.453 ms  statement: ALTER TABLE ONLY photos_searchlog ALTER COLUMN id SET DEFAULT nextval('photos_searchlog_id_seq'::regclass);
2017-12-31 03:34:27.048 CET [17247] hans@testdb LOG:  duration: 17731.032 ms  statement: COPY photos_searchlog (id, created, updated, lang, q, hits, count, ip_list, locked, ts_list, ts_count) FROM stdin;
2017-12-31 03:34:27.049 CET [17247] hans@testdb LOG:  duration: 1.126 ms  statement: SELECT pg_catalog.setval('photos_searchlog_id_seq', 16211932, true);
2017-12-31 03:35:36.752 CET [17247] hans@testdb LOG:  duration: 69703.146 ms  statement: ALTER TABLE ONLY photos_searchlog
    ADD CONSTRAINT photos_searchlog_lang_q_key UNIQUE (lang, q);
2017-12-31 03:35:40.236 CET [17247] hans@testdb LOG:  duration: 3483.664 ms  statement: ALTER TABLE ONLY photos_searchlog
    ADD CONSTRAINT photos_searchlog_pkey PRIMARY KEY (id);
2017-12-31 03:35:44.521 CET [17247] hans@testdb LOG:  duration: 4284.701 ms  statement: CREATE INDEX photos_searchlog_count ON photos_searchlog USING btree (count);
2017-12-31 03:35:48.969 CET [17247] hans@testdb LOG:  duration: 4447.547 ms  statement: CREATE INDEX photos_searchlog_created ON photos_searchlog USING btree (created);
2017-12-31 03:35:52.850 CET [17247] hans@testdb LOG:  duration: 3881.215 ms  statement: CREATE INDEX photos_searchlog_ts_count ON photos_searchlog USING btree (ts_count);
2017-12-31 03:35:56.222 CET [17247] hans@testdb LOG:  duration: 3371.491 ms  statement: CREATE INDEX photos_searchlog_updated ON photos_searchlog USING btree (updated);

I tested this with different PG versions, on different machines, with autovaccum on/off, with a complete database, with single tables - but always the same result: U14.04 is much faster...

May be someone has an idea where the "bug" is...

Thanks Hans

PS: The time difference is much bigger when dumping our 5 GB database.

U14.04: Always around 7 minutes
U16.04:  27 minutes (autovacuum off)
U16.04: 268 minutes (autovacuum on)!!!
ubuntu
Martin Hope
Barmi
Asked: 2017-04-18 17:15:22 +0800 CST
  • 0

Running Postgres on Ubuntu 16.04 autovacuum processes are using 100% CPU after a short time.

ps aux | grep postgres

postgres  79654 72.7  0.1 402164 226580 ?       Rs   Apr17  66:48 postgres: 9.6/main: autovacuum worker process   test
postgres  82850  0.4  0.1 379972 200984 ?       Ss   Apr17   0:14 postgres: 9.6/main: autovacuum worker process   test
postgres  83444 85.5  0.1 329888 161160 ?       Rs   Apr17  41:53 postgres: 9.6/main: autovacuum worker process   test

top

 79654 postgres  20   0  402164 226580 144188 R 100.0  0.2  66:45.14 postgres
 83444 postgres  20   0  329888 161160 141916 R 100.0  0.1  41:50.45 postgres
 86969 postgres  20   0  323852 161760 151372 R 100.0  0.1   1:58.84 postgres
 86973 postgres  20   0  322976 161284 151412 R  88.2  0.1   1:24.82 postgres

The same configuration runs on Ubuntu 14.04 like a charm... Tested with PG 9.4/9.5/9.6 and postgres.conf default config. What's the matter with U16.04?

ubuntu
Martin Hope
Barmi
Asked: 2016-10-21 10:16:19 +0800 CST
  • 0

From the official Riak documentation: "In a Riak CS system, any node can respond to client requests - there is no master node and each node has the same responsibilities. Since data is replicated (three replicas per object by default), and other nodes automatically take over the responsibility of failed or non-communicative nodes, data remains available even in the event of node failure or network partition."

Are there experiences if three replicas per object bring some advantages (speed, security) or is it ok to use Riak without replicas (less space)?

performance security replication riak
Martin Hope
Barmi
Asked: 2016-07-20 13:44:07 +0800 CST
  • 5

What is the best way to synchronize huge data of a running production server?

Our server has over 20 million files (small files with 10k and bigger files up to 50MB) stored in 1 millon directories. The size of all data is about 5 TB (steadily increasing).

Is it possible to synchronize the data with lsyncd and what are the limits (especially of inotify)? How much additional space does lsyncd need? What about the load (cpu and memory) and the live time?

Another solution would be GlusterFS. Is it possible to use GlusterFS on a production with none or minimal downtime? GlusterFS stores a lot of magic data in x-attributes files and the storage volume is about 15 to 20% bigger than systems with non GlusterFS. Seems like a huge amount of waste...? What about the load?

And at least rsync and cronjobs could do the job. rsync would only run on the slave... So no additional space is needed on the primary server, but rsync must read the full directory tree every time the cron runs...

synchronization linux glusterfs lsyncd
Martin Hope
Barmi
Asked: 2016-07-19 01:36:22 +0800 CST
  • 9

I have a production server running Postgres 9.4. The database is > 10 GB. Is it possible to upgrade to Postgres 9.5 without downtime and without loosing data?

Upgrade tutorials recommend to stop Postgres while executing sudo pg_upgradecluster 9.4 main, but this may take a long time. Updating a 10 GB cluster can take several hours!

I also tried pg_dump mydb > db.sql. Dropping the database and inserting the dump again in PG 9.4 (psql -d mydb -f db.sql) took about 50 minutes.

But inserting the dump in PG 9.5 finished only after mor than 7 hours. Especially creating the index was really slow...

2016-07-18 00:13:55 CEST [60358-5] ERROR:  canceling autovacuum task
2016-07-18 00:13:55 CEST [60358-6] CONTEXT:  automatic analyze of table ...
2016-07-18 00:36:20 CEST [60366-1] ERROR:  canceling autovacuum task
2016-07-18 00:36:20 CEST [60366-2] CONTEXT:  automatic analyze of table ...
2016-07-18 04:21:40 CEST [60361-1] ERROR:  canceling autovacuum task
2016-07-18 04:21:40 CEST [60361-2] CONTEXT:  automatic analyze of table ...
2016-07-18 07:55:19 CEST [61316-1] ERROR:  canceling autovacuum task
2016-07-18 07:55:19 CEST [61316-2] CONTEXT:  automatic analyze of table ...

So neither pg_upgradecluster nor pg_dump is an acceptable solution. Even with PG 4 you would have a downtime of at least 50 minutes. Therefore: How can databases be upgraded on production servers or big master-slave-clusters without downtime and dataloss?

postgresql upgrade data-loss
Martin Hope
Barmi
Asked: 2015-12-29 11:16:41 +0800 CST
  • 3

Why does Nginx proxy_pass to upstream send sometimes outgoing requests to IPv6?

2015/12/28 14:11:06 [error] 38194#0: *114469948 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xxx.xx.xxx, server: example.com, request: "POST /suggest/ HTTP/1.1", upstream: "http://[AAAA:BBB:CCC:DDDD::E]:5555/suggestion", host: "example.com", referrer: "https://example.com/en/apple-111111/"

nginx.conf:

location /suggest/ {
    proxy_pass http://testserver.com:5555/suggestion;
    proxy_set_header Authorization 'Basic xxx';
}

Instead of sending the request to our testserver.com the request goes to http://[AAAA:BBB:CCC:DDDD::E]:5555/suggest

Does anybody know where the IPv6 address is coming from or what is wrong with the nginx conf?

Thanks in advice, Hans

Here is a real example:

2015/12/28 14:11:03 [error] 38192#0: *114552633 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.xx.xxx, server: pixabay.com, request: "POST /suggest/ HTTP/1.1", upstream: "http://[2a01:4f8:160:4450::2]:5555/pixabay/suggestion", host: "pixabay.com", referrer: "https://pixabay.com/fr/"

And the nginx.conf:

location /suggest/ {
  proxy_pass http://pagewizz.com:5555/pixabay/suggestion;
  proxy_set_header Authorization 'Basic xxx';
}

We are running a big image datebase called Pixabay. For searching we use elasticsearch which is running on another server called Pagewizz (2a01:4f8:160:4450::2). If somebody is tagging images, we use elastic to get suggestions. I have no clue why the ipv6 address of Pagewizz appears in the error logs of nginx...

linux
Martin Hope
Barmi
Asked: 2015-12-09 05:47:46 +0800 CST
  • 4

We are running a Python WSGI server (uWSGI) and changed to socket file instead of a tcp/ip localhost:port connection.

Now our uwsgi logs are full of errors like

IOError: write error
SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) during GET /en/photos/?orientation... (ip ...) !!!
uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 296] during GET /en/photos/?orientation... (ip ...)

Changing back to localhost:port and no errors in the logs. The pages are loading with both configurations.

We would prefer Unix sockets because they are a little bit faster... Has anyone a clue what's causing this errors?

uwsgi.ini:

daemonize = /var/log/uwsgi/debug.log
module = project.wsgi:application

socket=127.0.0.1:1111

#socket = /tmp/tmp.sock
#chmod-socket = 666

master = true
vacuum = true

chdir=/var/www/...
pidfile=/tmp/project-master.pid

enable-threads = true
disable-logging = true

processes=6

nginx.conf

location / {
    uwsgi_read_timeout 300;
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:1111;
    #uwsgi_pass unix:/tmp/tmp.sock;
}
nginx
Martin Hope
Barmi
Asked: 2015-02-22 05:07:44 +0800 CST
  • 1

I'm getting the following backtrace in my uWSGI logs, I don't know where to begin looking to figure this out:

DAMN ! worker 5 (pid: 29056) died :( trying respawn ...
Respawned uWSGI worker 5 (new pid: 29088)
DAMN ! worker 6 (pid: 29080) died :( trying respawn ...
Respawned uWSGI worker 6 (new pid: 29089)
!!! uWSGI process 29089 got Segmentation Fault !!!
*** backtrace of 29089 ***
uwsgi(uwsgi_backtrace+0x2e) [0x468a9e]
uwsgi(uwsgi_segfault+0x21) [0x468e61]
/lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f74aa424d40]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(_PyType_Lookup+0x19d) [0x7f74aa97572d]
...
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x7d30d) [0x7f74aa83130d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f74aa8dde23]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x12e5f5) [0x7f74aa8e25f5]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f74aa8dde23]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7f74aa89c837]
uwsgi(python_call+0x11) [0x47b011]
uwsgi(uwsgi_request_wsgi+0x116) [0x47d206]
uwsgi(wsgi_req_recv+0x8e) [0x41e64e]
uwsgi(simple_loop_run+0xc4) [0x465084]
uwsgi(uwsgi_ignition+0x194) [0x4690b4]
uwsgi(uwsgi_worker_run+0x2dd) [0x46d88d]
uwsgi(uwsgi_run+0x3b4) [0x46ddb4]
uwsgi(_start+0) [0x41dd1e]
*** end of backtrace ***

I'm running uWSGI version 2.0.9 together with django 1.7.4 and nginx 1.6 on Ubuntu 14.04 LTS. This is my uWSGI app config:

module=project.wsgi:application
socket=127.0.0.1:7001
pidfile=/tmp/project-master.pid
master=True
vacuum=True
enable-threads=True
disable-logging=True
#limit-as=4096 # can cause problems with some application (especially on 64bit)?
max-requests=8192
processes=12
listen=12000
idle = 3600
stats=127.0.0.1:1717
memory-report = True

This is the nginx conf:

worker_processes 8; # 12 cores
worker_rlimit_nofile 100000;
pid /var/run/nginx.pid;
events {
    worker_connections 16384;
    use epoll;
    multi_accept on;
}
...

Additionally the following error appears sometimes:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 187, in __call__
    response = self.get_response(request)
  File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 199, in get_response
    response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 243, in handle_uncaught_exception
    return callback(request, **param_dict)
  File "./project/utils/utils.py", line 137, in error500
    return error(request, status_code, description)
  File "./project/utils/utils.py", line 127, in error
    response = render(request, 'error.html.jinja', {'description': description })
  File "/usr/local/lib/python2.7/dist-packages/django/shortcuts.py", line 50, in render
    return HttpResponse(loader.render_to_string(*args, **kwargs),
  File "/usr/local/lib/python2.7/dist-packages/django/template/loader.py", line 178, in render_to_string
    return t.render(context_instance)
  File "/usr/local/lib/python2.7/dist-packages/django_jinja/base.py", line 139, in render
    return super(Template, self).render(new_context)
  File "/usr/local/lib/python2.7/dist-packages/jinja2/environment.py", line 982, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/local/lib/python2.7/dist-packages/jinja2/environment.py", line 746, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/var/www/pixabay/pixabay/project/templates/error.html.jinja", line 1, in top-level template code
    {% extends "base.html.jinja" %}
  File "/var/www/pixabay/pixabay/project/templates/base.html.jinja", line 37, in top-level template code
    {% spaceless %}
  File "./project/utils/templatetags/jinga2_extensions.py", line 61, in _strip_spaces
    return strip_spaces_between_tags(caller().strip())
  File "/var/www/pixabay/pixabay/project/templates/base.html.jinja", line 51, in template
    {% if request.user.is_authenticated() %}
  File "/usr/local/lib/python2.7/dist-packages/jinja2/environment.py", line 400, in getattr
    return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'django.core.handlers.wsgi.WSGIRequest object' has no attribute 'user'

This code was running without errors on a machine with 6 cores and ubuntu 12.04 LTS... Any ideas would be great... Thanks

nginx
Martin Hope
Barmi
Asked: 2012-08-29 06:07:19 +0800 CST
  • 2

For some reason nginx is stopping any new requests after a while (2 minutes) whenever a long running request (5 minutes) is being handled.

user www-data www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}
http {

sendfile on;   
tcp_nopush on; 
tcp_nodelay on;
keepalive_timeout 200;   
client_max_body_size 12M;
types_hash_max_size 2048;

include /etc/nginx/mime.types;
default_type application/octet-stream;

gzip on;
gzip_vary on;
gzip_proxied any;     
gzip_comp_level 9;    
gzip_buffers 16 8k;   
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

include /usr/local/nginx/sites/*.conf;
}

Can this be a problem due to uwsgi settings?

[uwsgi]

module=project.wsgi_de:application
socket=127.0.0.1:...

chdir=/var/www/...
pidfile=/tmp/project-master.pid


max-requests=5000
limit-as=1024

master=True
vacuum=True
processes=5
nginx