speicherverbrauch steigt stätig....
-
3 MB, 8 MB, 12 MB, das sind alles Pimpifax-Werte, da kann man rein über den Task-Manager noch nicht sagen ob es ein Memory-Leak gibt oder nicht.
Kannst du das Programm so umbauen dass es mit 10-/100-/1000-facher Geschwindigkeit läuft? Ggf. einen lokalen Webserver zum Testen aufsetzen etc.
Dann würde der Speicherverbrauch - wenn es ein Leak gibt - schnell so deutlich ansteigen, dass du dir sicher sein kannst.
BTW: guck dir die "VM Size" ("Commit Size") an, und nicht die "(Private) Working Set Size". Das Working Set wird nämlich von Windows "gestutzt" wenn du das Programm minimierst, oder auch wenn andere Prozesse auf einmal viel Speicher brauchen.
-
Benutz doch libcurl. Das ist bereits mehrfach getestet worden.
-
Wenn der Speicher beim Minimieren freigegeben wird, aber dann wieder mit der Zeit beim minimierten Programm "wie üblich" steigt, dann kann das ja nicht die grafische Ausgabe sein, sondern da leckt Speicher, der beim Minimiervorgang aufgeräumt wird. Schau doch einfach nach, welche Ressourcen beim Minimieren freigegeben werden und ob die da sein sollen und nur fälschlicherweise geleert werden (z.B. Cache) oder dein Programm Leckt. Das kommt mir aber irgendwie seltsam vor.
Bei solchen Dingen hilft mir übrigens unter Linux manchmal "pmap -d" auf den Prozess, um den Übeltäter zu ermitteln. Das Windows-Pendant dazu kenne ich nicht, lässt sich aber bestimmt irgendwo finden.
-
Und vorallem sind 2000 Zeilen für so eine simple Aufgabe relativ wenig. Ich kann da echt nur raten, dass man vermehrt auf fertige Libs setzt. Dann wird das ganz schnell überschaubar und man schließt fehlerhafte Implementierungen eher aus.
-
.... schrieb:
Und vorallem sind 2000 Zeilen für so eine simple Aufgabe relativ wenig. Ich kann da echt nur raten, dass man vermehrt auf fertige Libs setzt. Dann wird das ganz schnell überschaubar und man schließt fehlerhafte Implementierungen eher aus.
Relativ viel!!!, war natürlich gemeint.
-
Mini schrieb:
Wenn der Speicher beim Minimieren freigegeben wird
Also ich tippe immer noch darauf dass garnix beim Minimieren freigegeben wird, sondern Windows einfach das Working Set beschneidet. Das hat mit Freigeben nix zu tun.
p.S.: es kann auch Speicher sein den Windows implizit verwendet, z.B. Texturen um das Fenster zu rendern oder etwas in der Art. Dann würde zwar wirklich was beim Minimieren freigegeben, aber nicht vom Programm selbst, sondern von einem Windows-Teil.
-
p.S.: es kann auch Speicher sein den Windows implizit verwendet, z.B. Texturen um das Fenster zu rendern oder etwas in der Art. Dann würde zwar wirklich was beim Minimieren freigegeben, aber nicht vom Programm selbst, sondern von einem Windows-Teil.
das klingt für mich am logischsten

Kannst du das Programm so umbauen dass es mit 10-/100-/1000-facher Geschwindigkeit läuft? Ggf. einen lokalen Webserver zum Testen aufsetzen etc.
ich werde das programm mal lokal testen und meinen server mit ner anfrage alle 1sex/1/10sec strapaziere.... also very extrem als so wie es momentan läuft...
BTW: guck dir die "VM Size" ("Commit Size") an, und nicht die "(Private) Working Set Size". Das Working Set wird nämlich von Windows "gestutzt" wenn du das Programm minimierst, oder auch wenn andere Prozesse auf einmal viel Speicher brauchen.
damit kann ich i.M nichts anfangen... was soll das sein?
btw... wer lust hat mal den kompletten source anzuschauen und seine meinung zu sagen kann sich gerne melden
würd mich echt mal interessieren was man zu meinem (seit 1 monat erst c gelernt)'m code so sagen würde...
apropo.. an ein speicherleck glaub ich momentant trotzdem nich... der code an sich schaut eigentl recht ok aus.. (bis auf das manches simpler gestaltet werden könnte
)
-
taurus schrieb:
BTW: guck dir die "VM Size" ("Commit Size") an, und nicht die "(Private) Working Set Size". Das Working Set wird nämlich von Windows "gestutzt" wenn du das Programm minimierst, oder auch wenn andere Prozesse auf einmal viel Speicher brauchen.
damit kann ich i.M nichts anfangen... was soll das sein?
die commit size ist die grösse des speichers den dein programm "belegt" hat.
die working set size ist die grösse des speichers den windows deinem programm momentan zugeteilt hat.die working set size kann daher viel geringer sein als die commit size, wenn windows z.b. (meist wenig genutzte) teile des belegten speichers auslagert.
beide werte kannst du dir mit dem windows 7 task manager angucken. wobei es sein kann dass du die "commit size" erst einblenden musst, ich glaube die wird per default nicht angezeigt.
-
dat geht so nisch... hab kein windows 7 arbeite noch mit winXP....
-
in windows xp heisst die spalte glaub ich "vm size".
-
Ansonsten ist ne passende Spalte bestimmt beim Process Explorer vorhanden

-
vm size wird wohl virtual memory site sein

nun.. Mem Usge liegt momentan bei 3,46MB die VM Size bei 5,74MB.
was sagen mir denn nun die angaben wenn vm size größer ist?
abgesehen davon:
im prozess manager kann ich ja auch version, firmen name, etc anzeigen.. wo genau werden diese angaben im programm gespeichert?
-
alter schwede
gibt es auch dinge die du selbst rausbekommen kannst?die versions-infos werden in einem "version" block in den sog. resourcen eine .exe/.dll datei abgespeichert.
-
ja und nein.. dazu hab ich nichts gefunden
was ist den nun mit der ram größe.. was sagt da denn aus?
-
Hallo taurus,
'VM Size' ist die virtuelle Größe des Programms.
'Mem Usge' ist der reale Speicherverbrauch.Zum Finden von Speicherleaks ist die 'VM Size' oft besser geeignet,
weil Caching und Auslagerungseffekte hierbei keine Berücksichtigung finden.Bitte versuche mal, wie schon erwähnt, die Arbeit deines Programms zu erhöhen
und ermittle den durchschnittlichen 'VM Size' Anstieg z.B. pro Loop.
Oft ist die Größenordnung alleine schon ein Hinweis.Intressant ist zudem ob du Handle Leaks oder andere Leaks (Threads, files, ...) hast.
Hierzu kannst du den Taskmanager oder besser den ProcessExplorer verwenden.Du kannst nach folgenden Schlüsselwörtern suchen:
malloc, new, open, init, ...
und verfolgen, ob es ein passendes
free, delete, close, exit, ... gibtOft ist es hilfreich eigene Object Memory Zähler einzubauen.
Man kann dann zu bestimmten Zeitpunkten loggen welche Objekte existieren.Mit diesen Mitteln habe ich alle bisherigen Memory leaks gefunden.
Einfach ist es deswegen aber noch lange nicht!Viele Erfolg, Gruß Frank
-
Bitte versuche mal, wie schon erwähnt, die Arbeit deines Programms zu erhöhen
und ermittle den durchschnittlichen 'VM Size' Anstieg z.B. pro Loop.ich kann das leider nicht mehr erhöhen als jede sekunde eine abfrage.., momentan bei 10sec.. sollte aber eigentl reichen...
Intressant ist zudem ob du Handle Leaks oder andere Leaks (Threads, files, ...) hast.
Hierzu kannst du den Taskmanager oder besser den ProcessExplorer verwenden.ich weiß nicht ob ich das richtig gemacht hab... bin auf "File / Handle " gegangen und habe dort nach "malloc, new, etc. gesucht.."
gefunden habe ich nichts... ich weiß auch das ich in meinem code kein malloc, new etc verwende
Oft ist es hilfreich eigene Object Memory Zähler einzubauen.
Man kann dann zu bestimmten Zeitpunkten loggen welche Objekte existieren.versteh ich nicht ganz.. da ehlen mir wohl auch die grundlagen.. zumindest würde ich sagen, ich nutze kein objekte. nur variablen und zeiger...
ich glaube ich weiß warum der speicher ansteigt.. und zwar wegen den 5 connect versuchen bzw dem verbindungsaufbau...
5 deshalb weil es sein kann das ein serer zwar erreichbar aber überlastet ist..
oder? kann es daran liegen??
wenn ja, dann benutze non-blocking threads.. richtig?
mit non-blocking kann ich ja sagen. prüfe nach 15sec prüfe nach 30sec usw. richtig?oder kann ich nicht einfach den speicher der beim verbindungsaufbau verbraucht wieder zurücksetzen? das muss doch auch gehen? non-blocking threads sind mir zu kompliziert und eigentlich unnötig... ist nämlich egal ob das programm blockiert wird oder nicht...
//error handling der übersicht rausgemacht... //Winsock starten int connect_handle; SOCKET new_socket; SOCKADDR_IN addr; WSADATA wsa; connect_handle = WSAStartup(MAKEWORD(2,0),&wsa); //Socket definieren new_socket = socket(AF_INET,SOCK_STREAM,0); //addr auf null setzen memset(&addr, 0, sizeof(SOCKADDR_IN)); //und wieder füllen addr.sin_family = AF_INET; addr.sin_port = htons(80); addr.sin_addr.s_addr = inet_addr(serverip.c_str()); //Verbindung aufbauen bool connect_success = false; connect_handle = connect(new_socket, (SOCKADDR*)&addr, sizeof(SOCKADDR)); // TRY IT 5 TIMES ( MAYBE THERE'S A SLOW SERVERS... ) //************************************************ // 1. Connect Versuch if(connect_handle == SOCKET_ERROR) { //TRY IT AGAIN connect_handle = connect(new_socket, (SOCKADDR*)&addr, sizeof(SOCKADDR)); //************************************************ // 2. Connect Versuch if(connect_handle == SOCKET_ERROR) { //TRY IT AGAIN connect_handle = connect(new_socket, (SOCKADDR*)&addr, sizeof(SOCKADDR)); //************************************************ // 3. Connect Versuch if(connect_handle == SOCKET_ERROR) { //TRY IT AGAIN connect_handle = connect(new_socket, (SOCKADDR*)&addr, sizeof(SOCKADDR)); //************************************************ // 4. Connect Versuch if(connect_handle == SOCKET_ERROR) { //TRY IT AGAIN connect_handle = connect(new_socket, (SOCKADDR*)&addr, sizeof(SOCKADDR)); //************************************************ // 5. Connect Versuch if(connect_handle == SOCKET_ERROR) { closesocket(new_socket); WSACleanup(); } else { connect_success = true; } } else { connect_success = true; } } else { connect_success = true; } } else { connect_success = true; } } else { connect_success = true; }