Mailman 3 August 2011 - python-de

Re: [Python-de] Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 24 Aug '11

24 Aug '11

Thomas Waldmann <tw-public(a)gmx.de> wrote: >> Dass man am Anfang mehr Speicher braucht bis der JIT alles schön >> optimiert (ist auch von Aufruf zu Aufruf schneller geworden, bis > Wollte nur mal drauf hinweisen, dass dieses "am Anfang" auch etwas > laenger als erwartet sein kann. Es waren ein paar Hundertausende von Requests. > Von daher koennte man vermuten, dass vielleicht bei Deinen Tests das > auch nur der JIT ist, der eben immer mal wieder was compiled (und dazu > RAM verbraucht). Auch ohne JIT getestet. Zuwachs ist nicht so schnell, aber es wird trotzdem stetig mehr verbraucht. Deswegen weiß ich nicht, ob weitere Tests mehr bringen. Ohne JIT sehe ich keinen Nicht-Fehler-Grund immer mehr Speicher zu benötigen. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

1 0

Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 24 Aug '11

24 Aug '11

Aktuelles Tornado 2.0 mit PyPy 1.6 habe ich mit dem Hello-Programm von der Tornado-Website getestet. ApacheBench auf 127.0.0.1 mit sehr vielen Zugriffen. Speicherverbrauch (RES bei top) stieg andauernd an. Kein Ende in Sicht. Dass man am Anfang mehr Speicher braucht bis der JIT alles schön optimiert (ist auch von Aufruf zu Aufruf schneller geworden, bis es ein Maximum erreicht hat) war mir klar. Aber das schien endlos zu laufen. Tests mit CPython 2.6 verliefen ohne Leck. Ist dazu vielleicht was bekannt? Auf der Mailingliste zu web2py hatte ich gelesen, dass PyPy Files nicht automatisch schließt wenn sie nicht mehr referenziert werden. GC weicht ab zwischen CPython und PyPy. Ist vielleicht so ein Problem? Oder eher grundsätzlich etwas mit PyPy noch nicht in Ordnung? -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

4 5

Sporadisch 10fach langsamer
by Thomas Guettler 16 Aug '11

16 Aug '11

Hallo, gegeben ist eine Intranet Anwendung (Django+Postgres), die auf einen gut ausgebauten Server läuft. Sporadisch dauern die Requests zehnmal so lange. Ich konnte die Ursache aber noch nicht finden. Es hat sicher **nichts** mit dem Netzwerk zu tun. Die Zeitmessung beginnt nach dem Empfang des Requests und endet vor dem Senden des Response. Die Datenbank wird per Unix-Domain Socket angesprochen. Parallel laufen auch keine Prozesse, die Last (CPU, Memory, IO) erzeugen könnten. Der Server langweilt sich nur: 8 Cores, 8 GB RAM. Dummerweise lässt sich das nicht reproduzieren, tritt aber täglich auf. Habt Ihre Ideen wie man den Fehler finden könnte? Meine Idee: Alle N Millisekunden merkt sich der Request-Handler in welcher Methode er sich gerade befindet. Am Ende des Requests wird das ausgegeben, falls der Request deutlich länger als sonst gedauert hat. So könnte man die Stelle im Quelltext finden, die deutlich länger dauert als sonst. Dieses Logging sollte den Ablauf nicht deutlich verlangsamen (Produktivsystem) Wie könnte man das machen? Um Threads habe ich bisher immer einen weiten Bogen gemacht. Gruß, Thomas

6 5

Nested defaultdict
by Wandfliese 16 Aug '11

16 Aug '11

Guten Abend, oft stehe ich vor der Aufgabe Logdateien auszuwerten um beispielsweise festzustellen wann welche Seite aufgerufen wurde. Hierbei hat mir defaultdict(list) gute Dienste geleistet aber oftmals habe ich mir gewünscht mehrere defaultdict's ineinander zu verschachteln. Habe dazu folgende Funktion gebastelt, die mir ein n-fach verschachteltes defaultdict zurückgeben sollte def nestedDict(factory, n): superClass = defaultdict(factory) for i in range(n-1): superClass = defaultdict(lambda : superClass) return superClass Leider legt der Rückgabewert ein seltsames Verhalten an den Tag wohingegen defaultdict(lambda:defaultdict(list)) das gewünschte leistet. Könnte ihr mir erklären was da schief läuft? Beste Grüße Wandfliese P.S.: Gibt es eine Abkürzung für for i in range(n): falls die Variable i nicht verwendet wird?

5 6

Looking for PyCon US 2012 Speakers
by Brian Curtin 15 Aug '11

15 Aug '11

With PyCon 2012 efforts off to a great start, we’re looking for you, the people of the Python community, so show us what you’ve got. Our call for proposals (http://us.pycon.org/2012/cfp/) just went out and we want to include you in our 2012 conference schedule, taking place March 7-15, 2012 in Santa Clara, CA. The call covers tutorial, talk, and poster applications, and we’re expecting to blow the previous record of 250 applications out of the water. Put together your best 3-hour class proposals for one of the tutorial sessions on March 7 and 8. Submit your best talks on any range of topics for the conference days, March 9 through 11. The poster session will be in full swing on Sunday with a series of 4'x4' posters and an open floor for attendees to interact with presenters. Get your applications in early - we want to help you put together the best proposal possible, so we’re going to work with submitters as applications come in. See more details and submit your talks here: http://us.pycon.org/2012/speaker/ We’re also looking for feedback from your past PyCon experiences along with what you’re looking for in the future, by way of our 2012 Guidance Survey at https://www.surveymonkey.com/s/pycon2012_launch_survey. The attendees make the conference, so every response we get from you makes a difference in putting together the best conference we can. If you or your company is interested in sponsoring PyCon, we’d love to hear from you. Join our growing list with Diamond sponsors Google and Dropbox, and Platinum sponsors Microsoft, Nasuni, SurveyMonkey, and Gondor by Eldarion. CCP Games, Linode, Walt Disney Animation Studios, Canonical, DotCloud, Loggly, Revolution Systems, ZeOmega, bitly, ActiveState, JetBrains, Snoball, Caktus Consulting Group, and Disqus make up our Gold sponsors. The Silver sponsors so far are 10gen, GitHub, Olark, Wingware, net-ng, Imaginary Landscape, BigDoor, Fwix, AG Interactive, Bitbucket, The Open Bastion, Accense Technology, Cox Media Group, and myYearbook. See our sponsorship page at http://us.pycon.org/2012/sponsors/ for more details. The PyCon Organizers - http://us.pycon.org/2012 Jesse Noller - Chairman - jnoller(a)python.org Brian Curtin - Publicity Coordinator - brian(a)python.org

1 0

Geodätische Funktionsbibliothek GeoDLL 32 Bit und 64 Bit
by Fred 14 Aug '11

14 Aug '11

Hallo Entwickler, wer Programme mit geodätischer Funktionalität wie z.B. Koordinatentransformationen oder Entfernungsberechnungen entwickelt, kann dafür die neuste Version meiner GeoDLL einsetzen. Die Dynamic Link Library kann einfach aus irgend einer Programmiersprache heraus verwendet werden, um den damit entwickelten Programmen geodätische Funktionen hinzuzufügen. In GeoDLL sind präzise Funktionen zu den Themen 2D- und 3D-Koordinatentransformation, Datums- bzw. Bezugssystemwechsel, Meridianstreifenwechsel, Koordinaten- und Bezugssysteme, Benutzerdefinitionen, Entfernungsberechnungen, Digitale Höhenmodelle, NTv2-Unterstützung, Geodätische Hauptaufgaben und viele andere geodätische Funktionen enthalten. Die DLL ist durch die konsequente Weiterentwicklung in C++ unter Microsoft Visual Studio 2010 sehr schnell und sicher geworden. Die geodätischen Funktionen stehen in der neuen Version 12.05 ab sofort in 32Bit- und 64Bit-Architektur zur Verfügung. Eine Testversion zum Herunterladen findet ihr hier: http://www.killetsoft.de/p_gdla_d.htm. Fred

4 3

Re: [Python-de] Nested defaultdict
by Wandfliese 14 Aug '11

14 Aug '11

Vielen Dank! On Aug 14, 12:01 am, "Diez B. Roggisch" <de...(a)web.de> wrote: > Das Problem ist das du superClass immer wieder neu bindest, und das lambda einen Closure bildet mit dem letzten wert. > > Benutz stattdessen > > lambda superClass=superClass : ... > > Das bindet den wert zur Konstruktion > > Diez > > Am 13.08.2011 um 23:34 schrieb Wandfliese <jonas.fi...(a)googlemail.com>: > > > > > > > > > Guten Abend, > > > oft stehe ich vor der Aufgabe Logdateien auszuwerten um beispielsweise > > festzustellen wann welche Seite aufgerufen wurde. Hierbei hat mir > > defaultdict(list) gute Dienste geleistet aber oftmals habe ich mir > > gewünscht mehrere defaultdict's ineinander zu verschachteln. > > > Habe dazu folgende Funktion gebastelt, die mir ein n-fach > > verschachteltes defaultdict zurückgeben sollte > > > def nestedDict(factory, n): > > superClass = defaultdict(factory) > > for i in range(n-1): > > superClass = defaultdict(lambda : superClass) > > return superClass > > > Leider legt der Rückgabewert ein seltsames Verhalten an den Tag > > wohingegen defaultdict(lambda:defaultdict(list)) das gewünschte > > leistet. > > > Könnte ihr mir erklären was da schief läuft? > > > Beste Grüße > > > Wandfliese > > > P.S.: Gibt es eine Abkürzung für for i in range(n): falls die Variable > > i nicht verwendet wird? > > _______________________________________________ > > python-de maillist - python...(a)python.org > >http://mail.python.org/mailman/listinfo/python-de

1 0

Re: [Python-de] Sporadisch 10fach langsamer
by Thorsten Kampe 11 Aug '11

11 Aug '11

* Diez B. Roggisch (Thu, 11 Aug 2011 10:30:11 +0200) > >> Sporadisch dauern die Requests zehnmal so lange. > > > > Welche "Requests"? HTTP-Requests des Browsers an den Web-Server? > > > >> Es hat sicher **nichts** mit dem Netzwerk zu tun. Die Zeitmessung > >> beginnt nach dem Empfang des Requests und endet vor dem Senden des > >> Response. > > > > Also dauern die Requests /nicht/ zehnmal so lang sondern (bis) die > > Antwort (kommt). > > Huh, jetzt wird's aber kleinlich... Wenn jemand ein "meine Anwendung ist langsam"-Problem hat, soll er das auch schreiben. Das ist zwar etwas "schwach" und produziert "geht's auch etwas genauer?" Nachfragen aber immer noch besser als das Problem pseudo-technisch und irreführend zu beschreiben. > >> Habt Ihre Ideen wie man den Fehler finden könnte? > >> > >> Meine Idee: Alle N Millisekunden merkt sich der Request-Handler in > >> welcher Methode er sich gerade befindet. Am Ende des Requests wird > >> das ausgegeben, falls der Request deutlich länger als sonst > >> gedauert hat. So könnte man die Stelle im Quelltext finden, die > >> deutlich länger dauert als sonst. > > > > Du könntest natürlich auch einfach deinen Martelli zur Hand nehmen > > und zum Thema Profiling (Module profile und pstats) lesen. Oder in > > einem Django-Forum (so es denn eines gibt) fragen. > > Profiling bei einer Live-Anwendung? Wohl kaum. Wenn ich Thomas "Idee" richtig verstanden habe, spielte er doch schon mit dem Gedanken, den Quelltext zu modifizieren. Das das bei einer "Live-Anwendung" problematisch sein kann, ist klar. Meiner Meinung nach, ist es immer noch am sinnvollsten, sich in einem Django-Forum nach Ideen oder Vorgehensweisen zu erkundigen. Ein "meine Web-Anwendung plus Datenbank ist manchmal langsam, was kann ich tun" Problem, ist ja nicht gerade untypisch. Thorsten

1 0

Re: [Python-de] Sporadisch 10fach langsamer
by Thomas Guettler 11 Aug '11

11 Aug '11

Am 11.08.2011 09:17, schrieb Stefan Behnel: > Thomas Guettler, 11.08.2011 08:30: >> Am 10.08.2011 23:05, schrieb markus espenhain: >>> On 08/10/11 22:18, Thomas Guettler wrote: >>> bevor du deine Python-App zerlegst - hast du dir mal die PG-Datenbank >>> angesehen? - Query-Log, Config, etc - manche Postgres Default-Configs >>> sind je nach Anwendung oft ... suboptimal. >> >> ja, die Tuning-Tipps aus dem Postgres Wiki sind mir bekannt. >> >> Die Anwendung (mit DB Anbindung) läuft ansonsten super gut. Nur hin- >> und wieder >> gibt es Hänger. Und die Requests die plötzlich länger brauchen sind >> einfache >> GET-Requests. > > Womit du jetzt aber nicht die Frage beantwortet hast, ob es die Queries > sind, die länger laufen, oder ob es ein Problem innerhalb des > Web-Servers ist. Das kann ich erst in ein paar Stunden sagen. Ich habe gerade log_min_duration_statement = 1s gesetzt. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de

1 0

Re: [Python-de] Sporadisch 10fach langsamer
by Thomas Guettler 11 Aug '11

11 Aug '11

Am 10.08.2011 23:05, schrieb markus espenhain: > On 08/10/11 22:18, Thomas Guettler wrote: >> Hallo, > > Hi, > > bevor du deine Python-App zerlegst - hast du dir mal die PG-Datenbank > angesehen? - Query-Log, Config, etc - manche Postgres Default-Configs > sind je nach Anwendung oft ... suboptimal. Hallo, ja, die Tuning-Tipps aus dem Postgres Wiki sind mir bekannt. Die Anwendung (mit DB Anbindung) läuft ansonsten super gut. Nur hin- und wieder gibt es Hänger. Und die Requests die plötzlich länger brauchen sind einfache GET-Requests. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de

2 1