2014-03-25 8 views
5

Ich habe eine django + uwsgi basierte Website. Einige der Tabellen haben fast 1 Million Zeilen.django + uwsgi riesigen übermäßigen Speicherverbrauch Problem

Nach einiger Webseite Verwendungen verwendeten VIRT Speicher den uwsgi Prozess erreicht fast 20GB ... fast meinen Server töten ...

Könnten Sie jemand sagen, was das Problem verursacht werden? Ist es mein Tisch Reihen zu groß? (unwahrscheinlich. Pinterest hat viel mehr Daten). Jetzt musste ich reload-on-as = 10024 reload-on-rss = 4800 verwenden, um die Arbeiter alle paar Minuten zu töten ... es ist schmerzhaft ... Hilfe?

Hier ist meine uwsgi.ini Datei

[uwsgi]

chdir   = xxx 
module   = xxx.wsgi 
master   = true 
processes  = 2 
socket  =127.0.0.1:8004 
chmod-socket = 664 
no-orphans = true 
#limit-as=256 
reload-on-as= 10024 
reload-on-rss= 4800 
max-requests=250 
uid = www-data 
gid = www-data 
#chmod-socket = 777 
chown-socket = www-data 
# clear environment on exit 
vacuum   = true 
+0

Virtueller Speicher bedeutet nicht „physischen Speicher“. Wie viel rss verwenden Ihre Prozesse? Haben Sie versucht, die Option "uWSGI" für den Speicherbericht hinzuzufügen, um zu sehen, welche Anforderungen mehr Speicher zuweisen? Welchen Datenbankadapter benutzen? – roberto

+0

danke roberto für schnelle antwort. Ich weiß, dass VIRT kein physisches Gedächtnis ist. Wenn es jedoch zunimmt, erhöht sich auch der physische Speicher RSS dramatisch und erreicht 6 GB. schnell. mein 32GB Speicher, nur noch 180M übrig. – edyssy

+0

gerade jetzt. Ich entfernte das Reload-on-As und Reload-on-rss und beobachtete dies: VIRT ist 17.8GB RES: 7.8GB für uwsgi Prozess ... CPU ist 100%. jetzt ist VIRT 19.8GB und RES 10GB. Ich benutze die MySQL. – edyssy

Antwort

13

Nach einigem auf stackflow und Google-Suche zu graben, hier ist die Lösung.

dann dachte ich, die Hauptparameter, um festgelegt in uwsgi.ini max_request ist. ursprünglich habe ich es als 2000 gesetzt. Jetzt setze es auf 50. Damit wird es wieder mit den Respawn arbeiten, wenn der Speicher zu stark ansteigt. Dann versuche ich herauszufinden, welche Anfrage riesige Datenabfrageergebnisse aus der Datenbank verursacht. Ich fand diese kleine Zeile: Betrag = Summe (x.Mount für x in Project.objects.all()) Während Projekt-Tabelle hat über 1 Million komplexe Einträge. Sehr großen Speicher zu beschäftigen .... seit ich dies auskommentiert ... läuft jetzt alles glatt.

So ist es gut zu verstehen, wie die [django Abfrage mit Datenbank arbeitet]

+1

Wenn Sie einfach so viele Zeilen abrufen, wird viel Speicher belegt (viel schlimmer, wenn DEBUG True ist). Ziehen Sie 'Project.objects.all(). Iterator()' vor, wenn Sie die abgefragten Zeilen eindeutig verwenden. In Ihrem Fall ist das viel einfacher: Sie hätten Ihren gesamten Speicher mit Django-Queryset-Aggregationsmethoden verschont. –

+0

tks. gute Idee. – edyssy

+1

Wenn diese 'Menge' ein Django-Feld und keine Python-Eigenschaft ist, können Sie aggregieren und die DB die Summe so schneller ausführen lassen als Python: https://docs.djangoproject.com/en/1.10/topics/db/aggregation/# Spickzettel – alanjds

1

(Leider habe ich einen Kommentar nicht genug Ruf haben - so entschuldigen, wenn diese Antwort in Ihrem Fall nicht hilft)

Ich hatte das gleiche Problem laufen Django auf uwsgi/gninx und uwsgi gesteuert über Supervisor. Der uwsgi-supervisor-Prozess begann mit viel Speicher und verbrauchte 100% CPU. Daher bestand die einzige Option darin, uwsgi wiederholt neu zu starten.

die Lösung stellte sich heraus, war die Protokollierung in der uwsgi.ini Datei einzurichten:

logto = /var/log/uwsgi.log 

Es gibt einige Diskussionen über das hier ist: https://github.com/unbit/uwsgi/issues/296

+0

danke. Ich habe es hinzugefügt, falls es ähnliche Probleme verursachen wird. – edyssy

Verwandte Themen