jakobMedlem sedan aug. 200017 inlägg
Hej på er alla gurus.
Jag behöver lite hjälp här...
Jag har skrivit ett gäng rader kod som
ligger och pollar irc kanaler på det som skrivs och skriks. Allt detta stoppas in i en anonym hash med ett antal nycklar (varav en är en array). Datan i hashen läses sedan kontinuerligt och trycks in i en mysql databas.
Problemet är minnesutnyttjandet, det växer , och det växer fort.
Först trodde jag att det berodde på att hashen inte rensades / frigjorde det minne den snott åt sig, så jag tömde / undeffade etc den på alla möjliga sätt å vis - men detta hjälper inte !
Sen övervägde jag lokala variabler i loopar , så jag tog bort alt. definerade om alla - till ingen nytta.
Så , hur kan jag (utan att använda Dev::Leak för jag får inte lägga till sånt för min ISP) på smart sätt se vad det är som snor minne ?
(Lååång post).
Tacksam för alla tips och råd.
Mvh
Jakob
jakobMedlem sedan aug. 200017 inlägg
Hej igen,
som vanligt så är det alltid bra att göra en sista koll. Hittade faktiskt en array som "skenade" iväg. Så problemet verkar vara löst för tillfället.
Dock är jag fortfarande intresserad av era tekniker för att hitta minnesläckor odyl i Perl.
/ Jakob
RobbanMedlem sedan dec. 19992 272 inlägg
Finns inga minnesläckor i Perl. Perl tar hand om sådana saker automatiskt. När en variabel inte används längre så frigör Perl minnet som den variabeln tog upp. :)
Minnesläckor hör främst till C-relaterade språk som har pekare och där programmeraren måste allokera minne manuellt.
jakobMedlem sedan aug. 200017 inlägg
Lysande i så fall. Då kan jag inte skylla på det någe mer ;)
spangoMedlem sedan juni 20006 147 inlägg
Robban skrev:
Minnesläckor hör främst till C-relaterade språk som har pekare och där programmeraren måste allokera minne manuellt.
Nja, det går ju faktiskt utmärkt att skapa minnesluckor i skräphanterande språk, om man klamrar sig fast vid saker man inte längre behöver :) I Java kan man hitta sådant genom att kräva en "verbose garbage collection"; jag skulle gissa att Perl har något liknande.